Planung für Komponententeams: Die Hölle
Letztens musste ich aus einem Zufall heraus in einem Workshop das Thema Planung für Komponententeams (vs. Featureteams) streifen und musste darüber nachdenken, warum es so schwierig ist, für Komponententeams zu planen.
Dazu fiel mir eine kleine Übung ein. Ich weiss nicht ob es diese Übung schon gibt und ob sie fair ist oder nicht. Ich weiss aber, dass sie sich so anfühlt wie die Planungen, die ich früher lange genug für Komponententeams machen musste, bevor ich endlich mit Featureteams arbeiten durfte.
Ich will an dieser Stelle auch gar nicht darauf eingehen, wie schwer es ist zu Featureteams zu kommen. (Ich weiss es 
Ich will hier auch nicht auf die Hemmnisse eingehen, die einen davon abhalten können, oder auf die gefühlten Nachteile und die daraus entstehenden bangen Fragen, wie „Ist das noch die selbe Qualität? Verlieren wir nicht unser Spezialwissen?“
Hier also die Übung (siehe Titelbild):
Es gibt vier Komponententeams: Rot, Blau, Grün und Gelb. (Rot könnte z. Bsp. für Backend, Datenbank, Payment API oder was auch immer stehen, Blau für Business Logik, Advertising, SAP Anbindung oder was auch immer stehen).
Die Teams sollen gemeinsam vier Features abarbeiten. Die Tasks sind oben in ihrer notwendigen Reihenfolge als farbige Kärtchen aufgeführt. (Ergebnis eines SAFe PI Planning?) Die Zahlen in den Tasks sind – der Einfachheit halber – die Schätzung in Tagen.
Die Aufgabe ist es nun, die Planung für meine 4 wichtigsten Features zu machen und mir die einfache Frage zu beantworten: Wie arbeiten die Teams die Features ab? Die Regel ist natürlich: das erste Feature soll erst geliefert werden, das vierte zuletzt. Eigentlich reicht mir die Antwort, wann die Features jeweils kommen. Wer mir noch zeigen kann, wie die Teams sich Ihre Aufgaben schnappen, kann das gerne tun. Das Schöne an der Situation: Wir haben fertig geschätzte tasks und Du kannst gerne davon ausgehen, dass diese korrekt sind Du hast fünf Minuten Zeit für diese einfache Übung.
Fertig? Bedenke: Die Aufgabe ist also ein vollkommen vereinfachter Laborversuch in der Planung von lediglich vier perfekt vorbereiteten Features. Verrückterweise ist diese Übung trotzdem schwer. Keins der Teams konnte die Übung beantworten. Ich weiss, dass man das lösen kann. Der Punkt ist einfach wie schwer diese einfache Übung ist.
Als kleine didaktische Komplikation könnten wir überlegen, was es bedeutet umzuplanen, weil Änderungen in den Schätzungen eintrudeln:
Aufgabe Nummer 2 – sich ändernde Schätzungen
- Feature 1: die erste Task, Team Rot, geht schneller und dauert nur 2 statt 5 Tage.
- Feature 2: die zweite Task, Team Grün dauert 4 statt 3 Tage
- Feature 3: die erste Task, Team Rot, dauert länger: 5 statt 3 Wochen.
Die Nettoarbeitszeit bleibt also (zufälligerweise) sogar gleich: Wann sind die Features jetzt fertig?
Aufgabe 3 – Veränderte Prioritäten
Noch eine – realistische – Komplikation könnte Neuplanung aufgrund von Repriorisierung sein: Feature 3 wird das wichtigste und Feature 1 übernimmt seine Position. Was passiert jetzt? Wann sind die Features fertig? jedes einzelne und alle gesamt? Und: Wie würde die Planung für 4 Featureteams aussehen?
Beim Ausdenken der einfachen Aufgabe hat es mich noch einmal fast umgebracht, wie kompliziert die Planung in diesen Abhängigkeiten ist.
Und plötzlich wusste ich wieder, warum ich diese Art der Planung nicht mag (wenn auch nicht verdamme, denn ich weiß, dass sie in vielen Umgebungen einfach noch nötig ist). Aber der Charme von Flow und forecasting wird doch wieder sehr klar.
Anmerkung: Bald werde ich meine Blogposts über meinen Newsletter bekanntmachen. Wenn Du über Posts informiert werden willst, oder über meine Trainings und Veranstaltungen, dann melde ich bitte hier an. Danke!