1. Einleitung 2. Persönliche Vorstellung 3. Scrum in der Praxis 4. Scrum Grundlagen 5. Erfolgsfaktoren für Scrum 6. Ergebnisse durch Scrum

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

2. 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

3. Ein paar Fragen…
Bild: flickr.com

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

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

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

7. Scrum in der Praxis

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

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

10. Bild: Standish Group

11. Bild: Standish Group

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

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

14. Scrum Grundlagen

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

16. 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.

17. Prozessrahmenwerk für komplexe Produkte.

18. Kein Prozess oder Technik zur Erstellung von
Produkten.

19. Rahmenwerk für verschiedene Prozesse und
Techniken.

20. Scrum sorgt für Transparenz.

21. Scrum zeigt auf, was verbessert werden kann.

22. 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

23. Scrum: Vom Product Backlog zum fertigen Produkt

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

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

26. Scrum Ereignisse Scrum ArtefakteScrum Rollen

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

28. 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

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

30. 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

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

32. Scrum Rollen Scrum ArtefakteScrum Ereignisse

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

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

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

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

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

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

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

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

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

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

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

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

45. Sprint Retrospektive
Ergebnis
• Maßnahmen zurVerbesserung

46. Scrum Rollen Scrum Ereignisse Scrum Artefakte

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

48. 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.

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

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

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

52. 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

53. 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

54. 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

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

56. 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

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

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

59. Beispiel: Sprint Burndown Chart

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

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

62. Voraussetzungen und Ergebnisse

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

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

65. Fragen?
Bild: flickr.com

66. Vielen Dank für Ihre Aufmerksamkeit