Hype oder Lösung Kanban als Methode für erfolgreiche IT-Projekte. DOAG 2011 Konferenz + Ausstellung Robert Szilinski, esentri consulting GmbH

Transkript

1 Hype oder Lösung Kanban als Methode für erfolgreiche IT-Projekte DOAG 2011 Konferenz + Ausstellung Robert Szilinski, esentri consulting GmbH

2 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 2

3 3 Kein Kampf der Systeme und religiösen Ansichten...

4 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 4

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

6 6 Vorteile einer agilen Vorgehensweise

7 Ein 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 7

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

9 TOC - Engpasstheorie Drum Buffer Rope Ansatz Im Multiprojektmangement: Critical Chain Management 9

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

11 11 KANBAN Beispiel

12 12 KANBAN Beispiel Aufbau des Boards

13 13 KANBAN Beispiel Puffer einbauen

14 14 KANBAN Beispiel los geht s! Der 1. Pull...

15 15 KANBAN Beispiel Definition WIPs

16 16 KANBAN Beispiel WIPs mit Puffer

17 17 KANBAN Beispiel WIP überschritten!

18 18 KANBAN Beispiel PULL in Development

19 19 KANBAN Beispiel

20 20 KANBAN Beispiel

21 21 KANBAN Beispiel

22 22 KANBAN Beispiel

23 23 KANBAN Beispiel

24 24 KANBAN Beispiel

25 Scrum vs. Kanban Scrum: agile Softwarentwicklung mehr Vorgaben Kanban: Change Management Kaizen Engpasstheorie Wenig invasiv Zwei unterschiedliche Ansätze! 25

26 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 26

27 Zusätzlich: Definition von 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) 27

28 Einführung von 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 28

29 29 Verbesserungen & Metriken: Cumlative Flow Diagram

30 30 Beispiel für ein KANBAN Board in der Praxis

31 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 31

32 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 32

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

34 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 11. Erfolgskontrolle und kontinuierliche Verbesserungen 34

35 Kontakt Robert Szilinski GPM zertifizierter Projektleiter Social PM Experte Geschäftsführer der esentri consulting GmbH Vielen Dank für Ihre Aufmerksamkeit! Besuchen Sie uns auf unserem Stand - Ebene 2!