Irgendwie zäh...

Im Refinement und im Sprint Planning war sich das Team noch einig, dass das Backlog Item klein genug und gut in einem Sprint machbar ist. Die Aufgabe wurde auch gleich am Sprintanfang angegangen und trotzdem kann das Team das Ergebnis im Sprint Review nicht präsentieren.

So oder so ähnlich haben wir es oft genug gesehen und vielleicht kennst Du die Situation auch: Irgendwie war die Entwicklung dann doch überraschend zäh und es hat am Ende nicht gereicht. Aber was ist der Grund dafür, dass eine eigentlich überschaubare Aufgabe sich so lange hinzieht?

Häufig ist der Grund für diese Verzögerungen die Vielzahl an Abhängigkeiten, mit denen das Team zu kämpfen hat:

1. Abhängigkeiten im Team zu anderen Kolleg:innen mit speziellen Kenntnissen oder Fähigkeiten
2. Abhängigkeiten außerhalb des Teams, die das Team nicht selbst auflösen kann
3. Abhängigkeiten innerhalb der Produktstruktur (Architektur), die an vielen Stellen bearbeitet werden müssen

Abhängigkeiten im Team

Um mit optimalem Flow arbeiten zu können, sollten wir weniger an individueller Auslastung interessiert sein, sondern an optimaler Zusammenarbeit, um unsere Aufgaben fertigstellen zu können. In vielen Teams bearbeiten nur bestimmte Menschen bestimmte Aspekte von Aufgaben. Die Arbeit wird also vom Einen zum Anderen gereicht und muss an jeder Station warten, bis sie bearbeitet werden kann.

Diese Optimierung auf lokale Effizienz und Auslastung verhindert leider wirksam, dass wir unsere Änderungen am Produkt schnell und unkompliziert ausliefern und damit unsere Hypothesen vertesten können. Deshalb sollten wir lieber die Zusammenarbeit im Team fördern, z.B. durch Pairing oder Ensemble Programming. Das betrifft nicht nur die Entwickler, sondern gerne auch den Product Owner und vielleicht sogar Stakeholder, die uns helfen können und wollen.

Abhängigkeiten nach Außen

Vermutlich gibt es keine 100%ig cross-funktionalen Teams, die vollkommen autonom ihr Produkt bauen und ausliefern können. Deshalb können Abhängigkeiten nach außerhalb des Teams auch nicht absolut vermieden oder eliminiert werden. Werden es aber zu viele, dann bremst uns das schon aus.

Lange Zeit haben wir - zumindest in Scrum - das Bild vom kleinen und interdisziplinären Team von ungefähr einem halben Dutzend Menschen vor uns hergetragen. Dass nicht jedes Produkt oder jedes Problem von einer Handvoll Menschen geliefert oder gelöst werden kann, ist wenig überraschend. Trotzdem ist es spannend, dass die Frage, wie wir Teams abseits dieses theoretischen Ideals aufstellen können, so lange nur ungenügend bearbeitet wurde.

Und dann kam Team Topologies: vier Topologien für Teams und drei Interaktionsformen, mit denen wir zielgerichtet Teamstrukturen und -zusammenarbeit modellieren und in kurzen Zyklen optimieren konnten. Team Topologies sind nicht der heilige Gral, aber sie sind ein kaum zu überschätzendes Werkzeug bei der Reduktion von Abhängigkeiten und damit kognitiver Belastung in der Produktentwicklung, die wir berücksichtigen sollten.

Abhängigkeiten im Produkt

Und dann ward es technisch. 🙂 Auch und gerade die technische Struktur eines Produkts beeinflusst, wie gut dieses wart-, veränder- und erweiterbar ist. Ein sehr verteiltes und an vielen Stellen abstrahiertes oder entkoppeltes Produkt muss bei Anpassungen häufig an vielen Stellen angefasst werden. Im schlimmsten Fall - erst diese Woche wieder im Team gesehen - ist es sogar für die Entwickler, die täglich in der Code Base arbeiten, schwierig, immer komplett zu überblicken, welche Stellen bei einer Änderung alles berücksichtigt werden müssen. Das macht sowohl die Entwicklung, aber im weiteren Verlauf natürlich auch die Qualitätssicherung (Reviews und Testing) sowie das Analysieren und Beheben von auftretenden Fehlern aufwändiger und unvorhersagbarer.

Fazit

Produktentwicklung ist ein komplexes Unterfangen und muss ganzheitlich in allen Aspekten betrachtet werden, um möglichst effektiv und effizient zu sein. Diese Aspekte sind zumindest die Folgenden:

• ein solides Verständnis des Problems, das durch das Produkt gelöst wird
• eine auf Fluss und kontinuierliche Veränderung ausgerichtete Architektur des Produkts
• eine Teamstruktur, die es ermöglicht, diese Architektur auch tatsächlich dauerhaft umzusetzen und liefern zu können