Einsatz von Scrum in. Bruno Schori Executive MBA & Dipl. Inf.-Ing. HTL Geschäftsfeldleiter

Transkript

1 Einsatz von Scrum in Bruno Schori Executive MBA & Dipl. Inf.-Ing. HTL Geschäftsfeldleiter

2 Vorstellung meiner Person Bruno Schori Aus- und Weiterbildung Führungsausbildung Malik Managementzentrum St. Gallen Executive MBA, Management Zentrum Bern Betriebswirtschaft / Unternehmensführung, FH Bern 2004 Systemisches Projektmanagement, FH Bern Informatik-Ingenieur HTL, FH Bern Berufserfahrung heute Geschäftsfeldleiter, Bedag Informatik AG Projektleiter, Business-Analyst, IT-Architekt, Bedag Informatik AG Software-Entwickler, Teilprojektleiter; Bedag Informatik AG Software-Entwickler, Teilprojektleiter; Eidg. Steuerverwaltung 1992 Software-Entwicklung Industriebetrieb; Studer AG Seite 2

3 Kurzporträt der Bedag Informatik AG Kunden Öffentliche Verwaltungen der Schweiz (Bund, Kantone, Gemeinden) Verwaltungsnahe Organisationen (Vereinte Nationen, öffentliche Betriebe) Gesundheits- und Versicherungswesen (Krankenkassen, Spitäler, Versicherungen) Privatwirtschaft 4% Dienstleistungen IT-Betrieb IT-Anwendungen IT-Gesamtdienstleistungen Personal 470 Mitarbeiterinnen und Mitarbeiter ISO 9001 und ISO/IEC SAP Certified in Cloud Services SAP Certified in Hosting Services Certification EcoEntreprise 70% Delémont Wettingen Aarau 21% Bern 5% Finanzkennzahlen Umsatz: 108 Mio. CHF Gewinn: 6 Mio. CHF Genf Lausanne Eigentümer Kanton Bern (100%) Aktienkapital von 10 Mio. CHF Seite 3

4 Warum Scrum? Erfolgsdimensionen kontrollieren Transparenz schaffen Risiken minimieren Kommunikation sicherstellen Qualität Budget Termine Funktionalität Qualität Umfang Liefern, was der Kunden wirklich wünscht Kosten Zeit Ist dafür Scrum notwendig? Aufgaben eines jeden Projektleiters Seite 4

5 Warum Scrum? Wie der Kunde es erklärt hatte Wie der Projektleiter es verstanden hat Wie der Analyst es auffasst Wie der Entwickler es umgesetzt hat Wie der Berater es verkauft Wie das Projekt dokumentiert wurde Welche Funktionen implementiert wurden Wie es dem Kunden verrechnet wurde Wie das Marketing damit wirbt Was der Kunde wirklich wollte Adaption aus Seite 5

6 Warum Scrum? Verwendung der Funktionen eines typischen Systems Immer oder oft verwendet: 20% Quelle: Source - The Standish Group CHAOS'2000 Survey Selten oder nie verwendet: 64% Seite 6

7 Initialisierung Voranalyse Konzept Realisierung Einführung Abschluss Warum Scrum? Vorgehensmodell Hermes Offener Standard der CH-Bundesverwaltung Eindimensionales Phasenmodell Vorgaben des Bundes & des Kantons Bern für IT-Projekte Quelle: Scrum Seite 7

8 Warum Scrum? PERSISKA.eFormular Prozessgesteuerte Formulare Dezentrale Verarbeitung Vorgehensmodell Hermes Phasenorientiert Enorme Aufwände bei der Erstellung der Systemanforderungen Seite 8

9 Warum Scrum? PERSISKA.Auskunft Informationssystem Zentraler & dezentraler Einsatz Prototyping mit Workshops Fehlende Mitarbeit der Endbenutzer Komplette Überarbeitung vor Einführung Seite 9

10 Warum Scrum? PERSISKA.Client Seite 10

11 Warum Scrum? PERSISKA Akteure Finanzdirektion / Personalamt Seite 11

12 Warum Scrum? Exkurs Verwaltete Personen Personen mit Anstellungen Gehaltsauszahlungen monatlich 600 Anwender/Innen 200 Mio. Gehaltssumme monatlich %-Stellen Lehrkräfte %-Stellen Kantonspersonal Seite 12

13 Warum Scrum? PERSISKA.Client Seite 13

14 Warum Scrum? PERSISKA.eFormular Phasenorientiert Enorm teuer mit geringer Ausbeute PERSISKA.Auskunft Prototyping Fehlende Mitarbeit des Kunden Wie animiere ich den Kunden zur Mitarbeit? Wie stelle ich sicher, das wir das Richtige tun? Seite 14

15 Grundlagen zu Scrum Agiles Manifest ( Individuen und Interaktionen gelten mehr als Prozesse und Tools Funktionierende Programme gelten mehr als ausführliche Dokumentation Die stetige Zusammenarbeit mit dem Kunden steht über den Verträgen Der Mut und die Offenheit für Änderungen steht über dem Befolgen eines festgelegten Plans Seite 15

16 Grundlagen zu Scrum Scrum in weniger als 100 Worten Scrum ist ein agiler Prozess, der es erlaubt, sich auf die Auslieferung der wichtigsten Geschäfts-Anforderungen innerhalb kürzester Zeit zu fokussieren. Scrum gestattet es, schnell und in regelmässigen Abschnitten tatsächlich lauffähige Software zu inspizieren. Das Business setzt die Prioritäten. Selbstorganisierende Entwicklungsteams legen das beste Vorgehen zur Auslieferung der höchstpriorisierten Features fest. Alle zwei Wochen bis zu einem Monat kann jeder echt lauffähige Software sehen und entscheiden, diese so auszuliefern oder in einem weiteren Abschnitt zu ergänzen. Seite 16

17 Grundlagen zu Scrum Der Prozess Prozess review learn Ziele vereinbaren Arbeite (30 Tage) Ergebnisse zeigen plan do review Seite 17

18 Grundlagen zu Scrum Die Rollen Team ist wertschöpfend ist funktionsübergreifend ist selbstorganisierend Product Owner ist Geldgeber erstellt Zielvorgabe definiert Priorisierung leistet Abnahme Scrum Master überwacht Scrum Werte entfernt Hindernisse fördert Zusammenarbeit sichert Produktivität Seite 18

19 Grundlagen zu Scrum Zeremonien Daily Scrum Meeting Sprint Planning Meeting Teil 1 Sprint Backlog Teil 2 Backlog Tasks (ausgearbeitet durch Team) 24 Std. Sprint (30 Tage) Sprint Review Meeting Product Backlog (priorisiert durch Product Owner) Potenziell auslieferbares Produkt-Inkrement Adaption aus Agile Software Development with Scrum von Ken Schwaber und Mike Beedle Seite 19

20 Bedenken zu Scrum Ist Scrum verträglich zu Hermes? Wie kann verhindert werden, dass die Entwickler machen was sie wollen? Wie kann die Kontrolle sichergestellt werden? Wer gibt die Garantie, dass mit Scrum das Ziel erreicht wird? Kann und will der Kunde soviel Zeit in das Projekt investieren? Seite 20

21 Bedenken zu Scrum Ist Scrum verträglich zu Hermes? Hermes Scrum Phasenorientiert Alles auf einmal Abnahme vor jeder weiteren Phase Betonung auf vordefinierter Organisation Dokumenten-orientiert (als Arbeitsergebnis) Abnahme einzelner Inkremente Betonung auf Selbstorganisation Produkt-orientiert (als Arbeitsergebnis) Infos zu Hermes: Seite 21

22 Bedenken zu Scrum Ist Scrum verträglich zu Hermes? Management Prozess Einbettung in Hermes Steuerung Führung Hermes SE Verbesserung Projektmanagement Ergebnisse Messung Scrum Tailoring Aktivitäten Rollen Auszug aus Lunch & Learn HERMES-Scrum Informatikstrategieorgan Bund ISB Konfig. management Rollen Risikomanagement Qualitätssicherung Beschaffung Finanzen Seite 22

23 Bedenken zu Scrum Wie kann verhindert werden, dass die Entwickler machen was sie wollen? Product Backlog wird vom Kunden geführt Monatliche Sprint-Reviews Seite 23

24 Anzahl Verwendung in P2 in Arbeit Core oder Umgehung Layout Erfassen Mutieren Speichern Löschen Validierung Fertigstellungsgrad Bedenken zu Scrum Wie kann die Kontrolle sichergestellt werden? Ausgangslage PERSISKA P2 Umsetzung in PERSISKA.Client Masken in P2 BE01A Suchen Person/Anstellung % BE02A Person % BE04A Pensionskassenzugehörigkeit % BE05A Angestellte(r) % BE21A Treueprämie % BE21A Treueprämie (mit Löschen) % BE23A Besitzstände verwalten % BE81A Besitzstandsverbindungen verwalten % BE85A Adresse zu Person % BE85A Adresse zur Anstellung % Anzahl Masken in Arbeit Fertigstellungsgrad der Masken in PERSISKA.Client Legende: rot = Arbeit noch nicht begonnen, orange = in Arbeit, grün = Fertig 32 von Total % Seite 24

25 Bedenken zu Scrum Wer gibt die Garantie, dass mit Scrum das Ziel erreicht wird? Customer on Site Sprint Review Meeting Burn Down Chart Seite 25

26 Bedenken zu Scrum Kann und will der Kunde soviel Zeit in das Projekt investieren? Ja und Nein Seite 26

27 Bedenken zu Scrum? Verwendung der Funktionen eines typischen Systems Immer oder oft verwendet: 20% Quelle: Source - The Standish Group CHAOS'2000 Survey Selten oder nie verwendet: 64% Seite 27

28 Scrum real (kleines Team) Sprint Review Meeting Daily Scrum Meeting Sprint Planning Meeting Teil 1 Sprint Backlog Teil 2 Backlog Tasks (ausgearbeitet durch Team) 24 Std. Sprint (30 Tage) Sprint Review Meeting Product Backlog (priorisiert durch Product Owner) und Team Potenziell auslieferbares Produkt-Inkrement Adaption aus Agile Software Development with Scrum von Ken Schwaber und Mike Beedle Seite 28

29 Sprint Review Meeting Meeting beim Kunden (2-4 Std.) Das Produkt ist beim Kunden lauffähig Alle Entwickler nehmen teil Seite 29

30 Sprint Review Meeting - Ablauf Standortbestimmung Was haben wir erreicht Was war gut, was war nicht gut Vorstellung der neuen Produktversion Sprintergebnis Eventueller Input für Product Backlog Initiierung nächster Sprint Product Backlog gemeinsam durcharbeiten und neu priorisieren Unklarheiten besprechen Scrum Master Team Scrum Master Scrum Master Seite 30

31 Sprint Review Meeting Meine persönlichen Ziele dieser Meetings Der Kunde freut sich darauf, eine neue Version zu erhalten Die Entwickler lernen die Sprache des Kunden Ehrliche und offene Zusammenarbeit Wir arbeiten miteinander, nicht gegeneinander Der Kunde kann nur durch professionelle Arbeit zufrieden gestellt werden Seite 31

32 Daily Scrum Meeting Täglich 15 Minuten (grosses Team) 3 Fragen Was hast Du gestern gemacht? Was machst Du heute? Welche Hindernisse sind Dir im Weg? Täglich 30 Minuten (kleines Team) 3+n Fragen + Problemlösung + Teambildung Seite 32

33 Daily Scrum Meeting Seite 33

34 Daily Scrum Meeting Feedback Entwickler Scrum hat für mich diverse Vorteile: Zum einen weiss man Bescheid mit was sich derzeit die anderen im Team beschäftigen und zum anderen findet ein Gedankenaustausch statt, welcher meiner Meinung nach nicht anders zu erreichen wäre. Ist es eine willkommene Abwechslung während eines Arbeitstages. Immer aktuelle Infos über das Projekt und andere relevante Projekte Struktur bietet schnelle Austausch- und Problemlösungsmöglichkeiten Hilft dem Team auf dem neuesten Stand zu bleiben Probleme und Lösungen werden schneller erkannt und umgesetzt Missverständnisse werden schneller erkannt und abgeklärt Ermöglicht einen projektübergreifenden-austausch Seite 34

35 Scrum real Keine Interrupts während des Sprints! Interrupts lenken ab und gefährden das Sprint-Ziel Bugs finden via Jira Aufnahme im Product Backlog Changes finden Aufnahme im Product Backlog Product Backlog führt Kunde (in Zusammenarbeit mit Scrum Master) plan do review Seite 35

36 Product Backlog Nummer Wichtigkeit -Sehr hoch - hoch - mittel Beschreibung 1 Sehr hoch Berechtigungen definieren 2 hoch Implementierung von PF-Funktionen 3 hoch Systemanforderung für Löschen erstellen Angaben für Version 2 1 hoch Datepicker bei Datumsfelder Erledigte Aufgaben 1 Sehr hoch XSearch für Suche einbauen Seite 36

37 Product Backlog Mein hochgeschätztes Instrument Change happens Die Priorisierung der Changes erfolgt immer im Gesamtkontext Der Kunde bemerkt unsinnige Changes oft selbst Konzentrierte Diskussion über alle Einträge beim Sprint Review Seite 37

38 Realisierungsrisiko niedrig hoch Product Backlog - Priorisierung Unsinn Wichtigkeit sehr hoch Vermeiden Sofort erledigen Später erledigen Als zweites erledigen Wichtigkeit mittel niedrig Nutzen hoch Wichtigkeit hoch Seite 38

39 Risiken Projekt kommt nicht zu einem Abschluss Bei aufeinanderfolgenden Iterationen werden einzelne Anforderungen immer wieder neu definiert Das Ziel wird unklar und diffus Scrum erzeugt Zusatzkosten Kostenkontrolle Funktionsumfang Qualitätskontrolle Planung Qualität Kosten Budget Termine Funktionalität Qualität Umfang Zeit Seite 39

40 Risiken Setze Scrum nie ein, wenn das Ziel nicht klar ist (wir wissen nicht was wir wollen, setzen wir doch mal Scrum ein) Setze keinen Scrum-Master ein, der sich nicht voll mit dem Projekt identifizieren kann Vergiss nie, Dich auf das Wichtigste zu konzentrieren; jeder Sprint-Review könnte das Projektende sein Vertraue nie darauf, dass mit Scrum alles gut kommt Seite 40

41 Scrum in Persiska.Client - Beispiel Realisierung (Iteration 5) Seite 41

44 Projekt Retrospektive Seite 44

45 Projekt Retrospektive Wie bewerten Sie die Zusammenarbeit im gesamten Team 6 Empfanden Sie die Ihnen zugewiesenen Aufgaben für Wie bewerten Sie das Gesamtergebnis? 5.5 sich selbst angemessen? Wie empfanden Sie die iterative Entwicklung (im Gegensatz zur bisherigen Vorgehensweise)? Wie wohl haben Sie sich im Team gefühlt? 4 Wie bewerten Sie die Projektplanung insgesamt (Termine, Aufwände etc.)? Wie gut konnten Sie Ihre eigenen Stärken einsetzen? Wie bewerten Sie die Arbeit der Projektleitung? Wie bewerten Sie den Informationsfluss im Projekt? Bewertung: 6 = sehr gut, 1 = ungenügend Wie bewerten Sie die Zusammenarbeit mit anderen Projekten (Auskunft, Formulare, etc.) Ø Bewertung PA Bewertung BI Bewertung Seite 45

46 Projekt Retrospektive Kommunikation Sprint-Review, Customer on Site, daily Scrum-Meeting, Besprechungen, PL-Meeting Dokumentation Unterschiedliche Bedürfnisse an die Dokumentation sind nicht abgedeckt Vorgehen Scrum wird durchwegs positiv bewertet Seite 46

47 Der Blick über den Tellerrand Seite 47

48 Bilanz Der Einsatz von Scrum in Persiska.Client hat sich für alle Beteiligten gelohnt. Der Erfolg von Persiska.Client liegt in der Fokussierung auf das Wesentliche. Scrum erzeugt Druck: jeden Monat eine lauffähige Software zu präsentieren stellt eine hohe Herausforderung aller Beteiligten dar. Dank den monatlichen Sprint-Reviews ist der Kunde permanent ins Projekt einbezogen. Der Weg zum Ziel wird gemeinsam ausgestaltet. Seite 48

49 Fazit Scrum kann mit Veränderungen umgehen Scrum fordert die Mitarbeit des Kunden Scrum fokussiert auf das Wesentliche Scrum ist ein einfaches PM-Framework Scrum erzeugt Druck Scrum gibt keine Garantien Seite 49

50 Fazit Konzentriere Dich immer auf das Wichtigste Betrachte jedes Sprint Review als potentielles Projektende Stelle sicher, dass das angestrebte Ziel keine Lippenbekenntnisse sind Arbeite mit, nicht gegen den Kunden Seite 50

51 Schlusswort Kommunikation ist nicht alles, aber ohne Kommunikation ist alles nichts Seite 51

52 Mehr Informationen Scrum Agile Software Development with Scrum Ken Schwaber and Mike Beedle Agile Project Management with Scrum Ken Schwaber Generelle Informationen Seite 52