Freitag, 6. November 2020

Crossfunktionale Teams (III)

Bild: Pexels / Tom Fisk - Lizenz

Wenn man sich in Firmen umhört die sich dem agilen Arbeiten verschrieben haben dann gehört das Bekenntnis zu den crossfunktionalen Teams mittlerweile zum Standard. Es ist weitgehend anerkannt, dass nur eine Einheit die alle zur Produktherstellung nötigen Skills enthält schnell auf Änderungen reagieren kann ohne auf Zulieferungen warten zu müssen, und dass solche Einheiten auch wesentlich besser darin sind die dabei entstehenden Aufwände zu schätzen kommt noch dazu. Es ist also alles gut. Oder?


Zugegeben, die Frage war rhetorisch. Tatsächlich ist in den meisten Fällen noch nicht alles gut, ein näherer Blick zeigt warum. In agilen Teams wird die Crossfunktionalität (ohne bösen Willen, bzw. durch fehlendes Verständnis) meistens auf Entwickler-Spezialisierungen reduziert.1 Ein so verstandenes Team besteht dann etwa aus zwei Frontend-Entwickler, zwei Backend-Entwicklern und zwei Testern. Crossfunktional? Ja, aber nur innerhalb eines Silos. Das reicht nicht.


Was in solchen Konstellationen zur Crossfunktionalität im eigentlichen Sinn fehlt ist die Einbeziehung derjenigen Organisationsbereiche die man als "Upstream" und "Downstream" bezeichnet. Gemeint sind damit die Menschen (oder Kompetenzen) mit denen auch die der Entwicklung vor- und nachgelagerten Tätigkeiten entlang der Bearbeitungskette durchgeführt werden können.


Upstream (stromaufwärts) befindet sich zum Beispiel das Anforderungsmanagement, also vereinfacht gesagt die Menschengruppe die den Kontakt zu Auftraggebern und Nutzern hat. Da dieser Kontakt nötig ist um regelmässiges Anwender-Feedback zu erhalten gehört diese Kompetenz genauso in die Teams wie der nächste Schritt, die Konzeption, in dem Business Analysten, Architekten, UX-Designer und ähnlichr Rollen bereits für die Entwicklung wichtige Entscheidungen treffen.


Anders strukturiert aber genauso wichtig ist der Bereich Downstream (stromabwärts). In ihm befinden sich Kompetenzen wie Integrationsmanagement, Testmanagement, Releasemanagement und Rolloutmanagement, ohne die neue Features nicht auf Produktions- oder Abnahmeumgebungen gelangen können. Da aber erst dort der Anwenderkontakt stattfindet (der die zwingende Voraussetzung für das folgende Feedback ist) gehört auch das ins Team.


Wichtig zum richtigen Verständnis ist dabei: es sind die Kompetenzen die in die Teams gehören und nicht notwendigerweise die Rollen. Architektur, UX-Design und Testmanagement können in den meisten Fällen auch vom Entwicklungsteam verantwortet werden (was übrigens Architekten, UX-Designer und Testmanager nicht überflüssig macht sondern deren Rolle in Richtung Coaching und Servant Leadership verändert).


Und um auf eine an dieser Stelle häufig geäusserte Sorge einzugehen: ja, auch aus Governance- und Compliance-Sicht ist ein derartig crossfunktionales Team in der Regel zulässig und arbeitsfähig. Man muss sich nur darauf einlassen wollen.


1Wobei derartige Teams bei genauerer Betrachtung meistens nicht wirklich agil agieren

Related Articles