In diesem Vortrag sollen die verwendeten internen Vorgehensmodelle präsentiert werden. Hier geht es vor allen Dingen um die Einführung von Scrum, den Wechsel zu Kanban und die daraus resultierenden Vorteile.

1. AGILE ENTWICKLUNG BEI DER SHOPWARE AG

2. DER EHEMALIGE WORKFLOW

3. EHEMALIGER SCRUM WORKFLOW

4. DIE CHARTS

5.  Keinen Überblick bei vielen kleinen Projekten
 hoher Pflegeaufwand
 Strenge Richtlinien von Scrum(Meeting Kultur)
 Tickets mussten in einen Sprint gepresst werden
 Druck entstand durch nicht erreichen des Sprint Ziels
PROBLEME

6. LÖSUNG: KANBAN?

7.  Kanban jap. Karte
 Gehört wie Scrum zu der Familie der Pull-Systeme
 Engpasstheorie
 Nachhaltige Entwicklungsgeschwindigkeit
 Beschränkt den Work in Progress
WAS IST KANBAN

8.  Keine Beschränkung auf Sprints
 Verbesserungen können jederzeit erfolgen und nicht erst nach einer Iteration
 Einfache Priorisierung durch First-In-First-Out
 Probleme im Workflow werden schneller erkannt
VORTEILE VON KANBAN

9. DER NEUE WORKFLOW

10. 1. Initiales Einschätzen des Backlogs von Projektverantwortlichen
2. Arbeit für ca. 2 Wochen dem Dev Team übergeben
2. Nach ca. 1 Woche wird geschaut wie viel das Team geschafft hat
3. Das Backlog wird erneut von den Projektverantwortlichen gesichtet
3. Tickets die abgearbeitet wurden werden wieder aufgefüllt
DER NEUE WORKFLOW

11. KANBAN DAS BOARD

12. KANBAN DAS TICKET

13. WIE SOLLTE EIN TICKET ANGELEGT WERDEN
Kaffee Crème Cappuccino
Espresso Latte Machiato
Michschaum Milchkaffee

14. KANBAN DIE CHARTS

15. KANBAN DIE CHARTS

16.  Daily Standup
 Backlog Grooming
 Retrospektive
KANBAN DIE MEETINGS

17. DAILY STANDUP
Zweck: Problemanalyse und Überprüfung des Entwicklungsstandes
Zeitpunkt: täglich
Vorgehen:
Man stellt die drei Fragen
Was hast du gestern gemacht?
Wo gab/gibt es Probleme/Hindernisse?
Was möchtest du heute machen?
Man geht die Tickets von rechts nach links durch
Teilnehmer: Entwicklungsteam QA evtl. PO

18. BACKLOG GROOMING
Zweck: Sichten des Backlogs und bestimmen der nächsten Tickets
Zeitpunkt: frei
Vorgehen:
• Analyse der Entwicklungsgeschwindigkeit anhand des Durchsatzes
• Sichten und priorisieren des Backlogs
• Tickets für die nächste Iteration an das Team weitergeben
Teilnehmer: PO und Projektverantwortliche

19. RETROSPEKTIVE
Zweck: Aufdecken und Lösen von Problemen die den Workflow behindern
Zeitpunkt: Nach einer Iteration oder wenn nötig
Vorgehen:
• Teammitglieder bewerten die letzte Iteration
• Teammitglieder zeigen Probleme auf, die ihre Arbeit behindert haben
Teilnehmer: Entwicklungsteam QA evtl. PO

20. • Viel Agiler in der Entwicklung (schneller reagieren auf Marktveränderungen)
• Der Entwicklungstand kann jederzeit am Board eingesehen werden
• Beschränkung der WIPs schafft Freiräume für Verbesserungen
• Mehr Focus auf Qualität
FAZIT

21. • Aktuelle Priorisierung
• Fertigstellung eines Releases schlechter zu prognostizieren
FAZIT

22. KANBAN INTEGRIEREN

23. • Work In Progress sollte limitiert werden
• Der bestehende Workflow sollte auf ein Kanban Board visualisiert werden
• Das Board sollte alle Informationen beinhalten
• Das Board sollte leicht veränderbar sein
KANBAN INTEGRIEREN

24. • Tickets sollten druckbar sein
• Generieren von Statistik-Charts
DAS TICKETSYSTEM

25. 1. Fokussiere auf Qualität
2. Reduziere den Work in Progress
2. Liefere häufig
3. Sorge für ein Gleichgewicht zwischen Nachfrage und Durchsatz
3. Bessere Priorisierung
4. Quelle der Variabilität analysieren um die Vorhersagbarkeit zu verbessern
DAS ERFOLGSREZEPT

26. • Kein starres Verfolgen von Vorgehensmodellen
• Es gibt keine allgemeine Lösung für alle Teams
PERSÖNLICHES-FAZIT