Das Dokument behandelt die Anwendung von Scrum und agiler Softwareentwicklung zur Erfolgssteigerung in IT-Projekten, die häufig scheitern, weil sie dynamisch sind und kontinuierlich Anpassungen erfordern. Es werden die Prinzipien und Werte von Scrum vorgestellt, darunter die Selbstorganisation des Teams, kurze Iterationen und enge Zusammenarbeit, sowie die Bedeutung von transparenter Kommunikation und dem Umgang mit Risiko während des Projektablaufs. Zudem beschreibt das Dokument die Rolle des Produkt Owners, Scrum Masters und der Teammitglieder sowie die wichtigsten Artefakte und Meetings im Scrum-Prozess.

1. Projekte mittels Scrum und agiler
Software Entwicklung meistern.
Aniello Bove, COO & Partner
http://www.slideshare.net/ONESchweiz

2. 2 von 3 IT Projekte scheitern!

10. Warum scheitern IT Projekte?

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

13. Schätzungen sind „wahrscheinlich“.
Projektleiter Median Entwickler
80% Wahrscheinlichkeit

19. Scrum & Agile Software Entwicklung.

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

24. Inkrementell und Iterativ.

25. Kontinuierlicher Flow.
UI
Designers
Users & Programmers
Sponsors Testers
Business
Analysts

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“!

28. Scrum Instrumente.
Rollen
 Produkt Owner
 Scrum Master
 Team
Meetings
 Sprint Planung
 Sprint Review
 Sprint Retrospektive
 Tägliches Scrum
Artefakte
 Produkt Backlog
 Sprint Backlog
 Burndown Diagramm

29. Scrum Rollen.
Rollen
 Produkt Owner
 Scrum Master
 Team
Meetings
 Sprint Planung
 Sprint Review
 Sprint Retrospektive
 Tägliches Scrum
Artefakte
 Produkt Backlog
 Sprint Backlog
 Burndown Diagramm

30. SEO
Scrum Rollen.

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

34. Scrum Meetings.
Rollen
 Produkt Owner
 Scrum Master
 Team
Meetings
 Sprint Planung
 Sprint Review
 Sprint Retrospektive
 Tägliches Scrum Meeting
Artefakte
 Produkt Backlog
 Sprint Backlog
 Burndown Diagramm

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?

40. Scrum Artefakte.
Rollen
 Produkt Owner
 Scrum Master
 Team
Meetings
 Sprint Planung
 Sprint Review
 Sprint Retrospektive
 Tägliches Scrum
Artefakte
 Produkt Backlog
 Sprint Backlog
 Burndown Diagramm

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

48. Scrum/Agile erfolgreich meistern!

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.

52. Dokumentationsinstrumente.
Prozesse
Inventare

53. Arbeitsinstrumente.
Produkt Backlog
Sprint Backlog
Sprint Aufgaben

54. Planungsinstrumente.
Projekte
Mitarbeiter

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.

57. SEO
Scrum auf einen Blick!
http://scrum-master.de/files/Scrum_on_1_page.pdf

58. SEO
Findest Du Scrum verblüffend?
 Es sieht nur komplizierter
aus als es in der Tat ist.

59. SEO
Auch Du kannst es schaffen!
 Man muss nur die richtige
Plattform dafür schaffen.

60. Danke!
INM - der One-Stop-Shop für durchgängige
Web-Marketing-Lösungen.
Aniello Bove, COO & Partner
aniello.bove@inm.ch