Mit agiler Planung zum Erfolg – Inspi­ra­tio­nen aus der Soft­ware­ent­wick­lung

29. Juli 2014 von Julian-G. Mehler

„Agili­tät“ ist schon fast ein Mode­wort. In der Soft­ware­ent­wick­lung gehö­ren „Agile Metho­den“ längst zum profes­sio­nel­len Stan­dard. 2013 wurde in Deutsch­land 84% aller Soft­ware mit Agilen Metho­den program­miert (2005 waren es noch 14%). In den meis­ten ande­ren Bran­chen sind Agile Metho­den noch weit weni­ger verbrei­tet.

Doch auch dort wird die Frage, inwie­fern ein Umden­ken in der tradi­tio­nel­len Planungs­lo­gik notwen­dig ist, zuneh­mend lauter disku­tiert. Der Erfolg spricht für Agile Planung – zumin­dest in der IT-Welt: Führen klas­si­sche „Wasser­fall-Metho­den“ in der Soft­ware­ent­wick­lung nur in 14% der Projekte zum gewünsch­ten Ergeb­nis, so sind es bei Agilen Metho­den 42%.

Was genau steht dahin­ter? Wie unter­schei­den sich Agile Metho­den von ande­ren Vorge­hens­wei­sen? Und was können Orga­ni­sa­ti­ons­ent­wick­lung, Manage­ment und Bera­tung von der Soft­ware­ent­wick­lung lernen?

Was sind „Agile Metho­den“?

Die Leit­prin­zi­pien Agiler Metho­den sind in einem 2001 von 17 inter­na­tio­na­len Softwareentwickler*innen veröf­fent­lich­ten „Mani­fest für Agile Soft­ware­ent­wick­lung“ zusam­men­ge­fasst. Kern­an­lie­gen dabei sind:

Indi­vi­duen und Inter­ak­tio­nen zählen mehr als Prozesse und Werk­zeuge
Funk­tio­nie­rende Soft­ware ist wich­ti­ger als umfas­sende Doku­men­ta­tion
Zusam­men­ar­beit mit den Kunde*innen bedeu­tet mehr als nur Vertrags­ver­hand­lung
Reagie­ren auf Verän­de­rung ist wich­ti­ger als das Befol­gen eines Plans

Dies ist ein Bruch mit der klas­si­schen Soft­ware­ent­wick­lung, die lange Zeit auf „Wasser­fall-Metho­den“ setzte, wie sie außer­halb der IT-Welt bis heute weit verbrei­tet sind: Unter Wasser­fall-Metho­den versteht man Lösungs- und Entwick­lungs­ver­fah­ren, die in einem linea­ren Schritt-für-Schritt Prozess aus der Sphäre der Bedarfs- und Problem­ana­lyse „hinab“steigen in die Sphäre der Lösun­gen. Wie beim flie­ßen­den Wasser gibt es nach jedem Arbeits­schritt nur eine mögli­che Bewe­gungs­rich­tung: nach vorne. Nach­dem das Ziel defi­niert ist (Wie soll mein Produkt ausse­hen?) arbei­tet man sich in oft lang­wie­ri­gen und klar abge­grenz­ten Analyse‑, Entwick­lungs- und Test­pha­sen nach einem vorge­ge­be­nen Plan in Rich­tung Ergeb­nis.

Foto eines Workshops Daily Standup (Drew Stephens, CC)
Daily Stan­dup (Drew Stephens, CC)

In der Agilen Soft­ware­ent­wick­lung ist das Vorge­hen hinge­gen itera­tiv. Der Prozess ist unter­teilt in kurze, über­schau­bare Phasen, in denen regel­mä­ßig Zwischen­er­geb­nisse über­prüft und am Endnut­zer getes­tet werden. Gelei­tet von den gewünsch­ten Leis­tun­gen einer Soft­ware und mit weni­gen Vorga­ben, wie genau das Produkt am Ende auszu­se­hen hat, baut sich der Entwick­lungs­pro­zess mit mini­ma­lem büro­kra­ti­schem Aufwand schritt­weise auf. Mensch­li­che Aspekte wie Team­geist und Verant­wor­tungs­ge­fühl gewin­nen stär­ker an Bedeu­tung. Auch die Rolle der Führung wird hier neu gedacht. Das Konzept der Agilen Metho­den ähnelt in vieler Hinsicht dem Design Thin­king-Ansatz, wie er in Deutsch­land u.a. vom Hasso Platt­ner Insti­tut in Pots­dam gelehrt wird.

Scrum – so funktioniert´s

Graphik eines Scumzyklus.

Am Beispiel von Scrum, der bekann­tes­ten Agilen Methode, wird schnell deut­lich, warum „agil“ die tref­fende Beschrei­bung dieser Vorge­hens­weise ist. Grund­prin­zip von Scrum sind kurze Entwick­lungs­i­te­ra­tio­nen – soge­nannte „Sprints“ – mit klaren Ziel­vor­ga­ben und regel­mä­ßi­gen Feed­back­schlei­fen. Zu Beginn einer Projekt­phase werden im „Sprint Plan­ning“ gemein­sam mit dem*der Kund*in Ziele defi­niert und daraus Aufga­ben abge­lei­tet, prio­ri­siert und für alle sicht­bar aufge­hängt („Scrum­board“).

Das gesamte Entwick­lungs­team macht sich anschlie­ßend daran, diese Aufga­ben zu bear­bei­ten – jede*r weiß jeder­zeit um den aktu­el­len Entwick­lungs­stand und arbei­tet eigen­ver­ant­wort­lich. Täglich werden in „Daily Stan­dups“ Zwischen­er­geb­nisse präsen­tiert und Probleme bespro­chen. Am Ende eines „Sprints“ werden Ergeb­nis, Prozess und Zusam­men­ar­beit reflek­tiert – und ein neues Inter­vall beginnt (s. Grafik).

Fünf Unter­schei­dungs­merk­male

Scrum hebt sich von klas­si­schen Planungs- und Entwick­lungs­an­sät­zen beson­ders durch folgende Merk­male ab:

  1. Stetige Einbin­dung des*der Kund*in: Ausgangs­punkt der Scrum-Methode ist der*die Kund*in. Er*sie wird von Anfang an und konti­nu­ier­lich in den Prozess einge­bun­den. Im einlei­ten­den „Sprint Plan­ning“ gibt es daher eine klare Rollen­ver­tei­lung: Der*die Kund*in gibt eine Liste von Entwick­lungs­zie­len vor – die Entwickler*innen bewer­ten diese nach ihrem Aufwand und legen erste Arbeits­schritte fest. Anschlie­ßend entschei­den Kund*in und Entwickler*in gemein­sam über die Ziele der ersten Itera­tion.
  2. Kleine Itera­tio­nen statt großer Master­plan: Statt lang­fris­tige große Ziele fest­zu­le­gen, konzen­triert sich Scrum auf kurze Planungs- und Umset­zungs­in­ter­valle. Damit kann jeder­zeit flexi­bel auf Verän­de­run­gen von Kund*innenwünschen und/oder tech­ni­schen Neue­run­gen einge­gan­gen werden.
  3. „Scrum­board“ statt Arbeits­plan: Im Scrum gibt es keine festen Zutei­lun­gen von Aufga­ben. Aus dem gemein­sam defi­nier­ten Aufga­ben­pool („Scrum­board“) holen sich die Entwickler*innen nach dem Pull-Prin­zip die zu erle­di­gen­den Aufga­ben. Im Grunde wird eine prio­ri­sierte To-Do-Liste gemein­schaft­lich abge­ar­bei­tet. Sobald ein Ziel erreicht ist, wird es direkt dem*der Kund*in zur Abnahme vorge­legt. Entspricht etwas nicht seinen*ihren Vorstel­lun­gen, kann sofort nach­ge­steu­ert werden. Die Führungs­auf­gabe ist hier auf den Mode­ra­ti­ons­teil redu­ziert – jedes Team­mit­glied kann selbst­stän­dig Aufga­ben aus dem Aufga­ben­pool über­neh­men.
  4. „Scrum Master“ statt Projekt­lei­tung: Zustän­dig für die Umset­zung ist ein Entwick­lungs­team und ein „Scrum Master“. Diese*r ist weder „Chef*in“ noch „Projektmanager*in“ im herkömm­li­chen Sinn. Seine*ihre Aufgabe ist es, das Team bei Proble­men zu unter­stüt­zen sowie die Einhal­tung von Zeiten, Zielen und Scrum­re­geln sicher­zu­stel­len. In einem gut laufen­den Team agiert der*die „Scrum Master“ im Hinter­grund und wird nur bei Bedarf aktiv.
  5. Review, review, review: Die neben­ein­an­der an einem Projekt arbei­ten­den Team­mit­glie­der tauschen sich täglich aus: In kurzen „Stan­dup Meetings“ werden in maxi­mal 20 Minu­ten Probleme bespro­chen und gege­be­nen­falls vom „Scrum Master“ am selben Tag gelöst. Am Ende jeder Woche steht dann ein ausführ­li­che­rer „Sprint Review“, an dem der aktu­elle Zwischen­stand präsen­tiert wird. Hier nehmen nicht nur Entwickler*innen und Kund*innen teil – wenn möglich werden die Zwischen­er­geb­nisse auch direkt von Anwender*innen getes­tet. So wird die Entwick­lung trans­pa­rent – die typi­sche Falle der „dienst­leis­ten­den, aber alltags­fer­nen Entwickler*innen“ entsteht nicht. Schluss­end­lich wird auch am Ende jedes Sprints erneut reflek­tiert und ausge­wer­tet. Hier liegt der Fokus auf der Arbeits­weise im Team – der „Scrum Master“ ist als Führungs­kraft und Mode­ra­toin gefragt.

Fünf Impulse für die Orga­ni­sa­ti­ons­ent­wick­lung

Was nun haben Orga­ni­sa­ti­ons­ent­wick­lung und Change Manage­ment mit Soft­ware­ent­wick­lung zu tun? Zunächst einmal ist beiden gemein­sam, dass es schwie­rig ist, von Anfang an Ziele spezi­fisch und mess­bar zu defi­nie­ren. Zugleich wollen aber viele Kund*innen genau das: Gewiss­heit darüber, was sie am Ende des Prozes­ses für ihr Geld bekom­men. Eine weitere Gemein­sam­keit: Nicht vorher­seh­bare Probleme und Ände­run­gen bei der Umset­zung von Zielen sind eher die Regel als die Ausnahme (vgl. Hans-Ulrich Streit; Orga­ni­sa­ti­ons­Ent­wick­lung Nr. 2 | 2013, S. 51). Zudem ist der Koor­di­nie­rungs­auf­wand in orga­ni­sa­tio­na­len Verän­de­rungs­pro­jek­ten oftmals sehr hoch, da viele Inter­es­sen­grup­pen invol­viert sind und das Umfeld selbst in stän­di­gem Wandel begrif­fen ist.

­­­Aus dem Ansatz der Agilen Planung möch­ten wir daher fünf Impulse ablei­ten, die für die Bera­tung von Verän­de­rungs­pro­zes­sen in Unter­neh­men und Orga­ni­sa­tio­nen nütz­lich sein können:

  1. Kurz-zyklisch: Statt einem linea­ren Master­plan zu folgen, gehen Agile Metho­den zyklisch vor. Zugleich lautet eine wich­tige Scrum-Regel, während der Umset­zung eines laufen­den Zyklus keine Ände­run­gen vorzu­neh­men. Das sichert die Stabi­li­tät im Arbeits­pro­zess. Die Arbeit in kurzen Inter­val­len bietet zwei entschei­dende Vorteile: (1) Sie ermög­licht flexi­bles Reagie­ren auf Verän­de­run­gen in der Orga­ni­sa­tion oder im Markt; (2) Während in lang­fris­ti­gen Projek­ten oft einer hohen Anfangs­er­war­tung rasche Ernüch­te­rung folgt, werden die Prozess­be­tei­lig­ten beim agilen Vorge­hen durch schnelle sicht­bare Ergeb­nisse immer wieder moti­viert.
  2. Frühe Test­bal­lons ohne Angst vor Miss­erfolg: Die Agile Soft­ware­ent­wick­lung folgt dem Prin­zip des „test-driven-deve­lo­p­ment“. Statt dem Anspruch, von Beginn an alle notwen­di­gen Infor­ma­tio­nen besit­zen zu müssen oder alle Varia­blen bis ins letzte Detail geklärt zu haben, werden in kurzer Zeit viele Versuchs­bal­lons gestar­tet um zu prüfen, ob der Weg über­haupt gang­bar ist. Auch in der Orga­ni­sa­ti­ons­ent­wick­lung helfen die Bera­ten­den dem*der Kund*in zu entschei­den, wo detail­lierte Planung nötig ist und wo eher kleine Test­bal­lons hilf­reich und ziel­füh­rend sind. Dabei ist ein miss­glück­ter Test­bal­lon nicht als „Fehl­schlag“ zu bewer­ten sondern als eine „hilf­rei­che Infor­ma­tion“.
  3. Gelebte Trans­pa­renz: Agile Metho­den legen Wert auf hohe Trans­pa­renz. Alle Team­mit­glie­der wissen immer, wo die jeweils ande­ren Kolleg*innen stehen und wie das vorläu­fige Gesamt­pro­dukt in jeder Etappe aussieht. Sicher ist nicht jede Infor­ma­tion in Verän­de­rungs­pro­jek­ten immer mit allen „teil­bar“, und dennoch: Trans­pa­renz im Vorge­hen und in der Kommu­ni­ka­tion ist eine der wich­tigs­ten Erfolgs­fak­to­ren der Orga­ni­sa­ti­ons­ent­wick­lung. Auch inner­halb des Projekt­ma­nage­ments oder Steue­rungs­teams kann ein „Scrum Board“ nütz­lich sein, das allen Betei­lig­ten Aufschluss über den derzei­ti­gen Projekt­stand gibt.
  4. Lernen und Reflek­tie­ren im Prozess (nicht erst, wenn es zu spät ist!): Austausch im Team ist beim Scum groß geschrie­ben – sowohl zu den Inhal­ten als auch zur Zusammenarbeit.„Sprint Reviews“ und „Sprint Retro­spec­ti­ves“ sind Formate, die Lernen perma­nent und expli­zit in den Prozess einbauen. Somit werden Fehler oder Fehl­ent­wick­lun­gen früh­zei­tig zur Spra­che gebracht und gemein­sa­mes Lernen ermög­licht. Die Agile Metho­dik berück­sich­tigt damit ein Herz­stück unse­res Verständ­nis­ses von Orga­ni­sa­ti­ons­ent­wick­lung: Lebens­lan­ges Lernen von Indi­vi­duen und Orga­ni­sa­tio­nen.
  5. Flache Hier­ar­chie und koope­ra­tive Führung: Beim Thema Führung geht die Scrum Methode sehr weit. Während des Projekts ist der „Scrum Master“ ledig­lich dafür zustän­dig, dass hemmende Hürden im Prozess besei­tigt werden und nimmt eher eine vermit­telnde Rolle ein. In Orga­ni­sa­tio­nen entspricht das einer sehr ausge­präg­ten Form eines koope­ra­ti­ven Führungs­stils. Die Passung von Führungs­stil und Orga­ni­sa­ti­ons­form ist ein Thema, das uns in der Bera­tung täglich begeg­net und im Kontext neuer Zusam­men­ar­beits­mo­delle immer wieder disku­tiert werden muss.

Fazit

Sind Agile Metho­den also das neue Mittel der Wahl für die Orga­ni­sa­tion­ent­wick­lung? Unsere Antwort auf diese Frage fällt diffe­ren­ziert aus und rich­tet sich nach dem jewei­li­gen Kontext. Es gibt Projekte und Kund*innenmilieus, bei denen sich klas­si­sche Planung bewährt hat und weiter bewäh­ren wird. Metho­dik und Planung müssen zu den Struk­tu­ren und zur Kultur einer Orga­ni­sa­tion oder eines Projekts passen, ebenso wie zum Charak­ter des Verän­de­rungs­pro­zes­ses selbst. „Verän­de­rung braucht Stabi­li­tät“ lautet ein Leit­satz der Orga­ni­sa­ti­ons­ent­wick­lung. Wenn die Bera­ten­den den ohne­hin schon aufge­reg­ten und verun­si­cher­ten Betei­lig­ten eines Change Prozes­ses verkün­den: „Wir machen viele kurze Itera­ti­ons­schlei­fen und schauen dann, wohin uns die Sache führt“, können sie damit ohne­hin schon vorhan­dene Ängste bis hin zum destruk­ti­ven Wider­stand schü­ren. Je aufwän­di­ger ein orga­ni­sa­to­ri­scher Reform­pro­zess ist und je höher das Risiko für die Betei­lig­ten (insbe­son­dere der Führungs­kräfte), desto gerin­ger ist in der Regel die Bereit­schaft, sich auf eine sehr offene und expe­ri­men­telle Metho­dik einzu­las­sen. Der Einsatz Agiler Metho­den muss hier also ausba­lan­ciert werden mit den bekann­ten Elemen­ten linea­rer Planung wie z.B. Meilen­steine, Berichte und Entschei­dungs­wei­chen.

Ande­rer­seits: Gerade in komple­xen Vorha­ben ist es häufig unmög­lich, „plan­voll“ vorzu­ge­hen (vgl. „Entschei­dungs­fä­hig­keit in komple­xen Situa­tio­nen“). Oftmals können wir die Auswir­kun­gen unse­res Tuns – also auch der Bera­tungs­in­ter­ven­tion – zu Beginn eines Verän­de­rungs­pro­jekts gar nicht planen oder vorher­sa­gen. In einer bereits gege­be­nen Komple­xi­tät kann ein ebenso komple­xer und womög­lich star­rer Plan die Ziel­er­rei­chung eher behin­dern als fördern. Es ist die Aufgabe einer seriö­sen Bera­tung, dies auch ehrlich gegen­über den Kunden zu kommu­ni­zie­ren und sie dabei zu unter­stüt­zen, mit dieser Unwäg­bar­keit umzu­ge­hen.

Zu diesem Zweck schen­ken wir unse­ren Kunden manch­mal ein Exem­plar des Best­sel­lers von Diet­rich Dörner „Die Logik des Miss­lin­gens“, in dem die Leser*innen zum Thema syste­mi­sches Manage­ment die hilf­rei­che Fest­stel­lung finden: „Die Fähig­keit, Unsi­cher­heit zu ertra­gen, ist wich­ti­ger als Intel­li­genz.“

Autoren: Julian‑G. Albert und Lars Kumbier