Agiles Arbeiten

Herr A. ist der Product Manager und zugleich Auftraggeber eines agilen Teams. Er gilt als der Richtungsgeber seines Produkts. Er hat ein Ziel vor Augen: Ein bestimmtes Produkt auf den Markt bringen und den Wert maximieren.

Er und sein Entwicklungsteam arbeiten in zweiwöchigen Iterationen. Täglich inspizieren die Entwickler*innen in einem kurzen Meeting, ob ihre initial-geplante Iteration nach Plan verläuft oder ob Adaptionen notwendig sind.

• Unerwartete Ereignisse und unerwünschte Störungen werden umgehend aufgedeckt und transparent gemacht. Mittels Schwarmintelligenz des Teams kann entschieden werden, wie mit diesen Einflüssen umgegangen wird.
• Spätestens nach zwei Wochen steht eine neue Version des Produkts zur Verfügung. Diese kann unmittelbar ausgespielt werden, wenn der Product Owner das möchte. Er holt sich Feedback von den Entwickler*innen dazu ein und zieht danach seine Schlüsse. Der Vorteil vom baldigen Release liegt klar auf der Hand: Risikominimierung.
• Dank der frühzeitigen Rückmeldung vom Markt kann direkt reagiert werden und, falls es die Marktsituation erfordert, auch noch während der Produktentwicklung eine Kurskorrektur vorgenommen werden.
• Vielleicht zeigt sich sogar, dass ein gewisses Feature in Zukunft nicht erwünscht ist. Das wiederum könnte Kosten einsparen. Die Geldgeber*innen und Produktsponsor*innen wären davon nicht gerade abgeneigt.
• Bevor das Produkt letztendlich ausgerollt wird, inspizieren das gesamte Team und die Stakeholder das Produkt in einem Review-Meeting. Allen Beteiligten ist bewusst: Diese regelmäßigen, gemeinsamen Treffen sind notwendig und wertvoll.
• Am Ende einer Iteration führt das Team eine Retrospektive durch, in der die Teilnehmenden über die vergangenen zwei Wochen reflektieren. In angenehmer Atmosphäre wird offen und vertrauensvoll über Learnings gesprochen: Was lief gut? Was hätte besser sein können? Was wird das Team die kommenden Wochen anders machen, um noch effektiver zu werden?  

Annahme: Aufwände, Meilensteine, Deadlines können im Vorhinein von fachfremden Personen vorgegeben werden, ohne das umzusetzende Team zu involvieren. In der Erwartungshaltung wird Software trotzdem In-Scope-Budget-Time umgesetzt, selbst wenn die Aufwandsschätzungen ohne die Techniker- und Entwicklerteams entstanden sind.

Tatsache: Agilität macht explizit, dass Fortschritt und Erfolg daran gemessen werden, funktionierende Versionen des Produkts regelmäßig zu überprüfen. Der Scope wird sich zwangsläufig ändern, sobald auf den Markt reagiert wird. Kein noch so genau ausspezifiziertes Dokument oder ein virtueller Prozess kann das im Vorhinein abbilden. 

Annahme: Anforderungsdokumentation > Kommunikation. Anforderungsdokumentation ist das A & O. Je genauer und detaillierter Anforderungen definiert sind, umso unwichtiger wird die Kommunikation. Denn dann kann fleißig, ohne Nachfragen, entwickelt und abgearbeitet werden. Zwischenfragen und Iterationen braucht es dann nicht mehr.

Tatsache: Eine initiale Anforderungsdokumentation hat sicherlich seine Wichtigkeit. Dennoch ersetzt das geschriebene Wort keinesfalls den persönlich durchgeführten Dialog zwischen Auftraggebenden und Auftragnehmenden. Kommunikation ist wichtig, um Feedback und Verständnisfragen zu bergen, die ungeklärt zu Missverständnissen führen.

Annahme: Business und IT sind unterschiedliche Abteilungen. Es handelt sich um zwei verschiedene Welten, die nicht miteinander vermischt werden sollten!

Tatsache: Agilität wird durch kontinuierliche Zusammenarbeit aller Projektbeteiligten getrieben. Das zeigt vor allem der Mehrwert von crossfunktionalen Teams. Wenn Stakeholder, IT, Business, Operations und weitere am selben Strang ziehen und dabei in die gleiche Richtung gehen, kann das Ziel schneller und treffender erreicht werden! Wie viele Fehler hätten verhindert werden können, hätte man nur mehr Wert auf gemeinsame Kommunikation gelegt hätte? 

Annahme: Agilität? Da wird ja nicht mal geplant!

Tatsache: Die Wirksamkeit von Plänen über große Zeiträume hinweg wird im agilen Umfeld tatsächlich stark in Frage gestellt. Aufgrund des unsicheren Umfelds, in welchem man sich bewegt, wird mit eher kurzfristigem Fokus geplant. Vergleichbar mit der Wettervorhersage. Für wie vertrauenswürdig halten Sie die Wetteraussichten über eine Zeitspanne von etwa 42 Tagen? Wie zuverlässig ist eine Vorhersage für morgen oder übermorgen? Es liegt in der Natur der Sache, dass Komplexität nur bedingt planbar ist und schnelles Anpassen des Plans vonnöten ist. Ein agiles Entwicklungsteam, welches in Iterationen arbeitet, legt dennoch höchsten Fokus auf die jeweiligen Iterationsplanungen.