Scrum
Erscheinungsbild
	
	

Überblick
Was ist Scrum
- Scrum ist eine Methodologie bzw. ein Vorgehensmodell für die Entwicklung von Produkten
 - iterativer und inkrementeller Prozess
- für Produktentwicklung und Projektmanagement
 - oft und ursprünglich in der Softwareentwicklung
 
 - klassische Rollen und Strukturen werden ersetzt durch agile Methoden und Abläufe
 
Vorteile von Scrum
Wenn Scrum richtig angewandt wird, können sich folgende Vorteile ergeben:
- schnellere Reaktion auf Kundenanforderungen durch frühzeitige Rückmeldungen
 - schneller Richtungswechsel möglich
 - klares Scoping gemäß Wert für den Kunden
 - kleine Produkt-Inkrements (Releases) mit wenigen Features, die dann aber auch funktionieren
 - kein endloses Entwickeln (mit zu vielen Features)
 - Ergebnisse sind schneller am Markt / beim Kunden
 - höhere Identifikation der Beteiligten am Produkt
 - größere Kreativität, Effizienz und Produktivität (und damit auch die Mitarbeiterzufriedenheit)
 - bessere Produkte
 
Drei Rollen

Scrum kennt drei gleichberechtigte Management-Rollen:
- Product Owner
 - Scrum Master
 - Team
 
Eigenschaften von Scrum
- eingeteilt in Sprints (kurze zeitliche Projektabschnitte bzw. Arbeitszyklen) fester Länge
 - basiert oft auf Schätzungen (Zeit)
 - hohes Maß an Selbstorganisation (kein Teamleiter vorhanden)
 - Kundenzufriedenheit und Menschen stehen im Mittelpunkt (Vermeidung von Überlastungen)
 - Arbeitsweise und das Produkt werden fortlaufend bewertet und angepasst
 - Es werden nur Anforderungen umgesetzt, die einen Mehrwert bieten
 - Anforderungen mit höchster Priorität werden zuerst angegangen
 - Anforderungen mit den größten Risiken werden zuerst angegangen (um schnell andere Richtung einschlagen zu können)
 - Keine neuen Anforderungen oder Änderungen während des Sprints; diese werden ins Product Backlog eingetragen
 - Aufgaben/Features sind erst erledigt und werden "released", wenn wirklich alles fertig ist (auch Doku etc.)
 - Sprint-Ende wird niemals verlängert
 
Scrum erfordert
- große Disziplin
 - hohe Selbstverantwortung
 - direkte Kommunikation aller Beteiligten (möglichst räumlich nahe)
 - Umdenken bei allen Beteiligten bzgl. der Rollen
 
Organisation
- Sprint Planning Meeting (alle)
- Team wählt aus dem Product Backlog Anforderungen aus, die im Sprint umgesetzt werden sollen. Diese werden ins Sprint Backlog übernommen.
 
 - Daily Scrum Meeting (alle, Product Owner optional)
- Jedes Team-Mitglied berichtet über seine Aktivitäten der letzten Arbeitsstunden und über die nächsten Schritte. Hindernisse werden angesprochen.
 
 - Sprint Review Meeting (alle)
- Arbeitsergebnisse werden dem Product Owner vorgestellt und von diesem abgenommen.
 
 - Sprint Retrospektive Meeting (alle)
- Reflexion des Sprints
 - Was war gut bzw. schlecht ? Was kann verbessert werden ?
 
 - Product Backlog und Sprint Backlog als wichtige Mittel zur Dokumentation des Projekts
 
Rollen
Product Owner
- ist verantwortlich für das Produkt (Deliverables) bzw. Ergebnisse des Projekts
 - vereint die klassischen Rollen des Produktmanagers, Chief Engineers, Projektmanagers (aus Business-Sicht)
 - erstellt und pflegt Produktvision (Releaseplan, Big Picture)
 - ist verantwortlich für finanzielle Ergebnisse und wirtschaftliche Ziele (Budget, Marge)
 - Schnittstelle zwischen Team und Stakeholdern (Kunde, Vertrieb, Support, 3rd Party, etc.)
 - erstellt Requirements aus den Kundenanforderungen (im Product Backlog)
- in Zusammenarbeit mit dem Kunden
 - sortiert nach Priorität gemäß Wert für den Kunden (Business Value)
 - möglichst über den nächsten Sprint hinweg (im voraus)
 
 - erstellt User Stories (im Product Backlog)
- detaillierte Beschreibung dessen, was vom Team geliefert werden soll (Features)
 - aus Sicht des Kunden und anderer Stakeholder
 
 - prüft Ergebnisse des Teams am Ende des Sprints (Abnahme)
 - prüft Qualität
 - Eigenschaften: kommunikativ, diplomatisch, technisches Wissen
 
Team
- eigenverantwortlich für Produktentwicklung und technische Umsetzung
 - organisiert sich selbst (ohne Leader)
 - legt selbst verbindlich fest, welche und wieviele Anforderungen (Requirements) zu einer vorgegebenen Zeit (Sprint) bearbeitet und als User Stories umgesetzt werden (Commitment)
 - erstellt sich selbst Aufgaben (Tasks), um die Features (User Stories) umzusetzen
 - wähle kleine Tasks <= 1 Arbeitstag
 - dokumentiert Zustand der Tasks im Sprint Backlog (mit Angabe der noch benötigten Zeit)
 - Nicht die Zahl der Arbeitsstunden zählt sondern der geleistete Mehrwert
 - 80% der Arbeitszeit als Netto-Auslastung für das Projekt (Kapazität)
 
Scrum Master
- Agile Leader, Team-Coach, Moderator
 - nur in Teilen mit der klassischen Rolle des Projektmanagers vergleichbar (nur als Projektbegleiter), ist aber nicht der Projekt Manager
 - verantwortlich für Einhaltung der Scrum-Regeln und Methoden
 - verantwortlich für das Beseitigen von Hindernissen und Konflikten, die das Team am weiterentwickeln hindern
 - schafft optimale Arbeitsbedingungen für das Team (Infrastruktur, Kommunikation, Tools, etc.)
 - sollte kein Entwickler sein (höchstens in einem anderen Projekt), da er sonst nicht objektiv genug seine Rolle wahrnehmen kann
 - auch hat er keine Personalverantwortung für das Team
 - Bindeglied zwischen Product Owner und Team, aber letztendlich nicht verantwortlich für Projekterfolg
 - je besser das Team Scrum anwendet, desto geringer wird die Rolle des Scrum Masters
 
Artefakte und Ereignisse
Backlogs
Sprint Planning Meeting
- http://scrummethodology.com/scrum-meetings/
 - http://www.mountaingoatsoftware.com/agile/scrum/sprint-planning-meeting
 - http://www.scrum-institute.org/Introduction_to_Scrum_A_Real_World_Example.php
 
Planning
- There is no Planning in Agile. Right? (agile42.com)
 
Priorisierung
- Product Owner: Backlogs priorisieren mit Costs of Delay und Monte-Carlo-Simulationen (entwickler.de) - ökonomische Aspekte in Kombination mit Simulationen als Grundlage
 
Probleme und Schwierigkeiten
- Team soll eigentlich die Anforderungen (Requirements) mit höchster Priorität bearbeiten, was viel Disziplin erfordert
 - Product Owner muss viele Talente (Skills) haben: Bei komplexen Themen und großen Projekten ggf. ein Product Owner Team bilden
 - Neue Rolle für den klassischen Projektmanager bestimmen: Product Owner (Business, Budget, Customer, Controlling) oder Scrum Master (Agile Leader, Prozess, als Projektbegleiter)
 - Anpassung an Unternehmensstrukturen nötig
 - Es ist nicht immer einfach, Prioritäten bei vielen Stakeholdern zu bestimmen.
 - Beseitigung von Risiken und Hindernissen oft nicht in der Hand des Projekts (je weniger man abhängig ist von äußeren Einflüssen desto besser) -> externe Abhängigkeiten
 - Alle am Produkt beteiligten müssen Scrum verstehen und daran beteiligt sein
 - Das Scoping im Team muss mit den Kundenwünschen übereinstimmen, was über die Priorität gesteuert wird. Das muss dem Kunden aber auch so "verkauft" worden sein.
 - da Product Owner und Scrum Master nicht notwendigerweise Mitglied des Entwicklungsteams sein sollen, sind mindestens 4-5 Personen pro Scrum-Projekt nötig.
 - Je größer das Projekt ist und je mehr Entwicklungsprojekte involviert sind, desto umfassender müssen die Anpassungen im Unternehmen sein (Enterprise Scrum).
 - Das Team soll die für die Entwicklung nötigen Tools selbst aussuchen können. Je nach Projekt sind verschiedene Tools nötig, die ggf. im Unternehmen nicht "unterstützt" werden. Beispiel: Revision Control Systeme.
 - Wie werden Change Requests bearbeitet ? -> Abbildung in die Scrum Methodik
 
Zertifizierung
Siehe Über uns.
Siehe meine Blog-Beiträge:
Literatur / weitere Infos
- Scrum in der Wikipedia, en
 - Agile Softwareentwicklung in der Wikipedia
 - Scrum Alliance
 - Scrum.org
 - Scrum Methodology
 - Scrum Guides
 - DasScrumTeam (Training und Infos)
 - UserStories.com
 - The Scrum Reference Card
 - Introduction of Scrum Agile Process - Development (mountaingoatsoftware.com)
 - Agile Modeling
 - inside-scrum Blog (de)
 - Agile FAQ Blog
 - Agile24 (Agilo for Scrum)
 - scrum-kompakt.de
 - Kriterien für eine Entscheidung für Scrum oder Kanban (heise.de)
 - Scrum - Agiles Projektmanagement erfolgreich einsetzen, dpunkt.verlag; ISBN: 3898644782, Amazon
 - Das Agile Adventure – Infografik
 - extremeuncertainty.com [1],[2]
 
- Kombination von Agil und Lean in der Softwareentwicklung (Scrum und Kanban), Informatik Spektrum 01/2014 S.28
 - Five books every ScrumMaster should read
 - Geschichten von Scrum, dpunkt Verlag, siehe c't 09/14 S.188
 - iX Dossier: Agiles IT-Projektmanagement - Wie man IT-Projekte erfolgreich abschließt
 - Mit Secure Scrum sichere Software entwickeln - Vorschlag für eine auf Sicherheit fokussierte agile Entwicklung
 - Produkt-Planung mit Produkt-Roadmap und Produkt-Backlog – das sind die Unterschiede (entwickler.de)
 - There is no Planning in Agile. Right? (agile42.com)
 - The 2015 State of Scrum Report (scrumalliance.org), siehe auch entwickler.de
 - Schöner scheitern mit Agile (entwickler.de)
 - Warum ist mein agiles Team langsam? (entwickler.de): Teil 1, Teil 2
 - Der perfekte Scrum Master – das unbekannte Wesen? (entwickler.de)
 
- User Story Mapping, O'Reilly
 - User Stories Applied
 - Splitting user stories -- the hamburger method
 - How we’ve destroyed user stories
 - Replacing The User Story With The Job Story
 
- Scum und Kanban
- siehe LM 12/13 S.24
 - Scrum vs. Kanban – Teil 1: Scrum (entwickler.de)
 - Scrum vs. Kanban – Teil 2: Kanban (entwickler.de)
 
 - Do Better Scrum - Booklet mit Tipps und Einsichten zu Scrum, EN-Version
 - Selbstorganisierte Teams führen, dpunkt Verlag
 
- Definition of Done
- Die Details der Definition of Done (entwickler.de)
 
 
Videos
Quellenangaben
- Bild "Der Scrum Prozess": Quelle Wikipedia, CC-Lizenz
 
Siehe auch
- mehr Links zu Scrum (en)
 - Agilo for Scrum (en)
 - Kanban