Warum ist es so schwer, ein Scrum-Team zu bilden?

Eine typische Organisationsform für System- und Softwareentwicklung sind Komponenten-Teams. Entwickler werden um Komponenten herum gruppiert, es gibt ein Team für Komponente X und eines für Komponente Y; dann gibt es auch oft Spezialteams wie ein GUI-Team oder ein Test-Team.

Eine andere weitverbreitete Organisationsform ist die Einteilung in Silos, Pools oder Services entlang der Disziplinen, also ein Requirements-Service, ein Design-Service, ein Test-Service (das eignet sich für Outsourcing angeblich sehr gut) und die Mitarbeiter dieser Services werden dann Projekten gemäß ihrer „Spezialisierung“ zugeordnet. Jeder Mitarbeiter arbeitet gewöhnlich in mehreren Projekten gleichzeitig.

Jeder will heute irgendwie agil sein und Scrum machen, das klingt so dynamisch und zeitgemäß. Es hat sich mittlerweile auch herumgesprochen, daß agiles Vorgehen bei der Entwicklung komplexer Produkte besser funktioniert als traditionelles, sequentielles Vorgehen. Aber es funktioniert nur dann wirklich gut, wenn nicht nur Lippenbekenntnisse und neue Namen dahinterstecken, sondern tatsächlich die agilen Werte und Prinzipien umgesetzt werden. Der wesentliche Aspekt sind dabei die Menschen, die Art, wie sie zusammenarbeiten und sich organisieren.

Scrum wird von Scrum-Teams gemacht. „Echte“ Scrum-Teams werden auch als Feature-Teams bezeichnet, wobei hier unter Feature ein für den Kunden wertvolles Etwas verstanden wird. Ein Feature-Team soll also in der Lage sein, unabhängig von anderen Teams dem Kunden einen Wert zu liefern.

Ein Feature-Team zeichnet sich durch folgende Eigenschaften aus:

• es organisiert und managt sich selbst,
• es deckt alle Fähigkeiten ab, die für die Lieferung eines Kundenwertes (Feature) notwendig sind (das heißt NICHT, daß jeder alles können und kennen muß!),
• es arbeitet damit auch Komponenten-übergreifend, da für die Erstellung eines Kundenwertes typischerweise mehrere Bereiche eines Systems (Komponenten) betroffen sind,
• es arbeitet über einen längeren Zeitraum (mehrere Jahre) zusammen, um eine hohe und zuverlässige Performanz (velocity) zu erreichen,
• es arbeitet an einem Standort zusammen,
• es besteht typischerweise aus 7 +/- 2 Mitgliedern.

Ein Feature-Team hat also die Verantwortung für die komplette Fertigstellung eines Backlog-Elementes und für die Koordination im eigenen Team und mit anderen. Es braucht damit keinen Projektmanager oder irgendeine Form von Matrixmanagement, da die Koordination auf dieser Ebene trivial ist. Da das Team die komplette Arbeit macht, sind keine Übergaben, die auch koordiniert werden müßten, notwendig und Wartezeiten werden reduziert.

Die Erfahrung zeigt, daß Komponenten-Teams, die sich nur mit einem Teilbereich eines Systems beschäftigen, typischerweise Code erzeugen, der nur noch von ihnen selbst verstanden und gewartet werden kann. Natürlich sind an komplexen Systemen viele Teams beteiligt und die Entwicklung komplexer Systeme erfordert viel Koordination. Die Ebene der Koordination ändert sich aber bei agilem Vorgehen mit Feature-Teams drastisch. Die Koordination findet nicht mehr auf der Ebene der Services oder Komponenten-Teams statt, sondern auf der Codeebene. Moderne Engineering-Praktiken, wie Continuous Integration und Test-Driven Development und der Einsatz entsprechender Werkzeuge ermöglichen es, daß viele Teams gleichzeitig und unabhängig voneinander an den gleichen Komponenten arbeiten können. Da alle Feature-Teams auf der gleichen Codebasis arbeiten und prinzipiell alle Komponenten eines Systems ändern können müssen, wird erheblicher Druck aufgebaut, ein einfaches Design und sauberen Code zu erzeugen. Kontinuierliches Refactoring und die Einbettung aller Änderungen in Unit-Tests werden zur gängigen Praxis.

Wenn die Entwicklung über mehrere Standorte hinweg geschieht, wird dies oft entlang des Entwicklungszyklus organisiert, etwa Anforderungen und Design in München, Entwicklung in Polen und Testen in Indien, verstößt das fundamental gegen agile Werte und Prinzipien. Es führt zu unnötiger Lagerhaltung, Übergaben und Verzögerungen, zu schlechten Durchlaufzeiten und verhindert zügiges Feedback. Diese Art der Organisation führt zwangsläufig zur Zementierung des Wasserfalldenkens.

Tom DeMarco hat auf die Frage, ob ein Team existieren kann, wenn die Menschen nicht an einem Standort zusammen sind und sich oft sehen und sprechen können, geantwortet:

No, teams have to be together. Remoteness makes the good community aspects impossible. Too often we name a group of people a team. They don´t acquire teamhood. They have it ascribed to them. [DeMarco, T., 1995, “Conversation with Tom DeMarco”, Computerworld, Dec.1995]

Natürlich sind die negativen Auswirkungen verteilter Teams unterschiedlich und abhängig von Gegebenheiten wie Sprache, Kulturkreis, Zeitzone, persönlicher Bekanntschaft und auch Technik. Es ist besser, wenn 4 Leute in München und 3 in Hamburg arbeiten, als 4 in München und 3 in Indien; es ist besser, wenn alle Teammitglieder die gleiche Muttersprache sprechen und dem gleichen Kulturkreis angehören; es ist besser, wenn alle Teammitglieder schon einmal für einen längeren Zeitraum an einem Standort zusammengearbeitet haben und sich persönlich kennen, und es ist besser, wenn Video Chats möglich sind statt nur Email-Kommunikation. Aber, wer alle Früchte ernten will, sollte dem Ideal möglichst nahe kommen. Statt Teams über Standorte hinweg zu schneiden, ist es besser, Feature-Teams pro Standort zu bilden.

Uwe Valentini

Kontaktieren Sie Uwe Valentini

Uwe Valentini arbeitet bei Agile-by-HOOD als Berater und Coach mit viel persönlichem Engagement mit Menschen, Teams und Organisationen auf ihrem Weg zu mehr Agilität. Uwe ist leidenschaftlicher Agilist, er lernt jeden Tag etwas Neues und hat viel Spaß daran. Sein Motto: Agilität beginnt im Kopf.