• Like
  • Save
Advanced kanban overview for waterfall & scrum practitioners  (16x9 deck)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

Advanced kanban overview for waterfall & scrum practitioners (16x9 deck)

  • 299 views
Published

Advanced kanban overview for waterfall & scrum practitioners (16x9 deck)

Advanced kanban overview for waterfall & scrum practitioners (16x9 deck)

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
299
On SlideShare
0
From Embeds
0
Number of Embeds
3

Actions

Shares
Downloads
1
Comments
0
Likes
5

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • References:
    http://www.solutionsiq.com/resources/agileiq-blog/bid/87799/What-is-Scrumban http://www.agilevelocity.com/kanban-vs-scrum-how-to-choose https://www.scrum.org/Portals/0/Documents/Scrum%20Guides/2013/Scrum-Guide.pdf http://www.crisp.se/file-uploads/Kanban-vs-Scrum.pdf (Chapter 6) http://leansoftwareengineering.com/ksse/scrum-ban/ http://www.eylean.com/blog/2013/04/scrum-vs-kanban-vs-scrumban-iterations-work-routines-and-scope-limits/ http://www.netobjectives.com/blogs/why-contrasting-scrumban-and-kanban-belies-lack-understanding-both http://www.ontheagilepath.net/2013/09/scrum-kanban-scrumban-fast-overview-and.html Kanban Applied to Software Development: from Agile to Lean What is Best, Scrum or Kanban?
  • Proto-Kanban is a term used for teams new to kanban method, and is not meant to be derogatory term such as scrum-butt.
  • “Stop Starting, Start Finishing” booklet exemplifies how to conduct daily standups in kanban.
    Feedback loops are not limited to those three. Some advanced practitioners found interesting, custom organizational feedback loops that help them evolve their departments in a way that helps the whole company seek, contextual fitness for purpose.
  • There are 3 primary metrics in kanban: average lead time, due date performance, and flow efficiency.
    There is growing trend of using Monte-Carlo simulation based to forecast delivery dates for planning fixed bid projects.
  • I request you all to not consider cycle time as far as kanban/scrumban team metrics are of your concern. Here is why:

    Even though there are well-established definitions of lead time & cycle time on the lean glossary of terms, those apply to lean manufacturing world, not always to knowledge work. In contrast, just like Stefan Roock’s blogpost, vendors like Rally (on this Rally help page) have defined cycle time as time from “WIP” to “accepted”, and I tend to agree with that definition for knowledge work.
     
    However, in past few months after my advanced Kanban coaching related training, I have had several discussions with various scrum/kanban experts on this and they don’t find cycle time practical for Kanban workflows. David J Anderson’s Kanban book (called “the blue book”) is considered equivalent of scrum guide in the lean Kanban community, and the blue book does not even mention the term “cycle time”. At a recent lean Kanban retreat, the practitioners of the Kanban method (David J Anderson & his disciples) decided not to recommend use or application of cycle time, since cycle time is not as important to the “customer”, even though it may be dearer to the delivery/product team management. There is an excellent blog post that mentions this with examples: The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
     
    There is more continuous improvement happening in the Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team kaizen survey)  or Hakan Forss (known to popularize flow efficiency metric as the primary Kanban metric).
     
  • I request you all to not consider cycle time as far as kanban/scrumban team metrics are of your concern. Here is why:

    Even though there are well-established definitions of lead time & cycle time on the lean glossary of terms, those apply to lean manufacturing world, not always to knowledge work. In contrast, just like Stefan Roock’s blogpost, vendors like Rally (on this Rally help page) have defined cycle time as time from “WIP” to “accepted”, and I tend to agree with that definition for knowledge work.
     
    However, in past few months after my advanced Kanban coaching related training, I have had several discussions with various scrum/kanban experts on this and they don’t find cycle time practical for Kanban workflows. David J Anderson’s Kanban book (called “the blue book”) is considered equivalent of scrum guide in the lean Kanban community, and the blue book does not even mention the term “cycle time”. At a recent lean Kanban retreat, the practitioners of the Kanban method (David J Anderson & his disciples) decided not to recommend use or application of cycle time, since cycle time is not as important to the “customer”, even though it may be dearer to the delivery/product team management. There is an excellent blog post that mentions this with examples: The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban
     
    There is more continuous improvement happening in the Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getkanban.com game creator), Christophe Achouizntz (known for Kanban team kaizen survey)  or Hakan Forss (known to popularize flow efficiency metric as the primary Kanban metric).
     
  • Kanban team assessments tend to be much broader due to serviceability agenda of kanban, when compared with product-focused scrum team assessments. Let’s see why!
  • Kanban assessment focusses around these “skills”: visualization, WIP limiting, Flow management, explicit policies (e.g. we will expedite work 3 days prior to due date), Feedback loops (daily, input queue replinisment & ops-reviews) and improvements (kaizen aspect).
  • The colors indicate the questions from the survey that reflect the kanban depth: teams need to move from red (inner-most) to green (outer-most) “color”.
  • The colors indicate the questions from the survey that reflect the kanban depth. I am interacting with @ChrisAch on the spreadsheet based survey created out of these questions, to define & refine those via a crisp glossary of terms he used in this survey.
  • In summaryKanban is a catalyst for change through small, incremental improvements to your existing process – be it scrum or otherwise.
    Rooted in lean manufacturing, kanban is a signaling system that can be effectively applied to software development, DevOps, IT operations, and many other processes.

Transcript

  • 1. Advanced Kanban Overview for Waterfall/Scrum Practitioners
  • 2. Advanced Kanban Overview Top 5 Topics for Discussion: 1. Compare “Toyota kanban” (aka TPS) with “software kanban” (aka “K”anban) 2. Scrum vs. Scrumban vs. Kanban Evaluator 3. Feedback Loops in Kanban 4. Kanban Metrics 5. Kanban Depth Framework- A Model for Kanban Team Assessment
  • 3. Compare Kanban for lean manufacturing (aka TPS) With Kanban for knowledge work (aka “K”anban)
  • 4. Kanban for lean manufacturing TPS (Toyota Production System) invented “kanban” • In Lean Manufacturing, a kanban is a signaling device that gives authorization and instructions for production or withdrawal (conveyance) of items in a pull system. Kanbans maintain inventory levels; a signal is sent to produce and deliver a new shipment as material is consumed. These signals are tracked through the replenishment cycle and bring extraordinary visibility to suppliers and buyers. Purpose: Logistic control system Implemented at: Toyota Date implemented: 1953 Toyota's Six Rules from TPS 1. Later process picks up the number of items indicated by the kanban at the earlier process. 2. Earlier process produces items in the quantity and sequence indicated by the kanban. 3. No items are made or transported without a kanban. 4. Always attach a kanban to the goods. 5. Defective products are not sent on to the subsequent process. The result is 100% defect-free goods. 6. Reducing the number of kanban increases the sensitivity. Source: Ohno, Taiichi (1988)
  • 5. Source: : David J Anderson (2010) Kanban for knowledge work • David J Anderson created “K”anban, now known as Kanban Method. Kanban for knowledge work is a management method of just-in-time delivery based on capacity to do work. As such, here the focus is not to overload the team members. • In kanban, the process workflow, from definition of work to its delivery to the customer, is displayed for participants to see and team members pull work from each queue. • Kanban for software development means a visual process management system that tells what to produce, when to produce it, and how much to produce-inspired by the Toyota Production System and Lean Manufacturing. • For more details on “Kanban (Method)”, please check out this wikipedia page.
  • 6. You may have used or seen a kanban board for running events like conference or even hackathon. Whenever a team starts visualizing work with a kanban board, that team is doing proto-kanban! Done Proto-Kanban Development Testing 2 ∞ AB P1 E F I Engineering Ready Deployment Ready G D GY PB MN Ongoing Done Verification Acceptance 3 3 DE Explicit policies & WIP Limits based on queues (aka lanes or columns) Lead time ends at 1st infinite queue! There could be additional queues with no WIP limit. Lead time “clock” starts at the 1st queue aka input queue!
  • 7. Done Development Testing 3 3 2 ∞ AB P1 E F 2 DE I Engineering Ready Deployment Ready G D GY PB MN Ongoing Done Verification Acceptance 1 Expedite 2 Fixed Date 3 2 Standard Intangible Lead time ends at 1st infinite queue! Lead time “clock” starts at input queue! Defect& Tech Debt (30%) NPD i.e. New Prod Dev (60%) Innov ation (10%) Getting Beyond Proto-Kanban Getting beyond visual board: Hedge risk by allocating capacity, by defining WIP limits to shape demand (total WIP) for queues/swimlanes. Explicit policies & WIP Limits based on classes of service & work type! 5 1
  • 8. From proto-kanban to kanban: A Practitioner’s Way to improve Flow Efficiency A team improves its average lead time and flow efficiency by applying explicit policies, WIP limits for queues/swim-lanes, at regular cadence! Mature kanban teams calculate lead time when accepting cards flowing on the physical/virtual card wall, with scrumban-style regular cadence. After participating in release planning, such kanban teams commit to iterative development/support on a cadence so as to finish in 1-2 weeks. Rallying with virtual kanban board & syncing physical card wall with it! That’s one way to do scrumban!
  • 9. Scrum vs. Scrumban vs. Kanban Evaluator Scrumban Level 1 - Scrum but no commitment to the content - Teams get most value out of daily standups, retrospectives, grooming and to a lesser degree planning (at least some planned work is done) - Aim to empty the queue in each timebox - Don't split stories Scrumban Level 2 - Essentially Kanban but timeboxed - It forces stories to be broken down so work is completed (versus open ended Epics) - Aim to empty the queue in each timebox - Don't split stories
  • 10. Scrumban & Kanban: Do Planning to fill available (not all) slots User Story Template • scrumban/kanban process is about moving story/task/activity cards as fast as you can across the value stream to have shortest lead time. This requires slightly different way to look at requirements than following scrum-style user story templates. – So while it does help when you use a user story template with tasks associated for teams that prefer that kind of card on their board, it can very well be at a granular activity level if all other cards on the board are of similar size and they are also activities rather than stories. Unlike scrum framework, in kanban (and scrumban) there is no need to take a particular stance on this. – Stories hover around typical size for kanban/scrumban teams (e.g. 3,5,8 if average size is a 5 pointer story). • Kanban manifesto could very well begin with this one liner: We prefer having typical sizes over following user story template! – decomposition- using patterns for splitting work (i.e. slicing user stories)- remains same since in scrumban we now have kanban board with timebox. Feedback mechanism • This is another area where contrasting scrumban with scrum and kanban makes a lot of sense, based on Corey Ladas's blog about scrumban. In scrumban (and kanban), focus of planning is on filling the available (not all) slots. Timeboxing • Scrumban does not distinguish between sprints/releases. It’s better to call it "timebox". – That way folks will know that in scrumban, burndown is less important than Lead Time and Cycle Time. – Here are quotes from the scrumban creator Corey Ladas whose blog exemplifies this. Read on these 3 excerpts:
  • 11. Burndown is less important than Lead Time and Cycle Time "With the pull system in place, our flow will become smoother as our process capability improves. We can use our inter-process buffers and flow diagrams to show us our process weaknesses and opportunities for kaizen. As we get closer to level production, we will start to become less concerned with burndown and more concerned with cycle time, as one is the effect and the other is the cause. Average lead time and cycle time will become the primary focus of performance. If cycle time is under control and the team capacity is balanced against demand, then lead time will also be under control. If cycle time is under control, then burndowns are predictable and uninteresting. If burndowns are uninteresting, then goal-setting and risky heroic efforts are unnecessary. If burndowns are uninteresting, then iteration backlogs are just inventory for the purpose of planning regularity and feeding the pull system. As such, they should be the smallest inventories possible that optimize planning cost."
  • 12. Sprint backlog- Smallest Inventory to Optimize Planning Cost "A simple mechanism that fits the bill is a size limit for the iteration backlog. Rather than go through the trouble of estimating a scope of work for every iteration, just make the backlog a fixed size that will occasionally run to zero before the planning interval ends. That’s a simple calculation. It’s just the average number of things released per iteration, which in turn is just a multiple of average cycle time. So if you have 5 things in process, on average, and it takes 5 days to complete something, on average, then you’ll finish 1 thing per day, on average. If your iteration interval is two work weeks, or 10 work days, then the iteration backlog should be 10. You can add one or two for padding if you worry about running out. This might be a point that’s been lost on the Scrum community: it’s never necessary to estimate the particular sizes of things in the backlog. It’s only necessary to estimate the average size of things in the backlog. Most of the effort spent estimating in Scrum is waste."
  • 13. Why estimate the average size of things in the backlog? "In our final incarnation of Scrumban, iteration planning still happens at a regular interval, synchronized with review and retrospective, but the goal of planning is to fill the slots available, not fill all of the slots, and certainly not determine the number of slots. This greatly reduces the overhead and ceremony of iteration planning. Time spent batch processing for iteration planning estimation can be replaced with a quality control inspection at the time that work is promoted to the ready queue. If a work item is ill-formed, then it gets bounced and repeat offenders get a root cause analysis."
  • 14. Process Framework Evaluator – An Example Questionnaire Questions Explanation Planning: Despite the PO trying to do so, is it impossible to lock down the scope for your chosen timebox? Do you have more than 25% scope churn during the chosen timebox? Scrum: Scrum works best when requirements are stable for the duration of the Sprint so that the team can commit to their delivery. Kanban: Some scope change can be accommodated. By dropping the fixed timebox, Kanban can allow teams to adapt more easily to quickly changing priorities. Scrumban: Iteration planning is done at a regular interval, with the goal of planning is to fill the slots available - not fill all of the slots, and certainly not to determine the number of slots. Decomposition: Even after trying your best, is it impossible to break features into incremental pieces of value to be delivered within the chosen timebox? Both Scrum and Kanban work best when you break your work down into small incremental pieces. The Scrum Sprint timebox can help new teams recognize deficiencies (work not completed at the end of the sprint) and adapt (retrospective). Scrumban: Can you decompose work to lock scope for the timboxed duration? Estimation: Is it hard or impossible for the team to size the work in the chosen timebox? Does estimation take more than 3 hours? Kanban: Kanban removes the overhead of estimation in favor of measuring cycle time for like sized items. Work should be comprised of similarly sized activities for Kanban. Scrum: Scrum absolutely requires that all work be estimated so that the team can commit to the sprint. Scrumban: Scrumban does not require estimation. Responsiveness: Is your top priority to optimize responsiveness to customer needs? Must work begin in the current timebox (cannot wait until the next one)? Kanban has a strong focus on cycle time, where Scrum has a stronger focus on Velocity. Both can be tuned to provide very similar output, but Kanban has the flexibility to lower batch size to reduce cycle time at the potential cost of productivity. Predictability & Productivity: Is your top priority predictability and productivity for larger projects? You can achieve predictability and a high level of productivity using any agile framework. Scrum provides more guidance on how to handle release planning and progress tracking so is preferable for new teams. Process Oriented Culture: Does your team culture demand a higher degree of process ceremonies? Although Scrum has fewer ceremonies and artifacts than many other methodologies, it has more than Kanban and can more easily be integrated into a culture requiring them. Shared Team Members: Do you share engineers with other teams? Does your team lack all the required skills to complete the work? Scrum: Scrum teams work best when they do not have dependencies on people outside of the team . Kanban: With Kanban, others can see when there is work for them to do and pick it up at that time. Variety in work (complexity & size): Are your work items of approximately similar size & complexity? Both Scrum and Kanban work very well with similar sized work items. However, in Kanban the variability between different sized items makes it difficult to adhere to SLAs.
  • 15. Primary Feedback Loops in Kanban Kanban has three primary feedback loops: 1. Daily standups (team level) 2. System capability review (team/department level), and 3. Ops review (organizational). Kanban includes many retrospective feedback loops, focused on various aspects of improvement and closing daily, monthly and every time in between.
  • 16. Implement Feedback Loops in Kanban • Daily Standups – First level of feedback is daily standups, where team collaborates to review flow of work and demand versus capability measures, metrics and indicators. – Why are daily standups in kanban are done differently than “daily scrums”? • Purpose of primary feedback loop - daily standup - in kanban – The focus of a kanban daily standup is on “flow”, with sanity check on WIP limits set for queues and swim-lanes. Your read the kanban board from right to left, as if the team were to read an Arabic poem! Watch what’s due in expedite, intangible & any other work-type specific swim-lanes, where the bottlenecks are developing, what is blocking the flow. – It’s no more about the scrum-style “3 questions” format then. • With that, size of a kanban team is not the issue, so team size can exceed the scrum team size of 5-9. • Daily standups result in the team/workgroup-level problem-solving activities that foster collaboration. • System Capability Review – Second level of feedback is known as system capability review – this is where the demand is shaped (replenished) at cadence based on average lead time. (We will revisit “shaping demand” when discussing average lead time, later.) – This feedback is at the level of the team, workgroup, department or business unit. • Ops Review – Third level of feedback - operations review – is where organizational process improvements occur beyond a localized team level, to realize full benefits of Kanban.
  • 17. 160 140 120 100 80 60 40 20 0 48 1 6 9 1217202326293235384144475053 3 6 9 12151821242730333639 2012 2013 2014 Throughput (# of resolved tickets / week) Average Lead Time / week Average Flow Efficiency % / week Kanban Metrics * Lead Time Distribution indicates Predictability * Average Lead Time impacts SLA Adherence * High Productivity means better “Flow Efficiency” * Monte-Carlo forecasting for planning fixed bid projects How do you coach a kanban team on adjusting their "Total WIP“? By observing trends in throughput, lead time & flow efficiencies! Apply Little’s law: Total WIP (for each workday) = Avg. delivery rate (per workday) * Avg. lead time (in workdays)
  • 18. Lead Time Distribution indicates Predictability • Lead Time Distribution Curve – Average lead time helps “shape demand” by coming up with a cadence for replenishing input queue for “planning” work intake. – Team can try to reduce the average lead time by doing scrum-style decomposition. – Example stats: Lead Time Stats 33.80435 (Average) 26.5 (Median) 0 (Mode) • Analyzing Lead Time Distribution Curve – Have you ever wondered how we measure lead time in Kanban and how we make use of them? – Alexei Zheglov has posted a couple of insightful articles on how to analyze, measure and understand lead time. Click to read more - • Analyzing the Lead Time Distribution Chart • Inside a Lead Time Distribution • Introducing Lead Time Forecasting Cards • Lead Time and Iterative Software Development – Alexei Zheglov shows how scrum teams can analyze 10 8 6 4 2 0 lead time distribution curve using mode, median, average and 75 percentile values of lead times as shown here: Lead Time Distribution (Frequency Curve) 0 10 20 30 40 50 60 Frequencies Lead Times Lead Time Frequencies Smoother frequency curve is better!
  • 19. Average Lead Time impacts SLA Adherence • Due Date Performance – For SLA adherence for classes of service, Due Date Performance metric can be used. – In this example, the +ve numbers indicate few missed SLAs, whereas the –ve numbers indicate that the SLAs were met on time or even earlier. 7/30/2014 6/10/2014 4/21/2014 3/2/2014 1/11/2014 11/22/2013 10/3/2013 Acceptance Dates Due Date Performance Accepted Date earlier (i.e. on time or before) is better! -50 0 50 100 150 200 250 300 350 SLA Adherence – According to Russell Healy, creator of getkanban board game: +ve and -ve values should not be treated equally. The cost of delay for a fixed delivery date item is a "Heaviside step function" (http://en.wikipedia.org/wiki/Heaviside_step_function) modified for the opportunity cost incurred for -ve values of x. Go figure!
  • 20. High Productivity means better “Flow Efficiency” Flow Efficiency metric • What percentage of lead time does a work item actually take end-to-end, on an average? By comparing lead time against the touch time (aka assigned time), we get “waste indicator”. • waste can be due to high WIP • waste can be due to wait/blocked times • How to compute Flow Efficiency? • It should be possible to create histogram based this formula: Flow Efficiency = “touch time” / “lead time” • Although very difficult to measure flow efficiency for knowledge work, histograms are useful • David Anderson mentions that 15% flow efficiency is quite normal for knowledge workers. In this example, max flow efficiency is 5.3%, with average of 0.6% which is too low. • What can teams do to increase it? 40 35 30 25 20 15 10 5 0 Flow Efficiency % Flow Efficiency (Ratio) Acceptance Dates higher % is better! It means there is not much waste! Flow Efficiency In other words: How do you use this metric to inspire teams to be even more productive? In order to improve flow efficiency , teams should try to reduce the WIP, so that less cards will have delays due to wait times and/or blocked times.
  • 21. Monte-Carlo forecasting for planning fixed bid projects Monte Carlo Simulation • Lean Kanban community & tool vendors recommend using Monte Carlo based forecasting for planning fixed bid projects, e.g. the forecast below: 120.00% 100.00% 80.00% 60.00% 40.00% 20.00% 0.00% Probability Projected Delivery time (days) Use the 85 percentile as the delivery time • Based on projected delivery time histogram above, Dimitar Bakarzhiev recommends using 85th percentile for commit point, which David Anderson talks about during his kanban training as well. Source: Dimitar Bakardzhiev
  • 22. Control Chart vs. “Time In Process” • Control Chart for Lead Time Variability Control chart can be used to determine lead time variability. It is a useful way to observe anomalies about out-of-control frequencies of lead times. In the example below, there are outlier lead times with values of greater than 80 days. Team should analyze special causes behind those outliers before ruling those out, to get smoother control “band”: 200 150 100 50 0 Control Chart for Lead Time Variability Lead Time Smoother control band is better! 10/3/2013 11/22/2013 1/11/2014 3/2/2014 4/21/2014 6/10/2014 7/30/2014 -50 Lead Times • Time In Process Acceptance Dates – This metric is specific to Rally Insights tool, and sounds very complementary to lead time, cycle time, and time to market. – Time in Process is the number of business days a typical user story is in the "In-progress" or "Completed" column. (i.e. not accepted yet). – Why is this Important? According to renouned metrics guru Larry Maccherone, Accurate planning & budgeting need accurate estimates. – Time in Process charting in Rally shows how long the median of Stories are in process.
  • 23. Kanban Depth Framework- A Model for Kanban Team Assessment
  • 24. Practitioners in smaller organizations have tended to adopt a relative assessment model Outer edge defines specific local goals Visualize Limit WIP Improvements Feedback Loops Activity Not present at Where we would Proto-Kanban level like to be Explicit Policies Manage Flow
  • 25. Assessing the Depth of a Kanban Implementation • See & Understand (WIP, Blocks, Queues) (13) 7 Lean 10 Effects 2 10 7 4 (12) 12 4 Necessary for sustainable improvements 6 • Improve Predictability • Reduced Task Switching • Reduced Lead times • Reduced Overburdening (quality, sustainability) • Improve continuously in a • Generate actionable feedback (information) from stakeholders to improve Feedback Limit WIP Loops (4) 1 2 5 2 3 Improving Sustainably 8 6 Excellence 2 3 10 • Increase Liquidity • Measure Flow / capability (WIP, throughput, Queues, lead time) • Defer Commitment (12) (11) (7) Improve (10) Visualize 10 6 • Set Standards to improve upon Explicit Policies Manage Flow sustainable way Source: Christophe Achouiantz –@ChrisAch
  • 26. Team: ________ Date: __/__/__ Visualize 1. Work (all, according to current policies) 2. Work Types 3. Workflow (“process”, way-of-working, value stream) 4. ‘Next’ & ‘Done’ 5. Current Team Focus (avatars) 6. Blocks 7. Current Policies (DoD, DoR, capacity allocations, etc.) 8. Ready for Pull (“done” within the workflow/in columns) 9. Metrics (lead-times, local cycle times, SLA targets, etc.) 10. WIP limits 11. Inter-work dependencies (hierarchical, parent-child, etc.) 12. Inter-workflow dependencies 13. Risk dimensions (cost-of-delay, technical risk, market risk) Limit Work in Progress 1. No WIP limit, but commitment to finishing work over starting new (eventually reaching a WIP level that “feels OK” for the team) 2. Some explicit WIP limits, at lower level than workflow (a.k.a Proto-Kanban): personal Kanban, WIP limit per person, WIP limits for some columns or swim-lanes, workflow with infinite limits on “done” queues, etc. 3. Explicit WIP limit at workflow level - Single workflow full pull 4. Multiple interdependent workflows with pull system Manage Flow 1. Daily planning meetings (as “daily” as agreed by policies) 2. Blocks out of team control are escalated for resolution 3. Next is re-prioritized continuously (no commitment in Next)- Deferred Pull decisions (dynamic prioritization) 4. CFDs (updated at least once a week) 5. Control Charts (updated at least once a week) 6. Size of ongoing work items is limited (large work is broken down) 7. Flexible staff allocation (swarming) 8. Cadence is established (planning, delivering, retrospective) 9. Flow metrics (number of days blocked, lead-time efficiency) 10. SLA expectations and forecasts (lead-time targets) 11. Capacity Allocations Make Policies Explicit - All Policies must be CURRENT (known & actually used) 1. Definition of Work Types and Work Item (template) 2. How to pull work (selection from ‘Next’/prioritization of WIP) 3. Who and when manages the ‘Next’ and ‘Done’ queues 4. Staff allocation / work assignment (individual focus) 5. Definition of Ready for ‘Next’ 6. Who, when and how to estimate work size 7. Limit size of work items (work breakdown) 8. How to select & prepare work for the ‘Next’ queue 9. Definition of Done at all steps (seen as a Target Condition) 10. Knowledge spreading/sharing strategy 11. Class-of-Service 12. Capacity allocation Implement Feedback Loops 1. Daily Team standups 2. Key stakeholders (mngt, customers, other groups) are regularly updated on the current situation 3. Managers go and see (walk the ‘gemba’) regularly 4. Regular discussions with upstream and downstream partners 5. Regular presentations and discussions about Financial performance 6. Regular presentations and discussions about Quality KPI (defect rate, customer satisfaction, etc.) 7. “Regularly” means once per month or more often Improve 1. The group knows why it exists and its criteria for success 2. Regular Retrospectives / Kaizen events 3. The team knows its current condition (may require metrics) 4. True North exists, is communicated and shared by the team 5. The team knows the current target condition (the challenge) 6. There is a validation criteria (test) for the current target condition to know when the target condition is reached 7. The team knows what obstacles are preventing them from reaching the target condition 8. The team knows what obstacle is being currently addressed 9. The team knows what is the next step in resolving the current obstacle (PDCA) 10. The team go and see what they have learned from taking that step Effects (seeing Evidence of…) 1. Team members are seeing and understanding the Big Picture (team-level vs. local situations) 2. Better “team spirit” (helping each-others to complete work, respect) 3. Focus on removing blocks 4. Focusing on finishing work rather than starting new work 5. Team is working on the “right” thing (“right” prioritization) 6. Limiting work to team’s capacity (limited stress, optimal lead-times) 7. Team has motivation to drive improvements 8. Local process evolution (visualization, workflow, policies, WIP limits) 9. Increase depth of Kanban implementation 10. Process evolution was model-driven 11. Process or management policy evolution as a result of mentor-mentee 12. Inter-workflow or management policy evolution due to operations review (13) (12) 7 Lean 10 Effects 2 10 7 4 12 4 Necessary 6 Feedback Limit WIP Loops (4) 1 2 5 2 3 Baseline 8 Excellence 6 2 3 10 (12) (11) (7) (10) Visualize Improve 10 6 Explicit Policies Manage Flow Source: Christophe Achouiantz – @ChrisAch 00 Current ”Score” Trend
  • 27. References & External Links There is more continuous improvement happening in Lean Kanban community with contributors like Arne Roock (known for “Stop Starting Start Finishing!”), Russell Healy (getkanban.comgame creator), Christophe Achouizntz (known for Kanban team assessment survey) or Hakan Forss (creator of flow efficiency metric as the primary Kanban metric). References • Pre-requisite #1: “STOP Starting, START finishing” by Arne Roock • Pre-requisite #2: Anderson, David (April 2010). Kanban - Successful Evolutionary Change for your Technology Business. Blue Hole Press. • Pre-requisite #3: Anderson, David (April 2012). Lessons in Agile Management- On the road to Kanban. Blue Hole Press. • Pre-requisite #4: Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas • External links – David Anderson’s blog posts & Henrik Kniberg’s blog posts – InfoQ eBooks by Henrik Kniberg & others [e.g. Jasper Boeg (2012-02). "Priming Kanban" (in English). InfoQ] – The difference between Cycle Time and Lead Time... and why not to use Cycle Time in Kanban – Scrumban - Essays on Kanban Systems for Lean Software Development by Corey Ladas – What is Kanban? by Joseph Hurtado – Aspects of Kanban by Karl Scotland – De-mystifying Kanban by Al Shalloway of Net Objectives – Kanban Applied to Software Development: from Agile to Lean – What is Best, Scrum or Kanban? – Kanban for Teams by Al Shalloway – Open Kanban Presentation – Open Kanban Documentation – LKNA conferences & related links • https://plus.google.com/113439681622341364754/videos • http://leankanban.com/case-studies • http://blackswanfarming.com/cost-of-delay/