Fortsetzung von Scrum — eine Revolution (4)
Sind die ScrumMaster an allen scheiternden Implementierungen schuld?
Obwohl ich der Meinung bin, dass eine gute Scrum Implementierung mit guten ScrumMastern steht oder fällt, ist es natürlich falsch, den ScrumMastern die Schuld am versagen der Scrum Implementierungen zu zu schreiben.
In letzter Zeit fragen mich zum Beispiel mehr und mehr Teams und Manager, was denn das Entscheidende bei der Einführung von Scrum sei? Meine Antwort ist immer gewesen: “Am Ende einer Iteration funktionierende Software vorliegen zu haben!” Dieses Grundprinzip muss von allen verstanden werden. Dem Management, den ScrumMastern, und den Teammitgliedern. Ein Management, das von vornherein mitteilt, dass es natürlich nicht möglich sei, innerhalb von 4 Wochen etwas zu liefern, oder das einfach nicht gewillt ist, einmal 2 Wochen auf eine Lieferung zu warten, ist selbstverständlich ein Problem. Denn es steht dem Hauptgrundsatz von Scrum, alle 4 Wochen vollkommen funktionierende Software vorliegen zu haben, vollkommen entgegen. Hier muss ein ScrumMaster in der Regel am härtesten seine Ansichten vertreten. Wenn dieser aber selbst nicht daran glaubt, dass man User Stories funktional so klein schneiden kann, dass man sie in zwei oder vier Wochen liefern kann, dann werden die Teams auch nichts liefern.
Seid dem Scrum Gathering 2009, in Orlando, möchte ich die obige Forderung, dass man am Ende eines Sprints etwas zu liefern hat, gerne anders formulieren und durch zwei weitere Aspekte erweitern:
1) Deliver every month
2) Inspect and Adapt
3) Ask the Team
So klar mir diese drei Aspekte selbst immer waren, es bedurfte einer kleinen Bühnenshow von Alistair Cockburn und Ken Schaber in Orlando, um mir diese drei Aspekte deutlicher ins Bewusstsein zu bringen: Alistair schlug bei der Erwähnung dieser drei Punkte immer verschieden tönende Gläser an, so dass beim Anschlagen der Gläser ein Dreiklang entstand. Eindrucksvoller konnten die beiden nicht verdeutlichen, worum es geht:
Deliver every month
Ken und Alistair machten wieder unmissverständlich klar, dass es bei Scrum um das Liefern von Funktionalität geht. Jeden Monat. Jeden Sprint. Jede Iteration. Wenn es dem Team nicht gelingt, etwas zu liefern, dann muss offen und transparent darüber diskutiert werden. Wir, das Team, oder die Organisation müssen etwas verändern, damit es gelingt, am Ende eines Monats etwas zu liefern. Zur Erreichung dieses Ziels ist dabei alles zu hinterfragen: hat das Team die notwendige Unterstützung, oder wie sieht die technische Ausstattung aus? Was immer geändert werden muss, das muss geändert werden.
Im schlimmsten anzunehmenden Fall, liefern Teams immer wieder nichts. Sie liefern nicht und die Organisation und die Teams werden ungeduldiger und demotiviert. Ausreden, warum diese Teams nichts liefern, gibt es dann sowohl auf der Seite des Teams, als auch auf der Seite des Managements. Alle fühlen sich schuldig, als wäre es ein Versagen und reden sich dann die Situation schön. Dabei ist dieses „Versagen“ keine Katastrophe, sondern eine transparent gemachte Erkenntnis: „Hier läuft etwas nicht so, wie es laufen sollte!“ In diesem Fall ist es tatsächlich angebracht offen darüber zu reden, ob wir das Team nicht verändern und die Teammitglieder auf andere Teams verteilen. Dieses Team ist ja offenbar nicht in der Lage etwas zu liefern. Oft ist es geradezu heilsam, die Teamstruktur dann drastisch zu verändern.
Inspect and Adpat
Läuft es nicht, dann muss etwas geschehen. Darum geht es bei Inspect and Adapt. Wo stehen wir? Was haben wir erreicht? Stehen wir da, wo wir hinwollen? Wollen wir noch dort hin, wohin wir letzen Sprint wollten? Wenn diese Fragen geklärt sind, dann können wir die notwendigen Maßnahmen treffen und die Dinge so verändern, dass wir das nächste Mal unsere Ziele erreichen. Inspect and Adapt heißt nicht, einen Schuldigen zu finden und dann dafür zu sorgen, dass dieser alles richtig macht. Inspect and Adapt bedeutet, wir sind da, wo wir sind, als nächstes sehen wir zu, was wir tun können, um uns zu verbessern. Dieses Prinzip gilt für jede Wissenschaft, für jeden Prozess, der sich nur durch empirisches Probieren und durch anpassen an die Realtät verbessern lässt.
Ist erst einmal erkannt, dass wir etwas verändern müssen, dann können wir nach Möglichkeiten der Veränderung suchen.
Ask the Team
Aber wie gehen wir dabei am Besten vor? Fragen wir einen Manger oder einen Experten, wie es gehen kann und geben dann diese Dinge dem Team vor? Sagen wir also dem Team, was es zu tun hat? Sicher nicht.
Wir Fragen das Team, was es tun will, um die Veränderungen einzuleiten. Wieder geben wir die Verantwortung an die Menschen, die die Arbeit tun müssen. An die also, die am besten wissen sollten, wie wir das gesteckte Ziel erreichen. Veränderungen sollten vom Team aus gestartet werden. Sie haben die Aufgabe, den besten Weg zur Zielerreichung zu finden.
Wichtig in diesem Zusammenhang: In Scrum behandeln wir die Menschen als „Erwachsene“. Wir schreiben Ihnen nicht vor, wie sie zu leben haben, wir schreiben ihnen auch nicht vor, wie lange sie zu arbeiten haben. Aber wir entlassen sie nicht aus ihrer Verantwortung, einen Weg zu finden, am Ende eines Sprints zu lieferen, was miteinander vereinbart worden ist. Etwas, was manche Teams erst lernen müssen. Zu schnell wird gesagt: „In Scrum darf man ja das Ziel nicht erreichen, es ging halt nicht!“ Nichts daran stimmt. In Scrum hat ein Team den selbst gesteckten Auftrag auch zu erreichen. Daher wird ein freiwilliges Commitment erarbeitet.
Komplexität und selbstorganisierende Teams
„Der Berater, den wir da hatten, war der Meinung, dass man in Scrum dem Team alles überlässt. Seine Meinung war, dass sich das Team schon selbst organisieren werde. Das war ein Fiasko, wir sind wieder zu einer traditionellen Teamstruktur mit Teamleitern zurück und seitdem funktioniert es einigermaßen.“ So ähnlich war die Geschichte, die mir ein Kunde erzählte. Das ist haarsträubend. Sollten Sie einmal einen Berater da haben, der ähnlich unverantwortlich mit ihren Mitarbeitern umgeht, setzen sie ihn bitte sofort vor die Tür.
Sich ein Team selbst organisieren zu lassen, hat nichts mit Zugucken oder gar Wegschauen zu tun. Gerade das Gegenteil ist der Fall: Selbst-Organisation funktioniert nur, wenn der Rahmen, der Container, in dem sich das Team befindet, klar definiert ist. Dieser Rahmen muss vom ScrumMaster gesteckt und aufrecht erhalten werden. Innerhalb dieses Rahmens, wird dann dafür gesorgt, dass die Selbst-Organisation in Gang kommt. Oft reicht es den Standard, den Scrum und die Tools, wie zum Beispiel das Taskboard, bieten „by the book“ einzuführen, damit die Teams beginnen können, sich selbst zu finden und zu organisieren. Aber – sollte das Entwicklungsteam auch nur den Anschein bieten, dass das Ziel gefährdet ist, dann wird sehr bestimmt und klar, aufgezeigt, dass da ein Ziel zu erreichen ist, und dass die Entwicklungsmannschaft gewisse Zusagen getroffen hatte. Oft reicht es in der Mitte des Sprints noch einmal die Ziele aufzuzeigen, oder ein Meeting einzuberufen, in dem noch einmal klar gestellt wird, um was es geht.
Viel öfter aber funktioniert die Selbst-Organisation deshalb nicht, weil die Menschen in den Teams nicht mehr gewohnt sind, selbst Entscheidungen zu treffen. Dann, ganz plötzlich in Scrum, sollen sie das tun. Für viele eine Überforderung. Wieder kommt es auf den ScrumMaster an. Er wird in einem solchem Fall das Team enger führen, als es ein scrum-erfahrenes Team benötigt. Er wird dem Team Fragen stellen, es provozieren, Anregungen geben, Gespräche und Diskussionen moderieren und im Notfall auch für das Team Entscheidungen treffen. Eines darf nämlich nicht passieren: Das Entwicklungsteam darf auf keinen Fall „versagen“, es darf nicht nicht-liefern. Wenn es dabei Hilfe benötigt, dann ist das eben so!
Der ScrumMaster wird über die Zeit hinweg immer und immer weniger eingreifen. Im Idealfall dauert es nur ein paar Sprints, bis er sein Team so weit hat, dass dort weitgehend selbst-organiserend gearbeitet werden kann.
Why? Because we want to get rid of the notion that the Teamlead leads a team.
Scrum 4 You 