Teil 1: Von der Revolution zur Routine – eine ehrliche Bestandsaufnahme
Einleitung: Ein Framework feiert Geburtstag – und kämpft ums Überleben
Vor 30 Jahren, im Oktober 1995, präsentierten Ken Schwaber und Jeff Sutherland auf der OOPSLA-Konferenz (Object-Oriented Programming, Systems, Languages & Applications) in Austin, Texas, erstmals offiziell das Scrum-Framework. Was als Alternative zu schwergewichtigen Wasserfall-Prozessen begann, sollte die Softwareentwicklung und später die gesamte Arbeitswelt fundamental verändern.
Drei Jahrzehnte später ist Scrum überall: Von Start-ups in Berlin bis zu Konzernen in Frankfurt, von Softwareteams bis zu Marketing-Abteilungen, von IT-Projekten bis zu Produktentwicklung in der Industrie.
Doch gleichzeitig mehren sich kritische Stimmen: „Scrum funktioniert nicht“, „Scrum ist tot“, „Wir machen jetzt was Moderneres“.
Zeit für eine ehrliche Bestandsaufnahme.
Meine persönliche Scrum-Reise: Vom Skeptiker zum Überzeugten
Vor 15 Jahren bin ich zum ersten Mal mit agiler Arbeit in Berührung gekommen. Damals in einem Unternehmen für medizinische Reinigungsgeräte. Marktführer in ihrem Segment. Etablierte Prozesse. Jahrzehntelange Erfahrung.
Der Kanban-Start
Wir begannen mit Kanban. Warum? Weil es weniger bedrohlich wirkte. Keine Rollen, die bestehende Hierarchien in Frage stellten. Keine Sprints, die Druck erzeugten. Nur ein Board, das Arbeit sichtbar machte.
Es war der richtige erste Schritt für eine Organisation, die Veränderung brauchte, aber Angst davor hatte.
Mit der Zeit entwickelten wir uns weiter – zu Scrumban, einer Hybrid-Form, die Elemente beider Frameworks kombinierte. Sprint-Plannings mit Kanban-Flow. Retrospektiven mit WIP-Limits. Es funktionierte für unseren Kontext.
Die Infektion: Scrum im Startup
Zwei Jahre später wechselte ich zu einem Startup. Junges Team, hohes Tempo, ständige Veränderung. Wir wollten „richtig“ agil werden. Wir wollten Scrum.
Wir holten uns einen erfahrenen Coach. Jemanden, der Scrum nicht nur kannte, sondern lebte. Der nicht die Prozesse predigte, sondern die Prinzipien.
Und ich war infiziert.
Ich sah, wie Scrum Teams transformierte. Wie aus einer Gruppe von Individuen ein echtes Team wurde. Wie Probleme sichtbar wurden und gelöst. Wie Feedback-Schleifen Produkte besser machten.
Ich wurde Scrum Master. Später Agile Coach. Und arbeite seitdem mit Teams, die agiler werden wollen.
15 Jahre später: Erfahrener – und kritischer
Heute, 15 Jahre nach meinem ersten Kontakt mit agilen Methoden, bin ich überzeugter denn je von den Prinzipien agiler Arbeit.
Aber ich bin auch kritischer geworden gegenüber der Umsetzung.
Ich habe zu viele Teams gesehen, die Scrum-Theater spielen. Zu viele Organisationen, die „agil“ sagen, aber „Command-and-Control“ meinen. Zu viele Zertifikate ohne echtes Verständnis.
Und genau deshalb ist diese Serie nötig.
Die Wurzeln: Wo kommt Scrum eigentlich her?
The New New Product Development Game (1986)
Die Geschichte von Scrum beginnt nicht 1995, sondern bereits 1986, als Hirotaka Takeuchi und Ikujiro Nonaka ihren bahnbrechenden Artikel „The New New Product Development Game“ im Harvard Business Review veröffentlichten.
Die zentrale Beobachtung:
Die erfolgreichsten Produktentwicklungsteams bei Unternehmen wie Honda, Canon und Fuji-Xerox arbeiteten nicht in sequenziellen Phasen (wie ein Staffellauf), sondern in überlappenden, selbstorganisierten Teams (wie ein Rugby-Scrum).
Die sechs Charakteristika erfolgreicher Teams:
- Built-in Instability: Herausfordernde Ziele, die kreative Lösungen erfordern
- Self-Organizing Project Teams: Teams mit Autonomie über Prozess und Umsetzung
- Overlapping Development Phases: Keine strikten Gates, sondern fließende Übergänge
- Multi-Learning: Lernen auf allen Ebenen (individuell, Team, Organisation)
- Subtle Control: Leichte Führung statt Micromanagement
- Organizational Transfer of Learning: Wissen fließt zwischen Projekten
Der Begriff „Scrum“ war geboren, als Metapher für ein Team, das gemeinsam auf ein Ziel zuarbeitet.
Die frühen Pioniere: Easel Corporation (1993)
Ken Schwaber experimentierte bereits Anfang der 1990er Jahre bei der Easel Corporation mit iterativen Entwicklungsprozessen. Er suchte nach einem Weg, komplexe Softwareentwicklung besser zu steuern – oder vielmehr: beherrschbar zu machen.
Die Erkenntnis: Software-Entwicklung ist kein definierter Prozess (wie Autobau), sondern ein empirischer Prozess (wie Forschung). Man kann nicht alles vorausplanen. Man muss beobachten, anpassen, lernen.
Gleichzeitig arbeitete Jeff Sutherland bei der Easel Corporation an ähnlichen Ideen. Er kombinierte Erkenntnisse aus:
- Lean Manufacturing (Toyota)
- Komplexitätstheorie
- Empirischer Prozesskontrolle
- Dem „New New Product Development Game“-Artikel
OOPSLA 1995: Die offizielle Geburtsstunde
Am 16. Oktober 1995 präsentierten Ken Schwaber und Jeff Sutherland gemeinsam auf der OOPSLA-Konferenz das Paper „SCRUM Development Process“.
Was war neu?
Nicht einzelne Elemente – die gab es teilweise schon. Sondern:
- Die systematische Kombination bewährter Praktiken
- Die klare Benennung von Rollen, Events und Artefakten
- Der Fokus auf empirische Prozesskontrolle
- Die Betonung von Selbstorganisation
Das Framework war radikal einfach – und genau das war die Stärke.
Die Evolution: Vom Chaos zur Struktur
Die ersten Jahre waren experimentell. Verschiedene Teams implementierten Scrum unterschiedlich. Es gab keine „offizielle“ Version.
2001: Das Agile Manifest
Ken Schwaber und Jeff Sutherland waren Mitunterzeichner des Agile Manifests in Snowbird, Utah. Scrum wurde Teil einer größeren Bewegung.
2010: Der Scrum Guide
Ken Schwaber und Jeff Sutherland veröffentlichten den ersten offiziellen Scrum Guide – eine „definitive Definition“ von Scrum.
Seitdem wurde der Guide mehrfach überarbeitet:
- 2011, 2013, 2016, 2017, 2020: Kontinuierliche Anpassungen
- 2020: Größte Überarbeitung – Verschlankung, Fokus auf „Product Goal“
Die Ironie: Ein Framework über Anpassung hat sich selbst kontinuierlich angepasst.
Was Scrum erreicht hat: Die vier großen Errungenschaften
1. Transparenz wurde vom Luxus zum Standard
Vor Scrum: Projekte liefen im Verborgenen. Niemand wusste wirklich, woran andere Teams arbeiteten. Probleme wurden versteckt, bis sie nicht mehr zu ignorieren waren.
„Geht gut voran“ war die Standardantwort – bis drei Wochen vor Deadline klar wurde: Es geht nicht gut voran.
Durch Scrum:
- Sprint Backlog ist öffentlich
- Velocity ist messbar
- Probleme werden im Sprint Review sichtbar
- Impediments werden im Daily besprochen
- Das Burn-Down Chart zeigt den echten Fortschritt
Die Revolution: Scrum machte Unsichtbares sichtbar – ob man wollte oder nicht.
Ja, Transparenz wird manchmal missbraucht – für Micromanagement, für Kontrolle, für Druck. Aber die Alternative – Intransparenz – ist schlimmer. Unsichtbare Probleme kann man nicht lösen.
Heute selbstverständlich, damals radikal: Die Idee, dass jeder jederzeit sehen kann, woran gearbeitet wird und wo Probleme sind.
2. Empirisches Arbeiten wurde zum Standard
Vor Scrum: Software-Entwicklung war ein Glaubensakt:
- Man plante alles im Voraus
- Man schätzte, was wann fertig sein würde
- Man hoffte, dass die Realität den Plan einholt
- Am Ende kam, was kam – meist zu spät, zu teuer, am Bedarf vorbei
Das Wasserfall-Paradigm: „Wir können die Zukunft vorhersagen, wenn wir nur genug planen.“
Scrum sagte: Bullshit. Software-Entwicklung ist komplex, nicht kompliziert.
Der Unterschied:
- Kompliziert: Viele Teile, aber vorhersagbar (z.B. eine Uhr bauen)
- Komplex: Viele Interaktionen, nicht vorhersagbar (z.B. Software entwickeln)
Die Scrum-Antwort: Empirische Prozesskontrolle
Basierend auf drei Säulen:
- Transparenz: Mach alles sichtbar
- Inspektion: Schau regelmäßig hin
- Anpassung: Ändere basierend auf dem, was du siehst
In der Praxis:
- Sprint-Zyklen: Alle 1-4 Wochen ein Review – funktioniert es?
- Retrospektiven: Was läuft gut, was nicht?
- Product Backlog Refinement: Passen die nächsten Items noch?
Heute Standard: A/B-Tests, kontinuierliche Deployments, datengetriebene Entscheidungen – all das basiert auf empirischem Arbeiten.
Scrum hat den Boden bereitet.
3. Selbstorganisation wurde legitim
Vor Scrum: Der Projektmanager sagte, wer was macht. Der Architekt entschied über Technologie. Der Business Analyst definierte Requirements.
Das Team setzte um.
Scrum fragte: Warum?
Warum trauen wir den Menschen, die die Arbeit machen, nicht zu, selbst zu entscheiden?
Die radikale Idee:
- Teams entscheiden selbst, WIE sie arbeiten
- Teams committen sich selbst zu Sprint-Zielen
- Teams organisieren ihre eigene Arbeit
- Niemand sagt einem Entwickler, an welchem Task er arbeiten soll
Das war – und ist – ein Vertrauensvorschuss.
Die Realität heute:
Nicht jedes Team ist bereit für Selbstorganisation. Nicht jedes Management lässt sie zu. Nicht jede Organisation hat die Kultur dafür.
Aber dass wir heute überhaupt darüber reden, dass Teams selbst entscheiden können und sollten?
Das verdanken wir Scrum.
4. Fail Fast ist besser als Late Fail
Das alte Paradigma:
- Monate, oft Jahre in Planung und Entwicklung investieren
- Alles auf einmal ausliefern
- Dann hoffen, dass es funktioniert
- Wenn nicht: Desaster
Das Scrum-Paradigma:
Ja? Großartig, was als nächstes?
Zwei-Wochen-Sprint (oder 1-4 Wochen)
Am Ende: Funktioniert es? Liefert es Wert?
Nein? Okay, ändern wir es im nächsten Sprint
Die Mathematik des frühen Scheiterns:
Traditionell:
- 12 Monate Entwicklung
- Am Ende: Funktioniert nicht
- Verlust: 12 Monate
Mit Scrum (2-Wochen-Sprints):
- Nach 2 Wochen: Funktioniert nicht
- Verlust: 2 Wochen
- Verbleibende Zeit für Anpassung: ~50 Sprints
Die Formel: Lieber 26x kleine Fehler machen (und korrigieren) als 1x einen großen Fehler machen (den man nicht mehr korrigieren kann).
Heute nennen wir es:
- Iteratives Lernen
- Kontinuierliche Verbesserung
- Build-Measure-Learn
- Lean Startup
Die Wurzel ist dieselbe: Scrum.
Wo Scrum heute steht: Zwischen Erfolg und Krise
Die Erfolgsgeschichte in Zahlen
Scrum ist das am weitesten verbreitete agile Framework:
Verbreitung (Stand 2024):
- 66% aller agilen Teams nutzen Scrum oder Scrum-Varianten (State of Agile Report 2024)
- Über 2 Millionen zertifizierte Scrum-Praktiker weltweit
- Fortune 500-Unternehmen: 87% haben agile Methoden implementiert (meist Scrum-basiert)
Geografische Verbreitung:
- Nordamerika: 72% Adoption in IT-Organisationen
- Europa: 65% Adoption
- Asien-Pazifik: 58% und steigend
Branchen:
- Software/IT: 78% Adoption
- Financial Services: 54%
- Healthcare: 41%
- Manufacturing: 38%
- Marketing/Kreative Branchen: 32%
Aber: Die Krise unter der Oberfläche
Die paradoxe Situation: Scrum ist beliebter denn je – und gleichzeitig unter mehr Druck als je zuvor.
Kritische Stimmen:
„Scrum funktioniert nicht in unserem Kontext.“ „Scrum ist zu starr.“ „Scrum erzeugt nur Overhead.“ „Wir machen jetzt was Moderneres.“
Und oft haben sie Recht – aber aus den falschen Gründen.
1. Scrum-Theater statt echter Agilität
Die Symptome:
- Teams machen Daily Standups – als Status-Reports für Manager
- Sprint Reviews finden statt – aber ohne echte Stakeholder
- Retrospektiven werden abgehalten – aber nichts wird umgesetzt
- Product Backlog existiert – aber ohne echtes Product Goal
Das Ergebnis: Rituale ohne Bedeutung. Form ohne Substanz.
Der Grund: Organisationen wollen die Vorteile von Agilität, aber nicht die Veränderung, die dafür nötig ist.
2. Zertifizierungs-Inflation
Die Realität:
- 2-Tages-Kurs
- Multiple-Choice-Test
- Zertifikat
- „Certified Scrum Master“
Das Problem:
- Null Erfahrung in echter Scrum-Praxis erforderlich
- Kein Nachweis von Coaching-Fähigkeiten
- Keine Prüfung von Change-Management-Kompetenz
- Keine Validierung von Organisationsverständnis
Das Ergebnis: „Scrum Master“ ohne echtes Verständnis für Scrum als Veränderungsprozess.
3. „One Size Fits All“-Mentalität
Der Irrglaube: Scrum funktioniert überall.
Die Realität: Scrum braucht spezifische Voraussetzungen:
- Komplexe Problemstellung (nicht nur kompliziert)
- Möglichkeit zu iterativem Arbeiten
- Stakeholder, die Feedback geben können
- Organisation, die Selbstorganisation zulässt
Wo Scrum oft scheitert:
- Sehr kleine Teams (2-3 Personen) – zu viel Overhead
- Hochregulierte Umgebungen – zu wenig Flexibilität
- Hierarchische Organisationen ohne Veränderungswillen – kultureller Mismatch
- Projekte mit fixen Requirements – kein Raum für Empirie
Die Konsequenz: Scrum wird implementiert, wo es nicht passt – und scheitert vorhersehbar.
4. Buzzword-Verwässerung
Die Inflation:
„Wir sind agil“ ist das neue „Wir sind innovativ“ – eine leere Phrase in Stellenanzeigen und Marketing-Material.
Was Unternehmen oft meinen:
- „Unsere Wasserfall-Phasen heißen jetzt Sprints“
- „Wir haben jetzt auch Daily Standups“
- „Die Entwickler müssen flexibler sein, wenn wir die Requirements ändern“
Was echtes Scrum bedeuten würde:
- Fundamentale Veränderung von Entscheidungsstrukturen
- Akzeptanz von Unsicherheit
- Fokus auf Outcomes statt Output
- Management als Enabler statt Controller
Die Lücke zwischen Anspruch und Realität ist gigantisch.
Was jetzt nötig ist: Ehrlichkeit statt Marketing
Nach 30 Jahren Scrum brauchen wir keine weiteren „Agile Transformation Programme“ für Millionenbudgets.
Wir brauchen Ehrlichkeit.
1. Ehrlichkeit über Anwendungsbereiche
Scrum ist kein Allheilmittel.
Es funktioniert hervorragend in bestimmten Kontexten:
- Komplexe Produktentwicklung
- Hohe Unsicherheit
- Möglichkeit für kurze Feedbackzyklen
- Team von 3-9 Personen
Es funktioniert weniger gut in anderen:
- Sehr kleine oder sehr große Teams
- Klar definierte, stabile Requirements
- Hochregulierte Umgebungen ohne Spielraum
- Organisationen ohne kulturelle Basis
Das zu sagen ist keine Schwäche von Scrum – sondern ehrliche Einordnung.
2. Ehrlichkeit über Voraussetzungen
Scrum funktioniert nicht „out of the box“. Es braucht:
Organisationale Voraussetzungen:
- Management, das Selbstorganisation zulässt
- Strukturen, die schnelle Entscheidungen ermöglichen
- Kultur, die Transparenz aushält
- Bereitschaft, aus Fehlern zu lernen
Team-Voraussetzungen:
- Cross-funktionale Skills
- Commitment zu gemeinsamen Zielen
- Bereitschaft zu kontinuierlicher Verbesserung
- Psychologische Sicherheit
Product Owner-Voraussetzungen:
- Echte Entscheidungsbefugnis
- Verfügbarkeit für das Team
- Produktvision und Business-Verständnis
- Mut, „Nein“ zu sagen
Wenn diese nicht gegeben sind: Sag es ehrlich. Und arbeite daran. Oder nutze etwas anderes.
3. Ehrlichkeit über Grenzen von Zertifizierungen
Ein 2-Tages-Kurs macht niemanden zum Master.
Punkt.
Was Zertifizierungen leisten können:
- Grundverständnis von Scrum vermitteln
- Gemeinsame Sprache etablieren
- Interesse wecken
Was sie nicht können:
- Erfahrung ersetzen
- Coaching-Fähigkeiten vermitteln
- Organisationsverständnis aufbauen
- Change-Management lehren
Was nötig wäre:
- Praktische Erfahrung als Voraussetzung
- Coaching-Kompetenz als Teil der Ausbildung
- Kontinuierliche Weiterbildung statt „One and Done“
- Rezertifizierung mit Nachweis echter Praxis
4. Ehrlichkeit über Scrum-Theater
Wenn ihr nur die Rituale macht, aber nichts sich ändert:
Ihr macht kein Scrum. Ihr spielt Theater.
Und das ist okay – solange ihr es zugebt.
Sagt nicht „Scrum funktioniert nicht“, wenn ihr nie echtes Scrum gemacht habt.
Die ehrliche Frage:
- Haben eure Teams echte Selbstorganisation?
- Hat euer Product Owner echte Entscheidungsbefugnis?
- Ist Transparenz eine gelebte Realität oder ein Lippenbekenntnis?
- Werden Retrospektiven-Ergebnisse umgesetzt?
- Gibt es echtes Stakeholder-Feedback?
Wenn die Antwort auf die meisten Fragen „Nein“ ist: Ihr macht kein Scrum.
Und das ist das eigentliche Problem.
Ausblick: Die nächsten 30 Jahre
Wird Scrum überleben?
Ja – wenn wir aufhören, es als Checkliste zu behandeln.
Scrum ist kein Prozess, den man ausrollt.
Scrum ist ein Rahmenwerk, das:
- Transparenz erzwingt
- Anpassung ermöglicht
- Lernen fördert
Die Zukunft von Scrum liegt nicht in:
- Mehr Zertifizierungen
- Komplexeren Frameworks (SAFe, LeSS, etc.)
- Neuen Tools und Software
Die Zukunft von Scrum liegt in:
- Tieferem Verständnis der Prinzipien
- Ehrlicher Anwendung im richtigen Kontext
- Mut zur Anpassung (auch von Scrum selbst)
- Fokus auf Outcomes statt Prozess-Compliance
Fazit: 30 Jahre Scrum – Zeit für ehrliche Reflexion
Scrum hat die Arbeitswelt verändert. Keine Frage.
Es hat Transparenz normalisiert. Empirisches Arbeiten etabliert. Selbstorganisation legitimiert. Fail Fast zum Standard gemacht.
Aber Scrum steht heute an einem Scheideweg.
Entweder wir behandeln es weiter als Marketing-Label und Checkliste – dann wird es tatsächlich sterben.
Oder wir besinnen uns auf das, was Scrum wirklich ist: Ein Framework für empirisches Arbeiten in komplexen Umgebungen.
Die Entscheidung liegt bei uns:
- Bei den Praktikern, die Scrum leben
- Bei den Coaches, die Scrum lehren
- Bei den Organisationen, die Scrum einführen wollen
- Bei der Community, die Scrum weiterentwickelt
30 Jahre sind eine beeindruckende Erfolgsgeschichte.
Die nächsten 30 Jahre werden zeigen, ob wir aus dieser Geschichte gelernt haben.
Wie es weitergeht: Die nächsten Teile dieser Serie
In den kommenden Artikeln dieser Serie werde ich tiefer eintauchen:
Teil 2: Was wir Scrum wirklich verdanken – Die vier Errungenschaften, die heute selbstverständlich sind (erscheint demnächst)
Teil 3: Warum so viele sagen „Scrum ist tot“ – Die unbequeme Wahrheit über Scrum-Theater und gescheiterte Implementierungen (erscheint demnächst)
Teil 4: Was sich ändern muss – Konkrete Schritte für besseres Scrum (erscheint demnächst)
Deine Meinung: Was sind deine Erfahrungen mit Scrum? Funktioniert es in deinem Kontext? Oder ist es Zeit für etwas Neues?
Lass es mich in den Kommentaren wissen!
Dieser Artikel ist Teil der Serie „30 Jahre Scrum“ anlässlich des 30. Jubiläums der ersten Präsentation des Scrum-Frameworks auf der OOPSLA-Konferenz am 16. Oktober 1995.
Schreibe einen Kommentar