dot.tipp - 13 Massnahmen für ein agileres Team in Scrum

Dein Team "liefert" nicht richtig? Dein Vorhaben verfärbt sich allmählich rot? Dann nutze Agilität als Turnaround-Methode, um dein Team zu stabilisieren.

Dieser Blog bietet ein Set von schnellen Massnahmen, um die Agilisierung bestehender Teams zu erhöhen für dein Effective Delivery.

#1 Grundsatz

Agilisierung ist Führungsaufgabe, ohne Management-Unterstützung kann ein bestehendes Team nicht agilisiert werden. Bist du also ein "einfaches" Team-Mitglied und möchtest agil arbeiten, dann teile diesen Blog mit deinem Vorgesetzten.

Und: Es müssen nicht alle Massnahmen gleichzeitig ausgeführt werden; man muss testen, ob eine Massnahme innerhalb einer Frist die gewünschte Wirkung zeigt.

BTW: Die Nummerierung ist auch keine Reihenfolge; die Nummerierung ist ein Identifikator.

#2 Teamgrösse verkleinern

Du suchst dir drei Entwickler und zwei testende Entwickler aus - idealerweise jene, die Agilität ablehnen. Den Rest verschiebst du in ein anderes Team - oder gründest mit ihnen ein ebenfalls "frisches" Team, das vom vorherigen Team möglichst "entkoppelt" ist.

Effekt

• Du nötigst das Team zur permanenten Kommunikation
  • Vor allem jene, die eigentlich nicht gerne kommunizieren
  • Du verkleinerst die Kommunikationskomplexität im Team

#3 Sprintlänge verkürzen

Du verkürzt die Sprint-Dauer auf eine Woche.

Effekt

• Das Team ist gefordert, innerhalb einer Woche ein lauffähiges Produktinkrement zu liefern
  • Das zwingt das Team zum konsequenten und MVP-artigen Schneiden
  • Das zwingt das Team zur ständigen Kommunikation; kombiniert mit einer verkleinerten Teamgrösse
• Es hat keine Zeit für langatmige Konzepte und Ausschweifungen, stattdessen kann sich das Team an echten Ergebnissen (Deployments!) messen

#4 Möglichst viele Stakeholder beteiligen

Fürs Sprint Review lädst du alle bzw. möglichst viele Stakeholder ein.

Effekt

• Das Team muss am Sprint Review Ergebnisse präsentieren
  • Kein Manager schützt das Team
• Fehler verantwortet das Team selbst
  • Wenn das Team nicht innerhalb einer Woche liefern kann, muss das Team sich selbst erklären
  • Das Team muss spüren, dass es Selbstverantwortung trägt

#5 Team abschirmen

Du schenkst dem Team absolute Autonomie gegenüber der Organisation.

Effekt

• Das Team kann selbst entscheiden über Architektur und sonstige "Richtlinien", die bislang innerhalb der Organisation galten
• Wenn jemand mit einer Konzernfunktion dein Team behelligt, schützt du dein Team
• Du vertrittst alle Entscheidungen im Kampf gegen interne Stellen und befreist damit das Team von dieser politischen Aufgabe

#6 Product Roadmap erstellen

Du verlangst eine Product Roadmap mit einem visualisierten Product Scope.

Effekt

• Das Team muss sich über die Vision und Nordstern austauschen
• Das Team muss sich finden, was überhaupt das "Richtige" ist
• Das Team muss einen groben Plan entwickeln, in welchen Schritten (Schneiden!) das Ziel erreicht werden kann
• Das Team muss regelmässig Wahrheiten mit produktiven Deployments schaffen

#7 Backlog Refinement institutionalisieren

Du implementierst einen Backlog Refinement Prozess.

Effekt

• Damit werden die Fehlerbehebungskosten nochmals reduziert, weil vor den Sprint gelegt
• Du sorgst mit einer strikten Definition of Ready, dass deine Aufgaben eine gewisse Qualität aufweisen
• Du beruhigst den Sprint, weil die Aufgaben generell klarer sind und weniger Abstimmung sowie Diskussion verlangen

#8 Entwicklungsregeln einfordern

Du definierst fünf goldene Entwicklungsregeln:

• Pairing einfordern
• Mindestens einmal täglich mergen (auf beide Seiten)
• Der Master ist immer auf einer Integrationsumgebung und lauffähig
• Architekturdokumentation ist immer aktuell
• Architekturänderungen nie ohne Team-Entscheidung

Effekt

• Die minimalen Qualitätskriterien werden eingehalten
• Die gelebte Disziplin ist transparent (in Code wie Dokumentation) und steckt das Umfeld/Team an
• Das Team spürt, dass Qualität gewünscht und auch "finanziert" ist

#9 Kompetenzen delegieren

Du als Vorgesetzter ziehst dich zurück; du vergisst quasi, dass du ein Team hast.

Effekt

• Du beeinflusst das Team nicht mehr
• Du zwingst das Team, sich selbst zu übertreffen
• Du zwingst das Team, selbst Lösungen zu finden
• Du hast mehr Zeit für die wichtigen Dingen

#10 Zu dominante Teammitglieder heruntertakten

Das dominante Team-Mitglied wechselst du aus oder reflektierst es mit einem Spiral Dynamics Integral (SDI) Assessment, damit es nicht mehr zu dominant wirkt im Team. 

Effekt

• Das Team muss sich selbst neu organisieren
• Das Team kann sich nicht mehr auf den dominanten Kollegen verlassen, der alles steuert und regelt
• Das Team muss echte Zusammenarbeit erlernen
• Das Team lernt, seinen eigenen Fähigkeiten zu vertrauen

#11 Product Owner ins Team bringen

Den vormals "abstrahierten" oder weit entfernten Product Owner setzt du in denselben Raum wie das Team.

Effekt

• Der sogenannte Kunde ist nun kein "unbekanntes Wesen" mehr, sondern wird durch den Product Owner verkörpert
• Der Kunde erlebt mit, wie das Team sich organisiert
• Das Team wird geehrt durch die permanente Anwesenheit des Kunden
• Feedback zwischen Team-Kunde ist massiv beschleunigt

#12 E2E-Services propagieren

Du vereinfachst die Architektur, dass jedes Team einen Service respektive ein Produkt verantworten kann.

• Ein Team verantwortet einen E2E-Service autonom und komplett
  • Also vom GUI bis Backend
  • Ein Team, mindestens ein Service

Effekt

• Das Team entwickelt echte Verantwortung für ein in sich geschlossenes Produkt
• Das Team kann autonom entwickeln; ist nicht mehr blockiert und kann folglich auch niemanden mehr "beschuldigen" bei Verzögerungen oder Konflikten

#13 Work-in-Progress limitieren

Du limitierst die Anzahl offener Stories im Sprint auf exakt zwei Stück.

Effekt

• Du zwingst das Team zum Fokus und Zusammenarbeit
  • Die nächste Aufgabe darf erst gestartet werden, wenn die aktuelle abgeschlossen ist
  • Damit identifizierst du auch mögliche "Wartezeiten", "Abhängigkeiten", die du mit dem Multitasking einfach kaschierst respektive nicht sichtbar machst

Weitere Massnahmen?

Diese Liste ist gewiss nicht abschliessend. Und gewiss entfaltet je nach Kontext nicht jede Massnahme den prognostizierten Effekt. Ein weiser Scrum Master integriert diese Massnahmen mittels der ordentlichen Retrospektive und macht dabei seine Aktivitäten sichtbar. 

Und was sind deine Ideen? Was hat gut funktioniert? Was hat aber auch schlecht funktioniert? Kommentiere einfach!