dot.tipp - Was ist der richtige Teamschnitt? Komponenten- vs Feature-Teams
Kennt ihr das?
- Sprint-Reviews, in der keine neuen fachlich relevanten Resultate, aka Value, gezeigt werden.
- Ausufernde, teamübergreifende Abstimmungs- und Koordinationsmeetings.
- Fachliche Anforderungen werden nicht stetig, sondern erst am Ende des Projekts fertig.
Dann wird es Zeit, sich den Teamschnitt genauer anzuschauen.
In diesem Blogbeitrag wird die Relevanz des Teamschnitts aufgezeigt. Dabei werden u.a. die Themen Komponententeams, Featureteams, End-2-End-Verantwortlichkeit und Crossfunktionalität beleuchtet.
Unabhängigkeit führt zu Geschwindigkeit
Ein Team, das nach jedem Sprint Wert für den Kunden liefern und dies in einem Review zeigen soll, muss von anderen Teams unabhängig arbeiten können.
Ist diese Unabhängigkeit nicht gegeben, kann das Team die Zielerreichung nicht aus eigener Hand gewährleisten, sondern ist vielmehr auf externe Hilfestellung angewiesen, welches das Team oft ausbremst und in seinem Flow stört.
Dies ist Gift für den Produktfortschritt und für die Motivation des Teams, das sich natürlich auch über seine eigene Zielerreichung motiviert.
Wie entsteht Abhängigkeit?
Team-übergreifende Abhängigkeit entsteht dadurch, dass die Teams nicht End-2-End aufgestellt sind. Ich möchte dabei folgende zwei End-2-End Probleme und die damit verbundenen Abhängigkeitsarten unterscheiden:
- Architektonische Abhängigkeit - Komponententeams
- Fehlende Crossfunktionalität
Die architektonische Abhängigkeit - Komponententeams
Diese Abhängigkeit entsteht durch die Verantwortungsteilung für technische Bausteine unter den verschiedenen Teams. Diese Teilung führt dazu, dass ein Team gar nicht alle technischen Bauteile verantwortet, die es für die Umsetzung einer fachlichen Anforderung verändern müsste. Man spricht hierbei von Komponententeams.
Wie wirkt sich dies nun aus? Eine Kunden-Anforderung, welche an das Team gelangt, ist üblicherweise End-2-End formuliert, da es sich in der Regel um eine fachliche Anforderung handelt. Hierzu ein Beispiel zur Illustration.
Beispiel: Der Kunde wünscht sich in seinem Verkaufs-Tool die Möglichkeit, ein neues Produkt auf der Verkaufsmaske auswählen zu können. Dies entspricht einer reinen Fachlichkeit. Der Kunde formuliert damit also sein Bedürfnis, seine Anforderung, also das WAS.
Die Lösungsfindung, das WIE, also in diesem Beispiel die technische Umsetzung der Anforderung obliegt dann der Verantwortung des Lieferanten, also des Teams. Wenn nun aber die Implementierung der Anforderung nicht von einem Team, sondern von mehreren Teams umgesetzt werden muss, weil die Teams, die davon tangierten technischen Bauteile unter sich aufgeteilt haben, dann entsteht eine Abhängigkeit.
Zwangsweise verlangt ein Schnitt in solche Komponententeams auch immer eine nachgelagerte, übergeordnete End-2-End Testingphase und eine Integration der einzelnen Komponenten, da diese Aufgaben ja nicht von einem einzelnen Team zur Umsetzungszeit gemacht werden können.
Die fehlende Crossfunktionalität
Das Problem der fehlenden Crossfunktionalität und der damit einhergehenden Abhängigkeit entsteht durch einen Teamschnitt, der auf Entwicklungsphasen (z. B., Analyse, Entwicklung, Parametrierung, Test, Betrieb) basiert. Dies führt konsequenterweise dazu, dass ein Team nur einen Teilschritt der Umsetzung selbst leisten kann, zum Beispiel die Entwicklung. Sobald diese abgeschlossen ist, wird das Artefakt übergeben und es kommt ein weiteres Team zum Einsatz, zum Beispiel das Testing Team. Wie schnell zu erkennen ist, führt dies zu einer vollständigen Abhängigkeit zwischen den Teams für jede einzelne fachliche Anforderung, die umgesetzt werden soll.
Crossfunktionalität bedeutet also, dass alle nötigen Disziplinen im Team vertreten sind. Damit soll gewährleistet werden, dass alle für die Umsetzung notwendigen Aufgaben (die Analyse, Entwicklung über alle technischen Layer und das Testing) durch das Team ausgeführt werden können.
Dieser Teamschnitt ermöglicht es, dass das Team die Fähigkeit besitzt, einen rein fachlich formulierten Arbeitsauftrag (eine Funktion, ein Prozess(teil), ein Feature, etc.), vollständig umsetzen zu können. Wie man reine Fachlichkeit formuliert (also nur das WAS und nicht das WIE) ist eine andere Fragestellung und die Aufgabe des Product Owners und wird im Rahmen des Backlog Managements ausgeführt.
Das Problem von Abhängigkeiten
Abhängigkeit manifestiert sich oft in sehr aufwendiger und häufiger team-übergreifender Kommunikation und Abstimmung. Damit sind Missverständnisse, Mehraufwände und Verzögerungen vorprogrammiert. Ferner kann die Anforderung des Kunden nicht mehr fixfertig von einem einzelnen Team umgesetzt werden. Das Resultat eines Teams sind also Halbfertigfabrikate, die man dem Kunden zwar am Review zeigen kann, aber vielfach eher zur Verwirrung beitragen, als zur Klärung von offenen Fragen. Nichts zeigen ist ja nun auch keine wirkliche Option. Damit ist das Dilemma perfekt.
Reality Check
In den meisten Organisationen, die sich auf den Weg zu einer agilen, lernenden Organisation gemacht haben, gibt es (noch) keinen reinen Schnitt nach Feature Teams. Woher kommt das? Wieso werden denn nicht einfach Feature-Teams eingeführt und alle Probleme sind gelöst?
Eines der grössten Hindernisse für Feature-Teams findet man in der Grösse der Deploymenteinheit des Systems. Um unabhängig arbeiten zu können, muss ein Team selbstständig deployen können, ohne andere Teams zu beeinträchtigen. Grosse (monolithische) Systeme müssen als eine grosse Einheit deployed werden. Ein solch grosses System kann jedoch nicht mehr von nur einem Team weiterentwickelt und betrieben werden und führt somit zwangsweise zu Abhängigkeiten. Es braucht also kleinere Deploymenteinheiten. Dies führt uns zum Themen-Cluster Service Mesh/Domain Driven Design/Microservices Model. Dieses Architektur-Pattern ist darauf ausgerichtet, das System in unabhängige entkoppelte End-to-End-Services (Microservices) zu teilen, welche eine einzige Geschäftsfunktion abbilden, zum Beispiel den Bestellvorgang eines Verkaufssystems. Durch die konsequente Anwendung einer sinnvoll geschnittenen Microservice-Architektur, werden also Feature-Teams erst möglich. Das Gesetz von Conway liefert die Begründung, warum sich eine solche Architektur dann auch optimal entlang des Teamschnitts halten und festigen kann und keine Verwässerung des gewählten Architektur-Musters in der täglichen Arbeit nötig wird.
Aus der obigen Begründung wird auch klar, weshalb dem Themen-Cluster Service Mesh/Domain Driven Design/Microservices Model eine zentrale Bedeutung als Enabler für Agilität zugeschrieben wird.
Fazit
Ist ein System oder eine ganze Systemlandschaft (noch) nicht sauber fachlich entkoppelt, dann können nicht ohne weiteres Feature-Teams eingeführt werden. Der Schritt hin zu mehr Agilität und zu Feature-Teams führt also über eine schrittweise Veränderung der Architektur mittels Domain Driven Design in Richtung Microservices.
Wie steht ihr zu dem Thema?
Gibt es bei euch bereits erste Versuche mit Feature-Teams? Welche Gründe seht ihr dafür, dass es (noch) keine Feature-Teams gibt? Wir sind gespannt auf eure Meinung! Gerne könnt ihr den Blogbeitrag kommentieren oder euch mit uns in Verbindung setzen.
Eventuell interessant
Verwandte Blogs
Keine Kommentare
Teile deine Meinung