The document compares Kanban and Scrum methodologies, detailing Kanban's principles such as limiting work in progress, visualizing tasks, and enabling continuous improvement. It outlines when to apply Kanban versus Scrum and explains key metrics and practices related to both frameworks. Additionally, it discusses the benefits of Kanban, particularly for product owners, and emphasizes that the effectiveness of any process depends on the team's capabilities.

1. Kanban VS Scrum Alimenkou Mikalai 31.10.2009

2. Agenda Introduction to Kanban Kanban main principles Example from Kanban-land When apply/not apply Kanban? Comparison of Scrum and Kanban

3. What is a Kanban? A Kanban is a physical card used in Toyota Production System (TPS) to support non-centralized "pull" production control. It has spread to the manufacturing industry all over the world as a tool of Lean Manufacturing . " Kan " means visual, and " ban " means card or board .

4. Kanban Practices Map the Value Stream Visualize the Work Limit Work in Progress Establish a Cadence Enable continuous improvement

5. Kanban Board Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

6. Limiting Work in Progress Reduce multi-tasking Prevent context switching Performing tasks sequentially yields results sooner Maximize throughput Enhance teamwork Working together to make things done Increase cross-functionality

7. Pull, Don’t Push

8. WIP Limit Strategy Start with some initial value Small constant (1-3) Number of developers Number of testers Measure the cycle time Average time of one piece full cycle flow Change limit to decrease cycle time

9. Idle Team Members Guide Can you help progress and existing kanban? – Work on that. Don’t have the right skills? – Find the bottleneck and work to release it. Don’t have the right skills? – Pull in work from the queue. Can’t start anything in the queue? – Check if there any lower priority to start investigating. There is nothing lower priority? – Find other interesting work (refactoring, tool automation, innovation).

10. What is Cadence? “ A regular cadence, or heartbeat, establishes the capability of a team to reliably deliver working software at a dependable velocity. An organization that delivers at a regular cadence has established its process capability and can easily measure its capacity. ”

11. Kanban Metrics Stories in progress ( SIP ) When story enters stories queue set entry date ( ED ) When story enters first process step set start processing date ( SPD ) When story is done set finish date ( FD ) Cycle time ( CT ) = FD – SPD Waiting time ( WT ) = SPD – ED Throughput ( T ) = SIP / CT

12. Workflow Diagram

13. 5 Wrong Reasons to Apply Kanban User stories diversity User stories vary in size a lot, large stories don’t feet into an iteration Failed iterations Many stories are not completed in a single iteration Failed retrospective meetings Retrospective meetings are waste Shared people We have a single pool of developers for some projects Simplicity Kanban is so simple, no planning, no retrospectives, no estimations

14. 5 Right Reasons to Apply Kanban Ability to release anytime When user story is ready you may release it Ability to change priorities on the fly Not started stories queue is always changeable No need in iterations Iterate first then flow No need to estimate Release when it is ready, do most important story Perfect flow visualization Clear view of current work in progress

15. When no Need in Iterations? Support project Bug fixing stage All valuable stories are too large and can’t be divided Testing can’t be finished in iteration so quality suffers Team is self-organizing and trusted enough to work without iterations No backlog ready for iteration planning

16. When no Need to Estimate? You are new to the project Estimations don’t change plans Velocity is not taken into account Team is very experienced in breaking tasks Average cycle time is enough for the customer

17. Example from Kanban-land 1 2 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

18. Example from Kanban-land 3 4 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

19. Example from Kanban-land 5 6 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

20. Example from Kanban-land 7 8 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

21. Example from Kanban-land 9 10 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

22. Example from Kanban-land 11 12 Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

23. Kanban for Product Owners New Prioritized buffer Unlimited size Preparing Work in Progress Limited to PO capacity Cycle time Promotion model Ready Prioritized buffer 1-2 Team Velocity In Progress Work in Progress Limited to Team WIP limit

24. Kanban Best Practices Bugs get top priority Set so minimal WIP as possible Stories should be ”minimal marketable features” Create separate column with goals Add Scrum practices (daily scrum, retrospectives, demos) Add XP engineering practices

25. User Stories Mapping

26. Kanban Issues Lack of goal and focus Less predictability Less commitment level More discipline required

27. Scrum Overview

28. Kanban is Less Prescriptive Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

29. Task Flow Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

30. Project Cadence Scrum Kanban Source: Crisp ( http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf )

31. Scrum VS Kanban (Similarities) Both are Lean and Agile Both use pull scheduling Both limit WIP Both use transparency to drive process improvement Both focus on delivery releasable software early and often Both are based on self-organizing teams Both require breaking work into pieces Both optimize release plan based on empirical data (velocity/cycle time)

32. Scrum VS Kanban (Differences)

33. Scrum VS Kanban (Differences)

34. Don’t Forget That … ANY process or methodology (that is not actively destructive), applied to a skilled, disciplined, high-functioning, motivated team, will succeed, regardless of the process. Likewise, any process applied to a low-functioning team will likely fail.

35. Resources http://availagility.wordpress.com/kanban - largest collection of Kanban related resources http://www.agileproductdesign.com/blog/2009/kanban_over_simplified.html - Kanban detailed description http ://www.lostechies.com/blogs/derickbailey/archive/2009/08/05/how-to-get-started-with-kanban-in-software-development.aspx - simple guide to start with Kanban http://lizkeogh.com/2009/09/16/scrum-vs-kanban-fight - funny Scrum and Kanban dialog http://www.crisp.se/henrik.kniberg/Kanban-vs-Scrum.pdf - great book from Henrik Kniberg

36. Any questions? Email me: [email_address] Read my blog: http://javadevelopmenttips.blogspot.com Visit my website: http://agilecoaching.com.ua