Warum crossfunktionale Teams bessere Aufwandsschätzungen machen

Bild: Pexel / Fauxels - Lizenz

Zu den heiligen Gralen der agilen Bewegung gehört mit grosser Prominenz das crossfunktionale Team. Im Vergleich zu Teams die einzelnen Technologien oder Bearbeitungsphasen zugeordnet sind gelten sie als deutlich effektiver, und das nicht ohne Grund: sie haben wenige Abhängigkeiten und sind darum weniger darauf angewiesen sich an komplizierten teamübergreifenden Planungen zu beteiligen, sie haben einen ganzheitlichen Blick auf ihr Produkt und können darum Zusammenhänge und potentielle Fehlerquellen schon früh erkennen und sie sind diverser und darum weniger anfällig für Group Think und ähnliche Phänomene. Ein weiterer Aspekt wird dagegen selten genannt, obwohl er ähnlich wichtig ist - crossfunktionale Teams machen bessere Aufwandsschätzungen.

Um zu verstehen warum das so ist empfiehlt sich eine Annäherung von der Gegenseite. Warum sollen komponenten- und technologiebasierte Teams nicht genau so gute Schätzungen abgeben können, reicht es denn nicht aus wenn jeder Teil seinen Aufwand schätzt und das danach addiert wird? Die Antwort: leider nein, es reicht nicht. Nicht crossfunktionale Teams geben überproportional häufig unrealistisch niedrige Schätzungen ab. Und zwar deshalb weil auf die Arbeit an einem Produkt das alte Sprichwort zutrifft - sie ist mehr als die Summe ihrer Teile.

Es beginnt damit, dass in "verteilten Schätzungen" Verständnisprobleme und Missverständnisse zwischen den (Teil)Teams selten berücksichtigt werden. Dem liegen sehr menschliche Verhaltensweisen zu Grunde: vorgelagerte Teams gehen zu oft davon aus alles verständlich übergeben zu haben (schliesslich haben sie selbst ja alles problemlos verstanden) und nachgelagerte Teams sind zu häufig der Meinung alles verstanden zu haben (schliesslich können sie nicht wissen was sie noch nicht wissen). Sobald diese Fehlkommunikation sichtbar wird muss neue, ungeschätzte und ungeplante Arbeit erledigt werden.

Ein weiterer Grund ist die kaum gegebene Machbarkeit reibungsloser Übergaben. Fast nie wird das nachgelagerte Team genau dann mit seiner bisherigen Tätigkeit fertig sein wenn das vorgelagerte Team seine Zulieferung fertiggestellt hat. Dann bleiben nur drei Möglichkeiten: 1.) das vorgelagerte Team fängt mit seiner nächsten Arbeit an und macht die Übergabe später, 2.) das nachgelagerte Team nimmt die Übergabe sofort an, beginnt die Arbeit aber erst später oder 3.) das nachgelagerte Team unterbricht seine bisherige Arbeit, nimmt die Übergabe an, erledigt die sich daraus ergebenden Tätigkeiten sofort und geht danach zur vorher begonnenen Aufgabe zurück. In allen drei Fällen kommt es zu Multitasking und Kontext-Switching, wodurch die Arbeit ineffektiver und langsamer wird als anfangs geschätzt.

Zuletzt besteht das Risiko, dass die Egoismen der einzelnen beteiligten Teams das gemeinsame Ziel in den Hintergrund drängen. Wenn vorgelagerte Teams ihre Aufwandsschätzungen "einhalten" können indem sie nachgelagerten Teams unfertige, schlecht getestete oder schlecht dokumentierte Zulieferungen übergeben, dann kann das eine Verlockung sein. Umgekehrt können nachgelagerte Teams versucht sein ihre Schätzungen "wahr werden zu lassen" indem sie Zulieferungen nicht anzunehmen solange darin nicht umfangreiche Vorarbeiten enthalten sind die sie sonst selbst machen müssten.

Diese Faktoren, die für die meisten der zu niedrigen Schätzungen ursächlich sein dürften, treten bei crossfunktionalen Teams deutlich seltener auf. Verständnisprobleme und Missverständnisse lassen sich in gemeinsamen Schätzungsterminen früh erkennen, ohne Abhängigkeiten von anderen Organisationseinheiten entfallen die Probleme mit den Übergaben und das Zusammenlegen von Teamziel und Produktziel verhindert, dass diese gegenläufig werden. Sowohl im Vorfeld als auch während der Umsetzung gibt es dadurch deutlich weniger mögliche Ursachen für eine falsche Aufwandsschätzung.

Nur um es klar gesagt zu haben - auch crossfunktionale Teams können sich natürlich verschätzen. Die Wahrscheinlichkeit dass das passiert ist aber deutlich geringer als bei Teams die einzelnen Technologien oder Bearbeitungsphasen zugeordnet sind.