Unsere Erfahrungen mit crossfunktionalen Teams

Seit 2010 haben wir verschiedenste Team-„Konfigurationen“ ausprobiert. Hier berichten wir von allen Vor- und Nachteilen.

In unserer Vor-Scrum-Ära hatten wir keine richtigen Teams. Das waren eher Gruppen von Leuten mit gleichem Skill-Set. In einem Raum saßen die Web-Entwickler, daneben die Perl-Developer, dann ein Raum mit Projektmanagern, und so weiter…

Scrum: Crossfunktionale Teams

Heute läuft das anders! 2010 fingen wir an nach Scrum zu arbeiten. Wir organisierten uns um in crossfunktionale 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. 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 crossfunktional!

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, Kundenbetreuung und Vertriebsmenschen. 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, erfahren Sie es auf jeden Fall hier.

Arbeitskultur, Infrastruktur und mehr

Hier teilen wir unsere Erfahrungen mit der digitalen Transformation – von kleinen Apps, bis hin zu großen Organisationsstrukturen.

Und es geht weiter

Wir bleiben nicht stehen und teilen gerne weiterhin unsere Erfahrungen mit Ihnen. Abonnieren Sie einfach unseren Infoletter und wir melden uns mit neuen Einblicken.