Stagnierende Teams

Wie immer: diese Gedankensammlung ist Work in Progress, kann und wird sich vermutlich noch mehrfach ändern.

Was ist ein stagnierendes Team?

Gelegentlich haben wir es als Scrum Master*in mit einem Team zu tun, das eine gute, stabile Lieferfähigkeit zeigt, sich aber nicht mehr weiterentwickelt. Aus Sicht des Scrum Masters kann das ein Problem sein, da es ja Teil des SM-Jobs ist, das Team kontinuierlich weiter zu verbessern. Aber wenn es nichts mehr zu verbessern gibt?

Das Team ist gut eingespielt, die technische Umgebung ist auf dem Stand der Dinge, die Testabdeckung ist gut und aussagekräftig, jeder Check-In wird gebaut und getestet, die Disziplin bei gebrochenem Build gemeinsam den Fehler zu suchen ist exzellent, kurz – es findet sich nichts zu meckern. Das gibt es wirklich!

Perspektiven

Jede Veränderung und Verbesserung erfordert einen Invest an Zeit ,Geld und Produktivitätsverlust. Und natürlich ist die Abwägung, ob der Invest eine Aussicht auf einen positiven Return hat nicht nur legitim, sondern es wäre fahrlässig sie zu ignorieren. Wenn also z.B. in technischer Hinsicht die Einführung eines moderneren Tools oder einer geänderten Entwicklungsstrategie mehr Invest erfordert als im Rahmen des erwarteten Projekt- oder Produkt-Lebenszyklus noch zu erwirtschaften ist, dann ist das vielleicht technisch reizvoll, aber unternehmerisch vielleicht unsinnig. Oder die Fähigkeiten sollen in der Organisation noch anderweitig zum Einsatz kommen, dann kann es dennoch sinnvoll sein, es gibt da viele unterschiedliche Einflußfaktoren und Perspektiven.

Die erste Frage, die sich also ein Scrum Master*in oder Team Coach*in an dieser Stelle beantworten muss (im Austausch mit allen Beteiligten, auch den Sponsoren außerhalb des Teams), ob eine weitere Veränderung überhaupt wünschenswert und erforderlich ist. Und dann gilt es die geeigneten Fähigkeiten zu identifizieren, die man sich aneignen muss, und die organisatorischen Veränderungen, die notwendig sind um diese Fähigkeiten auch zum Einsatz zu bringen.

Der Ausweg

Es gibt also einen Weg hinaus aus dem Plateau oder der Stagnation eines guten Delivery-Teams. Die Risiken und Nebenwirkungen muss eine Organisation auch aushalten können, denn eine Team in der Optimizing-Zone wird vielleicht deutlich mehr Reibungshitze im Umfeld erzeugen als die stabil funktionierende „Software-Fabrik“ des Teams in der Delivery-Zone. Optimizing Zone bedeutet mehr Verantwortung für die Produktgestaltung, mehr direkte Ergebnisverantwortung, mehr Kundenkontakt, mehr Produkt-Experimente. Es bedeutet aber auch, die Grenzen der Methode hinter sich zu lassen. Scrum als Framwork wird dann vielleicht mehr limitieren als enablen. Werdet kreativ, erfindet für euch etwas Neues, probiert andere Methoden aus. Aus dem Software-Team wird eine Produkt-Team. Die Möglichkeiten werden größer, die Verantwortung auch. Damit werden sich auch in der Teamzusammensetzung Veränderungen ergeben, nicht jeder mag die Verantwortung tragen, und es werden andere Fähigkeiten und Erfahrungen benötigt. Die gemeinsame Gestaltung dieser Veränderungen sind können konstruktiv gestaltet werden, also geht es ohne Angst vor dem „Tuckman cycle“ an!

Referenzen: Agile Fluency Modell