Total cross-funktional

[Dieser Post erschien zuerst auf Englisch.]

Seit wir 2010 mit Scrum angefangen haben, haben wir verschiedenste Team-„Konfigurationen“ ausprobiert. Hier stellen wir euch Teamzusammenstellungen im Laufe der Jahre vor und was jeweils die Vor- und Nachteile waren.

Spoiler Alert: Was wir 2010 für „cross-funktional“ hielten, war weit unter dem, was wir heute in 2016 bei unseren Produktteams für wünschenswert halten.

Vor Scrum: Silos

In unserer Vor-Scrum-Ära hatten wir keine richtigen Teams. Das waren eher Gruppen von Leuten mit gleichem Skill-Set, die zusammen in einem Raum saßen. Jeder hatte eigene Aufgaben zu tun. In einem Raum saßen alle Web-Entwickler, daneben die Perl-Hoschis, dann ein Raum mit Projektmanagern, und so weiter.

Diese Unterteilung war nicht der Stein der Weisen. Schön zu sehen an einem Beispiel aus jenen Tagen: In sipgate team Accounts gibt es eine Seite, die alle Gruppen des Accounts auflistet. Diese Seite hatte grausig langsame Ladezeiten. Ich spreche hier von mehreren Minuten! Als wir uns das später einmal näher anguckten, stellte sich heraus, dass die Seite jede Menge Anfragen ans Backend stellte, obwohl sie von den Infos in den Antworten jeweils nur Bruchteile anzeigte. Es gab einfach keine spezialisierte Funktion im Backend, die nur genau das lieferte, was diese Seite brauchte. Und da Web-Entwickler und Backend-Entwickler damals getrennt arbeiteten, holten sich die Web-Entwickler die Informationen mit Funktionen, die es halt schon gab. Eine neue Funktion zu bauen, hätte alles auf unbestimmte Zeit verzögert.

Scrum: Cross-funktionale Teams

Heute würde das anders laufen! 2010 fingen wir an nach Scrum zu arbeiten. Wir organisierten uns um in cross-funktionale Teams, in denen Entwickler, User Experience Leute und Product Owner zusammen arbeiteten. Die Product Owner waren die ehemaligen Projektmanager. Jeweils ein Entwickler pro Team hatte eine Doppelrolle und war zusätzlich Scrum Master. So ein Team arbeitete an gemeinsamen Aufgaben und konnte ein komplettes Stück Funktionalität alleine bauen.

Mit diesem Setup konnten wir schon sehr viel schneller neue Features entwickeln als vorher. Vor-Scrum hatte sich die Entwicklung oft lange hingezogen. Ab-Scrum hatten die fünf Product Owner plötzlich Probleme, sich ausreichend Features zu überlegen, damit alle Teams genug zu tun hatten. So weit, so gut.

Blöderweise hatte die Kommunikation zwischen den Teams etwas gelitten. Und das obwohl alle fünf Teams an den gleichen Produkten arbeiteten. Nicht unbedingt gleichzeitig, aber im Laufe der Zeit auf jeden Fall. Alle Teams zogen ihre Aufgaben aus dem gleichen Backlog. Wir wollten auf diese Weise flexibel bleiben, wie viel Energie wir wann in welches Produkt stecken. In der Praxis standen sich die Teams oft gegenseitig im Weg. Wenn ein Team Mist baute, war es gut möglich, dass ein anderes Team den Code zunächst aufräumen musste, bevor es loslegen konnte. Nicht die besten Voraussetzungen, um gut miteinander zu arbeiten.

Es war außerdem schwer, sich mit einem bestimmten Produkt zu identifizieren. Man kann sich einfach schlecht mit stolz geschwellter Brust hinstellen und sagen „Hier, guck mal! Toll, nich? Hab ich gebaut!“ wenn immer sehr, sehr viele Leute beteiligt sind, sogar bei kleinen Features.

Produkt-Teams – Jetzt mit noch mehr cross-funktional!

Heute arbeitet ein Team an genau einem Produkt. Dadurch können sich die Teammitglieder mit ihrem „Baby“ identifizieren und Produkt-Spezialwissen aufbauen. An manchen Produkten arbeitet mehr als ein Team, jeweils mit unterschiedlichem Fokus. Aber kein Team arbeitet an mehr als einem Produkt.

Außerdem haben wir inzwischen noch mehr Rollen in Teams: dedizierte Scrummaster, Marketing-Menschen und Kundenbetreuung. So sind alle Kundenprobleme nur einen Schreibtisch weit entfernt von den Leuten, die Problemursachen beseitigen können. Bisher funktioniert das gut für uns.

Das, wo wir am meisten ausprobiert haben und immer noch probieren, ist die Einbettung der User Experience: Sind sie ein eigenes Team? Hat jedes Team seinen eigenen UXer? Ein bisschen was von beidem? Die Schwierigkeit besteht auch darin, dass sich hinter der UX-Rolle verschiedene Spezialisierungen verstecken (Design, Konzepte, Texte, …). Sobald wir die „silver bullet“ finden, erfahrt ihr es auf jeden Fall hier im Blog!