Viele Unternehmen sind heute immer noch in einer Weise organisiert, dass das Wasserfallmodell als der passendere Ansatz erscheint. Das Problem dabei ist, dass der Wasserfall noch nie funktioniert hat, und über Jahre hinweg ein totes Pferd trainiert wurde. Die gute Nachricht: lautet: Agile Elemente lassen sich auch in Unternehmen einsetzen, die auf den ersten Blick alles andere als agil sind. Insbesondere die Prinzipien
- Iteration,
- lebendige, sortierte Listen statt epischer Dokumente
- sowie vergleichendes „Schätzen“ statt Raten
lassen sich umsetzen, ohne eine Neuorganisation zu erzwingen. Wenn nach diesen Prinzipien gearbeitet wird, ist schon viel gewonnen. Noch besser wird es, wenn mann*frau die Menschen in echten Teams arbeiten lässt, das wird aber Gegenstand des nächsten Artikels werden.
Iteration
Das Ergebnis eines Projektes ist zu Beginn ein Fantasie-Gebilde. So schön die Fantasie ausgemalt ist, so präzise sie beschrieben sein mag, es bleibt Fantasie. Nicht selten gibt es eine Enttäuschung, wenn nach langer hoffnungsvoller Wartezeit das vermeintlich fertige Produkt in Augenschein genommen wird. Dagegen hilft nur eines: So früh wie möglich ein Muster bauen und dieses dann in vielen Iterationen fertigstellen. Damit steigt die Wahrscheinlichkeit, dass am Ende sinnvolles herauskommt. Das gilt im Übrigen für fast alle Arten von Projekt-Ergebnissen.
Lebendige, sortierte Listen statt epischer Dokumente
Wenn das Prinzip der Iteration eingeführt ist, sollten als Nächstes die häufig zu Beginn des Projektes erstellten, epischen Dokumente abgeschafft werden. In schnell wandelnden Zeiten ist der Inhalt von Dokumenten, die in monatelanger Kleinarbeit erstellt wurden, bereits veraltet bevor das fertige Dokument überhaupt zum ersten Mal gelesen wird. (siehe Cartoon „Was fertig wirklich bedeutet“). Dazu kommen noch neue Anforderungen, die es aus vielfältigen Gründen nicht mehr in die Dokumente schaffen. Nebenstehende Grafik zeigt die Antworten einer Studie aus dem Jahr 2008 auf die Frage „Wieviel Prozent der Anforderungen zu Beginn des Projektes bekannt waren“ ((Technical Report der Uni Magedburg: “Einfluss agiler Praktiken auf Teammerkmale und Erfolg von Softwareentwicklungsprojekten” von Sven Lindenhahn, Sebastian Günther, Eberhard Huber 5. Dezember 2008)). Projekte, in denen alle Anforderungen bekannt waren, stellen eher die Ausnahme dar. Ein signifikanter Teil der Anforderungen wird erst während der Projektlaufzeit bekannt. Statt dicke Dokumente mühsam weiter zu pflegen und seitenlange Versions-Tabellen zu erstellen, kann man gleich in Listenform arbeiten. Wenn die Liste noch eine für den Kunden relevante Sortierung bekommt (z.B. nach Wert, Anwendernutzen o.Ä.) ist auch sofort klar, was in der nächsten Iteration umgesetzt wird.
Vergleichen statt Raten
Eine Gesamtschätzung auf Basis eines umfangreichen Anforderungsdokumentes ist in den meisten Fällen eine bessere Rate-Aktion. Etwas Unbekanntes zu schätzen ist Menschen ohnehin kaum möglich. Letztendlich versuchen wir immer zu vergleichen. Wir suchen instinktiv bekannte Größen, mit denen wir das Unbekannte vergleichen können. Dieses Prinzip lässt sich in iterativ arbeitenden Projekten mit Anforderungslisten elegant umsetzen. Neue noch nicht geschätzte Listeneinträge werden einfach mit den bereits umgesetzten Anforderungen verglichen.
Wenn dieses drei methodischen Prinzipien umgesetzt werden, sind immerhin die ersten Schritte in Richtung Agilität getan. Den Geist des agilen Manifests umzusetzen erfordert dann noch vieles mehr. Dafür zählen hier noch keine Ausreden, diese drei Schritte können auch in großen, starren Organisationen gegangen werden.
Der nächste Schritt ist dann das zyklische Lernen bzw. die Autonomie des Lernens.
