Scrum besteht nur aus wenigen sehr einfachen Regeln. Dennoch treffe ich immer wieder auf Unternehmen, die sagen: »Wir machen Scrum, aber …« Diese »ScrumButs« gelten im allgemeinen als sicheres Indiz dafür, dass man die Essenz der Agilen Vorgehensweise nicht verstanden hat und den scheinbar leichten Weg wählt, Scrum auf die eigenen Bedürfnisse anzupassen, wobei es richtiger wäre, sich selbst an die von der Agilität vorgegebenen Spielregeln anzupassen. Oder gibt es ScrumButs, die wir tolerieren können?
Eigentlich ist die Antwort klar. Scrum besteht aus sehr wenigen Regeln, und jede Einzelne erfüllt einen Zweck. Lässt man eine der Zeremonien weg oder modifiziert sie so stark, dass sie einen anderen (oder keinen) Zweck mehr erfüllt, dann entfernt man einen großen Teil. Die Retrospektive z.B. dient dazu, dass das Team den vergangenen Sprint reflektiert und Wege sucht, das eigene Vorgehen zu verbessern. Es sollen Schwachstellen in den Beziehungen zu anderen Abteilungen oder in der Kommunikation mit Stakeholdern oder ähnliche Dinge aufgedeckt werden. Wenn wir uns die Retrospektive sparen, wann kümmern wir uns um diese Themen? Oder sind wir der Ansicht, dass man diese Fragen nicht betrachten sollte?
Ich verstehe sehr gut, wie es zu diesen ScrumButs kommen kann. Selbstverständlich ist es einfacher, ein System so anzupassen, wie man es zu brauchen meint, als sich selbst anzupassen. Aber gerade darin besteht die Aufgabe, der wir uns stellen müssen, ansonsten könnten wir uns die ganze Sache auch sparen. Eigne ich mir aus einem sehr überschaubaren Regelkatalog nur die Dinge an, die mir gefällig sind, dann muss ich mir die Frage nach dem Sinn stellen. Was möchte ich dann noch erreichen? Handelt es sich dann wirklich noch um ein Agiles Vorgehen?
Um diese Frage zu beantworten, müssen wir wahrscheinlich wieder einmal das Agile Manifest bemühen, weil uns das eine sehr kurze Definition von Agilität liefert. Individuen und Interaktionen, funktionsfähige Software, Zusammenarbeit mit dem Kunden, Eingehen auf Veränderungen. Das sind die Dinge, die bei der Agilität im Mittelpunkt stehen. Entfernen wir eines der Elemente aus Scrum, schaffen wir automatische eine Einschränkung. Sparen wir uns das Daily, schränken wir die Interaktionen der Entwickler ein. Verzichten wir auf das priorisierte Backlog, dann fällt das Ergebnis der Zusammenarbeit mit dem Kunden unter den Tisch. Eine solche Liste ließe sich einfach fortführen. Es hat einen Grund, warum es so wenige Regeln in Scrum gibt: jede Einzelne erfüllt einen Zweck.
Doch auch wenn wir das wissen, sind wir immer wieder versucht, Scrum an unser bisheriges Vorgehen im Unternehmen anzupassen. Die meisten ScrumButs werden schließlich nicht damit begründet, dass diese eine Regel keinen Sinn mache, die meisten Gründe folgen eher dem Muster »Das können wir bei uns nicht so machen«. Man hat sich an ein bestimmtes Vorgehen gewöhnt (und damit ist der größere Rahmen gemeint, von dem die Entwicklung nur ein kleiner Teil ist), und man glaubt, dies beibehalten zu können und trotzdem noch agil zu sein. In den allermeisten Fällen ist das ein Trugschluss.
ScrumButs beziehen sich jedoch nicht nur auf das Modifizieren oder Weglassen einzelner oder mehrerer Zeremonien. Sie können auch das Verständnis der Rollen zum Thema haben. So sind mir bereits Settings begegnet, in denen der Product Owner dem Team die Vorgabe gemacht hat, wie viele Story Points sie in einem Sprint bearbeiten. Begründet wurde dieses Vorgehen meist mit der Unerfahrenheit der Teammitglieder. Der sehr erfahrene Product Owner könne besser beurteilen, was das Team in zwei Wochen schaffen könne.
Sie erkennen sofort, dass hier ein grundlegendes Prinzip der Agilität, nämlich die Selbstverwaltung des Teams, ad absurdum geführt wird. Dennoch sind solche Dinge keine Einzelfälle. Viele ScrumButs werden mit Unerfahrenheit begründet, unser Ziel sollte jedoch sein, dass die betreffenden Personen die Erfahrungen machen können. In unserem Beispiel bedeutet dies, dass das Team durchaus ein Commitment abgeben sollte. Wenn es sich irrt, hat es etwas für den nächsten Sprint gelernt. Nach einigen Durchgängen wird es in der Lage sein, eine sehr viel bessere Einschätzung abzugeben. Die Einführung von Scrum ist immer mit Schmerzen und einer mal steileren und mal flacheren Lernkurve verbunden. Wenn wir versuchen, dies zu vermeiden, um uns den Start zu vereinfachen, dann werden wir uns als Team und Unternehmen niemals weiterentwickeln. Mit anderen Worten: wir könnten uns den ganzen Mist sparen.
ScrumButs kommen meist dann zum Tragen, wenn man sich mit Agilen Grundsätzen nicht recht anfreunden möchte. Besonders anfällig hierfür scheinen vor allen Dingen Unternehmen zu sein, in denen einen Struktur und Abläufe gewachsen sind, die bei der Einführung von Scrum angepasst werden müssen. An dieser Stelle greifen wieder die liebgewonnenen Gewohnheiten. Der eine oder andere stellt sich quer und behauptet, dass man bestimmte Dinge nicht ändern könne. Um einer längeren Diskussion oder gar Auseinandersetzung aus dem Weg zu gehen, passt man kurzerhand das neue System an alte Gewohnheiten an und höhlt es damit aus.
Diese gefestigten Unternehmen verfügen über ebenso gefestigte Strukturen, sowohl hierarchisch als auch in ihren Prozessen. Diese Dinge aufzubrechen, erfordert Geduld aber auch ein in gewisser Weise kompromissloses Vorgehen. Jedes Zugeständnis, das wir an diese alten gewachsenen Strukturen machen, erschwert uns ein Agiles Vorgehen. Wir laufen Gefahr, den Agilen Gedanken der kurzfristigen Erleichterung zu opfern, womit wir uns auf lange Sicht das Leben nur schwerer machen.
Aber nicht nur »alte« Unternehmen sind von ScrumButs gefährdet. Auch Startups, die quasi von Null starten, und die vom ersten Tag an alles richtig machen könnten, neigen immer wieder dazu, ihre eigenen Regeln aufzustellen. Sei es, weil man meint, es besser zu wissen, oder weil man der Ansicht ist, von Sachzwängen getrieben zu sein. Man hat vielleicht keinen geeigneten Scrum Master gefunden, oder es fehlt das Geld. In dem Fall muss ein anderer in diese Rolle hineinwachsen, oder man holt sich externe Hilfe.
Nehmen wir uns aber ein anderes Beispiel: Wir haben ein Setting aus mehreren Scrum-Teams und bilden ein temporäres Team, weil sich eine umfangreiche technische Aufgabe ergeben hat, für die wir ein kleines Team aus Experten und Interessierten zusammenstellen, weil wir möglicherweise unsere Applikation auf eine neue Softwareversion heben möchten. Vielleicht haben wir uns entschieden, von Java 7 auf Java 8 umzusteigen. Ein solch technikgetriebenes Team kann durchaus auch ohne Product Owner auskommen. Es braucht nicht zwingend einen Scrum Master, und es kann sich von den Scrum Zeremonien lösen. Es agiert vielleicht eher in einem Kanban-Modus. Wir müssen uns an dieser Stelle nur die Frage stellen, ob es sich um ein Scrum-Team handelt. Die Antwort lautet ganz sicher Nein. Das bedeutet jedoch nicht, dass dieses Team nicht agil vorgeht.
Warum ist es aber so wichtig, dass wir uns diese Dinge bewusst machen? Wenn wir in einem Scrum-Setting die bewusste Entscheidung treffen, dass wir ein temporäres Team bilden, dass nicht den Scrum-Regeln folgt, und somit auch kein Scrum-Team ist, dann ist das vollkommen in Ordnung. Wir sagen damit auch nicht, dass dieses Team damit automatisch nicht agil arbeitet. Es ist lediglich wichtig, dass wir eine bewusste Entscheidung getroffen haben. Wir haben uns die Anforderungen angesehen, haben erkannt, dass für diesen Fall ein anderes Vorgehen geeigneter ist, und haben uns entschieden, einen anderen Weg zu gehen. Das bedeutet nichts weiter, als dass wir uns mit den Anforderungen und der Situation auseinandergesetzt haben.
Ein Problem haben wir nur dann, wenn wir uns der Folgen unseres Handelns oder unserer Entscheidungen nicht bewusst sind. Ich mache mich jetzt zum Ketzer, indem ich sage, dass es durchaus möglich ist, Scrum zu verändern. Ich muss mir nur bei jeder Anpassung die Frage stellen, was ich damit bezwecke, und was das für Folgen haben wird. Schließlich muss ich die Effekte auch beobachten und bewerten.
Ich kann mich beispielsweise entscheiden, dass ich für ein technikgetriebenes Thema auf einen Product Owner verzichten kann. Die Entwicklerkollegen entscheiden dann vollkommen allein. Auch wenn dies dann kein Scrum-Team ist, kann es durchaus agil vorgehen. Ich sollte nun aber beobachten, wie sich die Dinge entwickeln (was ich bei jedem anderen Scrum-Team auch tun müsste). Läuft es gut, das Team organisiert sich und seine Aufgaben vernünftig und neigt nicht dazu, zu viele unwichtige Dinge zu tun, ist alles wunderbar. Verzettelt sich das Team, erledigt eher unnötige Anforderungen und bekommt keine sinnvolle Priorisierung hin, dann war meine Entscheidung, auf einen Product Owner zu verzichten, vielleicht nicht richtig, und ich muss mir neue Gedanken machen.
In diesem Fall ist es kein ScrumBut, es ist schlicht nicht Scrum. Habe ich dies als bewusste Entscheidung getroffen. Ist das vollkommen in Ordnung. Ein ScrumBut, und damit ein Problem, habe ich dann, wenn ich Scrum verändere und an meine (scheinbaren) Bedürfnisse anpasse, ohne das Ganze zu betrachten. Ich kann Scrum verändern und noch immer agil sein, praktiziere dann nur eben kein Scrum mehr. Bei allem, was ich tue, ist es vor allem wichtig, dass ich mir vollkommen darüber im Klaren bin, warum ich was mache.
