Die Einführung von Scrum ist immer mit vielen Fragen verbunden, und eine der wichtigsten ist: Womit fange ich an? Die Antwort ist einfach: Am besten mit allem gleichzeitig. Das ist jedoch nur die halbe Wahrheit, denn die Etablierung von Scrum im Unternehmen beginnt schon lange vor dem ersten Daily.
Viele Teams versuchen eine schrittweise Einführung Agiler Softwareentwicklung, weil man meint, den harten Schnitt nicht stemmen zu können. Zu viele Personen müssten sich an zu viele neue Dinge gewöhnen, die Abläufe würden auf zu vielen Ebenen verändert, die Widerstände würden zu groß. Also beginnt man vielleicht damit, tägliche Stand-Up-Meetings als ersten Schritt einzuführen. Dem folgt vielleicht ein erster zaghafter Versuch, ein paar Personen an ein Backlog zu gewöhnen, die Gantt-Diagramme existieren jedoch weiterhin.
In meinen Augen ist ein solches Vorgehen vollkommener Blödsinn. Ich weiß nicht einmal genau, wo ich mit meiner Begründung für diese Aussage beginnen soll, weil es auf so vielen Ebenen nicht sinnvoll ist. Nur ein Beispiel: Ein Daily ist in einem starren Modell lediglich ein weiteres Reporting, aber gerade das ist nicht der Sinn unseres morgendlichen Stand-Ups. Nacheinander einzelne Zeremonien und Artefakte zu etablieren wird schon deshalb schwierig, weil sie bis zur vollständigen Einführung von Scrum aus dem Zusammenhang gerissen sind.
Dennoch kann man durchaus sagen, dass die Einführung Agiler Entwicklung in Ihrem Unternehmen schrittweise läuft. Das bezieht sich jedoch nicht auf Artefakte und Zeremonien, sondern auf den gesamten Prozess, denn wir nicht allein auf diese Dinge beschränken dürfen. Was passiert denn bei einer solchen Veränderung in Ihren Abläufen? Zunächst einmal muss jemand eine Entscheidung treffen. Und wer ist das? Genau hier beginnt der Weg in kleinen Schritten.
Sehr oft sehe ich, dass Scrum (oder Kanban) von der Geschäfts- oder Abteilungsleitung vorgegeben wird. Man erhofft sich sich eine Steigerung der Entwicklungsgeschwindigkeit und der Qualität, liest sich ein wenig ein und glaubt, mit Scrum die Antwort auf alle Fragen gefunden zu haben. Im Moment machen sowieso alle dieses Zeug, also muss da was dran sein. Wir machen jetzt also auch Scrum. Kurzerhand wird ein Project Manager zum Product Owner, irgendjemand wird zum Scrum Master, und alle erhalten den Auftrag, möglichst schnell mit Scrum zu beginnen.
Wenn ich weiter oben schon Probleme hatte, zu beschreiben, warum die schrittweise Einführung der Zeremonien und Artefakte wenig sinnvoll ist, so fehlen mir jetzt fast die Worte, aber ich versuche es trotzdem einmal: Sehen wir uns das Agile Manifest an, so finden wir dort eine der vier Kernthesen: »Individuen und Interaktionen sind wichtiger als Prozesse und Tools«. Ein solches Vorgehen widerspricht genau diesem Leitsatz Agiler Softwareentwicklung. Vor einer solchen Entscheidung steht immer das Umdenken, und genau dort wollen wir ansetzen. Es geht nicht darum, einen Prozess einzuführen, es geht um eine Änderung der Einstellung und Sichtweise. Der Prozess ist nur ein Spiegelbild dessen. Die Einführung von Scrum ohne den passenden Unterbau in der Unternehmensphilosophie (allein für diesen Begriff werfe ich gern einen Fünfer in das Phrasenschwein und sammle ein paar Punkte im Bullshit-Bingo), ist Scrum zum Scheitern verurteilt.
Was sollten wir also tun?
Wenn Sie mit der Vorgabe »Scrum« konfrontiert werden, stellen Sie die Frage nach der Motivation. Machen Sie klar, dass Agilität zunächst eine Frage der Einstellung ist, Scrum ist lediglich die sichtbare Erscheinungsform. Die Sache ist in gewisser Weise mit plastischer Chirurgie vergleichbar. Sie können bis zu einem gewissen Grad das Aussehen eines Menschen verändern, die charakterlichen Eigenschaften bleiben davon jedoch weitestgehend unberührt. Unser Ziel ist jedoch eine Veränderung im Unternehmen, in seinem Denken und Vorgehen, nicht eine Veränderung der Erscheinungsform.
Am Anfang steht also keine Vorgabe, sondern vielmehr ein Frage: Was versprechen wir uns von einer Veränderung? Welche Probleme und Schwächen wollen wir damit adressieren, welche Stärken möchten wir ausbauen?
Wer stellt diese Fragen wann wem? Das ist eigentlich egal. Es kann die Geschäftsführung sein, es kann ein einzelner Entwickler sein, ein Project Manager, ein Team, wer auch immer. Wichtig ist allerdings, dass nicht der Fragesteller gleich die Antwort liefert, sondern, dass wir uns diese einleitenden Fragestellungen gemeinsam betrachten. Vergessen wir nicht: Individuen und Interaktionen sind wichtiger als Prozesse und Tools. Gemeint ist mit diesem Satz, dass die Stärke einen Unternehmens in der Zusammenarbeit der handelnden Personen liegt. Auf diese Zusammenarbeit kommt es uns an.
Wir beginnen also mit einfachen Fragen. Was möchten wir verändern? Welche Probleme haben wir? Welche Stärken haben wir? Die Antwort liefern wir gemeinsam und gehen damit den ersten echten Schritt bei der Einführung von Agilität, auch wenn wir vielleicht zum Schluss kommen, dass Scrum nicht der richtige Weg für uns ist.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Wenn wir uns geeinigt haben, dass Scrum für uns der richtige Weg ist, dann ist eine Formulierung ganz wichtig: Wir probieren Scrum nicht einmal aus, wir setzen es um. Punkt. Unterschätzen Sie nicht den Unterschied, den wir hier vor uns haben. Wenn wir etwas nur einmal ausprobieren wollen, dann haben wir jede Entschuldigung, es nur mit halber Kraft zu versuchen, weil wir immer sagen können, dass es ja sowieso nur ein Test sei. Wenn wir jedoch an die Umsetzung anstatt an einen Versuch gehen, dann commiten wir uns auf etwas. Ein Versuch beinhaltet immer auch den möglichen Weg zurück, eine Umsetzung nicht.
Ich kann nicht genug betonen, wie wichtig diese Kleinigkeit ist. Der Erfolg von Scrum hängt immer von der Umstellung im Denken ab, und genau die finden wir hier. Halten wir also fest, dass die ersten Schritte Dialog, Konsens und Commit sind. Haben wir eines davon nicht erreicht, prophezeie ich ein Scheitern von Agilität. Wird Scrum von der Geschäftsführung vorgegeben, kann es an Verständnis und daher an Unterstützung mangeln. Haben wir keinen Konsens erzielt und einige Personen überstimmt, müssen wir mit aktivem und passivem Widerstand rechnen. Commiten wir uns nicht, werden wir uns der Sache nur mit halber Kraft widmen.
Gehen wir aber davon aus, dass wir unsere Sache bis jetzt gut und richtig gemacht haben, dann stehen wir jetzt vor der Frage, wie wir praktisch beginnen sollen. Haben wir mehrere Teams, rate ich Ihnen dringend zu einem Piloten. Führen wir Scrum gleich über mehrere Teams ein, verbinden wir die Einführungs- mit den Skalierungsschmerzen, und glauben Sie mir: das wollen Sie nicht. Es ist ganz selbstverständlich, dass nicht alles vom ersten Tag an rund läuft. Eine Veränderung in einem Team ist sehr viel überschaubarer. Die Ursachen lassen sich leichter identifizieren und bekämpfen. Die Dinge, die wir mit unserem ersten Team lernen, können wir bei den folgenden Teams nutzen.
Ich würde davon ausgehen, den Piloten drei bis vier Sprints lang laufen zu lassen, und dann das nächste Team nachzuziehen. Mit den gewonnenen Erkenntnissen wird der Start hier dann umso leichter. Natürlich kann sich diese Phase auch in die Länge ziehen. Vermeiden Sie also einen festen Zeitplan, schließlich unterliegt auch der Prozess selber vielen Ungewissheiten. Ist der Start im ersten Team schwierig, dann sollten wir warten, bis es hier rund läuft, bevor wir an das zweite Team denken.
Gehen wir noch weiter ins Detail, und betrachten wir uns nur unseren Piloten, dann stehen wir ganz schnell vor der Frage unserer ersten Maßnahmen, und hier schließt sich der Kreis zur Einleitung. Ich rate Ihnen dringend dazu, einen harten Schnitt zu machen, und nicht einzelne Zeremonien oder Artefakte nach und nach einzuführen. Diese ergeben nur in ihrer Gesamtheit einen echten Mehrwert.
Wir sprechen als neuer Scrum Master also mit dem Team, das hoffentlich in die Entscheidung für Scrum eingebunden war, und fragen zunächst einmal nach Wünschen, Erwartungen und Befürchtungen. Kennen wir diese nicht, geben wir nur wieder Anweisungen ohne Rücksicht auf die individuellen Bedürfnisse oder Wünsche der Kollegen, und gerade das wollen wir ja vermeiden.
Gehen wir jetzt davon aus, dass wir Scrum gut erklärt haben, dass alle ein gutes Grundverständnis von den Zeremonien und Artefakten haben, dann sollten wir uns in jedem Fall um die Frage kümmern, ob wir eine gemeinsame Vorstellung von Agilität entwickeln können. Was wollen wir erreichen, wie wollen wir arbeiten, und was ist uns besonders wichtig. Die Frage, wie wir arbeiten wollen, bezieht sich in diesem Zusammenhang nicht auf Dinge wie Sprintlänge oder Zeitpunkt des Dailies. Diese Details sprechen wir in einer Runde an, einigen uns auf einen Wert und laufen los. Stellen wir nach einiger Zeit fest, dass einwöchige Sprints besser zum Team passen als zweiwöchige Sprints, stellen wir eben um. Wir starten nicht willkürlich mit einzelnen Werten, sondern machen uns schon unsere Gedanken, aber genaue Erkenntnisse werden wir erst in der Praxis gewinnen.
Der erste praktische Schritt bei der Einführung von Scrum ist also sehr einfach: wir einigen uns auf einen Tag, an dem wir umstellen, und dann tun wir es einfach. Der Weg dahin ist jedoch viel wichtiger und ungleich komplizierter.
Im nächsten Blogbeitrag werde ich diese Frage vertiefen und mich mit den konkreten ersten Schritten und »Einstellungen« beschäftigen. Dann betrachten wir uns Sprintlängen, Zeremonientage, Artefakte usw.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
