Besser als Scrum? Kanban in der IT. DOAG 2013 Development, 19. Juni 2013

Transkript

1 Besser als Scrum? Kanban in der IT DOAG 2013 Development, 19. Juni

2 #Mission der esentri AG Wir leben unsere Vision vom agilen Unternehmen der Zukunft. Mit unserer Begeisterung für führende Technologien vernetzen wir Systeme, Prozesse und facebook.com/esentri 2

3 #Situationen im Projektgeschäft... 3

4 #Kanban - Let s do something about it! David J. Anderson als Erfinder des IT-KANBAN Aus der Praxis für die Praxis Best Practices Evolutionäres Change Management & Kaizen Beispiel Microsoft: Seit 2004 im Einsatz Verdreifachung Produktivität Vorhersagbarkeit um 98% verbessert 4

5 #Kein Kampf der Systeme und religiösen Ansichten... 5

6 Die Situation der Entwickler 6

7 #Spaß Stresssituationen im Projekt 7

8 #Ernst wann hatten Sie Ihre letzte 40 Stunden Woche? 8

9 #Motivation für einen neuen Ansatz 40 Stunden Woche machbar! Konstante Geschwindigkeit als Ziel Qualität in Softwareprojekten Nachhaltige Entwicklung Steigende Anforderungen des Managements Verrückte Zeitpläne, absurde Zeittermine für schnelle Zwischenlieferungen Vertrauen von Stakeholdern zurückgewinnen Vertrauensvolle Zusammenarbeit in Teams Change Management in Richtung Agilität 9

10 10

11 #Agiles Manifest 1. Individuen und Interaktionen wichtiger als Prozesse und Werkzeuge. 2. Funktionierende Software wichtiger als umfassende Dokumentation. 3. Zusammenarbeit mit dem Kunden wichtiger als Vertragsverhandlung. 4. Reagieren auf Veränderung wichtiger als das Befolgen eines Plans. 11

12 #Vorteile einer agilen Vorgehensweise 12

13 #Blick zurück Wo kommt KANBAN her? 1947 Taiichi Ohno - Toyota Produktionssystem (TPS) à Supermarktprinzip Mehrere Bestandteile Lean Production FIFO Theory of Constraints Visuelle Darstellung PULL WIP (Work in Progress) agiles Vorgehen Kaizen Kultur 13

14 #Wissensarbeit vs. stereotype Arbeitsabläufe Produktionsabläufe sind hart Für jeden verständlich und nachvollziehbar Änderungen sind teuer! Softwareentwicklung ist weich Änderungen sind günstig Abstrakte Güter, Verständnisprobleme Verlockung ist groß permanent Änderungen durchzuführen à Konzepte lassen sich nicht 1:1 anwenden! 14

15 #Theory of Constraints Engpasstheorie Drum Buffer Rope Ansatz Im Multiprojektmangement: Critical Chain Management 15

16 #Visualisierung der Arbeit als Erfolgsfaktor Softwareentwicklungszyklus als Wertstrom Problem: Engpass nicht überall gleich! Kontext ist für Engpass entscheidend à Nur durch die visuelle Darstellung allein ist es noch nicht KANBAN! Visualisieren Sie den echten(!) Workflow! J 16

17 KANBAN im Einsatz ein Beispiel 17

18 18

19 19

20 20

21 21

22 22

23 23

24 24

25 25

26 26

27 27

28 28

29 29

30 30

31 31

32 32

33 33

34 34

35 35

36 36

37 37

38 38

39 39

40 Ist Scrum besser oder schlechter als Kanban? 40

41 #Scrum vs. Kanban Scrum agile Softwarentwicklung mehr Vorgaben Kanban Change Management Kaizen Engpasstheorie Wenig invasiv à Zwei unterschiedliche Ansätze für Agilität! 41

42 #KANBAN ist immer im Kontext zu sehen! KANBAN erlaubt, dass man die Prozesse auf den Kontext anpasst UND NICHT den Kontext unter allem Umständen in einen bestimmten Prozess zu pressen! Nothing else in their world should have changed. Job descriptions are the same. Activities are the same. Handoffs are the same. Artifacts are the same. Their process hasn t changed other than you are asking them to accept an WIP limit and to pull work rather than receive it in a push fashion. David J. Anderson 42

43 Kann es das schon gewesen sein? 43

44 #Serviceklassen Standardklasse (gelb) unterschiedliche Typen (klein, mittel, groß) Grundlage für verschiedene SLAs Beschleunigt (weiße Tickets) nur begrenzt einsetzen höhere Priorisierung Fester Liefertermin (violett) gesetzliche Bestimmungen vertragliche Pflichten Unbestimmte Kosten (grün) Verzögerungskosten vage oder unbestimmbar z.b. Ablösung von Systemen (End of Life) 44

45 #Aufgabentypen Anforderung Feature User Story Use Case Change Request Fehler im Produktivsystem Wartung Refactoring Bug Verbesserungsvorschlag Blocker... Ticket/Aufgabentyp T-ID Deadline Feature User Story Historie Startdatum - Enddatum Bearbeiter 45

46 Verbesserungen & Metriken Cumlative Flow Diagram 46

47 #Beispiel für ein KANBAN Board in der Praxis 47

48 Wie löst man sich von bisherigen Denkweisen? 48

49 #Setup Wie man mit KANBAN beginnt... Ein paar grundlegende Empfehlungen: 1. Auf der aktuellen Basis starten Keine spezifischen Rollen notwendig Keine vorgegebenen Prozessschritte 2. Zusage aller Beteiligten inkrementelle Änderungen mitzutragen stetige aber kleine Verbesserungen 3. Die aktuellen Rollen, Prozesse, Zuständigkeiten und Verantwortlichkeiten respektieren 49

50 #Setup Empfohlene Vorgehensweise 1. Einen Start- und einen Endpunkt definieren 2. Aufgabentypen wählen 3. Ein KANBAN Board zeichnen 4. Bedarfsanalyse* 5. Kapazität gem. Bedarf verteilen* 50

51 Bedarfs- und Kapazitätsplanung 40% Neue Features 40% (saisonale) Change Requests 20% Bugfixing 51

52 #Setup Empfohlene Vorgehensweise 1. Einen Start- und einen Endpunkt definieren 2. Aufgabentypen wählen 3. Ein KANBAN Board zeichnen 4. Bedarfsanalyse* 5. Kapazität gem. Bedarf verteilen* 6. Elektronisches Tracking (bei Bedarf) 7. Lieferzeiten / SLAs festlegen* 8. Engpässe puffern 9. WIP Limits setzen 10. Serviceklassen festlegen (sofern notwendig) 11. Erfolgskontrolle und kontinuierliche Verbesserungen 52

53 Eignet sich KANBAN für alle Projekte? 53

54 #Hype oder Lösung? KANBAN auf die Spitze getrieben! 54

55 Robert Szilinski esentri AG