11. Projekte sind nicht „statisch“.
Business Features stehen im Vordergrund
Kontinuierliches Prüfen und Anpassen
Kurze Iterationen - Inkrementelles Liefern
Teamarbeit
12. Gefahren sollte man nicht „ignorieren“.
weit weg
vor Einigung
Anforderungen
kurz
vor Einigung
Lösung
vor Klarheit
weit entfernt
Klarheit
nahe an
20. Scrum ist nicht neu.
Microsoft Intuit
Yahoo Nielsen Media
Google First American Real Estate
Electronic Arts BMC Software
High Moon Studios Ipswitch
Philips Lexis Nexis
Siemens Sabre
Nokia Salesforce.com
Capital One Time Warner
BBC Turner Broadcasting
Intuit Allianz Deutschland
SAP …
21. Scrum.
Scrum fördert die Selbstorganisation/-verantwortung.
Lösungen werden in enger Zusammenarbeit und in
regelmässigen, kurzen Zyklen realisiert. Dadurch
wird ein dynamisches, agiles Umfeld geschaffen.
22. Agile Software Entwicklung.
Agile Entwicklung
unterstützt das
zyklische Vorgehen
von Scrum.
Projekte werden in
Arbeitspakete
aufgeteilt, damit
Erfolgsrisiken
schnell erkannt und adressiert werden können.
Transparenz und Nachvollziehbarkeit stehen im
Vordergrund.
23. Werte von Scrum/Agile Entwicklung.
sind
wichtiger
als
ist
wichtiger
als
ist
wichtiger
als
ist
wichtiger
als
26. Verbindlichkeit.
Typisches Szenario:
Projektleiter: Jungs, ihr habt mir gesagt, es dauert
2 Wochen.
Entwickler: Ja, aber das war nur eine Schätzung.
Projektleiter: Nun sagst Du mir, dass es noch 2
weitere Tage dauert? Ich dachte ich
könnte auf Euch zählen. Ich will,
dass es nun in 2 Wochen erledigt wird.
Schätzungen werden „verbindlich“!
27. Fertig.
Weiteres typisches Szenario:
Entwickler: Ich bin fertig!
Projektleiter: Schick mir den Link.
Entwickler: Ich muss es zuerst noch installieren.
…und so geht es weiter.
Definiere „erledigt“!
31. Produkt Owner.
Erfasst und priorisiert Produkt Features
Bestimmt Umfang und Termin
Ist verantwortlich für das finanzielle Ergebnis (ROI)
Akzeptiert oder weist Arbeitsergebnisse zurück
32. Scrum Master.
Vertritt das Management gegenüber dem Team
Schützt das Team vor äußeren Störungen
Unterstützt die enge Zusammenarbeit und
Kommunikation zwischen allen Beteiligten
Stellt sicher, dass das Team funktioniert und
produktiv ist
Verantwortlich für die Einhaltung der Scrum Werte
33. Team.
Besteht üblicherweise aus 5-9 Vollzeitmitglieder
Deckt alle notwendigen Disziplinen ab
Team organisiert sich selbst
Mitglieder bleiben während des gesamten Sprints
35. Sprint Planung (Scrum Master).
Vor jedem Sprint, 60 Minuten
Sprint Priorisierung (Produkt Backlog)
Produkt Backlog analysieren und auswerten
Sprint Ziel festlegen
Sprint Planung (Sprint Backlog)
Sprint Backlog aus Produkt Backlog erstellen
Sprint Backlog in Stunden schätzen
Entscheiden, wie man das Sprint Ziel erreichen kann
36. „Velocity“ als Sprint Planungswert.
Vor dem Sprint Nach dem Sprint
Produkt Sprint Sprint
Backlog Backlog Backlog
8 8 Erledigt! 8
Echte
5 5 Erledigt! 5 ”Velocity”
5 5 Erledigt! 5
3 Geschätzte 3 Teilweise Erledigt. 3
5 ”Velocity” 5 Nicht gestartet. 5
5
8
5
3
5
37. Sprint Review (Scrum Master).
Nach jedem Sprint, 30-60 Minuten
Jeder darf/soll teilnehmen
Das Team präsentiert, was es während des Sprints
erreicht hat
Max. 2 Stunden Vorbereitungszeit
Informell
Keine Folien
In Form einer Demo
38. Sprint Retrospektive (Scrum Master).
Nach jedem Sprint, 15-30 Minuten
Das ganze Team darf teilnehmen, evtl. sogar der
Kunde
Was lief gut? Was lief nicht gut?
Aufhören mit…
Weitermachen mit… Diese ist eine
Beginnen mit… von vielen
Methoden
um Retrospektiven
durchzuführen.
39. Tägliches Scrum (Scrum Master).
Täglich, 15 Minuten, Stand-Up
Team Mitglieder wählen Tasks aus oder verändern
diese, sobald weitere Kenntnisse geschaffen wurde
Keine Problemlösungsdiskussionen
3 Fragen an jedes Team Mitglied:
Was hast du gestern getan?
Was wirst du heute tun?
Welche Hindernisse stehen dir im Weg?
41. Produkt Backlog (Produkt Owner).
Eine Liste aller gewünschten Features,
Anforderungen, Wünsche und sogar Ideen
Das Sammeln/Dokumentieren von Requests erfolgt
ununterbrochen
Idealerweise soll jeder Eintrag „wertvoll“ für den
Anwender/Kunde der Lösung sein
Vom Produkt Owner fortlaufend (re)priorisiert
42. Beispiel „Produkt Backlog“.
Backlog Item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
As a hotel employee, I can run RevPAR reports
8
(revenue-per-available-room)
Improve exception handling 8
... 30
... 50
43. Sprint Backlog (Scrum Master).
Die Liste aller Aufgaben, welche für die Erfüllung
aller gemeinsam vereinbarten Features erforderlich
sind
Die Anzahl Features werden während eines Sprints
nie modifiziert, lediglich die Aufgaben können sich
verändern
Deshalb vom Scrum Master koordiniert und nur vom
Team täglich unterhalten
44. Beispiel „Sprint Backlog“.
Backlog Item Estimate
Allow a guest to make a reservation 3
... …
Tasks Mo Di Mi Do Fr
Code the user interface 8 4 8
Code the middle tier 16 12 10 4
Test the middle tier 8 16 16 11 8
Write online help 12
Write the foo class 8 8 8 8 8
Add error logging 8 4
45. Burndown Chart.
Grafische Visualisierung des Fortschritts dank
transpartentem geschätzten Restaufwand
Hilfsmittel zur Identifikation von Terminprobleme
Gibt Aufschluss über die „Velocity"
Wird fortlaufend nachgeführt/aktualisiert
Sprint Burndown Chart: täglich durch
Scrum Master
Produkt Burndown Chart: nach jedem Sprint durch Produkt
Owner
46. Beispiel „Sprint Burndown Chart“.
Tasks Mo Di Mi Do Fr
Code the user interface 8 4 8
Code the middle tier
50 16 12 10 4
Test the middle tier 8 16 16 11 8
40
Write online help 12
Stunden
30
Write the foo class 8 8 8 8 8
20
Add error logging 8 4
10
0
Mo Di Mi Do Fr
47. Beispiel „Produkt Burndown Chart“.
Backlog Item Estimate
Allow a guest to make a reservation 3
As a guest, I want to cancel a reservation. 5
As a guest, I want to change the dates of a
3
reservation.
Stunden
As a hotel employee, I can run RevPAR reports
8
(revenue-per-available-room)
Improve exception handling 8
... 30
... 50
49. Voraussetzungen schaffen.
Offen für Neues, denn Scrum stellt teilweise
bisherige Grundsätze komplett auf den Kopf
Die Mitarbeiter dürfen nicht versuchen ein
„Wasserfall Modell“ mit einem „agilen Vorgehen“ zu
vergleichen
Das Management ist verantwortlich, dass das
Umfeld (Ökosystem) für ein agiles Arbeiten
geschaffen wird
Der Kunde muss akzeptieren, dass Zeit, Umfang
und Budget nicht immer im voraus „fixiert“ werden
können
50. Transition kontrolliert angehen.
Scrum ist nicht immer Scrum, denn eine individuelle
Adaption ist unbedingt erforderlich (Kunden,
Projekte, Mitarbeiter, Hilfsmittel etc.)
Erstellen eines kompletten „Transition Plan“ in die
Scrum/Agile Zielorganisation und –methodik
Genügend qualifiziertes Fachpersonal innerhalb der
Teams sicherstellen, bevor mit der Transition
gestartet wird (Ausbildung/Rekrutierung/Consulting)
Adaptieren der Prozesse, Tools und Dokumente mit
der Unterstützung und Teilnahme der jeweiligen
Teams
51. Kollaborationsplattform als Basis.
Um Scrum mit agiler Entwicklung gerecht zu werden,
setzen wir eine Kollaborationsplattform ein, sodass
Kunde, Projektleiter, Mitarbeiter und Betrieb stets auf
dem selben Informationenstand sind.
Berechtigungen. Projekte. WebDAV. Ticketing.
Change Requests. Workflows.
Defects.
55. Vor- und Nachteile.
Kleinere und mehrere Auslieferungen (Teilprojekte/
und –lösungen) anstelle einer grossen Auslieferung
am Ende des Projektes (“Big Bang”)
Klare und offene Kommunikation dank direktem
Kontakt zwischen allen Beteiligten (inkl. Kunde)
Früherkennung von Gefahren und Risiken mittels
regelmässigen und frühzeitigen Feedbacks
Höhere Zufriedenheit seitens Kunde, da auf
geschäftskritische und –relevante Features
fokussiert wird (ROI)
Grössere Motivation seitens Mitarbeiter weil
Delivery Risiko auf das ganze Team verteilt ist
56. SEO
Fazit.
Scrum ist ein agiler Prozess, der es erlaubt auf die
Auslieferung der wichtigsten Anforderungen in
regelmäßigen Abschnitten (2-4 Wochen) tatsächlich
lauffähige Software zu liefern.
Der Kunde setzt die Prioritäten. Die sich selbst
organisierenden Entwicklungsteams legen das
beste Vorgehen zur Auslieferung der höchstprioren
Features fest.
Alle zwei bis vier Wochen kann jeder lauffähige
Software sehen und entscheiden, diese so
auszuliefern oder in einem weiteren Abschnitt zu
ergänzen.