Agile Ent­wick­lung: Das steckt dahinter!

Die agile Software-Ent­wick­lung ist nun schon seit längerem nichts Neues mehr und auch in anderen Ar­beits­be­rei­chen haben sich agile Methoden längst etabliert. Für viele ist der Begriff aber immer noch nicht ganz klar. Ab wann handelt man in seinem Un­ter­neh­men nach agilen Aspekten? Und was ist ei­gent­lich doch nur tra­di­tio­nel­le Arbeit, die fälsch­li­cher­wei­se mit einem Buzzword auf­ge­wer­tet werden soll?

Bereits in 1990er-Jahren haben Teams von Software-Ent­wick­lern an­ge­fan­gen, mit Methoden zu arbeiten, die man heut­zu­ta­ge zum Agile Software De­ve­lo­p­ment zählen kann. Bis zum Ende des 20. Jahr­hun­derts setzten ver­schie­de­ne Software-Ent­wick­ler und Teams vieles daran, Pro­gram­mier­ar­beit leicht­ge­wich­ti­ger zu gestalten, und so wurde die Methode vor allem unter dem Stichwort „light­weight“ bekannt. In dieser Zeit sind auch die Methoden Scrum und Kanban ent­stan­den, die man damals noch nicht unter dem Begriff „agile Pro­dukt­ent­wick­lung“ zu­sam­men­fas­sen konnte, denn diesen Ausdruck gab es noch nicht.

2001 schließ­lich fand eine klare Zäsur statt: Im heute als Snowbird-Meeting bekannten Zu­sam­men­tref­fen (nach dem Namen des Ski-Resorts in Utah, in dem das Treffen stattfand) haben 17 Ent­wick­ler das Agile Manifest erstellt: Sie alle brachten ihre je­wei­li­gen Er­fah­run­gen im Software De­ve­lo­p­ment und im Umgang mit Teams zusammen, fanden Lösungen, legten Prin­zi­pi­en fest und fassten alles unter dem Begriff zusammen, der heute gleich­be­deu­tend mit moderner Ar­beits­wei­se ist – agile Software-Ent­wick­lung.

Als man zunächst im Kleinen anfing, die Methoden der Software-Ent­wick­lung zu hin­ter­fra­gen und schließ­lich mit dem Agilen Manifest versuchte, eine neue Art der Pro­jekt­ar­beit zu eta­blie­ren, hatte man immer das Ziel, flexibler, kreativer und pro­duk­ti­ver agieren zu können. Statt wie bei tra­di­tio­nel­len Methoden – z. B. dem Was­ser­fall­mo­dell – einem durch­ge­plan­ten, linearen und bü­ro­kra­ti­schen Prozess zu folgen, bricht man das Projekt auf. Dafür misst die agile Software-Ent­wick­lung dem Team der Pro­gram­mie­rer sehr viel mehr Ver­ant­wor­tung zu.

Zu­sätz­lich ver­ab­schie­det man sich mehr oder weniger von riesigen Projekten: Statt Monate oder gar Jahre an der Fertigung eines Produkts zu sitzen, ver­brin­gen agile Teams nur wenige Wochen in einer Ar­beits­pha­se. Am Ende steht ein fertiges Produkt, ein Update oder ein Pro­gramm­teil, der dem Kunden prä­sen­tiert werden kann. Damit dies gelingt, hat man sich im Agilen Manifest auf zwölf Prin­zi­pi­en und vier Werte geeinigt.

Die Werte der agilen Software-Ent­wick­lung geben den Fokus vor, den Teams bei der Ent­wick­lungs­ar­beit immer im Auge behalten sollten. Sie sind als Ge­gen­satz­paa­re notiert; beide Aspekte sind wichtig, doch der eine wird in der agilen Ent­wick­lung dem anderen über­ge­ord­net:

• In­di­vi­du­als and in­ter­ac­tions over processes and tools: Die be­tei­lig­ten Personen und ihre Zu­sam­men­ar­beit un­ter­ein­an­der sind wichtiger als die Frage nach einem be­stimm­ten Prozess oder Werkzeug.
• Working software over com­pre­hen­si­ve do­cu­men­ta­ti­on: Im Mit­tel­punkt steht ein funk­tio­nie­ren­des End­pro­dukt. Die Do­ku­men­ta­ti­on der Arbeit ist dagegen zweit­ran­gig.
• Customer col­la­bo­ra­ti­on over contract nego­tia­ti­on: Agile Pro­dukt­ent­wick­lung ist mehr darauf bedacht, dem Kunden und seinen An­for­de­run­gen ent­ge­gen­zu­kom­men, als Ver­trags­ver­hand­lun­gen zu führen.
• Re­spon­ding to change over following a plan: Man geht davon aus, dass Software-Ent­wick­lung auf ständige Ver­än­de­run­gen eingehen muss. Dabei kann es er­for­der­lich sein, einen vorher fest­ge­leg­ten Plan um­zu­wer­fen.

Diese Werte sind wie ein Mantra zu verstehen. Sie bieten keine genaue Anleitung, sondern sind dazu da, Ent­wick­lern immer wieder die wirklich wichtigen Aspekte bei der Pro­duk­ti­on ins Ge­dächt­nis zu bringen: Arbeitet im Team; fo­kus­siert euch auf die Software; denkt an den Kunden; seid flexibel für Än­de­run­gen! Alle anderen, zwei­fels­oh­ne ebenfalls wichtigen Facetten haben sich diesen Punkten un­ter­zu­ord­nen.

Mehr in die Richtung von konkreten An­wei­sun­gen gehen die zwölf Prin­zi­pi­en des Agilen Manifests. Diese liefern zu­sätz­li­che In­for­ma­tio­nen und weiten die Ideen der Werte aus. Doch auch hierbei handelt es sich nicht um eine tat­säch­li­che Anleitung – diese will das Manifest nicht liefern. Die Prin­zi­pi­en sind weit gefasst und dienen dazu, agile von nichta­gi­len Methoden ab­zu­gren­zen.

• Kun­den­zu­frie­den­heit: Durch frühe und stetige Ver­öf­fent­li­chung – im Sinne von Con­ti­nuous Delivery – soll der Kunde jederzeit zufrieden gestellt werden.
   
• Fle­xi­bi­li­tät: Agile Teams bewerten Än­de­run­gen grund­sätz­lich als etwas Positives, selbst wenn diese erst spät im Ent­wick­lungs­pro­zess auf­tau­chen. Folgt man dem Agilen Manifest, bringen An­pas­sun­gen an geänderte An­for­de­run­gen dem Kunden einen Wett­be­werbs­vor­teil.
   
• Aus­lie­fe­rung: Funk­ti­ons­tüch­ti­ge Software wird direkt aus­ge­lie­fert, und zwar in einem Zeit­rah­men von wenigen Wochen oder Monaten. Ein kürzerer Zeit­rah­men ist immer will­kom­men.
   
• Zu­sam­men­ar­beit: Ent­wick­ler und Kollegen aus dem Sales-Bereich müssen eng mit­ein­an­der zu­sam­men­ar­bei­ten. Das Agile Manifest sieht tägliche Meetings vor.
   
• Un­ter­stüt­zung: Damit mo­ti­vier­te In­di­vi­du­en und kreative Teams gut arbeiten können, muss auch die Umgebung für sie stimmen. Dazu brauchen sie Un­ter­stüt­zung von anderen und vor allem auch das Vertrauen von Vor­ge­setz­ten.
   
• Ge­sprächs­kul­tur: Um In­for­ma­tio­nen möglichst effektiv und ohne Miss­ver­ständ­nis­se zu über­tra­gen, eignet sich die direkte Kom­mu­ni­ka­ti­on am besten. Von Angesicht zu Angesicht mit­ein­an­der zu sprechen, er­mög­licht Nach­fra­gen und vermeidet Fehl­schlüs­se.
   
• Erfolge: Der Erfolg eines Teams lässt sich vor allem an der Ver­öf­fent­li­chung funk­ti­ons­tüch­ti­ger Software messen.
   
• Nach­hal­tig­keit: Es ist sinnvoll, dass die Ent­wick­lung gleich­mä­ßig fortläuft. Dabei sollen alle Be­tei­lig­ten und nicht nur die Ent­wick­ler weiterhin an Ver­öf­fent­li­chun­gen arbeiten.
   
• Qualität: Ent­wick­ler sollen zudem immer darauf achten, dass ihre Produkte sowohl aus tech­ni­scher Sicht als auch in Bezug auf das Design höchsten An­sprü­chen genügen.
   
• Ein­fach­heit: Man sollte die Arbeit so einfach gestalten wie nur möglich. Alles Ver­meid­ba­re weg­zu­las­sen, führt zu einem schlan­ke­ren Prozess und somit zu besseren Er­geb­nis­sen.
   
• Or­ga­ni­sa­ti­on: Nur wenn man Teams er­mög­licht, sich selbst zu or­ga­ni­sie­ren, kann man au­ßer­ge­wöhn­li­che Er­geb­nis­se erwarten.
   
• Re­tro­spek­ti­ve: Ein wichtiger Aspekt der agilen Software-Ent­wick­lung ist, sich selbst jederzeit zu hin­ter­fra­gen. Um die Arbeit des Teams stetig zu ver­bes­sern, ist es wichtig, dass die Mit­glie­der sich re­gel­mä­ßig über die Ar­beits­wei­se aus­tau­schen und ihr Vorgehen daraufhin anpassen.

Im Umfeld von agiler Software-Ent­wick­lung haben sich einige Praktiken etabliert, mit denen man den agilen Ansatz in seinem Team oder Un­ter­neh­men umsetzen kann – „agile Ent­wick­lung“ bildet dafür nur den Über­be­griff. Viele dieser Techniken findet man in den Aus­prä­gun­gen der agilen Software-Ent­wick­lung, z. B. bei Scrum, Kanban, Extreme Pro­gramming, Feature Driven De­ve­lo­p­ment, Behaviour Driven De­ve­lo­p­ment oder Chrystal.

• Backlog: Die Idee eines Katalogs, in dem alle Aufgaben gesammelt werden, die noch erledigt werden müssen, an denen aber derzeit nicht ge­ar­bei­tet wird, ist kenn­zeich­nend für die agile Vor­ge­hens­wei­se. Der Grund dafür liegt in den kurzen Ar­beits­pha­sen. Statt sich mit mehreren Aufgaben gleich­zei­tig zu befassen oder in einem großen Plan jeder Aufgabe eine feste Zeit­span­ne zu­zu­ord­nen, hat man einen flexiblen Pool im Hin­ter­grund. Aus diesem kann das Team die nächste Aufgabe auswählen.
   
• Re­tro­spek­ti­ven: Die re­gel­mä­ßi­gen Meetings sind nicht nur als abs­trak­tes Prinzip in den agilen Methoden vorhanden, sondern werden teilweise konkret gefordert. Besonders Scrum ist dafür bekannt, einen festen Plan für ver­schie­dens­te Meetings zu haben. Nur wenn das Team re­gel­mä­ßig Her­aus­for­de­run­gen und Probleme, aber auch Erfolge anspricht, kann es sich lang­fris­tig ver­bes­sern.
   
• User Story: Dem Anspruch, sich auf den Kunden bzw. den Nutzer zu fo­kus­sie­ren, kann man mit User Stories gerecht werden. Hier wird mit einfacher Sprache kurz erklärt, was eine Funktion im Sinne des Nutzers können muss. Man notiert diese Be­schrei­bung auf eine so­ge­nann­te Story Card und ordnet alle Karten zu einer Story Map an.
   
• Agile Testing: In der agilen Software-Ent­wick­lung wird Testing als in­te­gra­ler Be­stand­teil des Ent­wick­lungs­pro­zes­ses angesehen. Ty­pi­scher­wei­se wird das Produkt am Ende einer Iteration – der kurzen Ar­beits­pha­se – im Team getestet, bevor es als ‚fertig‘ gilt und an den Kunden aus­ge­lie­fert wird. Erst dann beginnt die nächste Iteration mit einer neuen Aufgabe.
   
• Pair Pro­gramming: Das Vier-Augen-Prinzip kommt beim Pair Pro­gramming zur Anwendung. Dabei teilen sich zwei Ent­wick­ler einen Ar­beits­platz. Während einer der beiden den Code schreibt, überprüft der andere die Eingabe. Dies kostet zwar mehr zeit­li­chen Aufwand (der Prüfer könnte in der Zeit selbst Code schreiben), soll aber für weniger Fehler im Code sorgen.
   
• Ti­me­boxing: Manche Formen der agilen Ent­wick­lung haben strenge Zeit­vor­ga­ben. Auch hier ist Scrum ein gutes Beispiel, wo Sprints eine ganz bestimmte Länge haben. Am Ende muss das Team ein fertiges Produkt prä­sen­tie­ren. Das erfordert, dass man die Aufgaben passend gestaltet und auswählt.

Es gibt noch sehr viel mehr Techniken, denen man in agilen Methoden begegnet. Allen gemein ist der Anspruch, den Ar­beits­ab­lauf ef­fek­ti­ver zu gestalten und die Qualität des Produkts zu steigern.

Von ihren Ver­fech­tern wird die Her­an­ge­hens­wei­se der agilen Software-Ent­wick­lung gerne als einzige Mög­lich­keit pro­pa­giert, wie man heute Produkte ent­wi­ckeln sollte. Doch nicht für alle Teams und Un­ter­neh­men ist die Agilität die richtige Lösung. Abhängig von der Situation des Un­ter­neh­mens können die Nachteile die Vorteile über­wie­gen.