Die Einführung von Scrum in einem einzelnen Team ist zwar eine Herausforderung und sollte mit Bedacht und Erfahrung erfolgen, aber ein guter Scrum Master kriegt das hin, wenn er sein Geld wert ist, und wenn die Rahmenbedingungen einigermaßen stimmig sind. Viel schwieriger ist die Sache bei der Skalierung von Scrum über mehrere Teams. Der Scrum Guide hält sich hierbei sehr bedeckt, stattdessen finden wir nach kurzer Recherche viele unterschiedliche Systeme wie LeSS, Nexus, Scrum@Scale oder SAFe. Dem geneigten Leser stellt sich an dieser Stelle die Frage, welches dieser Systeme wann einzusetzen ist.
Ich kann Ihnen schon jetzt die Hoffnung nehmen, dass es hierauf eine einfache Antwort gibt. Ich kann Ihnen auch keine Entscheidungsmatrix an die Hand geben, unter welchen Bedingungen man welches System einsetzen sollte. Und Sie sollten mir dankbar dafür sein, dass ich es Ihnen eben nicht so leicht mache. Ich halte es für ein großes Problem, blind einem System zu folgen – ganz besonders bei der Skalierung.
Der Grund hierfür ist ganz einfach der, dass sich Teams im Prinzip recht ähnlich sind, während sich Organisationen deutlich stärker voneinander unterscheiden. Wie werden Entscheidungen gefällt? Welchen Grad der Komplexität der Organisation haben wir vor uns? Wie sieht das aktuelle Zusammenspiel der Abteilungen untereinander im Moment aus? Wir könnten starten, indem wir uns für ein System entscheiden und dann unsere Organisation in ein neues Korsett zwängen, womit wir unfassbar viel Widerstand erzeugen, oder wir wählen einen sanfteren Ansatz, indem wir die Dinge konservieren, die aktuell gut funktionieren, und die nicht im Widerspruch zur Agilen Vorgehensweise stehen. Genau hier begegnet uns eine große Schwierigkeit: viele Dinge und Abläufe stehen der Agilität entgegen, werden aber nicht angerührt, weil sie nicht einmal in Frage gestellt werden. Die Geschäftsführung entscheidet, darunter gibt es eine Programmleitung, dann diverse Projektmanager und schließlich die ausführenden Teams. Brechen wir diese Entscheidungshierarchie nicht auf, können wir es auch gleich ganz sein lassen. Worin liegt der Gewinn in der Umstellung auf Agile Methoden, wenn wir das Grundproblem nicht angehen?
Und jetzt wird es richtig eklig: wer trifft denn in Ihrem Unternehmen die Entscheidung, auf Scrum zu setzen? Die betroffenen Teams oder die Geschäftsleitung? Der Widerspruch, dass wir ein System einführen möchten, dass die Teams und einzelnen Mitarbeiter stärkt, und dies über deren Köpfe hinweg entscheiden, ist leider nicht jedem bewusst. Wenn Sie es also noch nicht getan haben, sprechen Sie mit Ihren Kollegen und erklären Sie ihnen, warum Sie Scrum für eine gute Idee halten, und dann fragen Sie sie nach ihrer Meinung dazu.
Jetzt aber genug von diesem Thema. Der Prozess der Entscheidung für Scrum könnte selbst ein ganzes Buch füllen, wir sind in unseren Überlegungen aber schon weiter. Wir fragen uns im Moment, wie wir Scrum auf unsere 6 Teams skalieren. Hier schließt sich der Kreis zu der Entscheidung der Geschäftsleitung. Mein dringender Rat an Sie lautet: geben Sie nichts vor, sondern erarbeiten Sie die Skalierung gemeinsam mit Ihren Kollegen aus den betreffenden Teams. Dahinter steht der einfache Gedanke, dass wir unser System nicht von oben nach unten sondern von unten nach oben aufbauen.
Jetzt kommen wir auch zu dem Punkt, warum ich es für schwierig halte, einfach ein fertiges System einzusetzen. Weil das genau dem widerspricht, was ich im letzten Absatz geschrieben habe. Oder formulieren wir es anders und etwas ausführlicher:
Wir haben eine Reihe von Teams vor uns, die bestimmten Aufgaben nachgehen und an einem oder mehreren Projekten arbeiten. Ein guter Ansatz wäre es jetzt, Product Owner und je einen Entwickler aus jedem Team zusammenzutrommeln und die Abhängigkeiten untereinander zu erarbeiten. Im Anschluss daran stellen wir die Frage, was wir tun müssen, um diesen Abhängigkeiten genüge zu tun.
Ein Beispiel: alle Teams arbeiten gemeinsam an einem Projekt und auch an einer Codebasis. Releases müssen unter allen Teams koordiniert werden. Da alle Teams in den selben Sourcen arbeiten, benötigen wir sicherlich gemeinsame Regeln, z.B. in Form eine Styleguides, den Entwickler aus mehreren Teams gemeinsam erstellen können. Für die Abstimmung der Releases benötigen wir sicherlich einen Austausch der Teams untereinander, was z.B. in einem täglichen Scrum of Scrums (SoS) erfolgen kann. Für rein technische Themen, die alle Entwickler betreffen, könnte man sich eine Community of Practice (CoP) vorstellen, an der ein Vertreter aus jedem Team teilnimmt. Dieser wäre wiederum dafür verantwortlich, das dort erarbeitete Wissen in sein eigenes Team weiterzutragen.
Eine kurze Anmerkung: Diese Form der CoP ist keine reine Community of Practice im ursprünglichen Sinn. Eine CoP ist eine freiwillige Runde aus Personen mit ähnlichen Interessen. Unsere Auffassung einer CoP ist in gewisser Weise „verschärft“.
Viele dieser Fragen bilden den „inneren Kern“ unserer Skalierung – die Koordination der Teams untereinander. Dazu gehören natürlich auch Dinge wie die Form des Backlogs, die Rolle eines Chief POs, Koordination von Terminen usw., richtig interessant wird es jedoch erst, wenn wir uns dem In- und Output widmen. Wie kommen Anforderungen in die einzelnen Teams, und wie sind die Abläufe um die Teams herum? Daran hängt die Frage, wieviel Agilität können wir ausgehend von den Entwicklungsteams in das Unternehmen bringen?
Hier ist die Frage wichtig, ob wir eine Sammlung von mehreren Teams haben, von denen jedes einzelne direkt mit den Stakeholdern kommuniziert, ober haben wir einen Chief PO, der die gesamte Entwicklungsabteilung nach außen repräsentiert und als Schnittstelle agiert?
Hier ist meine einzige echte Empfehlung in diesem Blogartikel: Sorgen Sie bitte unbedingt dafür, dass es in einem System, in dem mehrere Teams an einem Projekt arbeiten, eine Person gibt, die eine Schnittstelle zwischen Teams und Stakeholdern darstellt. Andernfalls erzeugen Sie nur Chaos, weil dann jeder mit jedem über alles sprechen könnte, und am Ende keiner mehr weiß, wann wer mit wem worüber geredet hat. Es ist für alle Beteiligten einfacher, wenn die Entwicklung von außen als eine Einheit wahrgenommen wird. Ein solcher Chief PO kann sowohl zusätzlich PO in einem Team sein als auch die Rolle CPO exklusiv ausfüllen. Ab einer Größe von vier Teams rate ich allerdings dazu, den Chief PO von allen anderen Dingen zu entlasten.
Hier findet Ihr eine Übersicht von Videos zu diesem und anderen Themen
Spätestens jetzt ist der Moment erreicht, in dem wir nicht mehr allein mit unseren Kollegen aus der Entwicklung sprechen können. Jetzt müssen wir uns darum kümmern, wie die Abläufe innerhalb des Unternehmens aussehen. Wie, wann, in welcher Form und von wem kommen Anforderungen, und wie viel Entscheidungsbefugnis liegt bei der Entwicklung?
Wo bleiben die Prinzipien der Agilität, wenn eine Programmleitung Umfang und Termine eines Projekts detailliert vorgibt? Dies ist die größte Herausforderung für den Scrum Master: außerhalb der Entwicklungsteams das Verständnis der Agilität zu schaffen, um zu einer gemeinsamen Lösung zu kommen. Unser Ziel ist, dass wir Stakeholder und Chief PO (oder die PO’s der einzelnen Teams) regelmäßig an einen Tisch bekommen, damit diese sich untereinander abstimmen. Sowohl bei Scrum in einem einzelnen Team als auch bei der Skalierung ist es eine unserer wichtigsten Aufgaben, die Einbahnstraßen zu vermeiden. Eine reine Top-Down-Entscheidung widerspricht allem, was wir mit der Agilität erreichen möchten.
Auch hier gehen wir wieder genau so vor, wie wir es innerhalb der Teams tun. Wir erarbeiten gemeinsam die Anforderungen und stellen dann die Frage, mit welchen Zeremonien oder Artefakten wir diese am besten abbilden können. Dem Scrum Master kommt dabei eine besondere Rolle zu: er moderiert diese Treffen, in denen wir unseren „Weg nach Rom“ erarbeiten, leitet die Kollegen dabei an, wie sie zu einem Ergebnis kommen können, und macht Vorschläge, wie welcher Anforderung zu begegnen sein könnte. Wichtig ist jedoch auch hier, dass der SM keine Entscheidung trifft. Wir machen Vorschläge, leiten an, regen an, aber die Entscheidungen treffen die Teams. Lediglich wenn wir der festen Überzeugung sind (aus Erfahrung oder sicherer Kenntnis) dass sich das Team auf einem fatalen Weg befindet, schreiten wir ein und klären auf. Dabei verbieten wir nicht, sondern wir erklären, warum der gerade diskutierte Vorschlag sehr schwierig ist.
Starten Sie klein. Legen Sie mit einem geringen Aufwand los und haben Sie ein offenes Auge, wann welcher Anforderung an unser System noch nicht genügt wird. Wenn wir regelmäßig mit allen Beteiligten sprechen, werden wir die Schwachstellen schnell finden, so dass wir für alles Lösungen erarbeiten könnten. Versuchen Sie garnicht erst, von Anfang an eine (fast) perfekte Organisation aufzubauen. Das klappt sowieso nicht, und Sie opfern viel Zeit in theoretischer Arbeit, während Sie schon praktische Erfahrung sammeln könnten. Haben Sie keine Angst davor, Dinge falsch zu machen. Wir können aus allem lernen, aber wenn Sie Agilität richtig verstanden haben, dann wissen Sie das sowieso.
Grundsätzlich gilt, dass viele (nicht alle) Wege nach Rom führen. Einige sind steiniger, andere bequemer, einige kürzer, andere länger. Vergessen Sie nicht, dass auch bei der Skalierung nichts in Stein gemeißelt ist. Wenn wir feststellen, dass einige unserer Antworten nicht gut funktionieren, dann finden wir eben neue. Am Anfang steht lediglich die Frage: Ist es gut genug, damit zu starten? In den folgenden Wochen und Monaten werden wir bei der Skalierung ebenso wie in den einzelnen Teams immer wieder nachschärfen, Dinge umwerfen und neue und bessere Lösungen finden.
Folgt mir auf twitter, um keine neuen Beiträge zu verpassen.
