Kanban highlights
•Download as PPT, PDF•
5 likes•6,701 views
Highlights of Kanban from Agilesparks Training for Managers
![Analysis Development Acceptance Prod Next ,[object Object],[object Object],[object Object],Ongoing Done ,[object Object],[object Object],[object Object],[object Object],Ongoing Done Ongoing Done ,[object Object],[object Object],[object Object],[object Object],2 3 3 2 Feature / story = completed = blocked = who is doing this right now 2009-08-20 2009-09-30 (description) ,[object Object],[object Object],[object Object],[object Object],Task / defect Hard deadline (if applicable) Date when added to board (description) (description) Why (description) Who is analyzing / testing right now = priority = panic What to pull first xxxx kjd dj d xxx Kanban kick-start example Henrik Kniberg www.crisp.se/kanban/example version 1.2 2009-11-16 =task =defect 2009-08-29 orem ipsum dolor sit amet, nse ctetur adi pis cing elit nisl 2009-09-01 orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-09-02 orem ipsum dolor sit amet, nse ctetur adi pis elit nisl 2009-09-03 ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-09-02 orem ipsum dolor sit amet, co nse 2009-08-27 orem ipsum dolor sit amet, ctetur adi pis cing elit nisl 2009-08-27 orem ipsum dolor sit amet, adi pis cing elit nisl 2009-08-20 orem olor sit amet, co nse ctetur adi pis cing elit nisl 2009-08-30 orem ipsum dolor sit amet, co adi pis cing elit nisl 2009-09-08 2009-08-20 orem ipsum dolor sit amet, co nse ctetur adi pis cing elit nisl 2009-08-25 2009-08-22 orem ipsum dolor sit amet, co 2009-08-25 orem ipsum dolor sit ctetur adi pis cing elit nisl orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur orem ipsum dolor sit amet, co nse ctetur (description) (description) orem ipsum dolor sit amet, co nse ctetur 2009-08-26 orem adi pis cing elit nisl orem ipsum dolor sit amet, co nse ctetur](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
More Related Content
What's hot
What's hot (20)
Similar to Kanban highlights
Similar to Kanban highlights (20)
More from Yuval Yeret
More from Yuval Yeret (20)
Recently uploaded
Recently uploaded (20)
Kanban highlights
- 1. Kanban Highlights Yuval Yeret – Kanban Lead Agilesparks http:// linkd.in/kanbanisrael
- 3. Kanban @ Imperial Palace Gardens
- 5. Kanban in your wallet Henrik Kniberg Darn. Forgot to limit.
- 6. Kanban @ Toyota Supplier Buyer Henrik Kniberg Receive Consume Detach Ship Allocate Manufacture Taiichi Ohno Father of the Toyota Production System The tool used to operate the [Toyota Production] system is kanban. Adapted from Kiro Harada’s slide
- 7. Pull ...
- 9. “ People with different skills have to work together to deliver product features. Don’t build features that nobody needs right now. Don’t write more specs than you can code. Don’t write more code than you can test. Don’t test more code than you can deploy.” Corey Ladas Why pull? Why kanban?
- 13. ” One day in Kanban land” Henrik Kniberg http://blog.crisp.se/henrikkniberg/tags/kanban/
- 14. Scenario 1 – one piece flow Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing
- 15. Scenario 1 – one piece flow Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing
- 16. Scenario 1 – one piece flow Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing
- 17. Scenario 1 – one piece flow Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing
- 18. Scenario 1 – one piece flow. Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing
- 19. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 20. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 21. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 22. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 23. Scenario 2 – Deployment problem Henrik Kniberg B C A D F G H I J L K M !? E Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 24. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M !? Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 25. Scenario 2 – Deployment problem Henrik Kniberg B C A D E F G H I J L K M Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 26. Scenario 2 – Deployment problem Henrik Kniberg B A D E F G H I J L K M C Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 27. Scenario 2 – Deployment problem Henrik Kniberg B A D E F G H I J L K M C Next Dev Done Backlog 3 2 In production :o) Ongoing PO
- 28. The K anban Change Machine Performance Time Revolution (Scrum) Evolution ( K anban) (kanban the tool)
- 29. The K anban change machine Designed by David Anderson http://plixi.com/p/61319629
- 37. Pop Quiz Full story at http ://yuvalyeret.com/2010/08/03/finding-the-right-dev-to-test-ratio-when-working-in-kanban / A lot of WIP in Test Empty Test Done Empty downstream (Bubble) Dev Done almost Full
- 38. How to deal with a test bottleneck How can I help current stories? Help us with Blocker Fix open defects on our Stories Help us automate tests for this story WIP Limit! Can’t start new DEV work!
- 39. How to deal with a test bottleneck How can I help you be more efficient? Help us do ATDD so you can develop based on our test expectations, and also offload some automation effort from us Automate Setups and Test Data Improve Dev Done quality! – less retesting for us Half of our work is not core test work. Maybe you can take some of it, or help us reduce waste there Come pair with us, you’ll probably see things from our perspective and have some ideas how to help! Creating more Blue Light - TOC
- 40. Cycle Time - Driving towards earlier feedback
- 41. Agile is all about early feedback – why?
- 42. Let’s start with a classic burndown/burnup chart
- 43. So we want to get to this…
- 44. How do we Visualize the work status in more depth? TODO Work in Process (WIP) Done
- 46. How to do a CFD Elad Inbar Elad Mushon Mushon Inbar Inbar Mushon Elad
- 47. How to do a CFD
- 48. What can teams learn from Cumulative Flow? Work in Process (WIP) Average Cycle Time Real Done Burnup Total Scope Dev Burnup Done Burnup
- 50. What we learn here Despite agile iterations, still cliff at the end Big gap between Dev and QA How much work is queued vs QA WIP? No visibility We want to iterate in a sustainable pace all the way to DONE DONE, not just to Done
- 51. Release Tracking using CFD total scope trend - assuming freeze from today Trend of “Done” Needed done rate to meet timeline/scope goal Note scope target is also from a specific lane (where all the scope for this timeline waits. Future scope is in earlier lanes)
- 52. Variability inherent to Creativity Build a system to DEAL with it
Editor's Notes
- blood cells, arteries, oxygen, heart beat
- Start with what you do now The Kanban Method does not ask you to change your process. It is based on the concept that you evolve your current process. There is no sweeping, engineered change to a new process definition or style of working. There is no such thing as the Kanban Software Development Process or the Kanban Project Management Method.
- Agree to pursue incremental, evolutionary change The organization (or team) must agree that their current circumstances warrant a gentle, evolutionary approach to improvement. Perhaps a sweeping engineered change has recently failed due to resistance from team members, or perhaps the politics of the organization make it too risky for managers to propose and implement sweeping changes? Without agreement that a slow, gentle, evolutionary, incremental approach is the right way forward then there won’t be the right environment or management support for a Kanban initiative.
- Empty after testing, development in done testing busy bottleneck in testing This is a classic bottleneck in an R&D team. Testing are at their work in progress limit, meaning they cannot take on more work. Acceptance has no work in progress, what we call a “bubble” Development are at their limit as well. Nothing from Testing is DONE waiting to be pulled, which explains why Acceptance has a bubble
- Empty after testing, development in done testing busy bottleneck in testing This is a classic bottleneck in an R&D team. Testing are at their work in progress limit, meaning they cannot take on more work. Acceptance has no work in progress, what we call a “bubble” Development are at their limit as well. Nothing from Testing is DONE waiting to be pulled, which explains why Acceptance has a bubble
- Automation – not just test automation! How can we help you spend more time actually testing (compared to setup, and other wastes) ( http://theoryofconstraints.blogspot.com/2007/06/toc-stories-2-blue-light-creating.html ) How often do we need to retest? Why? ATDD - drives better code into testing, as well as offload some testing work Agree on “READY for Testing” criteria for stories, setup relevant team rules and processes.
- In traditinal first feature developed first and only when release ended move to QA So code is waiting for a long time until start testing The blue line – to ask what do u think it means at the end that move up – (regression)
- From Dennis Stevens http://www.dennisstevens.com/2010/06/30/shorten-and-reduce-variability-in-lead-times-using-kanban/ : Wimbledon Okay, so there are some benefits to reducing variability and duration in lead time. But, how can you reduce lead time duration and variability without inhibiting the creativity required to do the work. Wimbledon provides some insight into this. At Wimbledon, the games take as long as they take. The number of games played is determined up front – they have to play all the games. There are Men’s and Women’s Singles, Men’s and Women’s Doubles, Mixed Double’s and many players participate in multiple events. Games can’t play in darkness (except on center court). Games can’t be played in the rain. Players can’t overlap doubles with mixed doubles or with singles play. Wimbledon has been played 142 times and the finals have been delivered late twice. That’s pretty amazing given the wide level of variation in the length of games and the other constraints that must be addressed. How does Wimbledon accomplish this? They have policies that impact the timing of the games – for the most part without impacting the way the game is played. For example: A tie breaker in the first four sets. This tie breaker is open ended as it requires a player to win by two points – only the final set requires winning by two games. Games can start earlier on a day if games are behind. The gap between games can be shortened to get in additional play each day. The tournament director may have players warm up on other courts to bring games closer together. Additional courts can be opened for play as long as it doesn’t create a conflict across events. They minimize the impact of rain by covering courts during rain delays. They have added lights and a roof over Center Court to allow games to run longer and during rain. Combined, these policies allow the games to take as long as they take – while allowing the tournament to deliver a fixed number of games in a fixed time.
- Reduce Waiting How much time is a work item actually actively being worked on? If you pay careful attention to flow of work through your system you will likely find that a typical work item spends more time waiting to be worked on then being worked on. It is not unusual to find 5-10x wait time to work time. With wait time being a large portion of lead time, reducing wait time will have a significant impact on reducing lead time. Limiting WIP and pulling work are key techniques to reducing waiting. Rework: Or Failure Load Another big cost on lead time – and typically a huge impact on variability – is rework. Rework is the result of a defect that unintentionally escapes from one work queue and is identified in another. The result is that work moves backwards through the system – increasing lead time not just of the current work item, but of other work items. Leveraging techniques that minimize or eliminate rework are important to reducing variability and duration of lead time. Test driven development, automated test frameworks, continuous integration, and coding standards are methods of reducing or eliminating rework. Investing into reducing rework reduces lead time duration and variability. Making Work Ready One cause of variability and extended lead times is when work is pulled that isn’t ready to be worked on. This can happen when dependent work items aren’t prepared, required external resources aren’t standing by, or when the outcome (not the how) is not well understood. Making work ready requires understanding and aligning dependent work items. Minimizing dependencies during design helps reduce negative impact. Using scheduling methods like Kanban to schedule external (non-instantly available) performers helps coordination of external performers so work can continue to flow. Feature injection, where outcomes are defined during analysis and presented as testable examples is an excellent method of understanding and clearly communicating the expected outcome. Extra effort put into making work ready often results in reduced lead time. Relatively Small and Similar Size Work Large work items – or high variability in size and complexity of work items will result in higher variability and duration of work items. Breaking work into relative small and similar size work is a good method for reducing variability and duration of lead time. Breaking solutions down into small work can also result in improved design, higher testability, and more flexibility in the solution. This doesn’t mean that work should be broken down arbitrarily. Work should be broken down to the smallest level that is reasonable and no smaller. Swarming Swarming is when team members work together on work items to move them forward faster. Sometimes this is increasing the number of developers doing development – often it involves having generalists work in areas outside of their specialization. You will want to have the performers work on work items that are in risk of being late against their SLA.