Wenn Sie sich bereits mit Scrum beschäftigt haben, werden Sie wissen, dass ein Agiles Vorgehen ohne ein hohes Maß an Disziplin nicht funktioniert. Es hat nichts mit Anarchie zu tun, obwohl das manchmal von Vertretern anderer Projektmanagementmethoden – halb im Scherz und halb ernst gemeint – behauptet wird. Dennoch ist in vielen Fällen weit mehr Disziplin nötig, und das sind genau die Fälle, in denen wir uns selbst um die Regeln kümmern müssen.
Es ist nicht schwierig, sich an die Scrum Vorgaben zu halten, soweit es die Zeremonien und Artefakte betrifft. Ein Sprint dauert (in vielen Teams) zwei Wochen, beginnt mit dem Planning und endet mit Review und Retrospektive. Wir pflegen ein Backlog und halten uns dabei an die Form, die wir einmal vereinbart haben. Die Anforderungen genügen ebenfalls immer unseren eigenen Vorgaben, ganz gleich ob wir sie in Form von User Stories oder anders erfassen.
Es ist nicht weiter schwer für einen Scrum Master, auf diese Regeln zu achten. Betrachten wir nur diese Dinge, macht es im Bezug auf die benötigte Disziplin keinen Unterschied, ob wir nach Wasserfall oder Agil vorgehen. Wesentlich schwerer wird es dort, wo die Regeln nur schwer in Termine und feste Formen zu packen sind, was auch sehr leicht zu erklären ist: Ein Review z.B. hat einen festen Termin. Damit ist es digital, da es nur zwei Möglichkeiten gibt. Entweder man hat den Termin wahrgenommen oder eben nicht. Ob eine Anforderung abgenommen und damit fertiggestellt ist, ist ebenfalls digital. Es genügt unserer Definition of Done oder eben nicht. Genau so kann ich eine Retrospektive betrachten oder ein Planning oder die Form einer Anforderung oder ein Daily. Alle festen Regeln, auf die wir uns innerhalb des Teams verständigt haben, können leicht vom Scrum Master auf ihre Einhaltung hin überprüft werden.
Die meisten Teams haben auch kein Problem damit, sich schnell an diese Dinge zu gewöhnen. Dort greift bereits nach wenigen Wochen eine Selbstdisziplin, weil es sehr einfach ist, sich an solche starren Strukturen anzupassen. Der Unterbau von Scrum ist hingegen kaum in festen Regeln auszudrücken, auch wenn wir uns bemühen sollten, soweit es uns möglich ist, dies zu tun, da feste Regeln eben sehr leicht zu überprüfen sind.
Unter dem Begriff »Unterbau« verstehe ich z.B. Dinge wie eine offene Kommunikation oder gegenseitiges Vertrauen. Diese sind selbstverständlich sehr viel schwerer in Regeln auszudrücken, die überprüfbar sind. Ein guter Scrum Master hat das im Blick und »erzieht« sein Team in gewisser Weise, dennoch lassen sich diese Dinge nicht digital betrachten. Es gibt immer einen Interpretationsspielraum, der sich auch verschieben kann. Dass unterschiedliche Personen Dinge unterschiedlich interpretieren, kommt noch erschwerend hinzu.
Es ist an dieser Stelle nicht nur der Scrum Master gefordert, diese »weichen« Faktoren kontinuierlich im Blick zu behalten, das gesamte Team sollte sich selbst immer wieder fragen, ob es den eigenen Ansprüchen genügt. Der SM sollte das anstoßen und auch durchaus seine Eindrücke schildern, diese können jedem einzelnen im Team jedoch nur als Input dienen, um sein eigenes Verhalten zu bewerten. Wenn ein Scrum Master zu stark darauf drängt, dass einzelne Personen oder ein ganzes Team sein Verhalten ändert, dann wird er nur Widerstände schaffen. Diese Dinge brauchen auf der einen Seite Zeit, auf der anderen Seite können Sie nur von den Beteiligten Personen selbst kommen. Der Scrum Master kann darauf aufmerksam machen und ein Bewusstsein wecken, er kann jedoch keine (oder nur in begrenztem Maße) Forderungen stellen.
Das bedeutet keinesfalls, dass man alles durchgehen lassen müsste. Ganz im Gegenteil: ein Scrum Master ist ganz besonders gefordert, die nicht in festen Regeln gefassten Aspekte der Zusammenarbeit zu beobachten und zu bewerten. Wenn Dinge seiner Auffassung nach nicht richtig laufen, hat er sie zur Sprache zu bringen, das Team selbst muss jedoch sein Verhalten von sich aus anpassen. Dazu braucht es den Input des Scrum Masters als Beobachter. Die Zusammenarbeit innerhalb des Teams erfordert also ein hohes Maß an Selbstdisziplin.
Der Kern des Agilen Vorgehens, der Regelkreis Plan – Do – Check – Act, ist ebenfalls nur schwer in Regeln zu fassen. Ganz besonders hierbei kann man sehr oft beobachten, dass genau dies vernachlässigt wird, und dass genau das der Grund ist, weshalb Scrum sehr schnell zu Wasserfall im Kleidchen wird.
Vernachlässigen wir das Prinzip, dass wir nach jeder Iteration unser Ergebnis überprüfen, indem wir in die Kommunikation mit dem Anwender gehen, uns dessen Feedback holen und das Gelernte für unsere nächste Iteration nutzen, könnten wir auch gleich nach einem festen Plan vorgehen, den wir der Einfachheit halber in kurze Abschnitte von zwei Wochen teilen. Und genau das passiert leider viel zu oft, weil es eben keine Regeln gibt, die unseren Austausch mit dem Anwender beschreibt. Und noch viel weniger Regeln gibt es dazu, wie das Gelernte dann auf unser Backlog zu übertragen ist.
Auch wenn man mit den besten Absichten in ein Projekt startet, ist es sehr einfach, diese bald fallenzulassen. Es ist wie mit dem guten Vorsatz zum neuen Jahr, regelmäßig ins Fitnessstudio zu gehen: die ersten paar mal hält man sich an seine eigenen guten Absichten. Dann kommt ein regnerischer kalter Tag, und man ist mit dem Fahrrad unterwegs. An einem solchen Tag versichert man sich sehr glaubhaft, dass man sich nur eine Erkältung holen würde, und verzichtet auf den Sport. Man könnte das ja am folgenden Tag nachholen. Zweimal ist man wieder brav, eine Woche später hat man jedoch einen dringenden Termin. Man überzeugt sich selbst davon, dass an diesem Tag alles zu knapp werden würde, und verschiebt Sport wieder auf den Folgetag. Im Laufe der folgenden Wochen weichen wir unsere guten Absichten immer weiter auf, bis wir eines Tages feststellen, dass unser letzter Besuch im Fitnessstudio schon einen Monat her ist.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Ganz genau so verhält es sich mit dem Regelkreis. Entweder weicht unser Vorgehen mit der Zeit immer weiter auf, oder dieser Kern des Agilen Vorgehens war uns nie wirklich bewusst, und wir haben ihn daher nie wirklich beachtet. Mir sind schon beide Fälle in vielen Unternehmen begegnet.
Wenn ich hier über Disziplin und Selbstdisziplin spreche, dann muss ich zuerst danach fragen, wer für die Einhaltung des Kreises verantwortlich ist. Als erster fällt mir da natürlich der Product Owner ein. Er verantwortet das Backlog, und er ist die Schnittstelle des Teams. Er holt die Anforderungen an das Produkt ein. Er kann selbst entscheiden, wie er an die Anforderungen für das Produkt kommt. Er könnte z.B. das Kundenforum durchsuchen, alle Wünsche aufschreiben, eine Strichliste führen und das am meisten gewünschte Feature umsetzen. Ist das erledigt, wiederholt der den Vorgang. Das würde zwar bedeuten, in irgendeiner Weise auf das Feedback des Anwenders einzugehen, hätte aber nichts mit Agilität zu tun, weil der Dialog fehlt. Dies wäre eine reine Einbahnstraßenkommunikation.
Seht her, liebe Anwender, wir haben Euer gewünschtes Feature eingebaut. Passt das so? Kommt Ihr damit gut zurecht? Ist es das was Ihr wollt?
Im Prinzip ist es super, aber an dieser einen Stelle verstehen wir es nicht richtig. Dadurch wird die Bedienung etwas schwierig.
Ist OK, wir sehen uns die Ecke noch einmal genauer an.
Wir haben sie jetzt – wie wir meinen – verbessert. Was denkt Ihr?
Das ist – nicht einmal optimal – Agiles Vorgehen. Und genau das liegt in der Verantwortung des Product Owners. Um so handeln zu können, muss er dieses Prinzip natürlich erst einmal verstanden haben. Ist das nicht der Fall, ist es Aufgabe des Scrum Masters, ihm das zu vermitteln. Soweit ist es sehr einfach.
Ist es ihm bewusst, er hält sich jedoch nicht daran, dann ist es Aufgabe des Scrum Masters, dem auf den Grund zu gehen und dies anzusprechen, um das weitere Vorgehen gemeinsam wieder in die richtige Richtung zu lenken. Ich sehe aber auch das gesamte Team in einer Verantwortung. Jeder sollte wissen, wie der Regelkreis funktioniert, und was es damit auf sich hat. Also sollte jedem auch bewusst werden, wenn man sich davon entfernt. Damit kann es auch jeder ansprechen, verantwortlich bleibt aber der Scrum Master.
Wir haben festgestellt, dass wir unser eigentlich gewünschtes Vorgehen aus den unterschiedlichsten Gründen immer wieder vernachlässigen. Jetzt komme ich natürlich zu der Frage, wie das zu vermeiden ist und damit auch zu der eingangs erwähnten Disziplin. Das muss auf der einen Seite Selbstdisziplin sein, auf der anderen Seite aber auch gegenseitige Unterstützung. Ich rate dringend dazu, auch den Regelkreis, soweit möglich, in Regeln zu gießen. Diese machen es uns so viel einfacher, uns selbst zu überprüfen.
Eine Regel könnte z.B. sein, dass kein Feature ohne Betatest veröffentlicht wird. Das ist zwar sehr grob gefasst, würde uns aber dazu zwingen, mit jedem Feature in die Betatest-Kommunikation zu gehen. Solche Punkte sind die Art Disziplin, die in vielen Scrum Projekten leider vernachlässigt wird.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
