Total cross-funktional

Alex
09.02.2016 6 3:40 min

[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.

gruppen-vor-scrum

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.

teams-2010

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.

teams-2013

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!

 

6 Kommentare


Simon:

Das hört sich gut an! Wäre schön, wenn die interne Kommunikation dann dazu gereicht, dass endlich auf die 032-Vorwahl unterstützt wird ;-)

antworten

Alexander:

Sehr spannende Innenansicht, Danke! There are no silver bullets … ;)

antworten

Benedikt:

Vielen Dank für die spannende Innenansicht Eurer Entwicklung und die Veränderung über die Zeit.

Eine Punkt würde mich noch interessieren:

In welcher Form ist die Kundenbetreuung bei euch in die Teams integriert?

* Nimmt diese beim Daily, Review, Retro des Entwicklungsteams teil?
* Was berichtet die Kundenbetreuung im Daily?
* Hat die Kundenbetreuung Aufgaben im Sprint?

Bin gespannt. Finde es einen super Ansatz die Kundenbetreuung in die Teams zu integrieren und so mehr Kundennähe zu erhalten.

antworten

Corinna:

Hi Benedikt!
Die meisten Produktteams haben Kundenbetreuer dabei. Meist so 2-4. Diese nehmen dann auch an allen Scrum Ritualen teil, sie gehören ja zum Team.
Im Daily Stand Up erzählen sie meist allgemeine Auslastung und wenn es etwas besonderes gab / für den Tag geplant ist. Manchmal gibt es in Stories Tasks für Kundenbetreuer (Doku, bei Interfacekonzepten helfen, …). Manchmal haben sie eigene Stories, z.B. wenn uns auffällt, dass wir Teile unserer FAQ systematisch überarbeiten sollten.
Außer den Kollegen in Produktteams gibt es noch Teams nur aus Kundenbetreuern, z.B. für die Hotline und den Großteil der Email-Tickets. Wenn die alle in Produktteams gingen, wären die Teams einfach zu groß.

Beantwortet das Deine Fragen?
Beste Grüße, Corinna

antworten

Benedikt:

Hallo Corinna,
vielen Dank für die offene Rückmeldung.
Ja, das hört sich nach einem spannenden Ansatz an.
Viele Grüße
Benedikt

antworten

Christoph:

Hallo Corinna,

es freut mich, dass sich die Teamzusammenstellung in diese Richtung entwickelt hat. Das vielfache Wechseln von Themen über mehrere Teams hinweg hat es tatsächlich oftmals schwer gemacht, dass sich das Team mit seinem „Baby“ identifiziert.
Somit eine erfreuliche Entwicklung, wobei diese natürlich immer weiter geht ;)

Viele Grüße

Christoph

antworten

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert