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.

Skalierung
bgloger-redakteur
January 15, 2015

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Warum macht ihr eigentlich kein SAFe?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Transformation

FRAGE: Was kostet eine agile Transformation?

Agile Management
Agile Organization
Agile Toolbox
Leadership
Agiles Lernen

FRAGE: Welche Rolle spielt Training?

Agile Coach
Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox

FRAGE: Wer sind die Top 10 agilen Unternehmensberatungen?

Agile Management
Agile Organization
Agile Tools
Agiles Management
Leadership

FRAGE: Wie viel bringt die Investition? Was ist der Business Case dahinter?

Agile Management
Agile Organization
Agile Prinzipien
Agile Toolbox
Führung

FRAGE: Welche sind häufige Herausforderungen, die ihr beim Kunden löst?

Agile Management
Agile Organization

FRAGE: Warum sollten wir mit borisgloger arbeiten?

Agile Management
Agile Organization
Agiles Management
Transformation

FRAGE: Wie viel kostet eine Beratung und ist es wirklich rentabel bei borisgloger?

Agile Prinzipien
Agile Toolbox
Projektmanagement

The Lie Behind the Parable of the Golf Balls and the Jar

Video
Change
Digitale Transformation
Hardware
Agile Organization

Agile in Industrial Automation: The Digital Transformation of Yokogawa

Versicherung
Neues Arbeiten
Führung
Agile Prinzipien
Kundenfokus

Kundenzentrierte Versicherung: Kann ein agiles Projekt die Organisation retten?

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

Agilität in den Vertrieb bringen – für Versicherer sinnvoll

Versicherung
Agile Prinzipien
Kundenfokus
Agile Toolbox
Produktentwicklung

BizDevOps in der Versicherungsbranche – Wie multidisziplinäre Teams wirklich besetzt sein sollten

Versicherung
Agile Prinzipien
Kundenfokus
Neues Arbeiten
Meetings

Undercover Agile für Versicherer: 5 agile Praktiken für Ihr klassisches IT-Projekt

Versicherung
Change
Digitale Transformation
Agile Prinzipien
Kundenfokus

IT-Projekte in der Versicherungsbranche – Das Rennen um die Time-to-Market

Team
Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills

Umgang mit Fehlern & Diversität – Erfolgreiche agile Teams #2

Team
Neues Arbeiten
Agile Toolbox
Produktentwicklung

Das Geheimrezept von High-Performance-Teams

Team
Arbeiten bei borisgloger consulting
Agile Prinzipien
Freiwilligkeit
Selbstorganisation

Konsent und offene Wahl: 2 Prinzipien aus der Soziokratie, die jedes agile Team gebrauchen kann

Team
Neues Arbeiten
Meetings
Social Skills

Der agile Adventkalender

Team
Agile Toolbox
Scrum
ScrumMaster-Praxistipps
Agile Prinzipien

Selbstorganisation der Teams fördern: Ask the team!

Team
Agile Toolbox
Design Thinking

Who Recognizes the Truly Good Ideas?

Team
Agile Organization
Transformation

Pizza Is Not Dead, and Neither Is Agility

Scrum4Schools
Neues Arbeiten
Führung
Life
Social Skills

Trauen wir unseren Kindern mehr zu – auch in der Schule!

Scrum4Schools
Change
Agiles Lernen
Neues Arbeiten
Remote Arbeiten

Eine Scrum4Schools-Projekt-Rückschau mit Physiklehrer Ivan Topic

Scrum4Schools
Mehr Formate
Interview
Nachhaltigkeit

Mit Scrum4Schools dem Weltraum auf der Spur

Scrum4Schools
Change
Agiles Lernen

Scrum4Schools - ein Projekt nimmt Fahrt auf

Scrum4Schools
Agile Schulentwicklung
Agile Toolbox

Technik im Alltag - Scrum4Schools zu Gast in Langenzersdorf

Projektmanagement
Agile Toolbox
Scrum
Scrum-Begriffe
ScrumMaster-Praxistipps

Sprechen Sie Agile? Den klassischen Projektplan in die agile Welt überführen

Projektmanagement
Agiles Management
Agile Toolbox
Scrum
Enterprise Scrum

Das Management in Scrum

Projektmanagement
Change
Digitale Transformation

Agilität in der Logistik oder: Liefern wie Amazon

Projektmanagement
Agile Toolbox
Scrum

Meilensteine und Scrum

Portfoliomanagement
Project management

Too many projects? Portfolio management simplified

Neues Arbeiten
Mehr Formate
Agile Toolbox
Scrum
Scrum Values

Wie agiles Arbeiten die Kommunikation aus der Selbstverständlichkeit holt

Neues Arbeiten
Change
Agiles Lernen
Mehr Formate
Audio

New Learning heute für das New Work von morgen – mit Angelika Weis

Neues Arbeiten
Change
Soziale Innovation

New Work Experience 2019 – ein Erfahrungsbericht

Neues Arbeiten
Audit
Change

Agil im Audit: das Starter-Kit

Neues Arbeiten
Agile Toolbox
Scrum
Scrum4Schools
Agile Prinzipien

Scrum4Schools: Lernen für die Zukunft

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Meetings
Retrospektive

Arbeiten wir uns gesund!

Neues Arbeiten
Agile Toolbox
Scrum
ScrumMaster-Praxistipps

Who should be in (agile) HR?

Neues Arbeiten
Agile Toolbox
Scrum
Scrum Values

Glauben Sie an die Seele Ihrer Firma?

Neues Arbeiten
Agile Toolbox
Scrum
Product Owner
ScrumMaster-Praxistipps

Produktivität auf Irrwegen: "Führen wir schnell mal Scrum ein!"

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freiwilliges Teilen von Wissen – Erfolgreiche agile Teams #5

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Doing vs. Being Agile – Erfolgreiche agile Teams #1

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Freude bei der Arbeit & Sustainable Pace – Erfolgreiche agile Teams #3

Neues Arbeiten
Agile Prinzipien
Selbstorganisation
Social Skills
Team

Anpassungsfähigkeit & schonungslose Offenheit – Erfolgreiche agile Teams #4