Kanban - Extreme improvements in five quarters
•Download as PPTX, PDF•
1 like•581 views
Learn how to implement a Kanban system into your company.
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kanban - Extreme improvements in five quarters
Similar to Kanban - Extreme improvements in five quarters (20)
More from Avarteq
More from Avarteq (12)
Recently uploaded
Recently uploaded (17)
Kanban - Extreme improvements in five quarters
- 1. Extrem improvements in five quarters Kanban - Chapter 4
- 2. Introduction • Dragos Dumitru became Programm-Manager in Oktober 2004 • contractor in india responsible for software maintenance of the XIT business unit • team consisted of 3 developers, 3 testers and local managers
- 3. The problem • team with the worth reputation regarding customer service • long lead times • political environment of his work • but many requirements in a very high quality
- 4. The visualization of the workflow
- 5. Factors with impact on productivity • cost estimation for every requirement • monthly meeting for prioritization • 70 or more requirements newly planned and prioritized
- 6. Factors with impact on productivity • wasted time and supplies - not used data • 11 days for one average requirement • cost estimations (ROM) consume a lot of effort • additional tasks in form of PTCs
- 7. Workflow with ROM and PTC
- 8. Make process rules explicit • team follows the process • a process is a set of rules which determine their behavior • process contains unfavorable rules
- 9. Estimations represent waste • team should no longer estimate • free capacities for developing und testing • improvements of predictability
- 10. Restrict Work In Progress • WIP: 1 requirement per developer and tester • additional queue for PTCs
- 11. Establish a rhythms for the input • weekly meeting with product manager • guaranteed delivery time of 25 days after placing an order
- 12. Workflow with WIP limits and queues
- 13. Proposal for a new arrangement • weekly prioritization meeting • restricted WIP • no more team estimations • delivery after 25 days
- 14. Introduce changes • many were doubtful • but it worked • satisfied delivery time • meetings proceeded with problems
- 15. Adapt the rules • every entry older than 6 months will be deleted from backlog • developer alert manager, if requirement is too big • weekly meetings were omitted
- 16. Lookout for further improvements • developer as bottleneck, therefore 2 testers and 4 developers • increase the quality of performance • enhancement of the budget for 2 additional team members
- 18. The result • increased performance • reduced lead time • satisfy delivery dates • no changes to software developing process
- 19. Conclusion • KANBAN enables • incremental changes • changes with little political risk • improvements without major changes of the developing methods
Editor's Notes
- Vorgänger waren Kollegen Personal Software Process/Team Software Process (PSP/TSP) -> nicht änderbar Durchlaufzeit 5 Monate und weiter steigend unkontrollierbar Menge an offenen Anforderungen
- PM ist Dragos Anforderungen unkontrolliert ins System 4 Produktmanager für Budgets von mehreren Kunden Fügen ständig neue Änderungen hinzu, auch Behebung nicht entdeckter Produktionsfehler Fehler von Anwendungsentwicklungsteam, nicht von Wartungsteam Anwendungsteams 1 Monat nach Auslieferung aufgelöst
- Berechnung des Return of Investment (ROI) -> Anforderung umsetzen oder nicht? monatlicher Durchsatz bei 7 Anforderungen, ausstehende Anforderungen bei 80+ Anforderung braucht 4 Monate zur Auslieferung Anforderungen relativ klein, aber ständige Umpriorisierung -> enttäuchte Anforderer
- Durchlaufzeit von 125-150 Tagen -> 90% mit Warten oder anderer Form unnötiger Arbeit grobe Schätzung (ROM = Rough Order of Magnitude), aber Kunden erwarten ziemlich genaue 1 Tag pro Entwickler und Tester: 33% bis 40% der Kapazitäten PTC = Production Text Changes, Werte in Tabellen oder XML-Dateien, brauchen Tester ohne Vorwarnung, umgehend bearbeitet, andere Aufgaben oder Schätzung bleiben liegen häufig einzeln
- Regeln vom Managern gesteuert PSP/TSP von Managementebene unterhalb von Bill Gates Vorrang von Schätzungen vor Entwicklungen lokal eingeführt war mal sinnvoll, Umstände haben sich aber geändert Regeln anpassen
- Verzicht auf Schätzungen problematisch Auswirkungen auf ROI-Berechnung, Kunden Angst vor schlechterer Priorisierung interne Kostenverrechnung und interne Steuerung größere Änderungen ab 15 Tagen nicht vom Wartungsteam
- Rhythmus (Cadence) ist ein Konzept von KANBAN, das den Takt bestimmter Ereignisse festlegt. Priorisierung, Auslieferung, Retrospektiven und jedes wiederkehrende Ereignis kann seinen eigenen Rhythmus haben
- ROI und innerbetriebliche Abrechnung nicht mehr auf einzelne Schätzungen kurze und zuverlässige Lieferzeiten alle Anfragen verursachen im Schnitt 11 Tagen Entwicklungsaufwand Kosten grundsätzlich anders berechnet Budget fester Betrag, von jedem Produktmanager anteilig bezahlt fairer Anteil an Kapazitäten, Round-Robin-Schema, wer nächste Anforderung auswählt