Hi, herzlich willkommen in dieser Lektion, in der wir uns mit den Grundlagen von Scrum beschäftigen.
Welchen Inhalt beschreibt diese Lektion?
Wir sprechen in den nächsten Minuten über:
- die Definition von Fachbegriffen, die für das Verständnis dieser Lektion wichtig sind,
- die Entstehungsgeschichte,
- die Wissensspirale bzw. das SECI-Modell,
- wir schauen uns gemeinsam an, wie sich die Methode über die Zeit weiterentwickelt hat,
- und welches Fundament dieser Entwicklung zugrunde liegt,
- wir gehen ganz kurz auf die Grundwerte und Prinzipien ein,
- betrachten eine schöne Übersicht namens Scrum 3-5-3,
- erkennen dann den Kern von Scrum,
- und die davon abgeleiteten Ziele,
- wir sprechen über Umsetzungstechniken,
- und – bitte nicht lachen – wie wir einen Elefanten essen,
- wir gehen auf die 3 tragenden Säulen von Scrum ein,
- schauen uns gemeinsam die Scrum-Boards für den Product Backlog und den Sprint Backlog an,
- und thematisieren ganz zum Schluss unsere Erkenntnis aus dem Inhalt dieser Lektion.
Vorab wieder die Begriffsdefinitionen für eine ganze Reihe von Fachbegriffen in dieser Lektion. Fast alle diese Begriffe werden in späteren Lektionen noch im Detail besprochen, deshalb hier nur eine kurze Erklärung, um die Grundlagen aus dieser Lektion ohne Probleme verstehen zu können:
Was ist ein Framework?
Ein Framework gibt im Gegensatz zu einer Methode nur einen überschaubaren Rahmen vor, der dann mit geeigneten Umsetzungstechniken individuell ergänzt wird. Zudem baut ein Framework in der Regel auf einer Methode auf.
Was ist Lean Management?
Lean Management hat das Ziel, alle nicht unbedingt notwendigen Arbeitsschritte zu beseitigen und zu harmonisieren sowie die Lagerhaltung und damit „totes Kapital“ zu reduzieren, um damit flexibler, schneller und kostengünstiger wirtschaften zu können.
Was ist ein interdisziplinäres Team?
Ein interdisziplinäres Team beinhaltet Teammitglieder mit vielen unterschiedlichen zur Zielerreichung notwendigen Fähigkeiten und Erfahrungen. Im Bereich der Softwareentwicklung wären das z.B. Teammitglieder aus der Programmierung, dem Projektmanagement, Abgesandten aus den Fachbereichen oder Ansprechpartner für Maschinen, Anlagen und IT-Infrastruktur. Die Teammitglieder aus einem interdisziplinären Team stammen of aus unterschiedlichen Unternehmen.
Was ist ein Product Owner?
Der Product Owner ist für das zu entwickelnde Produkt verantwortlich und stammt zumeist aus dem Fachbereich, für den die Lösung entwickelt wird.
Was ist ein Scrum Master?
Der Scrum Master ist Kümmerer und Ratgeber im Projekt-Team, wenn agil nach Scrum gearbeitet wird. Seine Aufgabe umfasst die Einhaltung von Zeitvorgaben und funktionalen Zielvorgaben. Er entdeckt Optimierungspotenziale und Hindernisse im Projektablauf und setzt Lösungen mit geeigneten Maßnahmen um – oft auch mit Budget und Personalverantwortung.
Was ist ein Daily?
Das Daily – auch Daily Standup oder Daily Scrum Meeting genannt – beschreibt ein tägliches kurzes Meeting des gesamten Projektteams, bei dem jedes Teammitglied kurz beschreibt, was es seit dem letzten Daily getan hat, was es bis zum nächsten Daily vor hat, welche ungelösten Probleme noch existieren und wie in der letzten Periode Probleme gelöst werden konnten.
Was ist ein Product Backlog Refinement?
Beim Product-Backlog-Refinement wird überprüft, ob anstehende Anforderungen vollständig und schlüssig sind, welche Skills und Werkzeuge zur Umsetzung notwendig sind, ob und welche Abhängigkeiten zu anderen Anforderungen bestehen und welcher Aufwand mit jeder einzelnen Anforderung verbunden ist. Dabei werden auch Anforderungen in Aufgaben heruntergebrochen.
Was ist ein Sprint?
Ein Sprint beschreibt den fest definierten zeitlichen Rahmen, in dem eine Lösung tatsächlich umgesetzt wird. Im Bereich der Softwareentwicklung ist das die Programmierung bzw. Implementierung der angeforderten Funktionalität. Der Zeitrahmen umfasst zwischen 1 Woche und 4 Wochen und ist im Verlauf eines Projekts immer gleich lang.
Was ist ein Sprint Review?
In einem Sprint-Review wird dem Auftraggeber die umgesetzte Lösung vorgestellt und dabei idealerweise vom Auftraggeber abgenommen. Manchmal erfolgt die Abnahme auch zeitversetzt oder die Lösung wird nicht abgenommen und muss nachgebessert werden.
Was ist eine Retrospektive?
Die Retrospektive – oder kurz Retro genannt – ist ein wichtiges Mittel zur Selbstorganisation im Team und findet im Anschluss jedes Sprints statt. Bei der Retro benennen alle Teammitglieder ganz offen die gut und schlecht gelaufenen Ereignisse aus dem abgelaufenen Sprint und schlagen dafür idealerweise Lösungsoptionen vor. Die Retro hat das Ziel, den Projektablauf konstant zu optimieren.
Was ist ein Product Backlog?
Der Product-Backlog umfasst alle noch nicht in Umsetzung befindliche und noch nicht umgesetzte Anforderungen. Der Product-Backlog wird vom Product Owner verwaltet.
Was ist ein Sprint Backlog?
Der Sprint-Backlog umfasst alle in Umsetzung befindliche Anforderungen. Der Sprint-Backlog wird vom Scrum Master in Zusammenarbeit mit dem Implementierungs-Team verwaltet.
Was ist ein Product Inkrement?
Ein Product Inkrement beinhaltet das Ergebnis aus einem oder mehreren Sprints. Ein oder mehrere Product Inkrements werden in einem Release an den Kunden ausgeliefert.
Was ist iterativ?
Iterativ bedeutet, sich schrittweise in wiederholenden Schleifen der Lösung anzunähern.
Was ist inkrementell?
Inkrementell bedeutet, Zwischenlösungen aufeinander aufbauend so lange zu überarbeiten, bis das Lösungsergebnis die Erwartung der Anforderung erfüllt.
Was ist ein Defect oder Bug?
Ein Defect ist ein Bug oder eine angeforderte, aber noch nicht erfüllte Funktionalität.
Was ist ein Burn Down Chart?
Der Burn-Down-Chart ist ein Diagramm, an dem abgelesen werden kann, wie weit ein Team innerhalb eines Sprints im Zielkorridor liegt, ob es zeitlich im Verzug ist oder der Planung sogar voraus ist und deshalb weitere Anforderungen in den Sprint ziehen kann.
Was ist eine Zeremonie?
Eine Zeremonie beschreibt bei Scrum eine fest eingeplante und wiederkehrende Tätigkeit im Team. Im Englischen werden sie auch als Events bezeichnet.
Doch jetzt zum Thema – Scrum:
Warum heißt Scrum „Scrum“?
Im Gegensatz zur in der letzten Lektion besprochenen Kanban-Methode, ist Scrum aus der Softwareentwicklung entstanden. Das Wort „Scrum“ beschreibt im Englischen den Begriff „Gedränge“ beim Rugby und verdeutlicht damit vortrefflich die in der Softwareentwicklung übliche Komplexität, das Gerangel zwischen Zeit, Budget, Qualität und Funktionalität sowie die vernetzte Zusammenarbeit und unvorhersehbare Herausforderungen. Neben der Organisation komplexer und unvorhersehbarer Aufgaben, hat das Scrum-Framework auch ein Basis-Lean Management integriert, so dass Arbeitsergebnisse auf eine effiziente Art erreicht werden. Scrum wird deshalb auch über die Softwareentwicklung hinaus in anderen Branchen als Organisations-Framework eingesetzt.
Wann und wie ist Scrum entstanden?
Scrum ist erst Anfang der 1990er Jahre entstanden und basiert auf Grundlagen der Wissensspirale, dem SECI-Modell, das von Professor Hirotaka Takeuchi und Professor Ikujiro Nonaka entwickelt wurde. Das SECI-Modell ist dabei der „Gegenentwurf“ zum im Japan üblichen unidirektionalen Befehls- und Überwachungskonzept als gängigste Organisationsform, in der es klare Anweisungen, aber keine Rückmeldungserwartung, keine Selbstverantwortung und auch keine Kreativität gibt. Im Gegensatz dazu setzt Scrum auf hochqualifizierte, interdisziplinär besetzte Teams, die zwar ein klares Ziel vorgegeben bekommen, den Weg zum Ziel aber selbst finden müssen. Erst damit erhalten die Teams den kreativen Spielraum um gänzlich Neues und Besseres zu erschaffen – und auch die eigene Team-Organisation konstant zu optimieren.
Wer hat Scrum entwickelt?
Jeff Sutherland hat diese Anregung aufgenommen und in seiner Rolle als Projektleiter entsprechend umgesetzt, so dass er fortan eine eher moderierende Rolle als die eines Managers eingenommen hat. Seinen Teammitgliedern hat er einen Großteil seiner Verantwortung übertragen. Seine Praxiserfahrungen formulierte er ab 1993 zusammen mit Ken Schwaber. 1995 wurde der erste Konferenzbeitrag über Scrum veröffentlicht. Scrum ist übrigens ein Begriff, der bereits von Hirotaka und Nonaka geprägt wurde. Das erste Buch über Scrum folgte von Schwaber und Mike Beedle verfasst im Jahr 2002. Auch Beedle war Praxisanwender und konnte damit seine Praxiserfahrung bei der Weiterentwicklung des Scrum-Frameworks einbringen.
Während Scrum 2002 nur die Softwareentwicklung abdeckte (Buchtitel: Agile Software Development with Scrum), wurde die Methode 2004 auf das allgemeine Projektmanagement (Agile Project Management with Scrum) und 2007 auf die Unternehmensführung (The Enterprise and Scrum) erweitert. Bereits seit 2006 ist Scrum laut der jährlichen VersionOne-Umfrage die gängigste agile Organisationsform.
Was sind die Grundlagen von Scrum?
Das Fundament von Scrum ist die neuartige Form des Wissensmanagements. Während man bis heute üblicherweise davon ausgeht, dass Wissen formuliert, geschrieben und damit lehrbar gemacht wird, gehen das SECI-Modell und auch Scrum davon aus, dass dieses geschriebene und mündlich vermittelte Wissen nur die Spitze des Eisbergs darstellt. Der Großteil des Wissens wird gemäß SECI-Modell und Scrum bei der persönlichen Interaktion im Team und dem Learning-by-Doing vermittelt und weitergegeben – ganz abseits von Büchern, Lehrfilmen und Vorträgen. Die 4 Grundwerte teilt sich Scrum mit dem seit 2001 existierenden Agilen Manifest, das gemeinsam von Ken Schwaber, Jeff Sutherland und anderen verfasst wurde und die wir wie die 12 Prinzipien bereits in einer vorherigen Lektion behandelt haben.
Was ist das 3-5-3 von Scrum?
Der Kern von Scrum auf Basis der Agilität lässt sich mit wenigen Regeln definieren. Wir haben
- 3 Basis-Rollen (nämlich den Product Owner, den Scrum Master und das Team)
- 5-6 Basis-Ereignisse (nämlich das Daily, (gegebenenfalls ein Backlog-Refinement), das Sprint-Planning, Sprint, Sprint-Review und die Retrospektive)
- und 3 sogenannten Basis-Artefakte (den Product Backlog, den Sprint Backlog und das Product Inkrement)
Man nennt diesen Kern deshalb auch gerne das 3-5-3 des Scrum.
Im Anhang an diese Lektion findest Du ein PDF im A3-Format mit dem Scrum 3-5-3. Du kannst Dir das gerne ausdrucken und in Deinem Projektraum als Übersicht für das Team an die Wand hängen.
Welchen Vorteil hat das 3-5-3 von Scrum?
Dieser Kern ist fix und in jedem Scrum-Projekt zu finden. Dieser fixe Kern garantiert, dass sich neue Teammitglieder schnell zurechtfinden und das Wording sowie die Basis-Organisation einheitlich und damit unmissverständlich sind. Noch etwas fördert dieser Kern zutage: Mit Scrum ist es jedem Teammitglied unmöglich, eigene Schwächen zu verstecken. Die Scrum-Werkzeuge legen alles offen und deshalb sind Transparenz und Offenheit bei dieser Organisationsform nicht nur Theorie. Ziel von Scrum ist, dass Wissen im Team geteilt wird und deshalb jedes Teammitglied mit seinen Aufgaben wächst.
Darüber hinaus gibt es umfangreiche Umsetzungstechniken. Diese Umsetzungstechniken sind flexibel einsetzbar, je nach Bedarf und Herausforderung. Die Scrum-Techniken sind praxiserprobt, sie vermeiden Probleme und zeigen funktionierende Wege zur Lösung auf.
Wie sieht iteratives Arbeiten mit Scrum aus?
Bei Scrum sind sich alle Teilnehmer darüber im Klaren, dass das Entwicklungsprojekt zu komplex und zu unvorhersehbar ist, um es planen zu können. Diese Herausforderung lässt sich lösen, indem das Gesamtprojekt in viele kleine Zwischenschritte unterteilt wird. Anhand der dabei entstehenden Zwischenergebnisse lassen sich sowohl neue Zwischenziele als auch Lösungen dafür finden. Dabei wird nicht nur das Produkt im langfristigen „Product Backlog“ iterativ und inkrementell entwickelt, sondern auch die detaillierte Planung des „Sprint Backlog“ nur für den jeweils nächsten Zyklus definiert. Damit bleibt das Projekt flexibel und gewährt den Freiraum zu konstanter Optimierung und Lösungsfindung. Einer oder mehrere Sprints führen dann zu einem „Product Inkrement“ – dem Arbeitsergebnis. Ziel von Scrum ist es auch, dem Kunden schnellstmöglich ein sich in der Folge verbesserndes nutzbares Arbeitsergebnis zu liefern – im Gegensatz zu Wasserfallmodellen, wo das Arbeitsergebnis dem Nutzer oft spät im Projekterlauf zur Verfügung gestellt wird, weil darin die gesamte vereinbarte Funktionalität und Qualität zur Verfügung stehen soll.
Wie lauten die 3 Säulen von Scrum?
Wir können die 3 Säulen der Lösung für zu hohe Komplexität und Unvorhersehbarkeit auch wie folgt beschreiben:
- Transparenz: Fortschritte und Hindernisse werden regelmäßig und für alle sichtbar festgehalten – z.B. in den Dailies und auf Scrum-Boards
- Überprüfung: Projektergebnisse werden regelmäßig abgeliefert und bewertet – z.B. mithilfe von Sprints, Sprint-Reviews und neuen Releases auf Basis von einem oder mehreren Product Inkrements
- Anpassung: Anforderungen werden zwar erfasst, unterliegen aber einer konstanten Neubewertung durch den Kunden und das Scrum-Team. Und jetzt aufgepasst bitte: Dasselbe gilt für die Projekt-Organisation und die Planung für Zeit und Budget.
Was ist ein Scrum Board?
Stichpunkt Scrum-Boards: wie Kanban-Boards als Organisationswerkzeug aussehen und wie man sie benutzt, haben wir in der vorherigen Lektion grundlegend kennengelernt. Bei Scrum gibt es für denselben Zweck Scrum-Boards, die sich jedoch grundlegend unterscheiden.
Wie sieht das Scrum Board für den Product Backlog aus?
Beim Scrum-Board für den Product-Backlog steht die Priorisierung und die Reife eines Vorgangs im Vordergrund. Unreife Vorgänge sammeln sich in diesem Beispiel in den hellen Kästchen mit hoher Nummerierung an, reifer werdende Vorgänge wandern in die dunkleren Regionen und die Nummer eines Kästchens zeigt an, in welcher Reihenfolge die Vorgänge zur Bearbeitung gezogen werden.
Das hier dargestellte Scrum-Board wird überwiegend für die Organisation des Product-Backlog genutzt, kann je nach Projekt aber auch um weitere Boards z.B. für den Kunden-Backlog erweitert werden, wenn der Product Owner außerhalb des eigenen Unternehmens sitzt. Das Scrum-Board für den Product-Backlog kann aber auch nach Anforderungstypen aufgeteilt werden, so dass Kunden-Anforderungen, Infrastruktur-Anforderungen, Defects und zusätzliche Anforderungen an genutzte Standardsoftware in separaten Scrum-Boards behandelt werden. Je nach Herausforderung im Projekt können die Organisationswerkzeuge so gewählt und auch nachträglich angepasst werden, dass der reale Arbeitsablauf transparent und qualitätssichernd abgebildet wird.
Wie sieht das Scrum Board für den Sprint Backlog aus?
Für die Organisation des Sprints wird bei Scrum das hier dargestellte Scrum-Board genutzt – wobei die Spalten an den realen Arbeitsablauf angepasst werden können. Ich persönlich nehme z.B. gerne zusätzlich den internen Sprint Review mit auf – und wo notwendig auch die Dokumentation, bevor ein Vorgang auf Done gesetzt werden kann. Wenn ein manueller Burn-Down-Chart gepflegt wird, dann bietet es sich sogar an, im Anschluss an die Done-Spalte eine Burned-Spalte anzuschließen – das erleichtert die Pflege des Burn-Down-Chart. Du siehst: die Umsetzungstechniken sind zwar definiert, aber flexibel an den Bedarf anpassbar.
Wie werden Aufgaben von einem Scrum Board zum nächsten übergeben?
Der Schritt von einem Board auf das nächste erfolgt übrigens innerhalb fester Zeremonien, wie z.B. dem Backlog Refinement und der Sprint-Planung, bei denen immer mindestens die jeweiligen Backlog Owner anwesend sein müssen.
Wir könnten an dieser Stelle jetzt mit den einzelnen Kern-Elementen und den Umsetzungstechniken fortfahren, und uns so ein breites Verständnis von Scrum erarbeiten. Da Scrum für ein agiles Softwareentwicklungsprojekt in Großunternehmen jedoch sozusagen das Rückgrat des Projekts ist und fast alle Scrum-Bestandteile dabei unverzichtbar sind, möchte ich erst nach der Vermittlung aller Grundlagen darauf eingehen – dann aber auch umfassend, kritisch und situationsbezogen auseinandernehmen.
Kann Scrum die Komplexität reduzieren?
Ich möchte diese Lektion mit der Einsicht beschließen, dass Scrum „nicht“ in der Lage ist, die Komplexität oder die Unvorhersehbarkeit eines Projekts zu reduzieren. Aber Scrum ist in der Lage, diese Herausforderungen so in kleinere Inkremente zu strukturieren, dass sie überschaubar und lösbar werden – und das mit einer erstaunlich hohen Effizienz.
Fassen wir nun zusammen, was wir in dieser Lektion behandelt haben:
- wir haben eine ganze Latte neuer Fachbegriff kennengelernt,
- ebenso, wo und wie Scrum entstanden ist,
- Du weißt nun, was hinter der Wissensspirale bzw. dem SECI-Modell steckt,
- und wie sich Scrum im Laufe der Zeit weiterentwickelt hat,
- welches Fundament diese Entwicklung hat,
- wir wissen jetzt auch, dass sich Scrum die Grundwerte und Prinzipien mit der Agilität teilt,
- wir haben alle Bestandteile des Scrum 3-5-3 grundsätzlich kennengelernt,
- und können damit den Kern und die davon abgeleiteten Ziele von Scrum schon ganz gut erkennen,
- wir wissen nun, dass es Umsetzungstechniken gibt, auch wenn wir darauf erst in Verlauf der Kursreihe näher eingehen werden,
- und wir wissen jetzt natürlich, wie man einen Elefanten verspeist, bzw. wie man unüberschaubar große Aufgaben so aufteilt, dass sie umsetzbar werden,
- wir sind uns auch der 3 Säulen bewusst geworden, ohne die Scrum nicht funktionieren kann,
- wir haben die Unterschiede zwischen Kanban-Boards und Scrum Boards kennengelernt,
- und uns ist inzwischen hoffentlich klar, dass Scrum keine Wunder bewirken, aber scheinbar unüberwindbare Arbeit deutlich erleichtern kann.
In der überübernächsten Lektion beginnen wir mit dem Scaled Agile Framework ein etwas umfangreicheres Thema, das sich gut strukturiert über einige Lektionen verteilen wird. Doch zuvor gibt es für Dich wieder eine kleine, aber auch eine große Überraschung:
Die folgende Lektion beinhaltet ein kurzes Quiz, bei dem Du für Dich selbst prüfen kannst, welche Inhalte aus dieser Lektion bei Dir hängengeblieben sind. Gleich in der auf das Quiz folgenden Lektion erwartet Dich dann der erste Praxis-Test, in dem wir uns noch einmal mit den Lerninhalten aus allen bisher behandelten Lektionen beschäftigen. Im Praxis-Test können im Gegensatz zum Quiz auch mehrere bis alle Antworten zutreffen. Du hast für die Praxis-Tests immer mehr als ausreichend Zeit, so dass Du keinen Zeitdruck hast. Du kannst den Test auch beliebig oft wiederholen, bis Du das erforderliche Minimalziel von 80% erreicht hast. Genau diese intensive Beschäftigung mit dem Lerninhalt festigt Dein neu erworbenes Wissen. Ich wünsche Dir dabei viel Spaß, wir sehen uns nach dem Praxis-Test wieder!
