Die Skalierung von Scrum ist doch gar nicht das Thema!

So langsam beginnt mich das Thema „Skalieren von Scrum“ zu nerven. Warum? Ganz einfach: Ständig sollen wir beweisen, dass auch große Projekte mit Scrum möglich sind. Als müsste Scrum – das nichts weiter als ein Vorgehensmodell ist – zeigen, wie alles gut wird. Können das denn die traditionellen Methoden? Mittlerweile wissen wir doch aus unzähligen Untersuchungen, dass mit zunehmender Größe eines Projekts die Wahrscheinlichkeit des Scheiterns steigt. Warum sollte man also überhaupt große Projekte durchführen? Warum etwas immer und immer wieder versuchen, das mit hoher Wahrscheinlichkeit nicht erfolgreich sein wird?Ja, aber ... können große Projekte mit Scrum trotzdem erfolgreich sein? Sicher. Heute können wir problemlos Scrum-Projekte mit mehr als 100, 1.000 oder sogar 10.000 Leuten durchführen. Die Mechanismen sind bekannt, alleine schon unsere Scrum Checklist zeigt die dafür nötigen, wichtigsten Elemente. Allerdings wird damit oft nur versucht, das Alte in einen neuen Mantel zu stecken. Alles andere bleibt so ineffizient wie bisher. Die Frage wird nämlich falsch gestellt. Sie lautet nicht „Wie skaliert man Scrum?“, sondern: „Wie gelingt es uns, hoch komplexe, große Vorhaben durchzuführen?“

Großartiges wird immer von wenigen geleistet

Bei näherer Betrachtung erkennt man an manchen Projekten, dass sie unnötig aufgeblasen werden. Aus politischen Gründen werden sie teurer, als sie es sein müssten. Viele dieser Projekte könnten mit weniger Menschen, weniger Budget und weniger Druck kostengünstiger und effektiver geliefert werden. All das ist im Chaos Manifesto 2014 der Standish Group nachzulesen. Auch Dan Ward zeigt in seinem Buch „F.I.R.E.“ deutlich, dass die meisten Militär-Großprojekte immer dann gelingen, wenn bei strikter Einhaltung des Budgets einfache Lösungen gesucht werden.Doch obwohl das eigentlich jeder weiß, stellen sich nun mit Agilität befasste Unternehmen die gleiche Frage wie ich als Early Scrum-Adopter vor 10 Jahren. 2004 hatte ich meine beginnende Karriere als Certified Scrum Trainer unterbrochen, um als Chef der Software-Entwicklung zurück in ein großes deutsches Unternehmen zu gehen. Die Frage „Wie skaliert man Scrum?“ ließ mich nicht los. Ich wollte wissen, wie man mit 40 Entwicklern an einem Standort und einem weiteren Team in Berlin gemeinsam erfolgreich scrummen kann. Zwischen 2004 und 2008 entwickelte ich mit anderen in der Scrum Community die Mechanismen für die Skalierung . Und wir haben sie ausprobiert: Nach Projekten mit 200 und mehr Entwicklern hatten sich die nötigen Best Practices herauskristallisiert. Wir hatten bewiesen, dass es funktioniert, aber wir hatten auch herausgearbeitet, warum es so schwer umzusetzen war.Das heißt: Es war zwar möglich, große Projekte zu managen, aber gleichzeitig verliefen sie nicht sonderlich effektiv. Dazu war viel zu viel Management-Overhead notwendig.Allmählich wurde klar, dass – obwohl wir erfolgreich waren – die Frage „Wie skaliert man Scrum?“ falsch gestellt worden war. Noch erfolgreicher waren nämlich jene Unternehmen, die große Projekte durch agile Vorgehensmodelle in kleine Projekte geschnitten und viele kleine Scrum-Teams an die Problemstellung gesetzt hatten. Ihre Projekte waren also gar keine „großen“ Projekte im klassischen Sinne mehr. Ihr Paradigma lautete: Die Entscheidung darüber, was wie zu tun ist, wird den Teams überlassen – und dadurch etablierten sich im Laufe der Jahre neue Führungssysteme. Es ist ja auch logisch: Die wichtigsten Erfindungen der Menschheit, die wissenschaftlichen Durchbrüche, die Cash-Cows von Unternehmen wurden in den seltensten Fällen von 200+ Menschen entwickelt. Nein, sie wurden von einigen wenigen, meist einer kleinen Gruppe von Menschen entwickelt. Also von kleinen Teams, die etwas Großartiges leisten wollten.

Skaliert wird durch Führung, Architekturen und Infrastrukturen

Schon höre ich das 08/15-Gegenargument: „Aber es gibt Aufgaben, die können nun mal nicht von einer kleinen Gruppe erledigt werden. Man baut ein Fußballstadion, einen Flughafen oder Photoshop nicht mit 7 Personen.“Korrekt! Bei keinem unserer Kunden arbeiten wir an Projekten, die mit sieben Personen zu bewältigen wären. Natürlich müssen wir darüber nachdenken, wie man mehr als 7 Personen, ja wie man mehr als 7 Teams synchronisiert. Einer unserer Kunden will sogar sein gesamtes Unternehmen im Scrum-Klang schwingen lassen. Wie geht das?Wir skalieren

1. über die Führung von Teams und nicht über Prozessmodelle 1. Ordnung
2. über eine angepasste Architektur und Entkopplung der einzelnen Komponenten oder Produktgruppen und
3. durch das Einziehen von Infrastrukturen, die das ständige Integrieren der fertigen Produktteile in ein Ganzes ermöglichen.

Gleichzeitig gilt: Die Teams müssen sich selbst ihre Prozesse, ihre Checklisten, ihre Arbeitsabläufe geben. Sie definieren also für sich die Art und Weise, wie sie arbeiten. Nach einiger Zeit sind sie dann selbst in der Lage, sich teamübergreifend zu synchronisieren und bei Problemen sofort zu bemerken, dass es diese Probleme gibt.

Neue Rezepte? Nicht nötig.

Das alles ist doch kein Hexenwerk. Dazu braucht man keine neuen Scrum-Frameworks, wie das SAF oder LaaS oder XYZ. Bei genauer Betrachtung sind solche Schablonen sogar hinderlich. In meinen Augen sind sie Rückschritte im Vergleich zu den eigentlichen Frameworks von Scrum oder Kanban. Dabei haben wir es nun nämlich mit allzu ausgefeilten Prozessmodellen 1. Ordnung zu tun. Prozessmodelle 1. Ordnung sind mit Rezepten in Kochbüchern vergleichbar, etwa mit den „30 Minuten Menüs“ von Jamie Oliver. Obwohl wir alle – mich eingeschlossen – natürlich gerne solche Rezepte hätten, müssen wir akzeptieren, dass die Welt und die Projekte in ihr zu komplex sind, als dass sie sich in Rezepte pressen ließen.Was wir also beim Thema Skalierung nicht gebrauchen können:

1. Noch mehr Bürokratie in Gestalt von noch mehr Prozessvorschriften 1. Ordnung.
2. Noch mehr Verwaltungsakte.
3. Noch mehr Entscheidungsdelegation.
4. Noch mehr Kollegen, die nur fürs Steuern da sind und nicht wissen, wie die eigentliche Arbeit funktioniert.

Obwohl es offensichtlich ist, erwähne ich das deshalb, weil wir gerade die ersten Anzeichen einer Scrum-Bürokratie erkennen können. Ganz sicher brauchen wir aber keine Company ScrumMaster, die darüber wachen,

1. ob alle Dokumente vorhanden sind, die Scrum vorschreibt
2. ob sich die Team ScrumMaster treffen oder
3. die Qualitätsstandards einhalten. Eine Stichprobe mag im einen oder anderen Fall notwendig sein, um dem einen oder anderen ScrumMaster noch einmal etwas zu zeigen. Aber es sollte nicht so weit kommen, dass Company ScrumMaster zu Verwaltern oder Hütern des „heiligen Scrums“ werden.

Im Grunde brauchen wir noch nicht mal verbesserte Varianten für das Schreiben von User Stories oder noch bessere elektronische Verwaltungsmaschinen. (Was nicht heißt, dass gute Ideen zu noch besseren Hilfsmittel nicht hilfreich sein können.)Wirklich notwendig sind hingegen Tools, die in Management-Frameworks („Modelle“ klingt mir zu sehr nach Spielzeug)

1. allen Beteiligten noch schneller Feedback liefern.
2. im entscheidenden Moment eine Konversation aller Beteiligten erzwingen.
3. dabei helfen, miteinander zu arbeiten, wenn man nicht am gleichen Ort ist.

Wenn wir es mit großen Teams zu tun haben, brauchen wir Frameworks, die selbst Prozesse erzeugen können. Frameworks, die Managern dann auch dabei helfen, die erzeugten Prozesse immer wieder zu verändern, so dass sie für die Anforderungen der großen Gruppe oder der Internationalisierung angepasst werden können. Diese Art von Frameworks nennt man Prozessmodelle 2. Ordnung. Dazu gehören Scrum, Kanban, die Theory U, die Appreciative Inquiry, die Open Space Methode oder die 14 Punkte des Toyota Production Systems.

Gesucht: Company ScrumMaster die führen

Die Company ScrumMaster sind dazu da, die Rahmenbedingungen für die anderen ScrumMaster im Unternehmen zu schaffen. Es sollten Menschen sein, die Scrum im Unternehmen weiter vorantreiben und neue Wege für das Lösen von Problemen finden, damit Unternehmen noch effektiver und produktiver arbeiten können. Daher müssen diese Company ScrumMaster auch führen – nämlich an den Punkt, an dem sich die Teams und schließlich die ganze Organisation immer mit dem Kunden im Blick selbst organisieren. Diese Company ScrumMaster ermöglichen Selbstorganisation im großen Stil.Womit wir beim Kern der Skalierung in Scrum wären: Scrum skaliert. Punkt.Ein Company ScrumMaster kann dafür sorgen, dass es einfacher wird, wenn er vier – ich nenne es einmal „Dimensionen“ – in Einklang bringt und so aufeinander ausrichtet, dass die Organisation ihre Aufgaben bewältigen kann.1. Befähigung. Die Akteure müssen zur Führung ihrer Teams in die Selbstorganisation befähigt werden. Sie sollten Anleitung zur Selbstorganisation und im Treffen von Entscheidungen bekommen, so damit sie selbst wiederum ihre Teams zum autonomen Arbeiten führen können.2. Rhythmus. Scrum bedeutet Taktung und Flow. Der Company ScrumMaster muss die Wertschöpfungskette abbilden und oftmals erst durch die Verdeutlichung etablieren und verteidigen. Dann muss er sie so gestalten, dass nicht nur das einzelne Team, sondern das gesamte Unternehmen seinen Rhythmus finden kann (wie Nonaka das nennt.)3. Architektur. Die Struktur der Produkte oder der Organisation (das kann ein Team, eine Abteilung, ein großes Team etc. sein) sollte so gewählt werden, dass die einzelnen Teams möglichst autark voneinander liefern können. Ob das eine Holokratie sein muss, oder ob andere Formen besser passen, muss jede Organisation für sich herausfinden. So vertritt 3M die klare Ansicht, dass eine Organisationseinheit nicht mehr als 150 Menschen umfassen sollte.4. Infrastruktur. Technologische Hilfsmittel sollten der Organisation dazu verhelfen, Produktionsfortschritte ständig (mehrmals pro Woche, noch besser pro Tag) sichtbar und damit spürbar zu machen (z.B. durch Integrationsserver, Simulationen, Modelle, Prototypen).Werden diese vier Dimensionen in der vorgegebenen Reihenfolge berücksichtigt, hat Skalierung eine Chance. Dann wird jede Schablone überflüssig.