• Share
  • Email
  • Embed
  • Like
  • Save
  • Private Content
Agilitaet gestern-heute-und-morgen
 

Agilitaet gestern-heute-und-morgen

on

  • 446 views

In diesem Artikel zum Schwerpunktthema „10 Jahre Agiles Manifest” lasse ich die vergangenen...

In diesem Artikel zum Schwerpunktthema „10 Jahre Agiles Manifest” lasse ich die vergangenen
Jahre Revue passieren und mache mir ein paar Gedanken darüber, wie es weitergehen könnte.
Ich möchte erzählen, wie die Agilität Einzug in die IT gehalten hat, wie es heute um die Agilität
steht und in welche Richtung sich das Thema weiterentwickeln könnte. Der Artikel deckt sicherlich nicht alle Aspekte vollständig ab und untersucht nicht streng wissenschaftlich alles bis ins
letzte Detail, aber ganz im Sinne der Agilität erhebe ich auch gar nicht diesen Anspruch.

Statistics

Views

Total Views
446
Views on SlideShare
446
Embed Views
0

Actions

Likes
0
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Agilitaet gestern-heute-und-morgen Agilitaet gestern-heute-und-morgen Document Transcript

    • mehr zum thema: schwerpunkt http://blog.codecentric.de/ der autor http://www.meettheexperts.de/ AGILITÄT GESTERN, HEUTE UND MORGEN: EINE BESTANDSAUFNAHME Uwe Friedrichsen (E-Mail: uwe.friedrichsen@codecentric.de) UND EIN BLICK IN DIE ZUKUNFT hat langjährige Erfahrungen als Architekt, Projektleiter und Berater. Aktuell ist er bei der codecentric AG für die strategische Entwicklung In diesem Artikel zum Schwerpunktthema „10 Jahre Agiles Manifest” lasse ich die vergangenen neuer Paradigmen und Technologien verantwort- Jahre Revue passieren und mache mir ein paar Gedanken darüber, wie es weitergehen könnte. lich und beschäftigt sich in dem Kontext insbeson- Ich möchte erzählen, wie die Agilität Einzug in die IT gehalten hat, wie es heute um die Agilität dere mit agilen Verfahren und neuen Architektur- steht und in welche Richtung sich das Thema weiterentwickeln könnte. Der Artikel deckt sicher- ansätzen. lich nicht alle Aspekte vollständig ab und untersucht nicht streng wissenschaftlich alles bis ins letzte Detail, aber ganz im Sinne der Agilität erhebe ich auch gar nicht diesen Anspruch. Als ich Anfang der 90er Jahre meine IT- martialischen Begriff „Methodenkrieg” Ähnlich wie das parallel in den 90er Begeisterung nach erfolgreich abgeschlos- bekannt. Einen Überblick gibt Abbildung 1. Jahren entstandene und populär geworde- senem Studium zum Beruf machte, waren Das Ende dieses „Krieges” wurde Mitte ne V-Modell zeichnet sich der RUP durch Structured Analysis (SA) und Structured der 90er Jahre mit der von Grady Booch einen sehr hohen Detaillierungs- und Design (SD) noch die vorherrschenden und Jim Rumbaugh entwickelten Unified Formalisierungsgrad aus. Man konnte Konzeptionsmethoden. Die seit Anfang der Method 0.8 eingeläutet. Kurz danach kam damit einfach alles regeln. Unterstützt wur- 70er Jahre immer weiter ausgefeilten dann noch Ivar Jacobson mit dazu und weil den diese Methoden von in der gleichen Prinzipien der Softwaretechnik bzw. des sich die „drei Amigos” offenbar doch nicht Zeit populär gewordenen Qualitäts- Software-Engineerings sorgten für einen so recht auf eine einheitliche Methode eini- standards wie DIN EN ISO 9000 und das ordentlich geregelten Rahmen. gen konnten, wurde aus der „Unified Capability Maturity Model (CMM). Method” kurzerhand die Unified Modeling Auch wenn viele Befürworter dieser Die Welt vor der Agilität Language (UML), die uns bis heute beglei- Methoden und Standards später immer Die IT-Welt war damals scheinbar in tet. Nach ein paar Jahren konnten sich die wieder betonten, dass man sie alle doch Ordnung. Allerdings säte die immer noch drei dann unter Führung von Philippe auch sehr leichtgewichtig verwenden könn- nicht überwundene Softwarekrise ihre Kruchten doch noch auf den Rational te, wurde das in der Regel nicht getan. Es Zweifel und der Siegeszug der PCs in den Unified Process (RUP) einigen. wurde geregelt, was das Zeug hielt. Zufall Büros dieser Welt seit Ende der 80er Jahre sorgte für Unruhe. Insbesondere die damit häufig verbundenen Ad-hoc-Entwick- lungen, die vielfach so erfolgreich waren, dass sie den klassischen Methoden den Schneid abzukaufen drohten, sorgten für einige Unruhe. Es brodelte, aber noch konnte man den Deckel drauf halten. Dazu kam, dass der Durchbruch der Objektorientierung zu Beginn der 90er Jahre nach neuen Konzeptionsmethoden verlang- te. Dieses Bedürfnis wurde übererfüllt, indem die Methoden gleich im Dutzend auf den Markt geworfen wurden: Peter Coad und Ed Yourdon, Sally Shlaer und Stephen Mellor, Rebecca Wirfs-Brock, Jim Odell, Grady Booch, James Rumbaugh, Ivar Jacobson, Donald Firesmith, Brain Henderson-Sellers und Ian Graham – um nur die wichtigsten Protagonisten zu nennen. Sie alle verbreiteten ihre Vorstellungen von der „einzig richtigen” Methode und Notation zur Konzeption und Erstellung objektorientierter Software- systeme. Diese Zeit wurde unter dem etwas Abb. 1: Überblick über objektorientierte Notationen und Methoden.2 / 2 011
    • schwerpunkt gab es nicht mehr, alles war im Prozess Ideale der 90er ausgedient hatten, egal ob Meeting aus Scrum und diverse XP- geregelt. Treiber für das Vorgehen waren man sie nun gut fand oder nicht. Techniken fanden ihren Einzug in unsere nicht die lästigen Kundenanforderungen, Zu Kent Beck gesellten sich immer mehr Projekte. sondern die Architektur. Das Schlagwort weitere Protagonisten, zum Beispiel Ken Aber es blieb immer ein Kompromiss. von der architekturgetriebenen Software- Schwaber und Jeff Sutherland, Alistair Das enge Prozesskorsett der beteiligten entwicklung war in aller Munde und die IT- Cockburn, Martin Fowler, Robert C. Unternehmen machte es praktisch unmög- Welt war wieder in Ordnung. Dass die Martin (besser bekannt als „Uncle Bob”) lich, durchgängig agil zu arbeiten. Softwarekrise noch immer nicht gelöst war, und Ward Cunningham, um nur ein paar Rückblickend betrachtet würde ich sagen, wurde geflissentlich ignoriert, ebenso wie zu nennen. Natürlich waren die meisten wir waren eher „pragmatisch agil” als die Tatsache, dass die ganzen Prozesse und von ihnen auch schon vorher aktiv und wirklich agil. Dennoch, wir taten, was wir Methoden offenbar in keinster Weise den bekannt, aber erst Kent Beck und sein XP konnten und was möglich war, und waren Projekterfolg sicherstellten, allerhöchstens sorgten – zumindest in Deutschland – für damit ziemlich erfolgreich. eine Vervielfachung der Kosten. die agile Initialzündung. Etwa zwei Jahre Nachhaltig geändert hat sich die Situa- Ich hatte zu der Zeit häufig ein schlechtes nach Kent Becks Keynote auf der OOP war tion für mich vor circa zweieinhalb Jahren. Gewissen, weil ich seit jeher eher einen es dann soweit: Die genannten Personen Mein damals neuer Arbeitgeber setzte nicht Hang zum Pragmatismus und nicht so sehr sowie eine Reihe weiterer agiler Pro- nur in der Projektdurchführung, sondern in zum Formalismus hatte und Dinge viel lie- tagonisten kamen im Februar 2001 für drei allen Bereichen auf Agilität. Das agile ber so machte, wie es erfolgversprechend Tage in einem Ski-Resort in Snowbird Wertesystem wurde so auch durchgängig in war, statt mich methodenkonform an die (Utah) zusammen und formulierten das der Interaktion mit den Kunden ange- zahlreichen Vorgaben und Templates zu „Agile Manifest” (vgl. [Agi]), das in diesem wandt: Die Verträge waren kurz, die halten. Das durfte man zu der Zeit zwar Jahr seinen zehnten Geburtstag feiert. Wichtigkeit der Kundenzufriedenheit nicht nicht laut sagen, aber solange man gute Interessanterweise hat das Manifest nur eine Management-Worthülse und eine Ergebnisse lieferte, wurde ein solches zumindest in meinem Umfeld lange nicht vertrauensvolle Zusammenarbeit mit dem Verhalten zumindest geduldet. die explosive Wirkung gezeigt wie Kent Kunden war wichtiger als die kurzfristige Becks XP-Feldzug. Das Manifest schlich Maximierung von Quartalszahlen. Gerade Auftritt der Agilisten sich eher durch die Hintertür in meine das Vertrauensthema war für mich eine In diesen trügerischen Frieden schlug die Projekte ein. Man kannte es, man schätzte sehr interessante Erfahrung. Ich kannte aus Agilität wie eine Bombe ein. Ich kann mich es, keiner widersprach dem darin Ge- meiner Vergangenheit „agile” Projekte, ein- noch immer sehr gut an die Keynote von schriebenen offen, aber es brauchte doch gebettet in perfekt ausformulierte Verträge, Kent Beck auf der OOP-Konferenz im Jahr relativ lange, bis aus diversen Lippen- die von Rechtsabteilungen nach allen 1999 erinnern, in der er die bis dahin eta- bekenntnissen ein Umdenken wurde. Es Regeln der Kunst auf Wasserdichte bezüg- blierten Methoden unerbittlich für geschei- mag auch daran liegen, dass ich zu der Zeit lich eines möglichen Prozesses mit dem tert erklärte und mit dem eXtreme primär mit Unternehmen zusammen arbei- Kunden getrimmt worden waren. Wie soll Programming (XP) einen radikalen Gegen- tete, die zumindest damals eher auf der ein Kunde einem glauben, dass man ver- entwurf zu den planungs- und architektur- „rechten Seite” des Manifests anzusiedeln trauensvoll und partnerschaftlich mit ihm zentrierten Methoden der 90er Jahre auf- waren, d. h. die eher einem traditionellen zusammenarbeiten will, wenn er so einen stellte: Weg mit den ewigen Planungen und Wertesystem verhaftet waren. Man konnte juristisch bis ins letzte Detail ausgefeilten ausufernden Konzeptionsphasen und statt- in dem Umfeld zwar ein paar ausgewählte Vertrag in die Hand gedrückt bekommt? dessen den Kunden und seine Wünsche, agile Praktiken verankern, aber ein Meine Kernerkenntnis aus der neuen Geschäftswert und lauffähige Software in Etablieren der agilen Ideen und Werte auf Vorgehensweise war, dass man zuerst auch das Zentrum des Interesses stellen. Diese breiter Ebene war (noch) nicht möglich. als Unternehmen an die agilen Werte glau- Forderung klang damals einfach unerhört. In unseren Projekten etablierten wir suk- ben muss, wenn man agile Projekte erfolg- Und dann auch noch so exotische Ideen wie zessive immer mehr agile Praktiken, da wir reich durchführen will. Im ersten Moment Pair Programming, den Kunden als Teil des wie alle anderen auch unter den gleichen mag einen zwar der gefühlte Kontroll- Teams begreifen, testgetriebene Software- Problemen litten, die auch die agilen verlust abschrecken, aber mal ganz ehrlich: entwicklung und lauffähige Software ab Protagonisten zum Entwickeln ihrer leicht- Was hat man letztlich von der zusätzlichen der ersten Iteration. Was war nur mit dem gewichtigen Methoden und zum Agilen Absicherung, wenn man ein Projekt erfolg- Mann los? Manifest geführt hatten. Wir entfernten so reich gegen die Wand gefahren hat? Wenn Ich weiß nicht mehr, was ich sonst noch viel Overhead wie möglich (was aufgrund man sich erst einmal mit einem Kunden vor auf der Konferenz gehört habe, denn die der umgebenden Management- und Gericht streitet, ist der Imageschaden per- Diskussionen, die ab der Keynote die Kundenvorgaben nicht immer einfach fekt, egal ob man gemäß Vertrag „recht” Konferenz beherrschten, haben alles andere war). Wir förderten direkte Kommuni- hat oder nicht. Da konzentriert man sich komplett überdeckt. So umstritten die kation und arbeiteten mit häufigen doch lieber darauf, dass der Kunde zufrie- Ideen von Kent Beck in ihrer damaligen Feedback-Zyklen, um sicherzustellen, dass den ist und (schnell) das bekommt, was er Radikalität auch waren: Jeder spürte, dass wir noch auf dem richtigen Weg sind. Wir braucht, und reduziert die ganzen sich etwas Grundlegendes geändert hatte. versuchten, die Anforderungen des Kunden Absicherungen auf ein Minimum. Noch wusste keiner, wohin es uns treiben in Abstimmung mit ihm zu priorisieren. Neben dem eingesparten Aufwand für würde, aber allen war klar, dass die alten Auch Ideen wie das tägliche Standup- letztlich unnütze Dinge hat das durchgän-44 45
    • schwerpunkt gig agile Vorgehen für mich noch einen Kanban wiederum schickt sich an, sich an agilen Werten getan hat. ganz anderen Nutzen: Es ist unfassbar, wie den Stellen zum agilen Standard zu mau- Ein weiteres großes Thema ist die Ein- viel mehr Spaß es macht, mit einem sern, an denen die Veränderung (Change), bindung agiler Methoden wie Scrum oder Kunden zusammenzuarbeiten, der einem die Scrum einfordert, zu radikal ist oder an Kanban in die Unternehmenssteuerung. vertraut und der davon überzeugt ist, dass denen Scrum aus anderen Gründen nicht Durch die neuen Methoden haben viele man gemeinsam daran arbeitet, dessen Ziel die probate Methode ist. Unternehmen das Gefühl, die von ihnen zu erreichen. Dieses Vertrauen zwischen Auch wenn mittlerweile jeder agil sein benötigten Controlling- und Steuerungs- Kunden und Dienstleister ist aber nur mög- will, sei es, weil man sich davon einen möglichkeiten gingen ihnen verloren. Sie lich, wenn man auch als Dienstleister die Wettbewerbsvorteil verspricht oder weil erhalten nicht mehr die notwendigen agilen Werte ganzheitlich adaptiert und man gehört hat, dass Scrum alle Probleme Kennzahlen – zumindest nicht, wenn sie die nicht ein „bisschen agil” versucht, aber lösen würde (was natürlich nicht stimmt), Methode isoliert betrachten. Deshalb ist es ansonsten weiterhin dem nicht agilen CYA so ist doch die große Lektion der vergange- wichtig, agile Methoden sinnvoll in ein (Cover Your Ass) frönt. nen Jahre, dass Agilität eine Menge Unternehmens-Controlling und eine Unter- Apropos Kunden: Sind diese denn nach Veränderung bedeutet. Eine Methode wie nehmens-Governance einzubinden. Dabei zehn Jahren Agilem Manifest so richtig Scrum oder Kanban ist schnell gelernt, müssen die (grundsätzlich sinnvollen) Ziele agil? Durch meine Dienstleister-Brille nicht umsonst passt Scrum auf einen des Controllings und der Governance betrachtet würde ich sagen: Nicht immer, Bierdeckel. Aber agil zu denken, das agile sichergestellt werden, die agilen Werte dür- aber es wird besser und besser. Mein Wertesystem zu verinnerlichen und danach fen aber trotzdem nicht aus den Augen ver- Eindruck ist, dass die agilen zu handeln, bedeutet für alle Beteiligte eine loren werden. Daher denke ich, dass der Erfolgsmeldungen die Kunden immer auf- große Veränderung, oftmals auch persön- weitere Erfolg der Agilität auch stark von geschlossener für Agilität machen. lich. Und das fällt nicht jedem leicht. guten Konzepten zur Einbindung in Trotzdem ist ein agiles Zusammenarbeiten Entsprechend hört man heute auf agilen Frameworks, wie z. B. „CobiT” (vgl. im Kunden-Dienstleister-Verhältnis noch Konferenzen immer weniger über [CobiT]), oder ein SOX-konformes lange nicht selbstverständlich. Ja, man Methoden und immer mehr über Change Controlling (vgl. [SOX]) abhängen wird. möchte Agilität, da geht doch alles viel Management und die menschliche Psyche schneller und billiger und flexibler ist es im Allgemeinen. Mittlerweile beschleicht ... und morgen dazu auch noch. Aber trotzdem möchte mich gelegentlich der Eindruck, dass sich Zum Abschluss möchte ich noch einen Blick man sich häufig noch nach guter Väter Sitte die agile Community vor lauter „Verän- in die „Kristallkugel” wagen: Wie wird es (und aktueller Prozessvorgabe) in alle derung” und „Motivation” teilweise in mit der Agilität weitergehen? So ganz genau Richtungen absichern und jedes Detail ziemlich esoterischen Gefilden verläuft, lässt sich das natürlich nicht voraussehen, geregelt wissen. Der Wandel fällt nicht aber letztlich sind genau diese Themen die aber ich bin überzeugt, dass Agilität nicht immer leicht. größte Herausforderung für eine richtige wie eine vorübergehende Modewelle ver- Das führt dann auch immer mal wieder Einführung von Agilität. Die Methoden schwinden wird. Natürlich gab und gibt es zu Rosinenpicken und so skurrilen Ideen funktionieren fast von allein, wenn man jede Menge Hype um den Begriff und die wie: „Wir möchten jederzeit alles ändern erst einmal den geistigen Schritt hin zu den Dienstleister und Produkthersteller verwen- können und zusätzlich am Ende alles so haben, wie es im Angebot spezifiziert wur- de” oder „Agil, wie wir vorgehen wollen, spezifizieren wir die Anforderungen erst während des Projekts, wollen aber trotz- dem einen Werkvertrag mit Festpreis, weil das unser Einkauf so will”. Da heißt es dann auf die agile Tugend der direkten Kommunikation mit dem Kunden zurück- zugreifen. In Summe lässt sich aber festhal- ten, dass die meisten Kunden auch in der Zusammenarbeit mit Dienstleistern immer stärker auf agile Prinzipien setzen und auch immer stärker die agilen Werte dahinter verstehen und verinnerlichen. Agilität heute ... Wo stehen wir heute, zehn Jahre nach dem Agilen Manifest? Ich denke, man kann sagen, dass Agilität mittlerweile Main- stream ist. Scrum ist bis in die obersten Führungsebenen allgegenwärtig, XP eben- so in den entwicklungsnäheren Kreisen. Abb. 2: Merkmale einfacher, komplizierter, komplexer und chaotischer Systeme.2 / 2 011
    • schwerpunkt den den Begriff „agil” geradezu inflationär. Natürlich gab und gibt es jede Menge Evangelisten bzw. mittlerweile eher Fundamentalisten, die dogmatisch auf die penible Einhaltung des geschriebenen Wortes pochen, egal ob es in der jeweiligen Situation sinnvoll ist oder nicht. Und natürlich sind Scrum, XP und Kanban nicht die Lösung für alle aktuellen Probleme in der IT. Tritt man aber einmal einen Schritt zurück, wird mei- ner Ansicht nach recht schnell klar, dass wir ohne Agilität dauerhaft gar nicht mehr über- lebensfähig sind. Warum so dramatisch? Wagt man einen Seitenblick in die Systemtheorie, dann wer- den dort häufig einfache, komplizierte, komplexe und chaotische Systeme unter- schieden (siehe auch Abbildung 2 und vgl. [Fri10]). Spannend ist hierbei die Unter - scheidung zwischen „kompliziert” und Abb. 3: Empfehlungen zum Management einfacher, komplizierter, komplexer und cha- „komplex”. Die Schwierigkeit komplexer otischer Systeme. Systeme steckt in der Dynamik der Beziehungen. Während es bei komplizier- ten Systemen hinreichend ist, die Einzelteile sehr viel gute Literatur dazu (vgl. beispiels- re spannende Impulse für die Weiter - und ihre Beziehungen untereinander einmal weise [Mal08], [Hon08], [Sno07]). Dort entwicklung der Agilität zu erwarten. zu verstehen, reicht das bei komplexen gibt es auch klare, wissenschaftlich belegte Zusammenfassend denke ich, dass wir Systemen nicht. Hier muss man immer wie- Empfehlungen für den Umgang mit unter- zehn Jahre nach dem Agilen Manifest der das Gesamtsystem (nicht die Einzel - schiedlichen Situationen (vereinfacht sind schon viel erreicht haben, um die heutigen teile) überprüfen und regelmäßige diese in Abbildung 3 zusammengefasst). komplexen Projekte besser und erfolgrei- Anpassungen am Vorgehen vornehmen, um Schaut man sich die Empfehlungen zum cher beherrschen zu können. Andererseits sich auf die sich über die Zeit verändernden Umgang mit komplexen Situationen an, sind wir aber noch lange nicht am Ziel der Vorgaben einzustellen. dann findet man dort: agilen Reise angekommen und haben noch Genau dafür benötigen wir Agilität. eine Menge Arbeit und Lernen vor uns. Ich Traditionelle Vorgehensweisen, die von den ■ systemische Analyse freue mich deshalb auf die nächsten Ideen der klassischen Softwaretechnik aus ■ evolutionäre Techniken zehn Jahre Agilität. ■ den frühen 70er Jahren geprägt sind, gehen ■ indirekte Steuerung von einem komplizierten Umfeld aus, das ■ kontinuierliches Lernen man mit einer „Teile-und-Herrsche”- ■ erhöhte Interaktion Literatur & Links Strategie beherrschen kann. Heutige Softwareentwicklungsprojekte sind aber Vergleicht man diese Empfehlungen mit [Agi] Manifesto for Agile Software Develop- meistens hochgradig komplex: Die den Prinzipien agiler Methoden, dann stellt ment, siehe http://www.agilemanifesto.org/ Zielvorgaben sind zu Beginn eines Projekts man fest, dass Agilität diese Empfehlungen [CobiT] CobiT (Control Objectives for eher unscharf, Meinungen und bis auf die systemische Analyse erfüllt. Information and Related Technology), siehe Anforderungen ändern sich dynamisch Anders ausgedrückt, ist Agilität eine http://www.isaca.org/cobit über den Projektverlauf, Projektergebnisse Möglichkeit, komplexe Systeme erfolgreich [Fri10] U. Friedrichsen, Agil oder ingenieurs- führen zu neuen, veränderten Anforderun- zu beherrschen. Und da die meisten heuti- mäßig?, in: Business Technology Magazin gen und der Wettbewerb liefert laufend gen IT-Projekte komplexe Systeme sind, bin 2/2010 neue Treiber für Veränderungen. ich davon überzeugt, dass Agilität bleiben [Hon08] J. Honegger, Vernetztes Denken und Für solche Umfelder liefern die traditio- wird – einfach weil wir sie benötigen, um Handeln in der Praxis, Versus Verlag AG 2008 nellen Verfahren keine Antworten, denn sie auch zukünftig in der immer komplexer [Mal08] F. Malik, Strategie des Managements können nur mit einfachen und komplizier- und schneller werdenden Geschäfts- und komplexer Systeme (10. Aufl.), Haupt Verlag ten Sachverhalten umgehen (die es in heuti- IT-Welt überhaupt überlebensfähig zu sein. 2008 gen Projekten natürlich ebenfalls noch Zum erfolgreichen Umgang mit [Sno07] D.J. Snowden, M.E. Boone, A gibt). Doch auf komplexe Umgebungen Komplexität fehlt – ergänzend zur Agilität Leaderss Framework for Decision making, in: muss man anders reagieren. In der – noch das systemische, das ganzheitliche Harvard Business Review November 2007 Managementlehre ist das schon lange Denken, aber auch auf dem Gebiet kann [SOX] Sarbanes-Oxley Act, siehe http://de.wiki- bekannt (wenn auch in der Praxis leider man mittlerweile eine Bewegung feststellen. pedia.org/wiki/Sarbanes-Oxley_Act häufig nicht umgesetzt) und es gibt auch Von der Seite sind meines Erachtens weite-46 47