Diese Woche hatte ich ein interessantes Erlebnis. Ich hatte den Vorschlag im "Scrum of Scrums" gemacht, unternehmensweite DoDs einzuführen, welche auch die Bereiche der Organisation einschließen sollten, die aktuell immer wieder zu Problemen wegen mangelhafter Qualität führen. Dieser Schritt hätte auch zu einer "Definition of Ready" der POs führen können - was dem Unternehmen gut tun würde. Soweit kam es aber nicht. Nach einer relativ langen und äußerst lebhaften Diskussion stellte sich heruas, dass einige der insgesamt 8 Teams ihre DoD nicht kannten. Noch schlimmer: Sie wussten nicht einmal, was genau das ist. Natürlich habe ich direkt Gegenmaßnahmen ergriffen - trotzdem kann es vielleicht dem ein- oder anderen Leser helfen, wenn er versteht, wie es dazu kam.
Vor etwa einem halben Jahr begann ich ein Engagement bei einem Kunden. Damals gab es keine Definition of Done, auch andere Grundelemente von Scrum waren nicht vorhanden. Im Grunde wurde Wasserfall gemacht, man hatte es nur neu gelabelt. Ich führte zunächst ein "Scrum of ScrumMasters" ein und brachte als erstes Thema die DoD auf den Tisch. Wir beschlossen, diese einzuführen. Von unseren Anstrengungen scheinbar entkoppelt, fiel unmittelbar danach eine DoD als Weisheit des "Test-Teams" (ein weiteres Scrum-But) von oben herab und wurde als verpflichtend deklariert. Diese DoD war mit keinem Team abgesprochen und schoss meilenweit am Ziel vorbei. Meine Reaktion auf diese DoD war kurz: Ich bat meine Teams, diese Email zu löschen und wie geplant selbst eine DoD zu entwerfen und mit dem PO zu verhandeln. Dies setzte ich auch gegenüber dem Test-Team durch und coachte die übrigen ScrumMaster darin, eine DoD zu entwickeln, einzuführen sowie kontinuierlich zu verbessern. Die Kollegen vermeldeten kurz danach Erfolg. In der (ebenfalls neu eingeführten) Retrospektive wurden die DoDs überarbeitet und eingeführt, in den folgenden Reviews wurde jedem Team die Frage gestellt, ob die DoD auch bei allen fertigen Stories eingehalten wurde. Dies wurde meist bejaht.
Klingt doch soweit in Ordnung. Wie konnte es trotzdem zu solchen erheblichen Defiziten kommen?
Es stellte sich heraus, dass einer der Scrum Master Kollegen es versäumt hatte, seinen Teams zu erklären, was eine DoD ist und wofür man sie braucht. Stattdessen wurde eine DoD per Email an das Team geschickt ("das ist jetzt eure DoD") und natürlich sofort vom Team ignoriert und vergessen. In der Folge einigte man sich auf den "Daumen des Product Owners" als Definition of Done - hop oder top wie im alten Rom. Nur leider hatten dadurch weder das Team noch der PO auch nur den Hauch einer Ahnung, wie gut die Qualität der gelieferten Features war. Auch unterschied sich die Qualität von Story zu Story stark. Jetzt sind es genau diese beiden Teams, die in einer Flut von Bugs versinken. Der Scrum Master dieser Teams hat auf ganzer Linie versagt - und ist leider nicht mehr verfügbar, um ihn zu coachen (er hat sich anderen Herausforderungen gestellt).
Was haben wir aus diesen Fehlern gelernt? Wie lösen wir das Problem?
Zunächst habe ich den Teams erklärt, was eine DoD ist und wofür sie gut ist. Auch habe ich die Folgen der fehlenden DoD transparent gemacht. Anschließend tat ich das Gleiche mit den Product Ownern und stieß sofort auf Zustimmung und Verständnis. Zum Nachlesen habe ich diese Informationen auf einer kleinen Wikiseite dokumentiert. Die POs werden zusammen mit ihren Teams und dem in Kürze verfügbaren neuen Scrum Master sinnvolle DoDs definieren.
Als weitere Maßnahme werden sich die Scrum Master in Zukunft gegenseitig coachen. Neben dem "Scrum of ScrumMasters", wird es ein intensives Pairing geben. Immer zwei Scrum Master werden sich in wechselnden Paaren gegenseitig unterstützen und von einander lernen. So wird hoffentlich verhindert, dass uns erneut entgeht, wenn ein Kollege Hilfe braucht.
Einen erneuten Anlauf für unternehmensweite DoDs wird es wohl in den nächsten paar Sprints nicht geben...
(Page 1 of 1, totaling 1 entries)