Was ist "SCRUM"?

SCRUM ist ein agiles Framework für das Projektmanagement, das ursprünglich aus der Softwareentwicklung stammt und zunehmend auch in Lean-orientierten Unternehmen Anwendung findet. Die Ursprünge basieren auf dem 1986 erschienenen Artikel von Hirotaka Takeuchi und Ikujiro Nonaka. Weiterentwickelt wurde die Idee von Jeff Sutherland, der erstmals die Rollen der einzelnen Projektmitglieder neu beschrieb. Seitdem wurde SCRUM stark in der IT-Branche vorangetrieben und findet seit einiger Zeit immer mehr Anklang in Bereichen klassischen Projektmanagements (vgl. Wenz 2014, S. 6–17).

Kernidee: Im Gegensatz zum klassischen Projektmanagement gibt man sich bei SCRUM nicht der Illusion hin, von Anfang an den genauen Weg zu kennen, der am Ende zum Projektziel führt. Änderungen in den Anforderungen sind kein ungeliebter Bestandteil, sondern ein erwarteter und einkalkulierter Teil des Prozesses (vgl. Wenz 2014, S. 6–17).

Die drei Rollen im SCRUM-Team

Bei SCRUM gibt es drei klar definierte Rollen, die zusammen das SCRUM-Team bilden (vgl. Wenz 2014, S. 6–17):

• Product Owner: Der Product Owner ist die Schnittstelle zwischen den Stakeholdern und dem SCRUM-Team. Er verantwortet den Erfolg des Projektes und vermittelt dem Team die Projektvision. Er generiert die zu entwickelnden Produkteigenschaften und entscheidet über deren Priorisierung. Um sich nicht von der Produktvision zu entfernen, hält er regelmäßig Rücksprache mit den Stakeholdern.
• SCRUM-Master: Der SCRUM-Master nimmt die Rolle einer dienenden Führungskraft (Servant Leader) ein. Er fungiert als Coach für die Mitglieder des SCRUM-Teams, schirmt sie von internen und externen Ablenkungen ab und ist dafür verantwortlich, dass SCRUM richtig verstanden und eingesetzt wird (vgl. Wenz 2014, S. 6–17).
• Entwicklungsteam: Das interdisziplinäre Team ist für die Lieferung der einzelnen Produkteigenschaften in der vom Product Owner gewünschten Reihenfolge verantwortlich. Dabei steuern und managen sich die Teammitglieder selbst. Üblicherweise besteht ein Entwicklungsteam aus drei bis sieben Personen.

Die Rolle des SCRUM-Masters im Detail

Innerhalb des SCRUM-Frameworks nimmt der SCRUM-Master verschiedene Rollen ein, die zum Teil starke Parallelen zum Kobetsu Kaizen (1. Säule des TPM-Hauses)-Coach aufweisen (vgl. Wenz 2015, S. 20–22):

• Agiler Coach: Der SCRUM-Master coacht gleichermaßen das Entwicklungsteam und den Product Owner. Er überwacht die Einhaltung der SCRUM-Regeln und unterstützt bei der Lösung von Problemen, ohne diese selbst zu lösen, analog zum Coaching-Ansatz, den Coachee zur eigenen Lösung zu befähigen.
• Dienende Führungskraft: In den täglichen Daily Standup Meetings werden neben den Standardfragen auch Themen angesprochen, bei denen das Team die Unterstützung seiner Führungskraft braucht. Im Gegensatz zum traditionellen Führungsverständnis steuert sich das Entwicklungsteam zum größten Teil selbst.
• Hindernisbeseitiger: Der SCRUM-Master fungiert als Eskalationspartei gegenüber dem Product Owner oder den Stakeholdern, soweit Probleme nicht eigenständig durch das Entwicklungsteam gelöst werden können (vgl. Wenz 2015, S. 20–22).
• Prozesseigner: Er ist für die Einhaltung der SCRUM-Regeln und Prinzipien verantwortlich und sorgt dafür, dass das SCRUM-Team die Werte verinnerlicht.
• Schutzschild: Er hält das Entwicklungsteam frei von kurzfristigen Anfragen und Störungen von außen, damit das Team seine Energie vollständig in das Projekt stecken kann. Ohne diesen Schutz können Arbeitskapazitäten von etwa 1,5 Tagen pro Woche verloren gehen (vgl. Wenz 2015, S. 20–22).

Aufgrund der Vielschichtigkeit ist ein besonderes Skillset für die Rolle des SCRUM-Masters notwendig: tiefes theoretisches Fachwissen, eine kritische Prozesssicht zum Hinterfragen von Annahmen sowie die Fähigkeit, das Team zu alternativen Lösungen zu führen. Gerade diese letzte Rolle kommt einem Kobetsu Kaizen (1. Säule des TPM-Hauses)-Coach sehr nahe (vgl. Wenz 2015, S. 20–22).

Der SCRUM-Prozess: Ablauf eines Sprints

Ein SCRUM-Projekt folgt einem klar strukturierten, iterativen Ablauf (vgl. Wenz 2014, S. 6–17):

• Produktvision und Product Backlog: Am Anfang eines SCRUM-Projektes entwickelt der Product Owner zusammen mit den Stakeholdern eine Produktvision. Diese wird in kleinere, selbständig entwickelbare Teile geschnitten und im Product Backlog priorisiert.
• Sprint Planung 1: Zusammen mit dem SCRUM-Team wird ein Sprintziel festgelegt und aus dem Product Backlog diejenigen Teile definiert, die am Ende des Sprints abgeliefert werden sollen.
• Sprint Planung 2: Das Entwicklungsteam legt fest, wie das Ziel umgesetzt werden soll. Dies geschieht in Form einzelner To Dos, die jeweils nicht mehr als einen Personentag benötigen sollten.
• Sprint-Durchführung: Der eigentliche Sprint dauert je nach Team ein bis vier Wochen. Während des Sprints werden die geplanten Aufgaben abgearbeitet. Die Sprintdauer ist nicht variabel, sondern immer gleich, um aus gemachten Erfahrungen lernen zu können.
• Daily SCRUM: Täglich findet ein zehnminütiges Treffen statt, bei dem die einzelnen Mitglieder über ihre Tätigkeiten berichten und Hindernisse ansprechen. Es dient dem Austausch des Teams und nicht dem Reporting an den SCRUM-Master.
• Sprint Review: Nach Ablauf des Sprints wird der fertige Projektteil an den Product Owner übergeben, der beurteilt, ob das Produkt seinen Erwartungen entspricht.
• Retrospektive: Im Retrospektive Meeting wird gemeinsam reflektiert, was gut war und was im letzten Sprint hätte besser laufen können. Danach beginnt der Zyklus von vorne.

Wertschöpfung durch SCRUM

Agiles Projektmanagement nach SCRUM bietet gegenüber klassischen Methoden mehrere Vorteile hinsichtlich der Wertschöpfung (vgl. Wenz 2015, S. 24–26):

Frühe Marktreife und Continuous Delivery

Bei klassischem Projektmanagement werden Ergebnisse erst am Ende des Projektes geliefert. Bei SCRUM erhalten die Stakeholder bereits am Ende eines jeden Sprints ein getestetes und lauffähiges Produktinkrement. Diese als Continuous Delivery bezeichnete Methode eröffnet die Möglichkeit, dass der Kunde bereits zum Ende eines Sprints den umgesetzten Teil nutzen kann. In der Umsetzung kleiner lauffähiger Inkremente liegt eine höchstmögliche Wertschöpfung zum frühestmöglichen Zeitpunkt (vgl. Wenz 2015, S. 24–26).

Agilität: Änderungen als Erwartungshaltung

Bei SCRUM sind Änderungen in den Spezifikationen nicht nur akzeptiert, sondern als erwarteter Bestandteil eingeplant. Der Product Owner priorisiert permanent das Product Backlog, sodass einmal getroffene Annahmen und Reihenfolgen jederzeit angepasst werden können. Auch neue Anforderungen der Stakeholder können leicht berücksichtigt werden. Die einzige zeitliche Konstante bildet der Sprint selbst, während eines Sprints ist das Team vor neuen Anforderungen geschützt (vgl. Wenz 2015, S. 24–26).

Das Pareto-Prinzip in SCRUM-Projekten

SCRUM stellt das klassische Projektdreieck aus Zeit, Budget und Anforderungen auf den Kopf. Die Einhaltung von Zeit und Budget wird in den Vordergrund gestellt. Da kurzzyklisch und regelmäßig eine Priorisierung des nächsten Inkrements vorgenommen wird, sind bereits ungefähr zur Projekthälfte mehr als 80 Prozent der Funktionalität umgesetzt. Nicht selten werden Projekte deshalb mit 80 Prozent Funktionalität beendet, weil der Mehraufwand für die letzten 20 Prozent in keinem Kosten-Nutzen-Verhältnis steht (vgl. Wenz 2015, S. 24–26).

SCRUM in der Lean-Praxis

Die Einführung von SCRUM in Lean-orientierten Unternehmen verläuft ähnlich wie die Einführung von Lean selbst, was zugleich eine gute und eine schlechte Nachricht ist. Die Erfahrung zeigt, dass nach anfänglicher Euphorie alte Gewohnheiten zurückkehren können (vgl. Wenz 2015, S. 18–20).

Typische Herausforderungen bei der Einführung von SCRUM umfassen: Das tägliche SCRUM Meeting wandelt sich von einem kurzen Informationsaustausch zu ausufernden Diskussionen. Der Projektleiter nimmt wieder seine klassische Rolle ein und lässt sich den Status berichten, statt als dienende Führungskraft zu agieren. Die Zuweisung von Aufgaben durch den Projektleiter schränkt den Freiraum des Teams ein, der für den Erfolg von SCRUM essenziell ist (vgl. Wenz 2015, S. 18–20).

SCRUM lebt davon, dass die Mitglieder des Entwicklungsteams in einem Freiraum miteinander agieren können, ohne Einwirkungen von außen. Sie sind die Spezialisten, die am besten wissen, wo sie besonders effizient und effektiv eingesetzt werden können (vgl. Wenz 2015, S. 18–20).

Agile Transformation: SCRUM nachhaltig verankern

Die erfolgreiche Verankerung von SCRUM im Unternehmen erfordert mehr als die Einführung einzelner Methoden. Die Erfahrung zeigt, dass der größte Widerstand nicht bei den Werkzeugen liegt, sondern beim Mindset der Menschen. Vielen fehlt der Wille und der Mut, Neues auszuprobieren, und ohne Unterstützung der Führungsebene scheitern Initiativen häufig (vgl. Lindner 2021, S. 24–25).

Ein wichtiger Erfolgsfaktor ist die Erkenntnis, dass SCRUM als Ganzes funktioniert, nicht in Einzelteilen. Unternehmen, die sagen, sie würden nach SCRUM arbeiten, es aber tatsächlich nicht tun, erleben keine Fortschritte. Erst das konsequente Anwenden aller Prinzipien und Werte des SCRUM-Frameworks führt zum Erfolg. Dabei hilft der Austausch mit erfahrenen Praktikern und die kontinuierliche Weiterbildung (vgl. Lindner 2021, S. 24–25).

Praxiserkenntnis: Die Einführung von SCRUM führt anfangs häufig zu einer deutlich erhöhten Projektgeschwindigkeit. Dann wird der Punkt erreicht, an dem zuarbeitende Organisationsteile wie IT oder Rechtsabteilung der Geschwindigkeit nicht mehr folgen können. Ziel von SCRUM ist nicht das Verkürzen der Projektdauer, sondern die Verbesserung der Qualität, dennoch wird durch den Freiraum des Entwicklungsteams meist eine Verkürzung erreicht (vgl. Wenz 2015, S. 18–20).

SCRUM und Lean: Gemeinsame Prinzipien

SCRUM und Lean teilen fundamentale Prinzipien. Beide Ansätze setzen auf iteratives Vorgehen, kontinuierliche Verbesserung und die Einbeziehung aller Beteiligten. SCRUM integriert verstärkt KATA, Instandhaltungsstrategie und Ansätze aus dem Kobetsu Kaizen (1. Säule des TPM-Hauses)-Coaching. Der Monozukuri-Gedanke nach Takahiro Fujimoto versteht ein Endprodukt als die Summe aller Informationen und Tätigkeiten. Da jeder schlechte Prozess ein Makel am Endprodukt ist, führen Projekte, die Prozesse verbessern, unmittelbar zu einer Verbesserung des Endproduktes (vgl. Wenz 2015, S. 24–26).

Aus Lean-Sicht bietet SCRUM den Vorteil, das Projektrisiko zu minimieren. Die größten Risiken bei Projekten betreffen die Bereiche Planung, Kommunikation und Qualität. Bei SCRUM ist der Planungsaspekt überschaubar: Es werden nur übergeordnete Themen priorisiert, und lediglich der aktuelle Sprint wird detailliert ausgeplant. Durch frühes und stetiges Kundenfeedback werden Disparitäten zwischen Projektziel und umgesetzten Teilen schnell offensichtlich (vgl. Wenz 2015, S. 24–26).

SCRUM-Artefakte und Ereignisse

Das SCRUM-Framework definiert mehrere zentrale Artefakte und Ereignisse, die den strukturierten Ablauf sicherstellen:

• Product Backlog: Eine priorisierte Liste aller gewünschten Produkteigenschaften und Anforderungen. Der Product Owner pflegt und priorisiert diese Liste permanent.
• Sprint Backlog: Die für den aktuellen Sprint ausgewählten Aufgaben aus dem Product Backlog, aufgeteilt in handhabbare Arbeitspakete.
• Produktinkrement: Das am Ende eines Sprints gelieferte, getestete und lauffähige Ergebnis, das gegenüber der Vorversion um die priorisierten Anforderungen erweitert wurde.
• Sprint Planning: Meeting zu Beginn eines Sprints, in dem Sprintziel und Sprint Backlog festgelegt werden.
• Daily SCRUM: Tägliches, zehnminütiges Treffen zur Synchronisation des Teams.
• Sprint Review: Vorstellung des Produktinkrements vor dem Product Owner und den Stakeholdern am Ende des Sprints.
• Sprint Retrospektive: Teaminternes Reflexionstreffen zur Verbesserung der Zusammenarbeit und Prozesse für den nächsten Sprint.

Erfolgsfaktoren für SCRUM-Projekte

Aus den Praxiserfahrungen lassen sich zentrale Erfolgsfaktoren für SCRUM-Projekte ableiten:

• Managementunterstützung: Ohne Rückhalt der Führungsebene scheitern SCRUM-Initiativen am Widerstand der Organisation. Die Führung muss den Kulturwandel aktiv unterstützen und vorleben.
• Konsequente Rollentrennung: Product Owner, SCRUM-Master und Entwicklungsteam müssen ihre jeweiligen Rollen klar verstehen und ausfüllen. Eine Vermischung führt zu den beschriebenen Rückfällen in alte Muster.
• Schutz des Sprints: Das Entwicklungsteam muss während des Sprints vor externen Anforderungen geschützt werden. Der SCRUM-Master übernimmt hierfür die Schutzschild-Funktion.
• Teamgröße und -zusammensetzung: Das Team muss klein genug sein, um flexibel zu bleiben, und groß genug, um die Arbeit innerhalb der Sprints erledigen zu können. Die interdisziplinäre Zusammensetzung ist entscheidend.
• Kontinuierliches Lernen: SCRUM lebt von der Retrospektive und der ständigen Anpassung. Teams, die die Retrospektive ernst nehmen und Verbesserungen konsequent umsetzen, erzielen die besten Ergebnisse.

Quellenangaben

Wenz, J. (2014): SCRUM bei Leanprojekten, Schritt für Schritt besser werden und aus Erfahrung lernen, in: YOKOTEN 06/2014, S. 6–17.

Wenz, J. (2015): SCRUM bei Lean Projekten, Wie werden Projekte agil?, in: YOKOTEN 02/2015, S. 18–20.

Wenz, J. (2015): Wertschöpfung durch Scrum, Warum nutzen überzeugte Lean-Anhänger die Scrum-Methodik?, in: YOKOTEN 04/2015, S. 24–26.

Wenz, J. (2015): Die Rolle des Scrum-Masters, Coach, dienende Führungskraft, Prozesseigentümer, in: YOKOTEN 05/2015, S. 20–22.

Lindner, C. (2021): Agile Transformation, Wie es gelingen kann, Agilität dauerhaft im Unternehmen zu etablieren, in: YOKOTEN 05/2021, S. 24–25.

Weiterführende Literatur

Rother, M.; May, C. (2019): Das KATA-Praxishandbuch. CETPM Publishing, Herrieden.

May, C.; Schimek, P. (2015): Total Productive Management. 3. korr. Aufl., CETPM Publishing, Herrieden.

Verwandte Konzepte

Kobetsu Kaizen (1. Säule des TPM-Hauses) · KATA · Instandhaltungsstrategie · Operational Excellence · · TPM (im Sinne von Total Productive Maintenance) · KVP · Muda · Kaizen · Verschwendung