Kanban highlights
Upcoming SlideShare
Loading in...5
×
 

Kanban highlights

on

  • 8,893 views

Highlights of Kanban from Agilesparks Training for Managers

Highlights of Kanban from Agilesparks Training for Managers

Statistics

Views

Total Views
8,893
Views on SlideShare
3,614
Embed Views
5,279

Actions

Likes
2
Downloads
186
Comments
0

17 Embeds 5,279

http://www.agilesparks.com 3447
http://agilesparks.com 1555
http://yuvalyeret.com 91
http://ubuntu.samity.org 60
http://www.agilesparks.co.il 40
http://localhost 35
http://46.38.173.170 30
http://feeds.feedburner.com 5
http://agilesparks.co.il 4
http://webcache.googleusercontent.com 3
https://app.unbounce.com 3
http://googleads.g.doubleclick.net 1
http://twitter.com 1
http://translate.googleusercontent.com 1
http://www.agilesparks.com. 1
url_unknown 1
http://www.google.co.il 1
More...

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

CC Attribution-ShareAlike LicenseCC Attribution-ShareAlike License

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment
  • 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.

Kanban highlights Kanban highlights Presentation Transcript

  • Kanban Highlights Yuval Yeret – Kanban Lead Agilesparks http:// linkd.in/kanbanisrael
  • Analysis Development Acceptance Prod Next
    • Definition of Done:
    • Customer accepted
    • Ready for production
    Ongoing Done
    • Definition of Done:
    • Code clean & checked in on trunk
    • Integrated & regression tested
    • Running on UAT environment
    Ongoing Done Ongoing Done
    • Definition of Done:
    • Goal is clear
    • First tasks defined
    • Story split (if necessary)
    2 3 3 2 Feature / story = completed = blocked = who is doing this right now 2009-08-20 2009-09-30 (description)
    • Panic features (should be swarmed and kept moving. Interrupt other work and break WIP limits as necessary)
    • Priority features
    • Hard deadline features (only if deadline is at risk)
    • Oldest features
    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
  • Kanban @ Imperial Palace Gardens
  • Kanban
    • Signaling system
    • Visual
    • Limited in supply
    Henrik Kniberg 看板 ” Visual Card”
  • Kanban in your wallet Henrik Kniberg Darn. Forgot to limit.
  • 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
  • Pull ...
  • “ 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?
  • How is it different than a taskboard?
    • taskboard provides visibility to where a task is in the workflow
    • Storyboard/Kanban Provides visibility to where a story is in the workflow
    • This raises the focus on flowing stories
    • Storyboard != Kanban board. Need WIP Limits to become kanban
  • Electronic Kanban
  • ” One day in Kanban land” Henrik Kniberg http://blog.crisp.se/henrikkniberg/tags/kanban/
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • 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
  • The K anban Change Machine Performance Time Revolution (Scrum) Evolution ( K anban) (kanban the tool)
  • The K anban change machine Designed by David Anderson http://plixi.com/p/61319629
  • Kanban approach to change
    • First - adopt the foundational principles ...
      • Start with what you do now
      • Agree to pursue incremental, evolutionary change
      • Respect the current process, roles, responsibilities & titles
    http://agilemanagement.net/index.php/Blog/the_principles_of_the_kanban_method/
  • Kanban – managing the end to end flow
    • Visualize the workflow
    • Limit WIP (work in progress)
    • Measure & optimize flow
    • Explicit policies (definition of Done, WIP limits, etc)
    • Improve Collaboratively ( using models & the scientific method )
    Henrik Kniberg Backlog Dev Done UAT Deploy 5 3 2 3 Pioneered by David Anderson in 2004 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 FLOW Avg lead time: days 12 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
  • Start with what you do now
    • Kanban doesn’t ask you to change your process, especially not up front
    • You EVOLVE your current process
    • There is no
      • Kanban software development process
      • Kanban Project Management Method
  • AGREE to pursue incremental, evolutionary change
    • Use in circumstances that warrant a gentle, evolutionary approach to improvement
    • For example:
      • Big change recently failed due to resistance
      • Politics make it risky to run a big change
      • Need to gain trust in the Lean/Agile direction
    • Warning: Without this the Kanban method will have a hard time.
    • If a revolution is REALLY* expected, don’t use the Kanban method. You CAN use a kanban pull system though.
      • Sometimes executives say they want a revolution, but either think otherwise when understand the implications, or are blind to the resistance levels within
  • Respect the current process, roles, responsibilities and job titles
    • Eliminate initial fear
      • Gains broader support for the Kanban initiative
    • Roles might evolve in the future
      • If/When it makes sense
      • By then, the organization connects the change to a real pain, and have trust in the Kanban system
  • Kaizen Continuous Improvement
    • Core kanban - WIP Limit
      • encourages “Stop the Line” mentality.
      • fix the problem, don’t hide it by working on something else or creating “inventory”.
    • Recommended Agile practices to add:
      • Daily Stand-ups
        • Deal with problems in Real time.
      • Retrospectives
        • See the bigger picture – deal with systemic problems.
        • Inspect and adapt – continuously improve.
  • Thinking Tools
    • Lean Thinking –
      • Deliver Fast – to improve time to market and reduce waste
    • Goldratt Theory of Constraints –
      • Bottleneck Thinking
    • Queuing Theory
      • Deal with variability
  • 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
  • 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!
  • 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
  • Cycle Time - Driving towards earlier feedback
  • Agile is all about early feedback – why?
  • Let’s start with a classic burndown/burnup chart
  • So we want to get to this…
  • How do we Visualize the work status in more depth? TODO Work in Process (WIP) Done
  • The Cumulative Flow Diagram
    • Introduced in Lean Product Development by Don Reinertsen and David Anderson
    • Visualize where the Features/Stories are in the workflow across time
    TODO Work in Process (WIP) Done
  • How to do a CFD Elad Inbar Elad Mushon Mushon Inbar Inbar Mushon Elad
  • How to do a CFD
  • What can teams learn from Cumulative Flow? Work in Process (WIP) Average Cycle Time Real Done Burnup Total Scope Dev Burnup Done Burnup
  • Work in Process
    • High Work-in-process leads to longest lead times
    • Low work-in-process greatly reduces lead times
    • Results in more effective and safer projects
  • 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
  • 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)
  • Variability inherent to Creativity Build a system to DEAL with it
  • So what do you do?
    • Assume SOME variability
    • Visualize Variability
    • Control Variability VIA
      • Relatively Small and Similarly sized Work
      • Make work Ready
      • Swarming / Collective Ownership
      • Reduce Rework/ Failure Load
  • Visualize Variability
  • Summary
    • Limit work in process:
    • Stop starting, start finishing
  • http://www.agilesparks.com/kanban
      • @yuvalyeret
      • www.linkedin.com/in/yuvalyeret
      • Blogging @ http://yuvalyeret.com
    • Presentations at http://www.slideshare.net/yyeret/
      Agile Professionals in Israel - I'm  there  - Are you?