Ein Blick in meine Tool-Box: Assessment für mein Scrum-Projekt

Teile diesen Beitrag mit deinen Freunden!

Der Scrum Guide beschreibt ein ideales ScrumTeam. Wie sieht aber meine Realität aus? Welche Dinge macht mein Team gut, wo haben wir Probleme? Was sage ich dem IT-Chef, wenn er beiläufig fragt „wie es denn so läuft?“. Bei meiner Arbeit als ScrumMaster hilft mir mein regelmäßiges Assessment zur Reife meines ScrumTeams.

Wenn sich ein ScrumTeam formiert hat und der erste Sprint gestartet ist, dann wurde ein Prozess eingeleitet, der die Zusammenarbeit, die Denkweise und die Handlungsweise der Menschen verändert. Aber auch das Umfeld eines ScrumTeams ist von dieser Veränderung betroffen. Manche Veränderungen will ich als Scrum Master fördern, manche will ich unterdrücken. Um nicht den Überblick zu verlieren, muss ich eine Vorstellung davon haben, wo im Entwicklungsprozess mein Team gerade steht.

Ich mache dies mit einem regelmäßigen, systematischen und quantitativen Assessment. Inspiriert vom „Nokia-Test“ von Bas Vodde[1], unterziehe ich die Scrum-Projekte, in die ich als Scrum Master involviert bin, einer systematischen Einschätzung. Als Bewertungsmaßstab nehme ich den offiziellen Scrum Guide, unterteilte diesen in entsprechende Dimensionen und hinterlegte eine Skala von 1-5. Ein Scrum-Projekt, welches vollständig die Beschreibung im Scrum Guide erfüllt, hat die Stufe „4“ erreicht. Stufe „5“ vergebe ich, wenn das Scrum-Projekt weitere Merkmale erfüllt, die ich persönlich für wichtig halte, die aber nicht Bestandteile des Scrum Guide sind.

Diese regelmäßige systematische Bewertung eines Scrum Projektes in verschiedenen Dimensionen bringt mir mehrere Vorteile:

  • Ich kann erkennen, in welchen Bereichen eine Verbesserung eingesetzt hat und wo Stagnation oder Rückschritt herrschen. Darauf basierend kann ich gezielte Maßnahmen einleiten, um das Team wieder auf Kurs zu bringen.
  • Ich kann dem Auftraggeber den Entwicklungsprozess und Status Quo deutlich machen. Notwendige Veränderungsmaßnahmen im Umfeld können dadurch verständlich werden.
  • Meine Einschätzungen können als Diskussionsgrundlage mit anderen Scrum Master dienen.
  • Ich bekomme eine quantitative und qualitative Aussage zur Reife des Scrum-Projektes und kann diese in Austausch mit dem Auftraggeber verwenden.
  • Ich kann zusammen mit dem Auftraggeber klären, wo das Zielbild für sein Unternehmen liegen soll.
Warnhinweise

Ich habe es nach meinen persönlichen Vorstellungen und Erfahrungen gebaut und vorrangig dient es mir, die Entwicklungen innerhalb und außerhalb des Scrum Projektes zu nachzuvollziehen, Unterstützungsbedarf zu erkennen und Gespräche zu führen. Wie bei jedem anderen Werkzeug besteht auch hier die Gefahr von unerwünschten Folgen bei unsachgemäßer Verwendungsweise. Dies ist kein Werkzeug, welches von unkundigen Personen benutzt werden sollte.

 

Nachstehend erläutere ich die Handhabung des Assessment Tools. Mir hilft mein Scrum Tagebuch, um täglich meine Eindrücke und Beobachtungen festzuhalten und daraus mein Assessment abzuleiten.

Bewertet werden von mir u.a. diese Dimensionen

  • Product Owner
  • Development Team
  • Scrum Master
  • Backlog
  • Sprint
  • Daily Scrum
  • Refinement Meeting
  • Planning Meeting
  • Werte
  • Scrum Theorie
  • Team-Geist
  • Umfeld

Wenn ich es für nötig erachte, ergänze ich diese um weitere Dimensionen.

Ich verwende die Beschreibungen aus dem Scrum Guide. Für die Dimension „Backlog“ sind dies z.B.:

  • Backlog (BL) ist eine geordnete Liste
  • BL ist ständig in Bewegung
  • BL enthält alle Features, Funktionalitäten, Verbesserungen, Fehler
  • Ein BL‐Eintrag enthält als Attribute eine Beschreibung, die Reihenfolge, die Schätzung und den Wert
  • der Reifegrad der BL-Items hinsichtlich READY nimmt von oben nach unten ab
  • Arbeiten mehrere Scrum Teams an einem Produkt, wird ein einziges BL verwendet

Derzeit verwende ich eine 4- bzw. 5-stufige Skala

  • 1: „noch keine Umsetzung“
  • 2: „Umsetzung in Teilen erkennbar, aber selten“
  • 3: „Umsetzung deutlich erkennbar, aber noch unregelmäßig“
  • 4: „Regelmäßig volle Umsetzung lt. Scrum Guide“
  • 5: „Volle Umsetzung lt. Scrum Guide und darüber hinaus“

Als Darstellungsform verwende ich meist Kurvendiagramme, um die zeitliche Entwicklung in den verschiedenen Dimensionen darstellen.

 

 

 

 

 

 

 

 

 

 

 

[1] Zur Geschichte des sog. „Nokia-Tests“:

https://blog.odd-e.com/basvodde/2011/02/history-of-nokia-test.html

 

Teile diesen Beitrag mit deinen Freunden!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *