2/2011

AGILITÄT GESTERN,

HEUTE UND MORGEN:

EINE BESTANDSAUFNAHME

UND EIN BLICK IN DIE ZUKUNFT

Ähnlich wie das parallel in den 90erJahren entstandene und populär geworde-ne V-Modell zeichnet sich der RUP durcheinen sehr hohen Detaillierungs- undForma lisierungsgrad aus. Man konntedamit einfach alles regeln. Unterstützt wur-den diese Methoden von in der gleichenZeit populär gewordenen Qualitäts -standards wie DIN EN ISO 9000 und dasCapability Maturity Model (CMM).

Auch wenn viele Befürworter dieserMethoden und Standards später immerwieder betonten, dass man sie alle dochauch sehr leichtgewichtig verwenden könn-te, wurde das in der Regel nicht getan. Eswurde geregelt, was das Zeug hielt. Zufall

In diesem Artikel zum Schwerpunktthema „10 Jahre Agiles Manifest” lasse ich die vergangenenJahre 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ätsteht und in welche Richtung sich das Thema weiterentwickeln könnte. Der Artikel deckt sicher-lich nicht alle Aspekte vollständig ab und untersucht nicht streng wissenschaftlich alles bis insletzte Detail, aber ganz im Sinne der Agilität erhebe ich auch gar nicht diesen Anspruch.

m e h r z u m t h e m a :http://blog.codecentric.de/http://www.meettheexperts.de/

martialischen Begriff „Methodenkrieg”bekannt. Einen Überblick gibt Abbildung 1.

Das Ende dieses „Krieges” wurde Mitteder 90er Jahre mit der von Grady Boochund Jim Rumbaugh entwickelten UnifiedMethod 0.8 eingeläutet. Kurz danach kamdann noch Ivar Jacobson mit dazu und weilsich die „drei Amigos” offenbar doch nichtso recht auf eine einheitliche Methode eini-gen konnten, wurde aus der „UnifiedMethod” kurzerhand die Unified ModelingLanguage (UML), die uns bis heute beglei-tet. Nach ein paar Jahren konnten sich diedrei dann unter Führung von PhilippeKruchten doch noch auf den RationalUnified Process (RUP) einigen.

Als ich Anfang der 90er Jahre meine IT-Begeisterung nach erfolgreich abgeschlos-senem Studium zum Beruf machte, warenStructured Analysis (SA) und StructuredDesign (SD) noch die vorherrschendenKonzeptionsmethoden. Die seit Anfang der70er Jahre immer weiter ausgefeiltenPrinzipien der Softwaretechnik bzw. desSoftware-Engineerings sorgten für einenordentlich geregelten Rahmen.

Die Welt vor der Agilität

Die IT-Welt war damals scheinbar inOrdnung. Allerdings säte die immer nochnicht überwundene Softwarekrise ihreZweifel und der Siegeszug der PCs in denBüros dieser Welt seit Ende der 80er Jahresorgte für Unruhe. Insbesondere die damithäufig verbundenen Ad-hoc-Entwick -lungen, die vielfach so erfolgreich waren,dass sie den klassischen Methoden denSchneid abzukaufen drohten, sorgten füreinige Unruhe. Es brodelte, aber nochkonnte man den Deckel drauf halten.

Dazu kam, dass der Durchbruch derObjektorientierung zu Beginn der 90er Jahrenach neuen Konzeptionsmethoden verlang-te. Dieses Bedürfnis wurde übererfüllt, indemdie Methoden gleich im Dutzend auf denMarkt geworfen wurden: Peter Coad und EdYourdon, Sally Shlaer und Stephen Mellor,Rebecca Wirfs-Brock, Jim Odell, GradyBooch, James Rum baugh, Ivar Jacobson,Donald Firesmith, Brain Henderson-Sellersund Ian Graham – um nur die wichtigstenProtagonisten zu nennen. Sie alle verbreitetenihre Vorstel lungen von der „einzig richtigen”Methode und Notation zur Konzeption undErstellung objektorientierter Software -systeme. Diese Zeit wurde unter dem etwas

schwerpunk t

Uwe Friedrichsen

(E-Mail: uwe.friedrichsen@codecentric.de)

hat langjährige Erfahrungen als Architekt,

Projektleiter und Berater. Aktuell ist er bei der

codecentric AG für die strategische Entwicklung

neuer Paradigmen und Technologien verantwort-

lich und beschäftigt sich in dem Kontext insbeson-

dere mit agilen Verfahren und neuen Architektur -

ansätzen.

der au tor

Abb. 1: Überblick über objektorientierte Notationen und Methoden.

44 45

schwerpunk t

gab es nicht mehr, alles war im Prozessgeregelt. Treiber für das Vorgehen warennicht die lästigen Kundenanforderungen,sondern die Architektur. Das Schlagwortvon der architekturgetriebenen Software -ent wick lung war in aller Munde und die IT-Welt war wieder in Ordnung. Dass dieSoftwarekrise noch immer nicht gelöst war,wurde geflissentlich ignoriert, ebenso wiedie Tatsache, dass die ganzen Prozesse undMethoden offenbar in keinster Weise denProjekterfolg sicherstellten, allerhöchstenseine Vervielfachung der Kosten.

Ich hatte zu der Zeit häufig ein schlechtesGewissen, weil ich seit jeher eher einenHang zum Pragmatismus und nicht so sehrzum Formalismus hatte und Dinge viel lie-ber so machte, wie es erfolgversprechendwar, statt mich methodenkonform an diezahlreichen Vorgaben und Templates zuhalten. Das durfte man zu der Zeit zwarnicht laut sagen, aber solange man guteErgebnisse lieferte, wurde ein solchesVerhalten zumindest geduldet.

Auftritt der Agilisten

In diesen trügerischen Frieden schlug dieAgilität wie eine Bombe ein. Ich kann michnoch immer sehr gut an die Keynote vonKent Beck auf der OOP-Konferenz im Jahr1999 erinnern, in der er die bis dahin eta-blierten Methoden unerbittlich für geschei-tert erklärte und mit dem eXtremeProgramming (XP) einen radikalen Gegen -ent wurf zu den planungs- und architektur-zentrierten Methoden der 90er Jahre auf-stellte: Weg mit den ewigen Planungen undausufernden Konzeptionsphasen und statt-dessen den Kunden und seine Wünsche,Geschäftswert und lauffähige Software indas Zentrum des Interesses stellen. DieseForderung klang damals einfach unerhört.Und dann auch noch so exotische Ideen wiePair Programming, den Kunden als Teil desTeams begreifen, testgetriebene Software -ent wicklung und lauffähige Software abder ersten Iteration. Was war nur mit demMann los?

Ich weiß nicht mehr, was ich sonst nochauf der Konferenz gehört habe, denn dieDiskussionen, die ab der Keynote dieKonferenz beherrschten, haben alles anderekomplett überdeckt. So umstritten dieIdeen von Kent Beck in ihrer damaligenRadikalität auch waren: Jeder spürte, dasssich etwas Grundlegendes geändert hatte.Noch wusste keiner, wohin es uns treibenwürde, aber allen war klar, dass die alten

Ideale der 90er ausgedient hatten, egal obman sie nun gut fand oder nicht.

Zu Kent Beck gesellten sich immer mehrweitere Protagonisten, zum Beispiel KenSchwaber und Jeff Sutherland, AlistairCockburn, Martin Fowler, Robert C.Martin (besser bekannt als „Uncle Bob”)und Ward Cunningham, um nur ein paarzu nennen. Natürlich waren die meistenvon ihnen auch schon vorher aktiv undbekannt, aber erst Kent Beck und sein XPsorgten – zumindest in Deutschland – fürdie agile Initialzündung. Etwa zwei Jahrenach Kent Becks Keynote auf der OOP wares dann soweit: Die genannten Personensowie eine Reihe weiterer agiler Pro -tagonisten kamen im Februar 2001 für dreiTage in einem Ski-Resort in Snowbird(Utah) zusammen und formulierten das„Agile Manifest” (vgl. [Agi]), das in diesemJahr seinen zehnten Geburtstag feiert.

Interessanterweise hat das Manifestzumindest in meinem Umfeld lange nichtdie explosive Wirkung gezeigt wie KentBecks XP-Feldzug. Das Manifest schlichsich eher durch die Hintertür in meineProjekte ein. Man kannte es, man schätztees, keiner widersprach dem darin Ge -schriebenen offen, aber es brauchte dochrelativ lange, bis aus diversen Lippen -bekenntnissen ein Umdenken wurde. Esmag auch daran liegen, dass ich zu der Zeitprimär mit Unternehmen zusammen arbei-tete, die zumindest damals eher auf der„rechten Seite” des Manifests anzusiedelnwaren, d. h. die eher einem traditionellenWertesystem verhaftet waren. Man konntein dem Umfeld zwar ein paar ausgewählteagile Praktiken verankern, aber einEtablieren der agilen Ideen und Werte aufbreiter Ebene war (noch) nicht möglich.

In unseren Projekten etablierten wir suk-zessive immer mehr agile Praktiken, da wirwie alle anderen auch unter den gleichenProblemen litten, die auch die agilenProtagonisten zum Entwickeln ihrer leicht-gewichtigen Methoden und zum AgilenManifest geführt hatten. Wir entfernten soviel Overhead wie möglich (was aufgrundder umgebenden Management- undKundenvorgaben nicht immer einfachwar). Wir förderten direkte Kommuni -kation und arbeiteten mit häufigenFeedback-Zyklen, um sicherzustellen, dasswir noch auf dem richtigen Weg sind. Wirversuchten, die Anforderungen des Kundenin Abstimmung mit ihm zu priorisieren.Auch Ideen wie das tägliche Standup-

Meeting aus Scrum und diverse XP-Techniken fanden ihren Einzug in unsereProjekte.

Aber es blieb immer ein Kompromiss.Das enge Prozesskorsett der beteiligtenUnternehmen machte es praktisch unmög-lich, durchgängig agil zu arbeiten.Rückblickend betrachtet würde ich sagen,wir waren eher „pragmatisch agil” alswirklich agil. Dennoch, wir taten, was wirkonnten und was möglich war, und warendamit ziemlich erfolgreich.

Nachhaltig geändert hat sich die Situa -tion für mich vor circa zweieinhalb Jahren.Mein damals neuer Arbeitgeber setzte nichtnur in der Projektdurchführung, sondern inallen Bereichen auf Agilität. Das agileWertesystem wurde so auch durchgängig inder Interaktion mit den Kunden ange-wandt: Die Verträge waren kurz, dieWichtigkeit der Kundenzufriedenheit nichtnur eine Management-Worthülse und einevertrauensvolle Zusammenarbeit mit demKunden war wichtiger als die kurzfristigeMaximierung von Quartalszahlen. Geradedas Vertrauensthema war für mich einesehr interessante Erfahrung. Ich kannte ausmeiner Vergangenheit „agile” Projekte, ein-gebettet in perfekt ausformulierte Verträge,die von Rechtsabteilungen nach allenRegeln der Kunst auf Wasserdichte bezüg-lich eines möglichen Prozesses mit demKunden getrimmt worden waren. Wie sollein Kunde einem glauben, dass man ver-trauensvoll und partnerschaftlich mit ihmzusammenarbeiten will, wenn er so einenjuristisch bis ins letzte Detail ausgefeiltenVertrag in die Hand gedrückt bekommt?

Meine Kernerkenntnis aus der neuenVorgehensweise war, dass man zuerst auchals Unternehmen an die agilen Werte glau-ben muss, wenn man agile Projekte erfolg-reich durchführen will. Im ersten Momentmag einen zwar der gefühlte Kontroll -verlust abschrecken, aber mal ganz ehrlich:Was hat man letztlich von der zusätzlichenAbsicherung, wenn man ein Projekt erfolg-reich gegen die Wand gefahren hat? Wennman sich erst einmal mit einem Kunden vorGericht streitet, ist der Imageschaden per-fekt, egal ob man gemäß Vertrag „recht”hat oder nicht. Da konzentriert man sichdoch lieber darauf, dass der Kunde zufrie-den ist und (schnell) das bekommt, was erbraucht, und reduziert die ganzenAbsicherungen auf ein Minimum.

Neben dem eingesparten Aufwand fürletztlich unnütze Dinge hat das durchgän-

2/2011

schwerpunk t

agilen Werten getan hat.Ein weiteres großes Thema ist die Ein -

bindung agiler Methoden wie Scrum oderKanban in die Unternehmenssteuerung.Durch die neuen Methoden haben vieleUnternehmen das Gefühl, die von ihnenbenötigten Controlling- und Steuerungs -mög lichkeiten gingen ihnen verloren. Sieerhalten nicht mehr die notwendigenKennzahlen – zumindest nicht, wenn sie dieMethode isoliert betrachten. Deshalb ist eswichtig, agile Methoden sinnvoll in einUnternehmens-Controlling und eine Unter -nehmens-Governance einzubinden. Dabeimüssen die (grundsätzlich sinnvollen) Zieledes Controllings und der Governancesichergestellt werden, die agilen Werte dür-fen aber trotzdem nicht aus den Augen ver-loren werden. Daher denke ich, dass derweitere Erfolg der Agilität auch stark vonguten Konzepten zur Einbindung inFrameworks, wie z. B. „CobiT” (vgl.[CobiT]), oder ein SOX-konformesControlling (vgl. [SOX]) abhängen wird.

... und morgen

Zum Abschluss möchte ich noch einen Blickin die „Kristallkugel” wagen: Wie wird esmit der Agilität weitergehen? So ganz genaulässt sich das natürlich nicht voraussehen,aber ich bin überzeugt, dass Agilität nichtwie eine vorübergehende Modewelle ver-schwinden wird. Natürlich gab und gibt esjede Menge Hype um den Begriff und dieDienstleister und Produkt hersteller verwen-

Kanban wiederum schickt sich an, sich anden Stellen zum agilen Standard zu mau-sern, an denen die Veränderung (Change),die Scrum einfordert, zu radikal ist oder andenen Scrum aus anderen Gründen nichtdie probate Methode ist.

Auch wenn mittlerweile jeder agil seinwill, sei es, weil man sich davon einenWettbewerbsvorteil verspricht oder weilman gehört hat, dass Scrum alle Problemelösen würde (was natürlich nicht stimmt),so ist doch die große Lektion der vergange-nen Jahre, dass Agilität eine MengeVeränderung bedeutet. Eine Methode wieScrum oder Kanban ist schnell gelernt,nicht umsonst passt Scrum auf einenBierdeckel. Aber agil zu denken, das agileWertesystem zu verinnerlichen und danachzu handeln, bedeutet für alle Beteiligte einegroße Veränderung, oftmals auch persön-lich. Und das fällt nicht jedem leicht.

Entsprechend hört man heute auf agilenKonferenzen immer weniger überMethoden und immer mehr über ChangeManagement und die menschliche Psycheim Allgemeinen. Mittlerweile beschleichtmich gelegentlich der Eindruck, dass sichdie agile Community vor lauter „Verän -derung” und „Motivation” teilweise inziemlich esoterischen Gefilden verläuft,aber letztlich sind genau diese Themen diegrößte Herausforderung für eine richtigeEinführung von Agilität. Die Methodenfunktionieren fast von allein, wenn manerst einmal den geistigen Schritt hin zu den

gig agile Vorgehen für mich noch einenganz anderen Nutzen: Es ist unfassbar, wieviel mehr Spaß es macht, mit einemKunden zusammenzuarbeiten, der einemvertraut und der davon überzeugt ist, dassman gemeinsam daran arbeitet, dessen Zielzu erreichen. Dieses Vertrauen zwischenKunden und Dienstleister ist aber nur mög-lich, wenn man auch als Dienstleister dieagilen Werte ganzheitlich adaptiert undnicht ein „bisschen agil” versucht, aberansonsten weiterhin dem nicht agilen CYA(Cover Your Ass) frönt.

Apropos Kunden: Sind diese denn nachzehn Jahren Agilem Manifest so richtigagil? Durch meine Dienstleister-Brillebetrachtet würde ich sagen: Nicht immer,aber es wird besser und besser. MeinEindruck ist, dass die agilenErfolgsmeldungen die Kunden immer auf-geschlossener für Agilität machen.Trotzdem ist ein agiles Zusam menarbeitenim Kunden-Dienstleister-Verhältnis nochlange nicht selbstverständlich. Ja, manmöchte Agilität, da geht doch alles vielschneller und billiger und flexibler ist esdazu auch noch. Aber trotzdem möchteman sich häufig noch nach guter Väter Sitte(und aktueller Prozess vorgabe) in alleRichtungen absichern und jedes Detailgeregelt wissen. Der Wandel fällt nichtimmer leicht.

Das führt dann auch immer mal wiederzu Rosinenpicken und so skurrilen Ideenwie: „Wir möchten jederzeit alles ändernkönnen und zusätzlich am Ende alles sohaben, wie es im Angebot spezifiziert wur-de” oder „Agil, wie wir vorgehen wollen,spezifizieren wir die Anforderungen erstwährend des Projekts, wollen aber trotz-dem einen Werkvertrag mit Festpreis, weildas unser Einkauf so will”. Da heißt esdann auf die agile Tugend der direktenKommunikation mit dem Kunden zurück -zugreifen. In Summe lässt sich aber festhal-ten, dass die meisten Kunden auch in derZusammenarbeit mit Dienstleistern immerstärker auf agile Prinzipien setzen und auchimmer stärker die agilen Werte dahinterverstehen und verinnerlichen.

Agilität heute ...

Wo stehen wir heute, zehn Jahre nach demAgilen Manifest? Ich denke, man kannsagen, dass Agilität mittlerweile Main -stream ist. Scrum ist bis in die oberstenFührungsebenen allgegenwärtig, XP eben-so in den entwicklungsnäheren Kreisen. Abb. 2: Merkmale einfacher, komplizierter, komplexer und chaotischer Systeme.

46 47

schwerpunk t

den den Begriff „agil” geradezu inflationär.Natürlich gab und gibt es jede MengeEvangelisten bzw. mittlerweile eherFundamentalisten, die dogmatisch auf diepenible Einhaltung des geschriebenen Wortespochen, egal ob es in der jeweiligen Situationsinnvoll ist oder nicht. Und natürlich sindScrum, XP und Kanban nicht die Lösung füralle aktuellen Probleme in der IT. Tritt manaber einmal einen Schritt zurück, wird mei-ner Ansicht nach recht schnell klar, dass wirohne Agilität dauerhaft gar nicht mehr über-lebensfähig sind.

Warum so dramatisch? Wagt man einenSeitenblick 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„komplex”. Die Schwierigkeit komplexerSysteme steckt in der Dynamik derBeziehungen. Während es bei komplizier-ten Systemen hinreichend ist, die Einzelteileund ihre Beziehungen untereinander einmalzu verstehen, reicht das bei komplexenSystemen nicht. Hier muss man immer wie-der das Gesamtsystem (nicht die Einzel -teile) überprüfen und regelmäßigeAnpassungen am Vorgehen vornehmen, umsich auf die sich über die Zeit veränderndenVorgaben einzustellen.

Genau dafür benötigen wir Agilität.Tradi tionelle Vorgehensweisen, die von denIdeen der klassischen Softwaretechnik ausden frühen 70er Jahren geprägt sind, gehenvon einem komplizierten Umfeld aus, dasman mit einer „Teile-und-Herrsche”-Strategie beherrschen kann. HeutigeSoftwareentwicklungsprojekte sind abermeistens hochgradig komplex: DieZielvorgaben sind zu Beginn eines Projektseher unscharf, Meinungen undAnforderungen ändern sich dynamischüber den Projektverlauf, Projektergebnisseführen zu neuen, veränderten Anforderun -gen und der Wettbewerb liefert laufendneue Treiber für Veränderungen.

Für solche Umfelder liefern die traditio-nellen Verfahren keine Antworten, denn siekönnen nur mit einfachen und komplizier-ten Sachverhalten umgehen (die es in heuti-gen Projekten natürlich ebenfalls nochgibt). Doch auf komplexe Umgebungenmuss man anders reagieren. In derManagementlehre ist das schon langebekannt (wenn auch in der Praxis leiderhäufig nicht umgesetzt) und es gibt auch

sehr viel gute Literatur dazu (vgl. beispiels-weise [Mal08], [Hon08], [Sno07]). Dortgibt es auch klare, wissenschaftlich belegteEmpfehlungen für den Umgang mit unter-schiedlichen Situationen (vereinfacht sinddiese in Abbildung 3 zusammengefasst).Schaut man sich die Empfehlungen zumUmgang mit komplexen Situationen an,dann findet man dort:

■ systemische Analyse■ evolutionäre Techniken■ indirekte Steuerung■ kontinuierliches Lernen■ erhöhte Interaktion

Vergleicht man diese Empfehlungen mitden Prinzipien agiler Methoden, dann stelltman fest, dass Agilität diese Empfehlungenbis auf die systemische Analyse erfüllt.Anders ausgedrückt, ist Agilität eineMöglichkeit, komplexe Systeme erfolgreichzu beherrschen. Und da die meisten heuti-gen IT-Projekte komplexe Systeme sind, binich davon überzeugt, dass Agilität bleibenwird – einfach weil wir sie benötigen, umauch zukünftig in der immer komplexerund schneller werdenden Geschäfts- undIT-Welt überhaupt überlebensfähig zu sein.

Zum erfolgreichen Umgang mitKomplexität fehlt – ergänzend zur Agilität– noch das systemische, das ganzheitlicheDenken, aber auch auf dem Gebiet kannman mittlerweile eine Bewegung feststellen.Von der Seite sind meines Erachtens weite-

re spannende Impulse für die Weiter -entwicklung der Agilität zu erwarten.Zusammenfassend denke ich, dass wir zehn Jahre nach dem Agilen Manifestschon viel erreicht haben, um die heutigenkomplexen Projekte besser und erfolgrei-cher beherrschen zu können. Andererseitssind wir aber noch lange nicht am Ziel deragilen Reise angekommen und haben nocheine Menge Arbeit und Lernen vor uns. Ichfreue mich deshalb auf die nächsten zehn Jahre Agilität. ■

Abb. 3: Empfehlungen zum Management einfacher, komplizierter, komplexer und cha-otischer Systeme.

Literatur & Links

[Agi] Manifesto for Agile Software Develop -

ment, siehe http://www.agilemanifesto.org/

[CobiT] CobiT (Control Objectives for

Information and Related Technology), siehe

http://www.isaca.org/cobit

[Fri10] U. Friedrichsen, Agil oder ingenieurs -

mäßig?, in: Business Technology Magazin

2/2010

[Hon08] J. Honegger, Vernetztes Denken und

Handeln in der Praxis, Versus Verlag AG 2008

[Mal08] F. Malik, Strategie des Managements

komplexer Systeme (10. Aufl.), Haupt Verlag

2008

[Sno07] D.J. Snowden, M.E. Boone, A

Leaders's Framework for Decision making, in:

Harvard Business Review November 2007

[SOX] Sarbanes-Oxley Act, siehe http://de.wiki-

pedia.org/wiki/Sarbanes-Oxley_Act