a presentation about scrum. We start looking at the roots of software-engineering and discuss the problems with traditional models like the waterfall-model and show the development of agile methods like scrum

1. Scrum
Janne Berngruber, Ralf Ohlenbostel, Stephan Wirries
1

2. Agenda
• Probleme beim Software-Development
• Paradigmenwechsel hin zur Agilität
• SCRUM
• Geschichte
• Rollen
• Prozesse
2

3. Probleme
bei der Software Entwicklung
3

4. Traditionelles Engineering
• Phasenweise Entwicklung
• Erwartete Ziele
• Im Voraus stark geplant
4

5. Traditionelles Engineering
frühes festlegen der Anforderungen Unflexibilität bei Änderungen
technische Hürden werden zu spät erkannt hoher Zeit / Kostenfaktor
„Big Bang Test“ geringer Einfluß des Kunden
5

6. Engineering
• definierte Prozesse
• intensive Dokumentation
• Konformität
6

7. Software Engineering
Peter Naur 1968 NATO
Konferenz:
„The phrase software engineering was chosen...
implying the need for software manufacture to be
based of foundations, that are traditional in the
established branches of engineering„
7

8. Paradigmenwechsel
Organisation durch
Befehls-und informationsbasierende
Abteilungen und
Kontrollorganisationen Organisationen
Geschäftsbereiche
Zeit
8

9. C3 Projekt
Chrysler Comprehensive Compensation
9

10. C3 Projekt
Martin Fowler Kent Beck
berät Chrysler rebootet das
Projekt mit XP
Entwicklung des C3
Projektes beginnt C3 Live
1993 1995 1996 1997
10

11. Standish Group
„Das Chaos Manifesto ist die Summe von 15 Jahren Arbeit
über Projektfehlschläge auf 48 Seiten“
11

12. Untersuchte Projekte
erfolgreich
29%
starke Projektänderungen
53%
Fehlschläge
18%
Standish Report 2004
starke Projektänderungen Fehlschläge erfolgreich
12

13. Standish Group - Umfrage
16
12
8 16
14 13
10
4 8
0
Erfolgsfaktoren bei IT-Projekten
Einbeziehen der User Unterstützung durch das Management Klare Anforderungen
Richtige Planung Realistische Erwartungen
13

14. Kostenüberschreitung IT-Projekte
21-50%
16%
32%
4%
9%
10%
30%
Unter 20% 21-50% 51-100% 101-200%
201-400% über 400%
14

15. Zeitüberschreitung IT-Projekte
20%
101-200%
36%
18%
11%
14% 1%
Unter 20% 21-50% 51-100% 101-200%
201-400% über 400%
15

16. Zusammengefasst
• nur 35 % der Projekte sind erfolgreich
• starke Kosten und Zeitüberschreitungen
• Erfolgsfaktoren essentiell:
•realistische Ziele
•klare Anforderungen
•Einbeziehen der User
16

17. Agiles Manifest
2001
Fowler Cockburn Beck Schwaber Sutherland
17

18. Agiles Manifest
Individuen &
Prozesse und Werkzeuge
Interaktion
funktionierende Software ausführliche Dokumentation
Zusammenarbeit mit Kunden Verhandlungen von Verträgen
Reagieren auf Änderungen Plan befolgen
18

19. Agile Prinzipien
iteratives entwickeln
19

20. Agile Prinzipien
Klasse XY erstellen
Listen abarbeiten
Feature Z bauen
stetig liefern
Methode AZ erstellen
20

21. Agile Prinzipien
Nur ein Feature
zur Zeit entwickeln
21

22. Agile Prinzipien
Den Kunden befriedigen
22

23. Agile Prinzipien
Abteilungsübergreifende
selbstorganisierende Teams
23

24. Agile Prinzipien
Face-to-Face Kommunikation
24

25. Agile Prinzipien
Menschen motivieren
25

26. Agile Prinzipien
Laufende Software als
Primäreinheit für den Erfolg
26

27. SCRUM
27

28. Scrum
Herkunft: Rugby
Neustart nach einem Foul
Bedeutung: Gedränge
28

29. Geschichte von Scrum
Jeff Sutherland Erstes offizielles OOPSLA 95
setzt „Scrum“ Scrumprojekt
erstmals bei GPA Konferenzbeitrag
ein Easel Corp. über Scrum von
Ken Schwaber
Agile Manifest
Gründung „Agile
Alliance“
Scrum Buch
1990-93 1993-94 1995 2001
„Scrum akzeptiert, dass der Entwicklungsprozess
unvorhersehbar ist...“
29

30. Wo man Scrum einsetzen kann
Neue & Festgefahrene Projekte
30

31. Ziele
Komplexität, Unverhergesehenes
beherrschbar machen
Flexible Änderungen durch stetige
Reflektion
Wettbewerbsvorteil durch
Flexibilität
31

32. Scrum Grundwerte
Commitment
Focus
Openness
Respect
Courage
32

33. Scrum Rollen
33

34. ScrumTeam
Product Owner
Scrum Master
Organisation (Kunde)
34

35. Wir haben tolle Ideen!
und mehr nicht...
Wir wollen Software die
funktioniert!
Organisation
(Kunde)
Wir wollen in 3 Monate
ein Redesign!
35

36. Wir wollen in 3 Monate
ein Redesign!
Product Owner
Wir haben tolle Ideen!
VISION
und mehr nicht...
Wir wollen Software die
funktioniert!
36

37. VISION
Product Owner ScrumTeam
37

38. Product Owner
Vision entwickeln
Festlegen der Produkteigenschaften
Team motivieren
Priorisierung der Backlogitems
Releaseplan bestimmen
ROI sichern
Verantwortung für das Projekt
38

39. Das Team
Lieferant des Produkts
Bereichsübergreifend (Entwickler, Designer..)
Definiert Aufgaben
Managed sich selbst
Steuert die Arbeitsmenge
Ist verantwortlich für die Qualität
39

40. Scrum Master
Unterstützende Führung
Behebt Probleme
40

41. Der Scrum Prozess
41

42. Product Backlog
42
picture by juhansonin

43. Product Backlog
Product Owner priorisiert
Keine Anforderungen
Nicht vollständig, nicht perfekt
Im Laufe des Prozesses weiterentwickelt
43

44. Product Backlog
44
picture by juhansonin

45. Product Backlog
priority item # description estimated by
very high
1 Datenbankverbindung erstellen 2 SW
2 Wildcards bei der Suche unterstützen 4 RO
3 Jquery einbauen 1 JB
4 Html5 Geolocator einbauen 3 SW
high
5 Grafiken optimieren 1 RO
6 User Registrationssystem erstellen 4 JB
45

46. Product Backlog
priority item # description estimated by
very high
1 Datenbankverbindung erstellen 2 SW
Priorisierung nach Wertigkeit und Risiko
2 Schätzwerte
Wildcards bei der Suche unterstützen 4 RO
3 Jquery einbauen 1 JB
4 Html5 Geolocator einbauen 3 SW
Userstories
high
5 Grafiken optimieren 1 RO
Öffentlich einsehbar
6 User Registrationssystem erstellen 4 JB
46

47. User Stories
(Als <user> möchte ich <Funktionalität>,
so dass <Nutzen>)
Als Mitglied möchte ich mein Profil einstellen,
so dass andere Mitglieder mich finden
können.
47

48. Time-Boxing
Kleine Entwicklungszyklen
Zeitlich gleich bleibend
Nur die wichtigsten Informationen
Keine Anpassung der Zyklen (zeitlich)
48

49. Sprints
Timeboxed – Festgelegte Features
Variabler Umfang – Liefert Ergebnis 49

50. Sprint Planning
Welche Backlog Items?
Team entscheidet
Sprint Goal = fertiger Teil der Software
50

51. Sprint Planning Meeting 1
Product Owner stellt Vision vor
Sprint Goal
Sprint Backlog Items bestimmen
Ergebnis präsentieren
51

52. Sprint Planning Meeting 2
Teamsitzung
Detailierte Planbesprechung
Sprint Backlog
Abstimmungsbedarf?
52

53. Sprint Backlog
53

54. Sprint Backlog
Requirement Task Who Status Work left
Day 1 Day 2 Day 3 Day 4
Database Coding JB Done 1 0 0
Unit Testing JB Done 2 0 0
Member Sign In Business Logic JB Done 2 2 0
Front End Screens RO Done 2 2 0
Ui Testscripts SW Done 2 2 1
Unit Testing SW Done 1 1 0
Business Logic RO Done 2 0 0
Reset Password
Ui Testscripts RO Done 2 2 1
Front End Screens JB Pending 1 1 1
Work remaining 15 10 3
54

55. Daily Scrum
Täglich
Selber Ort
Gleiche Zeit
55

56. Daily Scrum
Was habe ich seit dem letzten Daily Scrum gemacht?
Was will ich bis zum nächsten daily Scrum machen?
Welche Hindernisse sind mir dabei im Weg?
56

57. Task Board
57

58. Sprint Burn Down
Chart für Sprint 1
Points Expected Points Left
20
15
10
5
0
1.10.09 2.10.09 3.10.09 4.10.09 5.10.09 6.10.09 07.10.09 08.10.09
58

59. Sprint Review
Sprint Goal erreicht?
Feedback
Kommunikation
59

60. Sprint Review
Neue Funktionalitäten
Nicht geschaffte Backlog Items neu
einordnen
Veränderung der Priorisierung
60

61. Sprint Retrospective
Was lief gut?
Was lief schlecht?
Was soll übernommen werden?
61

62. Sprint Retrospective
62

63. Burn Down Chart
Features remaining Scope Target
100
75
50
Aufgabenbereichs-
25 wechsel
0
-25
-50
1.10.09 8.10.09 16.10.09 24.10.09 30.10.09 5.11.09 11.11.09 19.11.09
63

64. Release Planung
Planung von Features in Sprints und Releases
Releases hängen von den akzeptierten Sprints ab
picture by Sviluppo Agile 64

65. Release Sprints
• Usability testing
• Dokumentation
• Hilfe Dateien
• Packaging
65

66. Sprint Termination
• Nur in Ausnahmefällen
• Team Abbruch: Kann Sprint Ziele nicht
erreichen
• Product Owner Abbruch: Prioritätenwandel
• Arbeit fällt zum Ende des vorherigen
Sprints zurück
• Erhöht die Sichtbarkeit von Problemen
66

67. Sprints
•Durch den Product Owner angetrieben
•Kleine rückführbare Schritte
•Change Kultur
•Funktionsübergreifende Teams
•Beinhalten Design und Testing
•Beibehalten einer konstanten Geschwindigkeit
•Gemeinsame Hingabe
•Hohe Qualität
•Feedback bekommen
•Schnelles Scheitern
67

68. Results
effects of applying scrum
68

69. Risiken managen
Rolling wave Planung
Simple mini Projekte senken Risiken
69

70. Flexible Aufgabenstellung
Erlaubt Änderungen in fixen Intervallen
Releases ermöglichen lernen
70

71. Schnellere Lieferung
kürzere “time to market”
Der Wert wird inkrementell geliefert
71

72. Höhere Qualität
Kontinuierliches Testen
Eingebaute Prozessverbesserung
72

73. Entfernen von Überflüssigem
Es wird nichts designed das nicht gebaut wird
Es wird nichts gebaut das nicht genutzt wird
73

74. Erhöhte Sichtbarkeit
Alle Probleme sind sichtbar
Fortschritt ist die laufende, getestete Software
74

75. Mehr Spaß, Glückliche Teams
75

76. Vorbedingungen
76

77. Vorbedingungen
Empowerment
Disziplin
Courage
Ausdauer
Passion
Coaching
Stabile Teams
Funktionsübergreifend
Verfügbare Kunden
77

78. Bücher
78

79. Webseiten
www.scrumalliance.org
www.controlchaos.com
www.mountaingoatsoftware.com
www.jeffsutherland.com
www.implementingscrum.com
www.agilesoftwaredevelopment.com
www.noop.nl
79