Bitte entschuldigt den sperrigen Titel. Und gleich vorneweg: Ich habe dafür keine Lösung, sondern nur verschiedene Varianten. Zu diesen möchte ich gerne eure Meinung und Erfahrungen abholen.

Nachfolgend geht es um die Frage, wie man grosse Software-Projekte mit mehreren Teams agil führt. Mit „gross“ meine ich 50 Entwickler und mehr. Ich bewege mich im Scrum-Umfeld und verstehe unter einem Team ein Scrum-Master, ein Product Owner und das Entwicklungsteam.

Der einfache Fall

Praktisch alle Lehrbücher und Schulungen zu den Themen „Agile Software-Entwicklung“, „Agile Architektur“, „Scrum“ etc gehen von folgender Architektur aus:

Für die agile Entwicklung wird dann schnell der Begriff „Self-Contained Systems“ ins Feld geführt. Man soll die Anwendung in mehrere Teile aufbrechen, welche unabhängig entwickelt werden können. Diese können dann von verschiedenen Teams betreut werden, welche die Verantwortung sowohl übers Front- wie auch Backend haben:

Als prominentes Beispiel wird hier gerne Amazon erwähnt. Scheinbar werden dort die verschiedenen Seiten von unabhängigen Teams entwickelt, was sich teilweise in unterschiedlichen Benutzerführungen und Layouts bemerkbar macht. Belege dafür habe ich keine gefunden.

Mehrere Kanäle

Wie man den Schön-Wetter-Fall im grossen Stil agil entwickeln kann ist also klar. Was ist aber, wenn unsere Anwendung über mehrere Kanäle verfügt? Gehen wir nachfolgend von diesem Beispiel aus:

Das Backend beinhaltet die zentrale Logik und bindet verschiedene Umsysteme an. Bedient wird die Anwendung aber über mehrere unabhängige Kanäle. Denkbar sind:

• Webseite (Klassische Webanwendung oder als Single Page Application) für PC-Anwender
• Mobile-App für den mobilen Kunden
• Windows-Fatclient für den bedienten Verkauf
• Embedded-Lösung für ein Verkaufsterminal

Relevant ist, dass jeder Verkaufskanal spezifische Anforderungen hat und mit unterschiedlichen Technologien umgesetzt werden muss. Das Backend besteht aus verschiedenen (Micro-)Services, welche untereinander kommunizieren. Diese lassen sich mehr oder weniger scharf nach Fachlichkeit gruppieren:

Damit ist die Ausgangslage klar und wir können uns der eigentlichen Frage widmen: Wie legen wir unsere Scrum-Teams über diese Architektur?

Komponenten-Teams

Beginnen wir mit der naheliegendsten Lösung: Die Teams orientieren sich an den architektonischen Komponenten.

Pro Kanal gibt es ein zuständiges Team sowie je ein Team pro fachliche Gruppierung im Backend.
Vorteile: Jedes Team hat ein klar zugewiesenes Subsystem. Es hat die alleinige Verantwortung über die Code-Basis und kommuniziert mit den anderen Systemen über definierte Schnittstellen. Das Team kann selbst über Life-Cycle-Massnahmen entscheiden und diese umsetzen. Gerade in den Kanälen kann die Technologie eingesetzt werden, welche für den konkreten Anwendungsfall sinnvoll ist. Im besten Fall ergeben sich aus all diesen Punkte ein starkes Commitment der Teammitglieder zu ihrem Subsystem. Was wiederum zu hoher Qualität und innovativer Weiterentwicklung führt.
Nachteile: Es ist in dieser Konstellation sehr schwierig, Features übers ganze System End-to-End umzusetzen. Die Kanal-Teams können ein Feature erst umsetzen, wenn die nötige Funktionalität und die entsprechenden Schnittstellen im Backend fertig sind. Es besteht das Risiko, dass sich bis dann die Prioritäten im Frontend geändert haben.
Durch das Commitement auf das eigene Sub-System neigen die Teams dazu, die Sicht aufs Ganze zu verlieren. Gerade die Backend-Teams sehen selten den direkten Nutzen ihrer Arbeit für den Kunden.

Feature-Teams

Die agile Entwicklung strebt an, nur Code zu schreiben, welcher für den Kunden einen unmittelbaren Mehrwert bietet. Deshalb bietet es sich an Teams zu bilden, welche autonom ein Feature selbstständig und abschliessend entwickeln können. Dafür muss das Team über Kompetenzen in allen betroffenen Sub-Systemen verfügen. Mit den verschiedenen Kanälen und deren unterschiedlichen technischen Eigenschaften ist dies aber nicht ganz trivial.

Feature-Teams mit Backend-Fokus

Die Backend-Komponenten sind ja schon nach Fachlichkeit gruppiert, was der Feature-Entwicklung zugute kommt. Jetzt brauchen diese nur noch Verstärkung für die Kanal-Entwicklung:

Vorteile: Das Team hat das nötige Wissen, innerhalb seines fachlichen Kernbereiches ein Feature über alle Kanäle autonom umsetzen zu können. Es gibt ein bessere Verständnis für das Gesamtprodukt, weil alle Entwickler auf das gleiche Ziel zusteuern und am Schluss das Resultat sehen. Die geistige Trennung zwischen Kanal und Frontend wird aufgehoben und Entwickler können im ganzen Stack aktiv mitarbeiten.
Nachteile: Die einzelnen Kanäle werden von verschiedenen Teams bearbeitet, welche ausschliesslich einen fachlichen Fokus haben. Technische Weiterentwicklungen oder Life-Cycle-Massnahmen in den Kanälen werden so sehr schwierig umzusetzen. Dies ist insbesondere bedenklich, als gerade der Frontend-Bereich technisch sehr volatil ist.
Pro Sprint werden unterschiedliche Features umgesetzt, welche nicht zwangsläufig alle Kanäle betreffen. Durch die technische Spezialisierung können die Frontend-Entwickler aber nicht beliebig Kanal-übergreifend eingesetzt werden.

Feature-Team mit Kanal-Fokus

Die Kanäle dienen unterschiedlichen Anspruchsgruppen. Entsprechend werden in der Praxis die meisten Features einen bestimmten Kanal im Fokus haben. Deshalb werden in dieser Variante die Entwicklung an den Kanälen ausgerichtet:

Jeder Team hat also seinen Fokus auf den Kanal und wird mit Entwicklern angereichert, welche das Backend-Wissen mitbringen.
Vorteile: Es wird der Tatsache Rechnung getragen, dass die Kanäle technisch sehr unterschiedlich sind. Damit können die technischen Kompetenzen gebündelt werden. Die Schnittstellen und die Logik in den Backend-Systemen können direkt von den entsprechenden Entwicklern umgesetzt werden.
Nachteile: Jetzt sind die Backend-Systeme bezüglich der technischer Weiterentwicklung im Nachteil. Und auch hier wird nicht jedes Feature jedes Sub-System im Backend gleichermassen betreffen. Beides sehe ich hier allerdings weniger kritisch, weil die verschiedenen Services im Backend technisch homogener sein sollten.

Feature-Teams Plus

Bei den oben beschriebenen Feature-Teams ist immer das Problem, das entweder das Kanal- oder das Backend-Team bezüglich der technischen Weiterentwicklung im Nachteil ist. Dies liesse sich beheben, indem sich jeweils ein Kernteam nicht um die fachliche, sondern um die technische Entwicklung der Komponente kümmert:


Vorteile: Die technische Weiterentwicklung der einzelnen Komponenten ist sichergestellt. Die roten Kernteams kümmern sich auch um die Qualität, indem sie die Pullrequest aus den Feature-Teams reviewen. Im DevOps-Modus sind sie für das Releasing und Deployment zuständig.
Nachteile: Solche Kernteams neigen dazu, zu einem Elfenbeinturm zu verkommen. Sie kümmern sich nur um technische Aspekte und vergessen damit den Blick auf die eigentlich relevante Fachlichkeit.

Die Musketiere

Und zum Schluss noch ein ganz anderer Ansatz: Einer für alle, alle für einen:

Es gibt mehrere Entwickler-Teams, die komplett unabhängig von den einzelnen Komponenten oder Fachlichkeiten aufgestellt sind. Entsprechend tragen sie generische Namen wie Alpha, Beta, Gamma etc. Die Feature im übergreifenden Backlog werden bei jedem Sprint zufällig auf die Teams verteilt. Jedes Team hat alle nötigen technischen Kompetenzen, um in jeder Komponente arbeiten zu können.
Vorteile: Maximale Skalierung, da jedes Team alles kann. Life-Cycle-Massnahmen können ins übergreifende Backlog aufgenommen werden und von einem beliebigen Team umgesetzt werden. Es gibt kein Commitment mehr für eine spezifische Komponenten, sondern nur noch fürs Gesamtsystem.
Nachteile: Die Entwickler müssen eine aussergewöhnliche technische Polyvalenz an den Tag legen. Zudem muss der Code und die Architektur in den einzelnen Komponenten sehr stark standardisiert sein, damit die Einarbeitungszeit auf ein Minimum sinkt. Und es bleibt das Problem, dass die Kanäle technisch zu speziell sind, als dass sie von jedem Entwickler verändert werden können.

Fazit

Es handelt sich hier um ein wirkliches Problem. Jede Lösung hat zwar augenscheinliche Vorteile, aber auch fundamentale Nachteile. Als Architekt neige ich zu den Komponenten-Teams.

Deine Meinung?

Jetzt bis du gefragt! Welches ist deiner Meinung nach der beste Ansatz? Hast du mit einer Variante schon konkrete Erfahrungen gemacht? Oder siehst du eine weitere Lösung für das Multi-Kanal-Problem? Her damit! Ich ergänze diesen Artikel gerne um weitere Lösungen.