„The Art of Doing Twice the Work in Half the Time“ – ein im wahrsten Sinne des Wortes viel versprechender Buchtitel des Scrum-Mitbegründers Jeff Sutherland. In der deutschen Übersetzung war der Verlag zwar nicht ganz so mutig, nichtsdestotrotz bringt auch der Titel „Die Scrum-Revolution“ das Ziel des agilen Frameworks zum Ausdruck: einen Umbruch im Unternehmen bewirken. Aber was kann die Wunderwaffe Scrum wirklich? Eignet sich Scrum für jedes Projekt, jedes Unternehmen, jedes Team – auch für Sie?
Mal ehrlich: Wo ist der Haken?
Dass Scrum mehr ist als ein US-Hype mit dem typisch amerikanischen Hang zur Übertreibung, beweisen inzwischen zahlreiche deutsche Erfolgsgeschichten. Ein gutes Beispiel ist die Scout24-Unternehmensgruppe. Das Münchner Online-Unternehmen setzte schon vor rund 7 Jahren auf Scrum in der Produkt- und Softwareentwicklung – mit schnell sichtbaren (und messbaren) Erfolgserlebnissen: Im ersten Jahr nach der Scrum-Einführung stieg die Entwicklungsgeschwindigkeit nach eigenen Angaben um 200 Prozent und die Anzahl kritischer Fehler konnte um rund 80 Prozent gesenkt werden.
Effizienzsteigerungen durch Scrum im Vergleich zu klassischen Wasserfall-Modellen sind nachgewiesen. Aber wenn es so einfach ist, warum machen dann eigentlich nicht alle Scrum?
„Scrum is very easy to understand but very difficult to master.“ (Ken Schwaber)
Scrum ist komplex. Scrum fordert. Und Scrum verändert. Auch Scout24 berichtete von der Erfahrung, dass Scrum weit mehr ist als eine „Methode“. Die Einführung von Agilität geht Hand in Hand mit einer neuen Unternehmenskultur, die unter anderem das Verhältnis zwischen Team und Management und das Verständnis von Arbeit und Führung hinterfragt – und bei Bedarf eben auch umkrempelt.
„Scrum“ wird 30!
So revolutionär der Ansatz vielen Unternehmen scheint: Die Erkenntnis, dass kleine, interdisziplinäre und selbstorganisierte Teams bessere Ergebnisse erzielen, ist nicht neu. Bereits vor Jahrzehnten experimentierten renommierte Firmen mit vergleichbaren Modellen des Projektmanagements, ausgehend von der Lean-Production-Bewegung in Japan.
1986 stellten Hirotaka Takeuchi und Ikujiro Nonaka in einem Aufsatz der Harvard Business Review verschiedene Fallbeispiele von Unternehmen vor, deren Produktentwicklungen ungewöhnlich schnell und innovativ waren, u.a. Pkws bei Honda, Spiegelreflexkameras bei Canon, Kopierer bei Fuji-Xerox sowie PCs bei NEC.
Als ausschlaggebende Gemeinsamkeit der analysierten Unternehmen identifizierten die beiden Wirtschaftswissenschaftler kleine Teams mit einer charakteristischen Arbeitsweise, die Takeuchi und Nonaka „Scrum“ nannten (die engl. Bezeichnung für einen Rugby-Spielzug, übersetzt „Gedränge“).
„In today’s fast-paced, fiercely competitive world of commercial new product development, speed and flexibility are essential. Companies are increasingly realizing that the old, sequential approach to developing new products simply won’t get the job done. Instead, companies in Japan and the United States are using a holistic method – as in rugby, the ball gets passed within the team as it moves as a unit up the field.“ (Hirotaka Takeuchi und Ikujiro Nonaka)
Takeuchi und Nonaka formulierten 6 Bedingungen für effiziente Teams:
- Built-in instability
- Self-organizing project teams
- Overlapping development phases
- Multilearning
- Subtle control
- Organizational transfer of learning
Inspiriert von Takeuchi und Nonaka entwickelten Jeff Sutherland und Ken Schwaber rund 10 Jahre später den „Rugby Approach“ weiter zu dem Framework, das wir heute als Scrum kennen.
Die Zeit war reif für Scrum
1994 veröffentlichte die Standish Group den ersten CHAOS-Report mit desaströsen Zahlen: Rund ein Drittel aller IT-Projekte scheiterte vorzeitig, nur 16 Prozent erreichten das angestrebte Entwicklungsziel ohne Mängel. Gleichzeitig erhöhte sich Mitte der 90er Jahre die Nachfrage nach leistungsfähiger Software rasant – entsprechend händeringend suchte die Softwareindustrie nach Lösungen.
Auch Sutherland und Schwaber beschäftigten sich intensiv mit der Frage, wie die Produktion von Software effizienter gestaltet werden konnte. Großes Verbesserungspotenzial sahen sie in der Flexibilisierung der Projektprozesse, weg von „top down“, hin zu mehr Spielraum für eigenverantwortliches Handeln.
Die Veröffentlichungen von Schwaber und Sutherland wurden von der Entwickler-Community wissbegierig aufgenommen und getestet. 2001 hielten Jeff Sutherland, Ken Schwaber und 15 weitere Experten die neuen Werte der Bewegung im Agilen Manifest fest – bis heute das Fundament aller agilen Methoden, von denen Scrum die populärste ist.
Scrum: Freiheit in Grenzen
„Wenn man ein Projekt beginnt, warum sollte man dann nicht regelmäßig überprüfen, ob die Richtung noch stimmt und man Leistungen erbringt, die tatsächlich gebraucht werden? Warum nicht prüfen, ob es vielleicht Mittel und Wege gibt, um besser und schneller voranzukommen, und welche Hindernisse dem womöglich entgegenstehen?“ (Jeff Sutherland)
Als Gegenentwurf zum klassischen Projektmanagement formuliert Scrum statt eines Plans eine Vision, die erst im Projektverlauf konkretisiert wird. Diese empirische Entwicklung erfolgt nicht völlig ungesteuert, sondern iterativ-inkrementell und innerhalb fest definierter Rollen, Ereignisse und Artefakte.
2010 verfassten Ken Schwaber und Jeff Sutherland mit dem „Scrum Guide“ einen offiziellen Scrum-Leitfaden, der kontinuierlich weiterentwickelt wird.
Wichtig für den Projekterfolg ist das Zusammenspiel der Rollen, Ereignisse und Artefakte nach Scrum-Regeln. Dazu betrachten wir den Scrum-Flow genauer:
Die Scrum-Rollen
- Product Owner
Der Produkteigner vertritt die Interessen der Anwender und Stakeholder und ist für die strategische Entwicklung und den wirtschaftlichen Erfolg des Projekts verantwortlich. Er pflegt das Product Backlog und priorisiert die Anforderungen. Kurz gesagt: Er bestimmt WAS gemacht wird und in welcher Reihenfolge. Falls kein direkter Kontakt zwischen Entwicklungsteam und Kunde möglich ist, ist der Product Owner das Bindeglied zum Kunden. - Entwicklungsteam
Das Team entscheidet gemeinsam, WIE die Vorgaben des Product Owners umgesetzt werden, unter Berücksichtigung der gewünschten Reihenfolge und unter Einhaltung der vereinbarten Qualitätsstandards. Scrum-Teams arbeiten interdisziplinär, ohne Hierarchien und mit einer optimalen Teamgröße von 7 +/-2 Mitgliedern. - Scrum Master
Der Scrum Master stellt sicher, dass die Scrum-Regeln und Werte eingehalten werden und hilft dem Team, selbstorganisiertes Arbeiten so anzuwenden, dass bessere Ergebnisse erzielt werden. Er ist nicht weisungsbefugt, sondern fungiert als Moderator und versteht sich als Dienstleister des Projektteams.
Die Scrum-Ereignisse
Aktivitäten im Scrum-Prozess:
- Sprint Planning
Priorisierung und Auswahl der Backlog Items für den nächsten Sprint - Daily Scrum
Status quo und Tagesplanung - Sprint Review
Präsentation des Inkrements - Sprint-Retrospektive
Rückblick mit dem Ziel der Verbesserung - Product Backlog Refinement / Grooming
Pflege des Product Backlogs
Die Scrum-Artefakte
Resultate des Scrum-Prozesses:
- Product Backlog
alle Anforderungen an das Produkt - Sprint Backlog
alle ausgewählten Backlog Items für einen Sprint - Product Increment
fertiges Teilprodukt, das am Ende des Sprints geliefert wird
Von der Vision zum Product Backlog
Aus der Vision des Product Owners werden sämtliche Elemente des Produkts abgeleitet, die entwickelt werden müssen.
Tipp
Formulieren Sie die Funktionalitäten („Product Backlog Items“) in Form von User Stories auf Story Cards! Wichtig: Beschreiben Sie die Funktionalität aus Sicht des Anwenders in 1 Satz, ohne technischen Fachjargon und immer unter Betrachung des Kundennutzens. Bewährt hat sich das Muster „Ich als möchte <Ziel/Wunsch> um “. Ein Beispiel: „Als Nutzer des Onlineshops will ich zwischen verschiedenen Versandoptionen wählen können, um die Lieferung genau dann zu bekommen, wann ich sie benötige.“
Die Summe aller User Stories bildet das Product Backlog – eine Sammlung sämtlicher Funktionen und Merkmale, die das fertige Produkt haben soll. Zu Beginn des Projekts ist das Product Backlog noch grob und wird im Projektverlauf immer detaillierter. Auf Basis der User Stories wird auch der Aufwand für das Projekt geschätzt.
Nach dem Sprint ist vor dem Sprint
Charakteristisch für Scrum ist die Entwicklung in Zyklen („Sprints“). Die sogenannten Sprints sind während des Projekts immer gleich lang („Timebox“), um einen Entwicklungsrhythmus zu erzeugen. Gemäß Scrum-Guide sind die Sprints zwei bis maximal vier Wochen lang.
Tipp
Wir haben gute Erfahrungen damit gemacht, eine Scrum-Einführung mit einwöchigen Sprints zu starten. So gewöhnen sich die Projektbeteiligten schneller an die Routine von Scrum-Ereignissen und Scrum-Artefakten und das Feedback fließt in kürzeren Abständen ein. Auch Fragen und Änderungen können in einwöchigen Sprints sehr zeitnah diskutiert werden.
Ziel jedes Sprints ist die Fertigstellung einer neuen, lauffähigen Funktion („Inkrement“), die dem Kunden ausgeliefert werden könnte, d.h. innerhalb jedes Sprints werden alle Aufgaben (Planung, Entwicklung, Test, Dokumentation) abgeschlossen. Auch wenn die sofortige Nutzung nicht in jedem Sprint funktioniert (und auch nicht bei jedem Inkrement sinnvoll ist), so ist ein „potentially shippable increment“ doch immer das Ziel! So wird im Verlauf der Sprints der Umfang bzw. die Qualität des Produkts immer ausgereifter.
Aber wann ist ein Inkrement „fertig“? Als Bemessungsgrundlage dient hier die „Definition of Done“ – eine Checkliste konkreter und verbindlicher Anforderungen, auf die sich Product Owner und Team vor Beginn des Sprints einigen.
Während eines Sprints organisiert sich das Entwicklungsteam selbst und die Anforderungen dürfen nicht verändert werden.
Wie organisiert sich das Team während des Sprints?
Der Vorteil von Scrum liegt in der Ritualisierung der Prozesse: Alle Meetings finden regelmäßig und innerhalb einer gleichbleibenden Timebox statt. Alle Teilnehmer kennen das Ziel des Meetings und die zur Verfügung stehende Zeit. So ist gewährleistet, dass sich jeder auf das Wesentliche konzentriert und jedes Meeting dazu beiträgt, das Projekt voranzubringen – das Projekt bleibt kontinuierlich in einem produktiven „Flow“.
Sprint Planning
Jeder Sprint beginnt mit einer meist eintägigen Sprint-Planung: Der Product Owner präsentiert sein Ziel sowie die Product Backlog Items mit der höchsten Priorität, und das Team stellt Rückfragen, bis alle Anforderungen verstanden sind.
Auf Basis der Aufwandsschätzung und der Kapazitäten entscheiden die Teammitglieder dann gemeinsam, wie viele Stories sie in der vom Product Owner vorgegebenen Reihenfolge in den Sprint übernehmen („committen“) können. Aus der Liste dieser ausgewählten User Stories für den nächsten Sprint entsteht das Sprint Backlog.
Tipp
Achten Sie darauf, dass das Team seine Arbeitsmenge und die Arbeitsweise unbeeinflusst selbst steuern kann – es bekommt keinerlei Vorgaben über das „WIEVIEL“ und das „WIE“! Gleichzeitig trägt das Team die Verantwortung für eine pünktliche Lieferung der zugesagten Funktionalitäten in der vereinbarten Qualität – ein typischer Knackpunkt zu Beginn einer Scrum-Transition, da sich die Teams häufig zu hohe, unrealistische Ziele setzen.
Daily Scrum
Jeden Tag zur selben Zeit trifft sich das Team zu einem 15-minütigen Meeting, das vom Scrum Master moderiert wird. Die Teammitglieder berichten über die Fortschritte, sprechen sich ab, wer welche Aufgabe übernimmt und informieren den Scrum Master über Probleme. (Was habe ich gestern getan? Was werde ich heute tun? Was hindert mich zu tun, was getan werden müsste?) Auf einem Scrum Board wird ähnlich wie beim Kanban-Board der Status der einzelnen Aufgaben visualisiert.
Tipp
Verwenden Sie hier ein physisches Board, das viel Platz bietet! Es gibt zwar gute digitale Tools, aber eine Tafel erhöht die Transparenz und fördert die Kommunikation. Können Sie auf die Online-Variante nicht verzichten (z.B. weil sich die zeitweise räumliche Trennung des Teams nicht ganz vermeiden lässt), so ist ein zusätzliches physisches Board trotzdem sehr empfehlenswert.
Product Backlog Refinement
Für die Backlog-Pflege hat sich ein Product Backlog Refinement (oder „Grooming“) gegen Ende des Sprints bewährt. Ziel ist es, frühzeitig neue Informationen zusammenzutragen, so dass Product Owner und Teammitglieder optimal vorbereitet in das nächste Planning Meeting gehen.
Gegenstand des Refinement-Meetings sind beispielsweise Priorisierungen für den nächsten Sprint, Erweiterungen des Product Backlogs, das Herunterbrechen umfangreicher Backlog-Items in zeitlich umsetzbare Stories sowie neue oder genauere Aufwandsschätzungen.
Tipp
Planen Sie ausreichend Zeit für das Grooming ein – der Scrum Guide sieht vor, bis zu 10 Prozent der Sprint-Zeit für das Refinement-Meeting zu reservieren, um das nächste Sprint Planning so effizient wie möglich zu gestalten.
Sprint Review
Am Ende des Sprints präsentiert das Team dem Product Owner die neue Funktionalität. Nur lauffähige Inkremente dürfen vorgestellt werden, alle nicht fertig gestellten Funktionalitäten gelten als nicht geliefert.
Sprint Retrospektive
Ein wesentliches Scrum-Element ist kontinuierliches Lernen: Im Rahmen einer Sprint Retrospektive analysieren die Teammitglieder die Prozesse und beschließen, welche Änderungen nötig sind, um in der Zukunft effektiver zu arbeiten („Backlog Impediment“).
Tipp
Die Änderungen sollten nicht auf die lange Bank geschoben, sondern möglichst sofort umgesetzt werden! Übrigens: Zum effektiven Arbeiten zählt auch der Spaß an der Arbeit! Die Verbesserungsvorschläge können also durchaus auch Ideen aufgreifen, wie die intrinsische Motivation erhöht werden kann.
Und wann ist das Produkt fertig?
Der Scrum-Trick: Mit den Inkrementen erhält der Kunde während des Projekts schon sehr früh voll funktionsfähige (Teil-)Versionen geliefert, die mit jeder Iteration umfangreicher und/oder qualitativ hochwertiger werden. Neue Features können mit „echten“ Nutzern getestet werden, und in jedem Sprint können bestehende Anforderungen abgeändert oder neu priorisiert werden.
So bestimmt der Kunde während des gesamten Projekts die Entwicklungsrichtung – auch den Zeitpunkt des Projektabschlusses: Wenn der Product Owner mit den Funktionalitäten der aktuellen Produktversion zufrieden ist und keine weiteren Entwicklungen wünscht, ist das Scrum-Projekt beendet.
Scrum: lean, aber nicht leicht
„Prima, Scrum passt ja auf 1 DIN-A4-Blatt!“, so scheint der erste Eindruck. Stimmt, das Rahmenwerk ist schlank und die Regeln sind einfach zu verstehen – aber in der Umsetzung alles andere als trivial! Insbesondere das neue Rollenverständnis und das selbstorganisierte, interdisziplinäre Arbeiten ohne übergeordneten Projektmanager und ohne genaue Vorgaben „von oben“ muss verinnerlicht werden.
In Unternehmen mit anweisungsorientierter Unternehmenskultur sind außerdem nicht nur die Erwartungen hoch, sondern auch die Bedenkenliste lang:
- Wird unser Management durch Scrum entmachtet?
- Was passiert mit den Zielvereinbarungen (MBO) unserer Mitarbeiter?
- Was machen künftig überhaupt unsere Projektleiter?
- Wie sollen wir Budgets planen, wenn die Aufwände nicht exakt geschätzt werden können?
- Sind unsere Projekte nicht zu groß für agile Methoden (Thema Skalierung)?
Fakt ist: Der Erfolg von Scrum hängt von zahlreichen Faktoren ab. Wie aufgeschlossen sind die Teammitglieder für die neuen Prozesse – und wie gut setzen sie Selbstorganisation um? Hält sich das Management in den Meetings tatsächlich mit „top down“-Ansagen zurück? Wird von beiden Seiten offen und ehrlich kommuniziert? Hat das Team Unterstützung durch einen versierten Scrum Master?
Tipp
Sofern im Team niemand die nötige Erfahrung hat, um die Rolle des Scrum Masters einzunehmen, ist die Begleitung durch einen externen Scrum-Coach empfehlenswert, der übergangsweise die Rolle des Scrum Masters übernimmt und das Team bei der Transition unterstützt.
Die wichtigste Voraussetzung für eine erfolgreiche Scrum-Transition ist die Bereitschaft für die in Sutherlands Buch versprochene Revolution im Unternehmen – alles andere ist erlernbar. Um auf den Titel zurückzukommen: Ja, dann kann Scrum tatsächlich dazu führen, die doppelte Arbeit in der halben Zeit zu schaffen. Wir helfen Ihnen gerne dabei!
Beitrag teilen
