Scrum als agilesVorgehensmodell für Programmierer
Tobias Schlüter Mayflower GmbH

Der rote Faden
1. Einleitung
2. PersönlicheVorstellung
3. Scrum in der Praxis
4. Scrum Grundlagen
5. Erfolgsfaktoren für Scrum
6. Ergebnisse durch Scrum
7. Fragen?
8. Ihr Feedback
Bild: flickr.com

Ein paar Fragen…
Bild: flickr.com

Wer kennt das Wasserfallmodell, bzw. dasV-Modell?
Bilder: de.wikipedia.org

Wer kennt Scrum oder andere agileVorgehensweisen?
Quelle: www.allthings.io

GmbH
tobias.schlueter@mayflower.de
8++ Jahre Projekterfahrung in der agilen Softwareentwicklung
4++ Jahre Agiler Coach / Certified Scrum Master
Tobias Schlüter

Scrum in der Praxis

Wie es der Kunde erklärte...
Bild: Quelle unbekannt

The Chaos Report
• Studie der Standish Group: Agil vs Waterfall
• Über 10.000 Projekte in der Auswertung (2011-2015)

Bild: Standish Group

Bild: Standish Group

Fazit der Studie
Agil ist erfolgreicher bei
kleinen, mittleren und großen
Projekten.
Warum?

Projekt-Einordnung nach Komplexität
Bild: http://iq3group.blogspot.de/2012/12/solving-data-governance-by-scaling.html

Scrum Grundlagen

Zielsetzung
Scrum ist ein Rahmenwerk zur
Entwicklung und Erhaltung komplexer
Produkte.
Bild: flickr.com

Definition
Scrum:
Ein Rahmenwerk, innerhalb dessen Menschen komplexe
adaptive Aufgabenstellungen angehen können, und durch das sie
in die Lage versetzt werden, produktiv und kreativ Produkte
mit dem höchstmöglichen Wert auszuliefern.

Prozessrahmenwerk für komplexe Produkte.

Kein Prozess oder Technik zur Erstellung von
Produkten.

Rahmenwerk für verschiedene Prozesse und
Techniken.

Scrum sorgt für Transparenz.

Scrum zeigt auf, was verbessert werden kann.

AGILE MANIFESTO
We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Twelve Principles of Agile Software
Our highest priority is to satisfy the customer
through early and continuous delivery of
valuable software.
Welcome changing requirements, even late in
development. Agile processes harness change for
the customer's competitive advantage.
Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work
together daily throughout the project.
Build projects around motivated individuals.
Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of
conveying information to and within a
development team is face-to-face conversation.
Working software is the primary measure of
progress.
Agile processes promote sustainable
development. The sponsors, developers, and
users should be able to maintain a constant pace
indefinitely.
Continuous attention to technical excellence and
good design enhances agility.
Simplicity – the art of maximizing the amount
of work not done – is essential.
The best architectures, requirements, and
designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to
become more effective, then tunes and adjusts its
behavior accordingly.
http://agilemanifesto.org
Image©2009FractalKen
Agile Manifesto

Scrum: Vom Product Backlog zum fertigen Produkt

Das Scrum Team
• Product Owner
• Entwicklungsteam
(3-9 Mitglieder)
• Scrum Master
Bild: flickr.com

Das Scrum Team
• Liefert iterativ
• Liefert inkrementell
• Maximiert Gelegenheit für
Feedback
Bild: flickr.com

Scrum Ereignisse Scrum ArtefakteScrum Rollen

Product Owner
Zuständig für
• Wertmaximierung des Produkts
• Arbeit des Entwicklungsteams
Eine Person (kein Komitee)
Bild: flickr.com

Product Owner
Erfolgsfaktoren
• Akzeptanz in der gesamten
Organisation
• Entscheidungen werden
respektiert
• Bestimmt Inhalt und Reihenfolge
des Product Backlogs
• Der Product Owner allein
versorgt das Entwicklungsteam
mit Arbeit
Bild: flickr.com

Entwicklerteam
• 3-9 Mitglieder (ohne PO u. SM)
• Profis
• Selbstorganisiert
• Liefern ein fertiges Produkt
Inkrement am Ende jedes Sprints
Bild: flickr.com

Scrum Master
• Verantwortlich fürVerständnis und
Durchführung von Scrum
• Vermittelt Theorie, Praktiken und
Regeln von Scrum
• Servant Leader für das Scrum
Team

Rollen Zusammenfassung Product Owner, Entwicklerteam, Scrum Master
Bild: Henrik Kniberg

Scrum Rollen Scrum ArtefakteScrum Ereignisse

Scrum Ereignisse
• Ermöglichen Transparenz und Überprüfungen kritischen
Stellen
• Erfassen den Ist-Stand, um darauf reagieren zu können
(Inspect & Adapt)

Scrum Ereignisse
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospektive
• Sprint als "Container"

Sprint
• Länge: 2-4 Wochen
• Kann als Projekt mit festem Zeithorizont gesehen werden
• Definiertes Ziel
• Dient zur Entwicklung eines potentiell auslieferbaren
Produktinkrements

Sprint
Während des Sprints
• Keine Änderungen (Fokus auf Sprint Ziel)
• Qualitätssicherung
• Fester Anforderungsumfang, aber...

Sprint Planning
Klärt
Umfang des Produkt Inkrements des kommenden Sprints.
- Was -
Erforderliche Arbeit durch das Entwicklungsteam.
- Wie -
Beispiel
Features in Form von Userstories

Sprint Planning
Ziel
Das Entwicklungsteam kann dem PO schildern, wie es das Ziel
erreichen möchte.

Sprint Planning
Ergebnis
Sprint Backlog
== Ausgewählte Product Backlog-Einträge

Daily Scrum
Täglich
15 Minuten timeboxed
Quelle: wikipedia.org

Daily Scrum
Entwicklungsteam
synchronisiert Arbeiten
Sprint Ziel im Fokus
Quelle: wikipedia.org

Daily Scrum
Jeder beantwortet die Fragen
• Was habe ich gestern erreicht?
• Was werde ich heute erledigen?
• Gibt es Hindernisse (Impediments)?

Sprint Review
• Überprüfung des Produkt Inkrements
• Demonstration der Ergebnisse des Sprints
• Vorführung als Anregung für Feedback
• Basis für die Zusammenarbeit

Sprint Retrospektive
Selbstreflexion
• Was lief gut?
• Was lief nicht so gut?
• Wie können wir uns verbessern?

Sprint Retrospektive
Ergebnis
• Maßnahmen zurVerbesserung

Scrum Rollen Scrum Ereignisse Scrum Artefakte

Scrum Artefakte
• Product Backlog
• Sprint Backlog
• Fortschrittskontrolle
• Inkrement
Bild: flickr.com

Product Backlog
• Geordnete Liste von allem, was das im Produkt enthalten
sein kann.
• Einzige Anforderungsquelle für Änderungen am Produkt.
• Entwickelt sich mit dem Produkt und dessen Einsatz weiter.

Product Backlog
Liste aller
• Features
• Funktionalitäten
• Verbesserungen
• Fehlerbehebungen

Product Backlog
Attribute eines Backlog-Eintrags
• Reihenfolge
• Beschreibung
• Schätzung
• Wert

Product Backlog
Refinement
• Verfeinerung des Product Backlogs
• Anpassung der Einträge
• Erstellung von Schätzungen
• Gemeinsam mit Product Owner und Entwicklungsteam

Product Backlog
• Höher angeordnete Einträge:
• Mehr Details
• Präzisere Schätzungen
• Auf Basis von Klarheit und Detailtiefe
• Je niedriger der Rang, desto weniger Details

Product Backlog
• Einträge werden verfeinert, bis sie verstanden wurden.
("Ready")
• "Ready"-Einträge als Basis für Sprint Backlog
(Sprint Planning)
Quelle: rockstart.com

Fortschrittskontrolle in Richtung des Ziels
• Überprüfung durch den Product Owner spätestens im Sprint
Review
• Summe der verbleibenden Arbeiten ist messbar
• Basis für Prognosen

Beispiel: Release Burndown Cart
Quelle: agilewarrior.wordpress.com

Sprint Backlog
• Auswahl von Product Backlog-Einträgen
• Plan für die Lieferung des Produkt-Inkrements zur Erfüllung
des Sprint-Ziels
Quelle: rockstart.com

Sprint Backlog
• Prognose des Entwicklungsteams für das kommende
Inkrement
• Arbeit des Entwicklungsteams innerhalb eines Sprints
Quelle: rockstart.com

Überwachung des Sprint-Fortschritts
• Überprüfung des Sprint-Fortschritts im Daily Scrum
• Bewusstsein über die Wahrscheinlichkeit, das Sprint-Ziel zu
erreichen

Beispiel: Sprint Burndown Chart

Inkrement
• Ergebnis aller im Sprint fertiggestellten Product-Backlog
Einträge
• Ergänzt das Resultat aller früheren Sprints

Inkrement
• Verwendbarer Zustand (Done/Abgenommen durch PO)
• Einsatzfähig (, da getestet)
• Auslieferbar, wenn der Product Owner es will

Voraussetzungen und Ergebnisse

Erfolgsfaktoren
• Selbstorganisierte Teams
• Offenheit
• Coaching
• Stabiles, cross-funktionales Team
• Verfügbarer Kunde
Bild: flickr.com

Ergebnisse
• Schnelle Lieferung nach jedem
Sprint
• Höhere Qualität
• Flexibler Scope
• Unsicherheiten meistern
• Verschwendung (Waste)
eliminieren
• Transparenz
Bild: flickr.com

Fragen?
Bild: flickr.com

Vielen Dank für Ihre Aufmerksamkeit