Mit agiler Planung zum Erfolg – Inspirationen aus der Softwareentwicklung
29. Juli 2014 von Julian-G. Mehler
„Agilität“ ist schon fast ein Modewort. In der Softwareentwicklung gehören „Agile Methoden“ längst zum professionellen Standard. 2013 wurde in Deutschland 84% aller Software mit Agilen Methoden programmiert (2005 waren es noch 14%). In den meisten anderen Branchen sind Agile Methoden noch weit weniger verbreitet.
Doch auch dort wird die Frage, inwiefern ein Umdenken in der traditionellen Planungslogik notwendig ist, zunehmend lauter diskutiert. Der Erfolg spricht für Agile Planung – zumindest in der IT-Welt: Führen klassische „Wasserfall-Methoden“ in der Softwareentwicklung nur in 14% der Projekte zum gewünschten Ergebnis, so sind es bei Agilen Methoden 42%.
Was genau steht dahinter? Wie unterscheiden sich Agile Methoden von anderen Vorgehensweisen? Und was können Organisationsentwicklung, Management und Beratung von der Softwareentwicklung lernen?
Was sind „Agile Methoden“?
Die Leitprinzipien Agiler Methoden sind in einem 2001 von 17 internationalen Softwareentwickler*innen veröffentlichten „Manifest für Agile Softwareentwicklung“ zusammengefasst. Kernanliegen dabei sind:
Individuen und Interaktionen zählen mehr als Prozesse und Werkzeuge
Funktionierende Software ist wichtiger als umfassende Dokumentation
Zusammenarbeit mit den Kunde*innen bedeutet mehr als nur Vertragsverhandlung
Reagieren auf Veränderung ist wichtiger als das Befolgen eines Plans
Dies ist ein Bruch mit der klassischen Softwareentwicklung, die lange Zeit auf „Wasserfall-Methoden“ setzte, wie sie außerhalb der IT-Welt bis heute weit verbreitet sind: Unter Wasserfall-Methoden versteht man Lösungs- und Entwicklungsverfahren, die in einem linearen Schritt-für-Schritt Prozess aus der Sphäre der Bedarfs- und Problemanalyse „hinab“steigen in die Sphäre der Lösungen. Wie beim fließenden Wasser gibt es nach jedem Arbeitsschritt nur eine mögliche Bewegungsrichtung: nach vorne. Nachdem das Ziel definiert ist (Wie soll mein Produkt aussehen?) arbeitet man sich in oft langwierigen und klar abgegrenzten Analyse‑, Entwicklungs- und Testphasen nach einem vorgegebenen Plan in Richtung Ergebnis.
In der Agilen Softwareentwicklung ist das Vorgehen hingegen iterativ. Der Prozess ist unterteilt in kurze, überschaubare Phasen, in denen regelmäßig Zwischenergebnisse überprüft und am Endnutzer getestet werden. Geleitet von den gewünschten Leistungen einer Software und mit wenigen Vorgaben, wie genau das Produkt am Ende auszusehen hat, baut sich der Entwicklungsprozess mit minimalem bürokratischem Aufwand schrittweise auf. Menschliche Aspekte wie Teamgeist und Verantwortungsgefühl gewinnen stärker an Bedeutung. Auch die Rolle der Führung wird hier neu gedacht. Das Konzept der Agilen Methoden ähnelt in vieler Hinsicht dem Design Thinking-Ansatz, wie er in Deutschland u.a. vom Hasso Plattner Institut in Potsdam gelehrt wird.
Scrum – so funktioniert´s
Am Beispiel von Scrum, der bekanntesten Agilen Methode, wird schnell deutlich, warum „agil“ die treffende Beschreibung dieser Vorgehensweise ist. Grundprinzip von Scrum sind kurze Entwicklungsiterationen – sogenannte „Sprints“ – mit klaren Zielvorgaben und regelmäßigen Feedbackschleifen. Zu Beginn einer Projektphase werden im „Sprint Planning“ gemeinsam mit dem*der Kund*in Ziele definiert und daraus Aufgaben abgeleitet, priorisiert und für alle sichtbar aufgehängt („Scrumboard“).
Das gesamte Entwicklungsteam macht sich anschließend daran, diese Aufgaben zu bearbeiten – jede*r weiß jederzeit um den aktuellen Entwicklungsstand und arbeitet eigenverantwortlich. Täglich werden in „Daily Standups“ Zwischenergebnisse präsentiert und Probleme besprochen. Am Ende eines „Sprints“ werden Ergebnis, Prozess und Zusammenarbeit reflektiert – und ein neues Intervall beginnt (s. Grafik).
Fünf Unterscheidungsmerkmale
Scrum hebt sich von klassischen Planungs- und Entwicklungsansätzen besonders durch folgende Merkmale ab:
- Stetige Einbindung des*der Kund*in: Ausgangspunkt der Scrum-Methode ist der*die Kund*in. Er*sie wird von Anfang an und kontinuierlich in den Prozess eingebunden. Im einleitenden „Sprint Planning“ gibt es daher eine klare Rollenverteilung: Der*die Kund*in gibt eine Liste von Entwicklungszielen vor – die Entwickler*innen bewerten diese nach ihrem Aufwand und legen erste Arbeitsschritte fest. Anschließend entscheiden Kund*in und Entwickler*in gemeinsam über die Ziele der ersten Iteration.
- Kleine Iterationen statt großer Masterplan: Statt langfristige große Ziele festzulegen, konzentriert sich Scrum auf kurze Planungs- und Umsetzungsintervalle. Damit kann jederzeit flexibel auf Veränderungen von Kund*innenwünschen und/oder technischen Neuerungen eingegangen werden.
- „Scrumboard“ statt Arbeitsplan: Im Scrum gibt es keine festen Zuteilungen von Aufgaben. Aus dem gemeinsam definierten Aufgabenpool („Scrumboard“) holen sich die Entwickler*innen nach dem Pull-Prinzip die zu erledigenden Aufgaben. Im Grunde wird eine priorisierte To-Do-Liste gemeinschaftlich abgearbeitet. Sobald ein Ziel erreicht ist, wird es direkt dem*der Kund*in zur Abnahme vorgelegt. Entspricht etwas nicht seinen*ihren Vorstellungen, kann sofort nachgesteuert werden. Die Führungsaufgabe ist hier auf den Moderationsteil reduziert – jedes Teammitglied kann selbstständig Aufgaben aus dem Aufgabenpool übernehmen.
- „Scrum Master“ statt Projektleitung: Zuständig für die Umsetzung ist ein Entwicklungsteam und ein „Scrum Master“. Diese*r ist weder „Chef*in“ noch „Projektmanager*in“ im herkömmlichen Sinn. Seine*ihre Aufgabe ist es, das Team bei Problemen zu unterstützen sowie die Einhaltung von Zeiten, Zielen und Scrumregeln sicherzustellen. In einem gut laufenden Team agiert der*die „Scrum Master“ im Hintergrund und wird nur bei Bedarf aktiv.
- Review, review, review: Die nebeneinander an einem Projekt arbeitenden Teammitglieder tauschen sich täglich aus: In kurzen „Standup Meetings“ werden in maximal 20 Minuten Probleme besprochen und gegebenenfalls vom „Scrum Master“ am selben Tag gelöst. Am Ende jeder Woche steht dann ein ausführlicherer „Sprint Review“, an dem der aktuelle Zwischenstand präsentiert wird. Hier nehmen nicht nur Entwickler*innen und Kund*innen teil – wenn möglich werden die Zwischenergebnisse auch direkt von Anwender*innen getestet. So wird die Entwicklung transparent – die typische Falle der „dienstleistenden, aber alltagsfernen Entwickler*innen“ entsteht nicht. Schlussendlich wird auch am Ende jedes Sprints erneut reflektiert und ausgewertet. Hier liegt der Fokus auf der Arbeitsweise im Team – der „Scrum Master“ ist als Führungskraft und Moderatoin gefragt.
Fünf Impulse für die Organisationsentwicklung
Was nun haben Organisationsentwicklung und Change Management mit Softwareentwicklung zu tun? Zunächst einmal ist beiden gemeinsam, dass es schwierig ist, von Anfang an Ziele spezifisch und messbar zu definieren. Zugleich wollen aber viele Kund*innen genau das: Gewissheit darüber, was sie am Ende des Prozesses für ihr Geld bekommen. Eine weitere Gemeinsamkeit: Nicht vorhersehbare Probleme und Änderungen bei der Umsetzung von Zielen sind eher die Regel als die Ausnahme (vgl. Hans-Ulrich Streit; OrganisationsEntwicklung Nr. 2 | 2013, S. 51). Zudem ist der Koordinierungsaufwand in organisationalen Veränderungsprojekten oftmals sehr hoch, da viele Interessengruppen involviert sind und das Umfeld selbst in ständigem Wandel begriffen ist.
Aus dem Ansatz der Agilen Planung möchten wir daher fünf Impulse ableiten, die für die Beratung von Veränderungsprozessen in Unternehmen und Organisationen nützlich sein können:
- Kurz-zyklisch: Statt einem linearen Masterplan zu folgen, gehen Agile Methoden zyklisch vor. Zugleich lautet eine wichtige Scrum-Regel, während der Umsetzung eines laufenden Zyklus keine Änderungen vorzunehmen. Das sichert die Stabilität im Arbeitsprozess. Die Arbeit in kurzen Intervallen bietet zwei entscheidende Vorteile: (1) Sie ermöglicht flexibles Reagieren auf Veränderungen in der Organisation oder im Markt; (2) Während in langfristigen Projekten oft einer hohen Anfangserwartung rasche Ernüchterung folgt, werden die Prozessbeteiligten beim agilen Vorgehen durch schnelle sichtbare Ergebnisse immer wieder motiviert.
- Frühe Testballons ohne Angst vor Misserfolg: Die Agile Softwareentwicklung folgt dem Prinzip des „test-driven-development“. Statt dem Anspruch, von Beginn an alle notwendigen Informationen besitzen zu müssen oder alle Variablen bis ins letzte Detail geklärt zu haben, werden in kurzer Zeit viele Versuchsballons gestartet um zu prüfen, ob der Weg überhaupt gangbar ist. Auch in der Organisationsentwicklung helfen die Beratenden dem*der Kund*in zu entscheiden, wo detaillierte Planung nötig ist und wo eher kleine Testballons hilfreich und zielführend sind. Dabei ist ein missglückter Testballon nicht als „Fehlschlag“ zu bewerten sondern als eine „hilfreiche Information“.
- Gelebte Transparenz: Agile Methoden legen Wert auf hohe Transparenz. Alle Teammitglieder wissen immer, wo die jeweils anderen Kolleg*innen stehen und wie das vorläufige Gesamtprodukt in jeder Etappe aussieht. Sicher ist nicht jede Information in Veränderungsprojekten immer mit allen „teilbar“, und dennoch: Transparenz im Vorgehen und in der Kommunikation ist eine der wichtigsten Erfolgsfaktoren der Organisationsentwicklung. Auch innerhalb des Projektmanagements oder Steuerungsteams kann ein „Scrum Board“ nützlich sein, das allen Beteiligten Aufschluss über den derzeitigen Projektstand gibt.
- Lernen und Reflektieren im Prozess (nicht erst, wenn es zu spät ist!): Austausch im Team ist beim Scum groß geschrieben – sowohl zu den Inhalten als auch zur Zusammenarbeit.„Sprint Reviews“ und „Sprint Retrospectives“ sind Formate, die Lernen permanent und explizit in den Prozess einbauen. Somit werden Fehler oder Fehlentwicklungen frühzeitig zur Sprache gebracht und gemeinsames Lernen ermöglicht. Die Agile Methodik berücksichtigt damit ein Herzstück unseres Verständnisses von Organisationsentwicklung: Lebenslanges Lernen von Individuen und Organisationen.
- Flache Hierarchie und kooperative Führung: Beim Thema Führung geht die Scrum Methode sehr weit. Während des Projekts ist der „Scrum Master“ lediglich dafür zuständig, dass hemmende Hürden im Prozess beseitigt werden und nimmt eher eine vermittelnde Rolle ein. In Organisationen entspricht das einer sehr ausgeprägten Form eines kooperativen Führungsstils. Die Passung von Führungsstil und Organisationsform ist ein Thema, das uns in der Beratung täglich begegnet und im Kontext neuer Zusammenarbeitsmodelle immer wieder diskutiert werden muss.
Fazit
Sind Agile Methoden also das neue Mittel der Wahl für die Organisationentwicklung? Unsere Antwort auf diese Frage fällt differenziert aus und richtet sich nach dem jeweiligen Kontext. Es gibt Projekte und Kund*innenmilieus, bei denen sich klassische Planung bewährt hat und weiter bewähren wird. Methodik und Planung müssen zu den Strukturen und zur Kultur einer Organisation oder eines Projekts passen, ebenso wie zum Charakter des Veränderungsprozesses selbst. „Veränderung braucht Stabilität“ lautet ein Leitsatz der Organisationsentwicklung. Wenn die Beratenden den ohnehin schon aufgeregten und verunsicherten Beteiligten eines Change Prozesses verkünden: „Wir machen viele kurze Iterationsschleifen und schauen dann, wohin uns die Sache führt“, können sie damit ohnehin schon vorhandene Ängste bis hin zum destruktiven Widerstand schüren. Je aufwändiger ein organisatorischer Reformprozess ist und je höher das Risiko für die Beteiligten (insbesondere der Führungskräfte), desto geringer ist in der Regel die Bereitschaft, sich auf eine sehr offene und experimentelle Methodik einzulassen. Der Einsatz Agiler Methoden muss hier also ausbalanciert werden mit den bekannten Elementen linearer Planung wie z.B. Meilensteine, Berichte und Entscheidungsweichen.
Andererseits: Gerade in komplexen Vorhaben ist es häufig unmöglich, „planvoll“ vorzugehen (vgl. „Entscheidungsfähigkeit in komplexen Situationen“). Oftmals können wir die Auswirkungen unseres Tuns – also auch der Beratungsintervention – zu Beginn eines Veränderungsprojekts gar nicht planen oder vorhersagen. In einer bereits gegebenen Komplexität kann ein ebenso komplexer und womöglich starrer Plan die Zielerreichung eher behindern als fördern. Es ist die Aufgabe einer seriösen Beratung, dies auch ehrlich gegenüber den Kunden zu kommunizieren und sie dabei zu unterstützen, mit dieser Unwägbarkeit umzugehen.
Zu diesem Zweck schenken wir unseren Kunden manchmal ein Exemplar des Bestsellers von Dietrich Dörner „Die Logik des Misslingens“, in dem die Leser*innen zum Thema systemisches Management die hilfreiche Feststellung finden: „Die Fähigkeit, Unsicherheit zu ertragen, ist wichtiger als Intelligenz.“
Autoren: Julian‑G. Albert und Lars Kumbier