Kürzlich wurden wir beauftragt, die Scrum Master einer der big-four Unternehmensberatungen auszubilden und zu trainieren. Und auch im Rahmen vieler agiler Transformationen in Unternehmen mit unterschiedlichsten Voraussetzungen werde ich immer wieder gefragt, wie agile Teams vorbereitet werden, bzw. wie ein effektives Scrum Training verläuft.
Scrum ist nun mal eine tückische Angelegenheit.
Als Methodik scheint sie auf dem ersten Blick sehr einfach zu sein. Theoretisch – und dieser Begriff ist mit Bedacht gewählt – ist Scrum das auch. „Einfach“ bedeutet, dass die Methodik auf relativ wenigen Tatsachen beruht, es gibt zum Beispiel nur drei Rollen, wenige Prozesse (Sprints, Plannings, Dailies) und auch nicht sonderlich viele Artefakte (Backlog, Stories, ein paar Charts). Daher haben viele Trainer nach ein paar Stunden auch nicht mehr viel zu sagen denn die Theorie ist relativ schnell erzählt. Jetzt kommt natürlich das „Aber“. Metaphern sind ja oft Glückssache, dennoch verwende ich hier mal eine. All das oben gesagte über Scrum gilt auch für das Schachspielen. Ich vergleiche Scrum oft mit einem Schachspiel, sofern ich Scrum nicht gerade mit einem Artisten auf dem Drahtseil vergleiche, was persönlich meine Lieblingsmetapher ist. Ich denke, dass es durchaus möglich ist einer 10jährigen in zwei bis drei Stunden Schach zu erklären, habe es vor vielen Jahren selbst an meiner Tochter ausprobiert (und prompt das erste Match verloren). Weltmeister ist sie damit allerdings nicht geworden. Das dauert zweifellos etwas länger und braucht natürlich viel, viel mehr Training.
Wenn ich gegen einen ziemlich guten Spieler eine Partie spiele, höre ich oft nach einigen Zügen ihn den Satz sagen: „sorry Klaus, Schachmatt“. Und dann denke ich jedes Mal, mein Gott, wie konnte das passieren? Jeden meiner Züge habe ich doch korrekt und regelkonform ausgeführt. Hmmm… und es hat doch wieder nicht gereicht. Bei der Gelegenheit fällt mir ein sehr schönes Zitat von Ludwig Wittgenstein – mein Lieblings-Sprachphilosoph – ein. Es geht ungefähr so „Was ist eine Regel lernen? Das. Was ist ein Fehler in ihrer Anwendung machen? Das. Und worauf hier gewiesen wird, ist etwas Unbestimmtes“. Das Zitat beschreibt eigentlich alles, was wir wissen müssen und ist perfekt für ein verregnetes Novemberwochenende, eine gute Flasche Wein und Kaminfeuer. Zurück zu unserem Thema…
Scrum Regeln
Das befolgen der Scrum Regeln (falls es diese überhaupt gibt) bzw. das Zitieren des Scrum Guides in allen Situationen führt oft nicht dahin, wo wir hinmöchten. Nicht trotz, sondern wegen der Einfachheit von Scrum. Diese ermöglicht nämlich eine nahezu beliebige Komplexität. Jeder Schachspieler weiß, dass die Herausforderung darin besteht bei jedem Zug den ich mache, den Impact auf das Gesamtgeschehen im Blick zu behalten. Diesen merke ich dann meist erst ein paar Züge (oder Sprints) später. Die Komplexität in Scrum entsteht dadurch, dass so gut wie keine Entscheidung, so gut wie kein Schritt ohne Folgen bleibt. Da es nun mal nur sehr wenige Dinge in Scrum gibt, ist es keine Überraschung, dass alle wichtig sind und nicht fahrlässig weggelassen oder folgenlos customized werden können. Wie oft habe ich schon gesehen, dass Teams einfach mal den Scrum Master weglassen, oder keine Vertretung definieren. Auch wird die Product Owner Rolle immer wieder gerne in zwei Rollen geteilt, vorzugsweise in einen technischen PO und einen fachlichen PO. Auch dynamische Sprints sind so ein sehr beliebtes „Verbrechen“ gegen die Scrum Ethik. Die Beispiele lassen sich fast endlos fortsetzen. Aber das Thema ist hier nicht, was man in Scrum machen sollte und was nicht, sondern wie ein Scrum Training erfolgreich und nachhaltig gestaltet werden kann. Also los.
Regel Nummer eins ist, suchen Sie sich einen erfahrenen Coach. Man kann sich heute ja nahezu alles selbst beibringen und das Selbststudium ist heute auch sehr beliebt. Das mag so sein und ich glaube auch, dass das oft sehr gut funktioniert. Aber funktioniert das auch kollektiv? Es macht schon einen gewaltigen Unterschied ob ich für mich ganz alleine etwas im Selbststudium erlerne und dabei mir meine eigene, auf mich zugeschnittene Methode- und meinen eigenen Rhythmus frei wählen kann, oder ob ich dabei plötzlich Rücksicht auf ein halbes Dutzend Teammitglieder nehmen muss. Das ist plötzlich etwas ganz anderes und funktioniert in der Regel auch nicht. Hinzu kommt, dass Organisationen meist sowieso viel zu spät dran sind mit ihrer agilen Transformation und ihr demzufolge gerade die Zeit davonläuft. Unter diesem Zeitdruck muss man jetzt nicht unbedingt auch noch Selbststudium-Experimente machen.
Scrum ist nun mal eine „best practice“ und keine Theorie, daher muss ein Scrum Training auch praktisch erfolgen und das dauert bekanntlich immer etwas länger als nur theoretisches Wissen zu vermitteln. Bis ein Scrum Team gut funktioniert, werden also einige Wochen vergehen. Sofern man es gut macht, müssen es keine Monate sein, können aber. Vergessen wir mal nicht, dass die Entwickler ja nicht nur sich die Methodik aneignen müssen, sondern im Grunde ja eine ganz neue Art von Softwareentwickeln lernen müssen und ich spreche hier nicht von einer neuen Programmiersprache, sondern von vertikaler, sprich featureorientierter Entwicklung an sich.
Um mich jetzt scheinbar gleich zu widersprechen, beginne ich meine Scrum Trainings mit einem eintägigen Scrum Einführungskurs, also der Theorie. Ganz gleich was ein vorheriges Assessment sagt, wie erfahren viele Teammitglieder schon sind. Es gibt so viele verschiedenen Vorstellungen von- und Irrtümer über Scrum. Ziel des Einführungskurses ist, ein gemeinsames Verständnis bzw. eine gemeinsame Interpretation der Methodik zu bekommen. Wenn alle auf der gleichen Page sind, also die gleichen Referenzen haben, wird es später einfacher. In diesem Einführungskurs geht es nicht sosehr darum, Scrum zu erklären, sondern die Hintergründe, also das Warum und Wieso zu beleuchten. Wir sprechen beispielsweise nicht so sehr darüber welche Rollen es in Scrum gibt – das kann man überall nachlesen – sondern warum wir diese brauchen und warum es in Scrum nur diese drei gibt und zwar unabhängig von der Beschaffenheit des Projektes oder der Art der Organisation. Das Ziel dieses Einführungskurses ist es also die Beziehung der Methodik Scrum zur Organisations- und Projektrealität, also zur aktuellen Lebenswirklichkeit der Teams herzustellen. Warum kann Scrum die Probleme lösen, die die Teams aktuell haben und warum können andere Methoden das vermutlich nicht. Mit dieser, die Lebenswirklichkeit der Teams sehr unmittelbar betreffenden Herangehensweise haben Sie recht schnell die Aufmerksamkeit der Teams und können jetzt in das eigentliche Scrum Training einsteigen, jetzt folgt also unmittelbar der praktische Teil.
Agile Entwicklung ist eine mit einigen Risiken behaftete Angelegenheit. Insbesondere, da Teams keine langfristigen Estimates geben können. Meist fehlt dafür schlicht die Zeit oder eine ausreichende Spezifikation oder beides. Teams müssen lernen, diese Risiken auszugleichen und genau dafür ist die Methodik Scrum geschaffen. Die beiden Grundwerte von Scrum drehen sich daher um Commitment und Completion. [Die 4 C’s: Das Wesen von Scrum] Der Umgang mit diesen Grundwerten steht daher im Fokus eines Scrum Trainings. Commitment bedeutet nichts anderes, als im Sprint geplante Storys abzuliefern, d.h. eine ziemlich präzises Schätzung für kleinere Aufgaben und Zeiträume zu geben. Completion bedeutet schlicht Fertigwerden, also z.B. die Implementierung eines Features so abzuschließen, dass dabei „working software“ herauskommt. Im Grunde können nur so die enormen Risiken agiler Entwicklung minimiert werden und das Abgleiten in die Beliebigkeit vermieden werden. Ein Team kann sich dann als agiles Team betrachten, wenn es beide Seiten gut beherrscht. Mehr wird von Teams streng genommen nicht erwartet. Sie sehen schon, das Zitieren des Scrum Guides gehört nicht dazu.
In meinen Scrum Trainings konzentriere ich mich mit den Teams zunächst auf das Fertigwerden. Teams haben meist kein so großes Problem damit performant zu entwickeln. Was ihnen immer wieder im Weg steht, sind nicht vollständig abgeschlossene Aufgaben. Das hört sich dann oft ungefähr so an: „Wir sind fast fertig“, „Wir sind fertig, es muss aber noch getestet werden“, „eigentlich sind wir fertig“, „auf meiner lokalen Umgebung hat das funktioniert“, „gestern ging das alles noch“, usw. Das unbedingte Abschließen von kleinen Aufgaben sind Teams aus klassischen Methoden wie Wasserfall nicht wirklich gewohnt. Und genau das müssen Teams in der ersten Phase des Trainings lernen. Fertigwerden. Sprint Accuracy ist also der erste KPI der zu diesem Zweck eingeführt wird. Im Gegensatz zu anderen KPI’s wie z.B. Velocity ist Sprint Accuracy ein kurzfristiger KPI, weist also nicht auf einen langfristigen Trend, sondern wir erwarten, dass Teams mindestens 3 von 4 Sprints erfolgreich abschließen. Die Trainingsmethode ist relativ einfach. Teams sollen sich in den ersten Sprints nur wenige Storys vornehmen, also mehr als ausreichend Puffer lassen. Dann sollen die Storys nacheinander abgearbeitet werden, also nicht nach der Methode „ein Entwickler, eine Story“, sondern möglichst eine Story früh abschließen und dabei so viele Entwickler wie möglich und sinnvoll parallel arbeiten lassen. Teams die fertigwerden können, können auch schnell fertigwerden. Sie werden sehen, in dem Moment in dem Ihre Teams Sprints erfolgreich abschließen können, steigt die Velocity ganz von alleine.
Wenn das funktioniert, gehen wir in die zweite Phase über. Commitment. Wie schätzt sich ein Team richtig ein, wie gelingt es ihm, Storys einigermaßen präzise zu schätzen. Nichts ist doch schöner als wenn ein Team ihrem Product Owner für ein Sprint ein klares Commitment geben kann und der PO sich darauf verlassen kann, dass dies auch gehalten wird. Ganze Organisationen wären plötzlich wieder planungs- und controllingfähig. Da Teams ja nun gelernt haben, Storys vollständig abzuschließen, werden sie jetzt lernen, dies im Geiste schon während des Plannings zu tun, denn nichts anderes ist ein Commitment. Die Teams nehmen das Ergebnis schon mal abstrahierend vorweg. Hier braucht es natürlich mehr Erfahrung und daher lernen wir das auch erst in der zweiten Phase. Da das für Teams in der Regel die größere Herausforderung ist, müssen wir die Umgebung so gestalten, dass Teams diese Aufgabe auch bewältigen können. Dazu empfehlen sich sehr kurze Sprints, maximal eine Woche. Je kürzer eine Periode ist, desto einfacher lässt sie sich überblicken und planen. Und je höher die dadurch entstehende Übungsrequenz wird, desto kürzer dauert die Phase. Was für die Zeiträume gilt, gilt für die Aufgaben natürlich genauso. Kleine Aufgaben lassen sich leichter schätzen als große, daher sollte der Product Owner sich von vornherein angewöhnen, möglichst kleine Storys zu schreiben -je kleiner, desto besser. Das Team dankt es ihm mit einem guten Commitment. Wenn auch diese Phase durchlaufen ist, haben wir die wichtigsten Ziele agiler Entwicklung schon erreicht. Wir können Risiken dadurch minimieren, dass Teams in kurzen Iterationen gestellte Aufgaben gut schätzen- und zuverlässig abschließen können. Mehr will Scrum eigentlich nicht. Und ganz beiläufig haben wir auch die großen Scrum Werte wie Selbstorganisation und Accountability dabei gleich mitgelernt.
In einer dritten Phase kann das Team sich jetzt mit dem Besserwerden beschäftigen. Dabei lernt es Retrospektiven richtig zu nutzen und führt den Langzeit-KPI Velocity als Maß für das Besserwerden ein. Alle die JIRA nutzen, werden hier etwas verzweifeln, denn JIRA kann Velocity nicht gut darstellen. Besser Sie nutzen als Tool runScrum mit echten Velocity-Charts, basierend auf gleitenden Durchschnitten.
Die dritte Phase ist natürlich nie abgeschlossen, denn auch Schachweltmeister trainieren immer weiter. Aber die Teams haben an dieser Stelle eine große Stabilität und Leistungsfähigkeit entwickelt. Wichtig ist beim Scrum Training darauf zu achten, dass Teams möglichst bald das Gefühl bekommen, dass die Scrum Methodik etwas für sie tut und nicht umgekehrt. Scrum erfordert nun mal ein hohes Maß an Disziplin und Teams müssen am Anfang sehr viel für die Methode tun. In dem Moment, in dem sich dieses Gefühl umkehrt und die Methode als hilfreich empfunden wird, haben Teams Scrum verstanden und der Trainer war erfolgreich.