Selbstorganisierte, flexible Teams, die schnellere und bessere Ergebnisse liefern, sind für jeden Unternehmensbereich ein Fortschritt. Kein Wunder also, dass längst nicht mehr nur Software-Teams Scrum oder Kanban nutzen, sondern die agile Transformation alle Abteilungen und Standorte erfasst. Doch während die Einführung agiler Methoden in isolierten IT-Teams oder kleinen Unternehmen meist noch recht gut funktioniert, scheitert die Skalierung häufig an der Unternehmenskultur und einem fehlenden agilen Mindset.

Voraussetzung für jede lernende Organisation ist eine kontinuierliche Selbstdiagnose der Projektteams: Wo stehen wir und wie agil arbeiten wir? Wie erkennen wir, wo es im Projekt brennt (und warum)? Wo können wir ansetzen, um besser zu werden? Das Skalierungs-Framework SAFe bietet mit dem „Team Self Assessment“eine Methode des gemeinsamen Lernens, indem der Status der Stärken und Schwächen regelmäßig reflektiert wird.

360° Team-Radar in 5 Dimensionen

Der strukturierte Assessment-Prozess startet mit einer initialen Retrospektive – häufig, wenn ein Agile Coach oder ein neuer Scrum Master ins Team kommt. Ziel ist es, durch die Bewertung von fünf Team-Dimensionen genauer zu analysieren, wo es „brennt“. Basierend auf dem sogenannten „Radar Chart“ können die Teammitglieder die nötigen Optimierungen priorisieren und passende Maßnahmen für den nächsten Sprint ableiten.

Product Ownership Health

  • Laufen die Refinements und Plannings strukturiert?
  • Arbeitet der Product Owner kooperativ mit dem Team zusammen?
  • Erfolgt die Priorisierung der Product Backlog Items nachvollziehbar?
  • Funktioniert das Stakeholder Management?
  • etc.

PI Health / Product Backlog Item Health

  • Das Team interagiert proaktiv mit anderen Teams, um Hürden zu überwinden
  • Sind die Product Backlog Items nachvollziehbar dokumentiert und ist die Priorisierung erkennbar?
  • Erfüllen die Product Backlog Items die Kriterien gemäß INVEST?
  • etc.

Iteration Health

  • Wurde das Sprintziel erreicht?
  • Wurden die vorgesehenen Meetings (Daily, Refinement etc.) strukturiert und wie vorgesehen durchgeführt?
  • Wurde nur an den geplanten Aufgaben gearbeitet oder sind unvorhergesehene Aufgaben aufgetreten?
  • Erfolgte die Durchführung des vergangenen Sprints ohne Störungen durch Stakeholder oder unvorhersehbare technische Ausfälle?
  • etc.

Team Health

  • Hat sich die Zusammenarbeit innerhalb des Teams gut angefühlt?
  • Wurde effizient und ausreichend miteinander gesprochen?
  • Gab es neben den obligatorischen Scrum Meetings auch Treffen zum Mittagessen oder in der Freizeit?
  • Werden Probleme offen angesprochen und helfen sich die Teammitglieder untereinander?
  • etc.

Technical Health

  • Entspricht der aktuelle Status der Software den für den Sprint vereinbarten fachlichen Anforderungen?
  • Wurde die Software gemäß einer Definition of Done entwickelt, d.h. ist sie ausreichend getestet und dokumentiert?
  • Ist die Software für den Product Owner, die Stakeholder und das Team in einem integrierten Stand auf einem Testserver erreichbar?
  • etc.

 

Der Fragen-Katalog kann sich an SAFe orientieren, aber selbstverständlich sind individuelle Anpassungen an das jeweilige Team oder Projekt sinnvoll.

Jedes Teammitglied vergibt in jeder der fünf Team-Dimensionen Punkte zwischen 0 („Never“) und 5 („Always“). Alternativ sind auch Prozentzahlen in 20-er Schritten üblich. Anschließend werden die Zettel eingesammelt, die Punkte addiert, der Team-Durchschnitt für jede Dimension errechnet und in das Radar-Chart eingetragen. Wichtig: Die Vergabe der Punkte und die Auswertung erfolgt anonym.

 

Team Self Assessments in der Praxis

Wir haben gute Erfahrungen damit gemacht, in jeder zweiten oder dritten Retrospektive ein Team Self Assessment durchzuführen. So erkennen Teams negative Trends in einer (oder mehreren) der fünf Dimensionen frühzeitig und können gegensteuern. Langfristig lässt sich bei der Auswertung der Radar-Charts eine Tendenz erkennen, welche Maßnahmen und Ziele die Zusammenarbeit und die Qualität der Ergebnisse positiv oder negativ beeinflusst haben. Ein iterativer Optimierungsprozess wird etabliert.

Beitrag teilen

Alle Blogartikel
Christoph Dibbern war als Scrum Master und Agile Coach bei Teamprove tätig.

Beitrag teilen