AKTUELLES SCHLAGWORT* / SCRUM
}
Scrum
Der Pradigmenwechsel im Projekt- und Produktmanagement – Eine Einführung
Boris Gloger
Einführung
Scrum1 ist heute der De-facto-Standard in der
agilen2 Softwareentwicklung. Es hat sich in den
letzten Jahren aus einer (agilen) Projektmanagementmethode zu einem neuen Verständnis darüber
entwickelt, wie man dysfunktional arbeitende
Teams, Abteilungen, ganze Organisationseinheiten
und Firmen agil und lean managt. Meist wird Scrum
von Firmen zunächst auf Team- oder Projektebene
als Projektmanagementmethode eingesetzt. Dabei bleibt es für einige Firmen; andere gestalten
im Laufe der Zeit ihre gesamte Organisation mit
Scrum.
Kurze Geschichte von Scrum
In den USA begannen in den 1990er-Jahren Alistair Cockburn, James Coplin, Jim Highsmith, Ken
Schwaber, Kent Beck u. a. die agile Softwareentwicklung zu kreieren.3 Sie erkannten, dass kleine
Entwicklungsteams mit Teammitgliedern, die im
Wesentlichen alle Skills haben, effektiver und
schneller bei höherer Qualität Softwareapplikationen liefern als große Teams [2, 4, 13]. Zunächst
verbreitete sich eXtreme Programming (XP) [1],
dann startete Ken Schwaber mit dem Certified
ScrumMaster Programm ab 2002 eine weltweite
Bewegung. Er bot die Möglichkeit, zu lernen,
wie agile Softwareentwicklung funktioniert. Da
Scrum im Gegensatz zu XP das Management
und das Business anspricht, setzte es sich als Defacto-Standard der agilen Softwareentwicklung
durch.4
Andere agile
Softwareentwicklungsmethoden
Scrum, im Klima der Bewegung zur agilen Softwareentwicklung entstanden, war zu Anfang
nur eine unter vielen agilen Softwareentwicklungsmethoden. Zu diesen Methoden gehörten:
das Extreme Programming, Kent Beck; Crystal,
Alistair Cockburn; Feature Driven Development,
Jeff de Luca und einige andere unbedeutendere
Ansätze.
Scrum hat sich dabei immer als reine Management-Rahmenmethode verstanden.5 Daher sagt
Scrum nichts darüber aus, wie Software entwickelt werden soll. Methoden wie XP oder FDD
haben im Gegensatz dazu klare Vorgaben zur Entwicklung gemacht. Daher kann Scrum mit jeder
gängigen Softwareentwicklungsmethode, also auch
mit anderen agilen Methoden kombiniert werden.
1
Der Name Scrum kommt aus dem Artikel The New New Product Development
Game, in dem Nonaka und Takeushi das Neuentwickeln von Projekten mit Rugby
vergleichen und für das Zusammenarbeiten von cross-funktionalen Teams das
Bild des Scrum, eine Freistoßsituation im Rugby, verwenden [11].
2 Agile Softwareentwicklung ist der Oberbegriff für den Einsatz von Agilität in
der Softwareentwicklung. [. . .] Agile Softwareentwicklung versucht mit geringem
bürokratischen Aufwand und wenigen Regeln auszukommen. Siehe dazu auch:
http://de.wikipedia.org/wiki/Agile_Softwareentwicklung.
3 Siehe dazu das Agile Manifesto (www.manifesto.org).
4 Weltweit gibt es mehr als 60.000 Certified ScrumMaster, mehr als 100.000
Menschen sind in Scrum ausgebildet, mehr als 1000 Firmen nutzen Scrum.
5 Ken Schwaber stellt es selbst immer als Management Framwork dar [14].
DOI 10.1007/s00287-010-0426-6
© Springer-Verlag 2010
Boris Gloger
Schwarzwaldstrasse 139, 76532 Baden-Baden
E-Mail: boris.gloger@borisgloger.com
*Vorschläge an Prof. Dr. Frank Puppe
<puppe@informatik.uni-wuerzburg.de> oder
Prof. Dr. Dieter Steinbauer <dieter.steinbauer@schufa.de>
Alle „Aktuellen Schlagwörter“ seit 1988 finden Sie unter:
www.ai-wuerzburg.de/as
Informatik_Spektrum_33_2_2010
195
{ SCRUM
Zusammenfassung
Scrum ist der De-facto-Standard in der agilen
Softwareentwicklung. Mit Scrum werden Prinzipien aus dem Knowledgemanagement und
dem Toyota Production System in das Managen
von Softwareentwicklung eingeführt. Der Artikel stellt den Scrum-Flow und die Rollen kurz
vor.
Ein Paradigmenwechsel
Scrum entwickelte aus den Ideen des Knowledgemanagements6 die gleichen Vorgehensprinzipien wie
das Toyota Production System (TPS)7 :
– kleine Self Directed Work Teams oder crossfuncional Teams, in denen die Teammitglieder
alle verschiedenen Aufgaben durchführen können,
– der PDCA-Cycle (siehe Abschn. „Der Deming
Cycle und Scrum“) als kontinuierlicher
Verbesserungsprozess,
– der one-piece-flow (nur ein Teil ist in Arbeit),
– das ständige Ausmerzen von Waste, in Scrum
Impediments und
– das Pull-Prinzip statt des Push-Prinzips.
tät (Anzahl von entwickelter Funktionalität) und
z. B. einer 38%igen Steigerung der Lieferungen
von Funktionalität pro Entwickler innerhalb eines
Jahres.9 Gründe für diese Produktivitätssteigerungen
sind:
– Cross-funktionale Teams arbeiten gemeinsam
an dem Produkt, ihre Kenntnisse werden sofort
miteinander ausgetauscht. Abstimmungen finden
sofort statt.
– Eine klare Fokussierung der Teammitglieder auf
eine Aufgabe, ein Projekt.
– Scrum-Teams brauchen keine aufwändige Verwaltung und Kontrolle, d. h. der sonst vielfach übliche
Overhead kann weitestgehend entfallen.
– Es gibt klare Verantwortlichkeiten. Konflikte und
Probleme werden so früh wir möglich erkannt,
besprochen und entschieden.
– Wenn sich etwas im Hinblick auf das Ergebnis
nicht bewährt, dann fällt das sehr schnell auf, d. h.
Fehler können schnell und kostengünstig beseitigt
werden.
Das sind nur einige Gründe. Allgemein kann man
sagen, dass Scrum dysfunktionale Strukturen aufdeckt und dass der ScrumMaster dafür sorgt, dass
diese sofort beseitigt werden.
Mit dem kontinuierlichen Liefern von fertiger,
nutzbarer Software am Ende einer EntwicklungsIteration, dem Sprint, bricht Scrum gänzlich mit
traditionellen Projektmanagementansätzen.
Scrum erhöht die Produktivität
Von den Anwendern von Scrum wird berichtet, dass die Anwendung dieser Prinzipien zu
erheblichen Produktivitätssteigerungen bei der
Softwareentwicklung führt.8 Sie berichten von
höherer Zufriedenheit der Mitarbeiter, höherer
Codequalität, wesentlich verbesserter Transparenz
zum Stand der Produktentwicklung und vielem
mehr. Exemplarisch kann man das bei der Firma
Salesforce.com, San Francisco, sehen. Steve Green
berichtet von 568% Verbesserung der Produktivi6 [11] enthält bereits die Ideen zu cross-funktionalen, autonomen Teams und zu
einem Entwicklungsverfahren, in dem alle gemeinsam gleichzeitig am Produkt
arbeiten.
7 Siehe zum TPS [10].
8 Dazu gibt es immer noch wenige verlässliche empirische Daten. Was es aber
gibt, ist die Aussage der Menschen, die erfolgreich Scrum eingeführt und gelebt
haben: Sie alle erklären, dass Scrum der richtige Weg zu Produkivitätssteigerung
und mehr Transparenz in der Entwicklung von Produkten ist.
196
Informatik_Spektrum_33_2_2010
Die Prinzipien angewendet
Kleine, selbstorganisierte Teams
Ein Scrum-Team besteht im Idealfall aus sieben
Personen, dem ScrumMaster, dem Product Owner,
und den Personen des Entwicklungsteams. Diese
sind hocheffektiv, weil sie nach dem klassischen
Modell der self-directed work teams [7], den automen Arbeitsgruppen, gebildet sind: Alle Mitglieder
des Entwicklungsteams sind in der Lage, mehrere
Arbeiten im Arbeitsprozess durchzuführen. Sie
organisieren ihre Aufgaben vollständig selbst. Der
ScrumMaster ist nicht Teil des Entwicklungsteams.
Er organisiert die Rahmenbedingungen um das
Scrum-Team herum. Der Product Owner steuert
das Team aus der fachlichen Sicht. Er entscheidet,
was wann vom Team umgesetzt werden soll, macht
aber keine Vorgaben, wie das Produkt erstellt werden
soll.
9 Aus
meiner eignen beruflichen Praxis kann ich diese Aussagen bestätigen. Die
Präsentation in [9] liefert hier gutes Datenmaterial.
Die Teile und Verantwortlichkeiten des ScrumTeams. Es gibt drei Teile, die das Scrum-Team
bilden: ScrumMaster, Product Owner und das Team.
Die Umwelt des Scrum-Teams sind die drei Teile:
Manager, Customer und User.
Das Scrum-Team. Der ScrumMaster als Rolle
managt die Grenzen des Scrum-Teams.10 Er beschützt es vor äußeren Einflüssen. Er sorgt dafür,
dass der Scrum-Prozess von allen eingehalten
wird, implementiert Scrum und arbeitet mit
dem Management an produktivitätssteigernden
Verbesserungen.
Der ScrumMaster als Person ist eine Führungskraft ohne disziplinarische Verantwortung. Er sorgt
für die Selbstorganisation des Teams, in dem es die
formale Autorität, alle notwendigen Ressourcen
und alle notwendigen Informationen bekommt. Er
sorgt dafür, dass sich das Team für das zu Liefernde
verantwortlich fühlt. [7, S. 16]
Der Product Owner als Rolle erstellt die Product Vision11 und das priorisierte und geschätzte
Product Backlog, die Liste der Funktionalitäten,
die zu erarbeiten sind. Er stellt die Profitabilität der Produktentwicklung sicher, indem
er streng auf den Return-on-Investement12
achtet.
Als Person ist er Visionär. Er führt die Produktentwicklung strategisch und beantwortet dem
Entwicklungsteam fachliche Fragen.
Das Team als Rolle ist verantwortlich für die
Lieferung des Produkts, die technische Umsetzung,
die Qualität des Gelieferten und die Einschätzung,
was es tatsächlich liefern kann.
Als Personen, als Teammitglieder, organisieren
sie sich so, dass sie alles Versprochene liefern können. Dazu führen sie alle Arbeiten gemeinsam aus
und erhöhen ständig ihre Produktivität.
der Head of Development sein, der Regeln darüber
aufstellt, wie zu entwickeln ist.
Der Customer als Rolle bezeichnet den Auftraggeber.
Der User als Rolle gibt das Feedback zur erstellten Funktionalität. Als Person nutzt er das
Produkt.
Der Deming Cycle und Scrum
Im Kern von Scrum, als Mindset, um professionell
Produkte zu entwickeln, steht die kontinuierliche
Verbesserung. Daher ist der Scrum-Flow als Implementierung einer Folge von Meetings zu sehen, um
den von Dr. W. Edwards Deming eingeführten PlanDo-Check-Act-Zyklus (PDCA)14 zu implementieren
(siehe Abb. 1).
Der Sprint wird vom strategischen Planungsprozess umrahmt. Der Product Owner konkretisiert
kontinuierlich die Product Vision, aktualisiert
und re-priorisiert das Product Backlog (die Liste
der Funktionalitäten, die zu erarbeiten sind) und
arbeitet mit dem Entwicklungsteam an der Sprintübergreifenden Release-Planung. Dazu dienen ihm
einige Meetings: das Estimation Meeting und das
Business Value Estimation Meeting.
Der One-Piece-Flow
Das Entwicklungsteam erarbeitet während des
Sprints die zu liefernde Funktionalität konsequent
in der priorisierten Reihenfolge. Im Idealfall arbeiten alle Teammitglieder dabei immer an genau einer
Funktionalität (One-Piece-Flow). Das Ziel ist es, eine
Funktionalität nach der anderen zu liefern.
Maintenance-Aufgaben, z. B. Fehlerbehebung
während des Sprints, werden sofort erledigt. Ungeplante, neue Funktionalitäten werden ins Product
Backlog gegeben und im nächsten Sprint erledigt.
Impediment-Bekämpfung
Die Scrum-Teamumgebung: drei Nebenrollen. Die
Umgebung des Scrum-Teams kennt drei weitere
Rollen: Der Manager als Rolle setzt die organisatorischen Rahmenbedingungen.13 Als Person kann das
10
Zur Idee des Managers als boundary manager siehe [7].
11 In Scrum bezeichnet man mit Product Vision die zugrunde liegende
Produktidee.
12 Der Begriff Return-on-Investment (deutsch Kapitalverzinsung oder Kapitalrendite, kurz ROI) bezeichnet ein Modell zur Messung der Rendite des eingesetzten
Kapitals. Siehe dazu: http://de.wikipedia.org/wiki/Return_on_Investment.
13 Zur Rolle des Managers in einer Organisation wie Pixar siehe [5].
Probleme, Impediments, im Toyota Production System Waste, die beim Erstellen einer Funktionalität
auftreten, werden vom ScrumMaster möglichst
sofort behoben.
Das Pull-Prinzip
Das Toyota Production System führt konsequent
das Pull-Prinzip ein. Dieses Prinzip führte zum
vollständigen Paradigmenwechsel in der Automo14
http://en.wikipedia.org/wiki/PDCA.
Informatik_Spektrum_33_2_2010
197
{ SCRUM
Abb. 1 Der Scrum Flow – strategische und taktische Ebene
bilindustrie und Logistikindustrie. Nicht mehr die
Produktionskapazität steuert den Ausstoß der Produktion, sondern einzig der tatsächliche Bedarf an
einem Produktteil.
Dieses Prinzip wird von Scrum beim Managen
von Projekten gelebt:
1. Das Produkt Backlog wird vom Product
Owner basierend auf den Markterfordernissen priorisiert. Technische Machbarkeit spielt
bei der Priorisierung der Funktionalitäten eine
untergeordnete Rolle.
2. Das Entwicklungsteam entscheidet im Sprint
Planning Meeting 1, wie viel Funktionalität es liefern
wird.
Done
Das entscheiden Prinzip ist: Am Ende eines Sprints
hat das Entwicklungsteam potenziell nutzbare Funktionalität zu liefern. Das heißt keine weiteren
Arbeiten sind notwendig, um diese Funktionalität
an den End-User zu übergeben.
Diese Vorgabe muss an die jeweiligen Entwicklungsbedingungen angepasst werden. Deshalb
wird zwischen dem Entwicklungsteam und dem
Product Owner der Level of Done vereinbart.
Der ScrumMaster arbeitet mit dem Scrum-Team
198
Informatik_Spektrum_33_2_2010
daran, diesen kontinuierlich zu erhöhen. Im Idealfall wird am Ende des Sprints an den End-User
ausgeliefert.15
Scrum in der Umsetzung
Scrum in Unternehmen kann nur gelingen, wenn auf
zwei Ebenen, der strategischen und der taktischen
gearbeitet wird. Um den PDCA-Zyklus auf beiden
Ebenen effektiv durchzuführen, bedarf es einiger
Meetings und Artefakte.
Die Meetings auf strategischem Level.
Im Estimation Meeting wird vom Team gemeinsam
mit dem Product Owner ein erstes Grundverständnis über die zu liefernde Funktionalität erarbeitet
und die Größenordnung eingeschätzt.16
Im Business Value Estimation Meeting werden
die Product Backlogs unterschiedlicher Abteilungen gegeneinander priorisiert. Auf diese Weise kann
jedes Team an den jeweils wichtigsten Inhalten
arbeiten.
15 Es
gibt mittlerweile Scrum-Teams, die nicht nur am Ende des Sprints fertige
Software an den Product Owner oder ihre internen Kunden ausliefern, sonderen
diese Teams liefern kontinuierlich, d. h. während des Sprints, die neu entstandene
Funktionalität an Kunden und End-User aus.
16 In der agilen Softwareentwicklung werden Funktionsumfänge, nicht Aufwände
geschätzt. Siehe dazu [8] und [3].
Im ScrumMasters Weekly besprechen die ScrumMaster aller Teams wichtige Änderungen und
identifizieren Impediments auf organisatorischer
Ebene und vereinbaren die Lösungsmaßnahmen.
In den Knowledge Domain Meetings treffen
sich die Spezialisten der Teams, zum Beispiel die
Datenbankentwickler, um fachliche Richtlinien zu
erstellen.
Die Meetings – Taktischer Level.
Im Sprint Planning Meeting 1 erstellt das Entwicklungsteam eine Analyse der zu liefernden Funktionalität. Basierend auf der genauen Kenntnis,
wie die Funktionalität sein soll, wird vom ScrumTeam die Auswahl getroffen, was geliefert wird. Im
Sprint Planning Meeting 2 entsteht eine klare Vorstellung darüber, wie die jeweilige Funktionalität zu
implementieren ist.
Ein tägliches Meeting, Daily Scrum, erzeugt die
notwendige Sichtbarkeit, um aus der individuellen
Leistung des Einzelnen eine öffentliche Leistung des
Teams zu machen.17 Die Visualisierung der Leistung
des Teams erfolgt mithilfe eines Taskboards oder
Scrumboards.18 In diesem Meeting planen die Teammitglieder ihre täglichen Aktivitäten und sprechen
sich untereinander ab.
Arbeiten mehrere Scrum-Teams daran, ein Produkt zu liefern, treffen sich die Teammitglieder aus
den Entwicklungsteams täglich zum Scrum of Scrums
(SoS). Hier werden die technischen Abhängigkeiten der Teams bekannt gegeben und dann von den
Entwicklungsteams aufgelöst.
Die Product Owner bilden das Product Owner
Team. Sie treffen sich täglich im Product Owner
Daily Scrum (PODS), um die Koordination auf der
Großprojektebene durchzuführen.
Im Sprint Review lassen die Teammitglieder
den End-User mit der erstellten Funktionalität
experimentieren. Der Product Owner und der
ScrumMaster nehmen jede dabei entstehende Idee
in das Product Backlog auf.
Im Sprint Retrospective Meeting berät das Entwicklungsteam gemeinsam mit dem ScrumMaster,
wie man die Produktivität durch das Ausräumen von
Impediments erhöhen kann.19
17
Zur Veränderung in der Art und Weise, wie Software in der agilen Softwareentwicklung gemacht wird, hin zur einer Typisierung der agilen Softwareentwicklung
als ,,kollektiv“, ,,körperlich“, ,,implizit“ und ,,öffentlich“, findet sich in [12].
18 Die Darstellung, wie man mit dem Taskboard arbeitet, findet sich in [8].
19 Eine gute Darstellung des gesamten Ablaufs findet sich in [8] und in [6].
Scrum in großen Umfeldern
In den letzten Jahren wurden Praktiken entwickelt,
um Scrum auch in großen Projekten mit mehr als
100, ja 1000 Personen zum Steuern von Abteilungen
und sogar Unternehmen einzusetzen.
In diesen Umfeldern werden synchronisierte
Sprint Planning Meetings mit bis zu 15 Teams gleichzeitig, SoS mit bis zu 60 Personen, virtualisierte
Daily Scrums und road-show-artige Sprint Reviews
durchgeführt.
Organisationen setzen Scrum ein, wenn Teams
an unterschiedlichen Standorten gemeinsam an
einem Produkt arbeiten. Die Arbeiten von Jeff
Sutherland zeigen, dass mit Scrum die Chance
besteht, dass die Produktivität der Softwareentwicklung linear mit der Anzahl der Scrum-Teams
wachsen kann [15]. Das wird erreicht, wenn ein
tiefes Verständnis aller Beteiligten in der Organisation für die Wirkweise von Scrum besteht
und der Paradigmenwechsel in der Durchführung von Entwicklungsprojekten bereits real gelebt
wird.
Schluss
Prinzipien und Erkenntnisse des Knowledge
Managements und des Toyota Production Systems sind mit Scrum in das Managen von
Softwareprodukt-Entwicklungsprojekten eingeflossen. Viele Organisationen erleben mit Scrum
erhöhte Produktivität ihrer Softwareentwicklungsteams. Der Paradigmenwechsel hat in diesen
Firmen begonnen, und sie erleben eine gesteigerte Produktivität bei höherer Zufriedenheit ihrer
Mitarbeiter. Damit ist Scrum aus der modernen
Softwareentwicklung nicht mehr wegzudenken.
Literatur
1. Beck K, Andres C (2004) Extreme Programming Explained: Embrace Change, 2nd
edn. Addison-Wesley Professional, Boston
2. Cockburn A (2006) Agile Software Development: The Cooperative Game, 2nd edn.
Addison-Wesley Professional, Boston
3. Cohn M (2006) Agile estimating and planning. Prentice Hall Professional Technical Reference, Upper Saddle River, NJ
4. Coplien JO (1994) Borland software craftsmanship: A new look at process, quality
and productivity. Software Production Research Department AT&T Bell Laboratories, Orlando, FL
5. Cutmull E (2008) How pixar fosters collective creativity. Harvard Bus Rev 9:60–72
6. Derby E, Larsen D (2006) Agile Retrospectives: Making Good Teams Great. Pragmatic Bookshelf, Raleigh, NC, Dallas, TX
7. Fisher K (2000) Leading Self-Directing Work Teams. McGraw-Hill, New York
8. Gloger B (2008) Scrum. Produkte zuverlässig und schnell entwickeln. Hanser Fachbuch, München
9. Green S (2009) A Year of Living Dangerously. How Salesforce.com delivered Extraordinatory Results through a “Big Bang” Enterprise Agile Revolution.
Salesforce.com, Scrum Gathering, Stockholm
Informatik_Spektrum_33_2_2010
199
{ SCRUM
10. Liker J (2003) The Toyota Way. McGraw-Hill, New York Chicago San Francisco
11. Takeushi H, Nonaka I (1986) The new new product development game. Harvard
Bus Rev
12. Schmidt R (2008) Praktiken des Programmierens – zur Morphologie von Wissensarbeit in der Softwareentwicklung. Z Soziol 37(4):282–300
200
Informatik_Spektrum_33_2_2010
13. Schwaber K (2004) Agile project management with Scrum. Microsoft Press, Redmond, WA
14. Schwaber K (2007) The enterprise and Scrum. Microsoft Press, Redmond, WA
15. Sutherland J, Downey S, Granvik B (2009) Shock Therapy: A Bootstrap for HyperProductive Scrum. agile, 2009 Agile Conference, pp 69–73