Downloaded 203 times
Uploaded byLeanKit
Why Limit WIP?
This document discusses work-in-process (WIP) limits in Kanban systems. It explains that WIP limits help improve workflow by surfacing problems. There are three types of WIP limits: personal, team execution limits to improve flow, and organizational structural limits to provide focus. Managing WIP limits can be challenging due to variability, constraints, and personal work styles, but lowering WIP limits over time helps identify issues. The document recommends several resources for learning more about Kanban and WIP limits.
More Related Content
Why Limit WIP?
- 1. • Why it’simportant • Why It’s hard • What you can do about it Chris Hefley, CEO of LeanKit @indomitableHef Kanban: An Evolutionary Approach to Agility Why Limit WIP?
- 2. Chris Hefley, CEOand Co-founder of LeanKit, is a practitioner and thought leader in the global Lean/ Kanban community. In 2011, he was nominated for the Lean Systems Society’s Brickell Key Award. After years of coping with “broken” project management systems in the world of software development, Chris helped build LeanKit as a way for teams to become more effective. Prior to LeanKit, Chris worked with globally distributed teams in leadership positions at HCA Healthcare and IMI Health. He believes in building software and systems that make people’s lives better and transform their relationship with work. follow @indomitableHef ABOUT CHRIS HEFLEY
- 4. What is Work-In-Process? allmaterials and partly finished products that are at various stages of the process Value Demand that has been started, but is not yet providing value to the customer
- 5. What is Work-In-Process? Total Story Lead Time 30 days DevelopmentTime 5 Days (~ 15%) Testing Time 2 Days Defect Rework 2 Days Release / DevOps Time 1 Day Blocked and Waiting Time 9 Days Waiting Time 3 Days Waiting Time 8 Days By Troy Magennis, FocusedObjective.com – used by permission
- 6. What is Work-In-Process? Total Story Lead Time 30 days DevelopmentTime 5 Days (~ 15%) Testing Time 2 Days Defect Rework 2 Days Release / DevOps Time 1 Day Blocked and Waiting Time 9 Days Waiting Time 3 Days Waiting Time 8 Days By Troy Magennis, FocusedObjective.com – used by permission
- 7. What is Work-In-Process? Total Story Lead Time 30 days Story/ Feature Inception 5 Days Waiting in Backlog 25 days System Regression Testing & Staging 5 Days Waiting for Release Window 5 Days “Active Development” 30 days Pre Work 30 days Post Work 10 days
- 8. Total Story Lead Time 30 days Story / FeatureInception 5 Days Waiting in Backlog 25 days System Regression Testing & Staging 5 Days Waiting for Release Window 5 Days “Active Development” 30 days Pre Work 30 days Post Work 10 days 9 days (70 total) approx 13% What is Work-In-Process?
- 9. Partially Done Work HasZero Value
- 10. 1. Visualize yourWork 2. Limit your Work in Process 3. Focus on Flow 4. Continuous Improvement What is Kanban?
- 11. This is Greekto me. So are many/most project deliverables to non-specialists
- 12. A picture translatescomplexity into a simple pattern we can all digest
- 13. Ready In Process Done DevelopmentTest Done DeployIn Process Done F1 F2 F3 F4 D1 F5 (3) (3) (6) - Daniel and Stephen, Developers Yay! More Codez to write! This queue replenishment process is a example of “Push” - Jon (Product Manager) It’s my job to replenish the ready queue – I prioritize the top 6 items every 2-3 days Day 1
- 14. In Process Done DevelopmentTest Done DeployIn Process Done F1 F2 F3 F4 D1 F5 (3) (3)Ready (6) - Daniel and Stephen, Developers Finished One! Day 2
- 15. In Process Done DevelopmentTest Done DeployIn Process Done F1F2 F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 - Chris (Tester) Now I have something to pull - Jon (Product Manager) Better replenish the queue… Day 3
- 16. In Process Done DevelopmentTest Done DeployIn Process Done F1F2 F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 - Chris (Tester) This one is ready to deploy… Day 4
- 17. In Process Done DevelopmentTest Done DeployIn Process Done F1F2F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 - Scott (DevOps) I’m on it… Day 5
- 18. In Process Done DevelopmentTest Done DeployIn Process Done F1F2F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 Day 6
- 19. In Process Done DevelopmentTest Done DeployIn Process Done F1F2F3 F4 D1F5 (3) (3)Ready (6) F6 F7 F8 F9 - Chris (Tester) This one isn’t working… I’ll go ahead and pull some more to test… Day 7
- 20. In Process Done DevelopmentTest Done DeployIn Process Done F1F2 F3 F4 D1F5 (3) (3)Ready (6) F6 F7 F8 F9 F10 D2 F11 - Daniel and Stephen, Developers Rock and Roll… We’ve been very productive these last couple of days Day 8
- 21. In Process Done DevelopmentTest Done DeployIn Process Done F1F2 F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 F10 D2 F11 - Daniel and Stephen, Developers Oops…can’t do that…it would break the WIP limit What can we do to help? F2 is broken… Ok, we’re on it Day 9
- 22. In Process Done DevelopmentTest Done DeployIn Process Done F1 F2 F3F4 D1 F5 (3) (3)Ready (6) F6 F7F8 F9 F10 D2 F11 F12 Work is flowing nicely now… Day 10
- 23. In Process Done DevelopmentTest Done DeployIn Process Done F1 F2 F3 F4 D1 F5 (3) (3)Ready (6) F6 F7 F8 F9 F10 D2 F11 F12 - Scott (DevOps) Now we’re really getting some stuff done! Day 11
- 24. Why Kanban SystemsWork 1) The means to observe the flow of work 2) The mechanics to improve the flow of work (WIP Limits, Explicit Policies) 3) The evidence to show improvement, run experiments, and make adjustments A KANBAN SYSTEM GIVES YOU
- 25. From the Book:Stop Starting, Start Finishing, by Arne Roock
- 29. Three Kinds ofWIP Limits • Personal WIP Limits • Team (Execution) WIP Limits • Organizational (Structural) WIP Limits
- 32. The Zeigarnik effect: Whenwe finish tasks, we get closure and move on. When we don’t finish tasks—we don’t.
- 34. Managing Team (Execution)WIP Limits • Why: To Improve Flow • Challenges: –Variability –Constraints –Personal WIP
- 35. Lowering WIP Surfaces Problems From thebook: Implementing Lean Software Development: From Concept to Cash by Mary Poppendeick and Tom Poppendeick
- 38. Managing Organizational (Structural) WIPLimits • Why: Clear Focus, Limit Options to increase the chance of achieving goals • To Make It Work –Limit your options –Systems Thinking –Watch for Hidden WIP
- 39. Limiting WIP atLeanKit
- 40.
- 44.
- 45. 1. What arewe going to finish today? 2. What is needed to push this item over the line? 3. Is there any hidden WIP? All work is the Team’s Work
- 47. Resources • Stop Starting,Start Finishing, by Arne Roock • available on Amazon.com
- 48. Resources • The PhoenixProject, a Novel About DevOps, IT, and Helping Your Business Win, by Gene Kim, Kevin Behr, and George Spafford • available on Amazon.com
- 49. Resources • Why LimitWIP: We are Drowning in Work, by Jim Benson • Available in a 2-3 weeks at moduscooperandi.com
- 50. Resources • KANBAN Roadmap:How to Get Started in 5 Steps, by Chris Hefley and Liz Llewellyn • Available at the LeanKit booth at PathToAgility 2014 and at LeanKit.com • Download the electronic copy at http://leankit.com/path-to-agility
Editor's Notes
- #5 Let’s back up a moment and define WIP. According to the manufacturing industry definition, “work in process” refers to all materials and partly finished products that are at various stages of the process; therefore, it excludes the raw materials at the start of the product cycle and the finished products at the end.In knowledge work, this usually translates into value demand that has been started but is not yet providing value to the customer. Essentially, it’s an investment that has had zero return and depreciates in value over time.
- #11 So what is Kanban? There's more than one definition out there, but it boils down to a few basic principles. Visualize your workLimit your work-in-processFocus on FlowContinuous ImprovementThat's the order most people list them in, even those that have longer lists. Visualize Work is #1, and Limit your work-in-process is #2. But dammit, it's hard, really hard, to limit WIP. An enormous pressure has to be placed on existing systems, often to the point of breaking existing systems, to limit work-in-process. Well, dammit. Now we're back where we started. So, I think the order is backwards, honestly. There are lots of reasons to limit WIP, which we will discuss, but in terms of economic value to the organization, the primary reason to do it is that it improves flow. The Lean Manufacturing community learned a long time ago that a lot of economically good things just happen when you focus your attention on improving the flow of work, the flow of value to the customers. It turns out the same thing is true in knowledge work. Let's look at the flow of a typical work item through a typical process.
- #13 Visual Management using Kanban boards allows you to get a clear picture into the status of work, by using a shared visual language that your brain can interpret instantly, without having to read a lot of details about the work from a typical spreadsheet-like task list.
- #25 Why Kanban Systems workA Kanban System Gives youThe Means to observe the flow of workThe mechanics to improve the flow of workThe evidence to show improvement, run experiments, and make adjustments
- #26 So, what’s important is how much we finish. Not how much we start. Limiting our WIP gives us the level to make sure our team is focused on finishing work before starting on more work.
- #30 There are three different perspectives to consider when managing WIP limits: personal, team and organizational. A common mistake is to assume that the same approach for managing WIP limits will be effective at each of those levels. Take it from me that it won’t. In this post, I’ll share some of the observations, ideas and lessons that I’ve learned about managing WIP limits at the team (execution) level and at the organizational (structural) level.
- #31 Scientific Research has proven that those who self-identify as multi-taskersare the worst multi-taskers, when evaluated on how much the actually get done. Multi-tasking is a myth. Your brain can’t really do it, even though it thinks it can.
- #34 We have created an economy at work where busy-ness is valued over getting things done. It comes through in many ways, including how we are judged, the questions we ask, and the value we place on completed work.
- #35 At the team or execution level, one of the primary purposes of constraining WIP is to ensure a smooth flow of work through the system, thus reducing the amount of time it takes to deliver value to the customer. Limiting the team’s WIP serves as the “lever” to implement a pull system so the amount of work to be executed matches the capacity of the team. While it sounds straightforward in theory, in practice there are a number of challenges you’ll need to be prepared for.Three Common Challenges for Team WIP LimitsVariability. I’ve yet to work with a team that doesn’t confront massive levels of variability. Variability can be found in the form of demand, the nature and complexity of the work, associated risks, the cost of delays, outside expectations and influences, individual performance, team performance, interpersonal relationships, skill availability, outside dependencies, and the list goes on. Trying to get your head around each variability in isolation is challenging enough. Understanding the combined effect of these curves can be mind-boggling.Constraints. This challenge is tightly coupled to variability. We know that system constraints, or bottlenecks, define the overall capacity of the system. It would be extremely nice if a constraint remained stationary and consistent, but I’ve yet to be lucky enough to run across one that behaves so politely. Instead, I’ve found that the high variability of the system often prevents us from stabilizing the constraint, i.e.,“nailing the Herbie.” This makes it difficult at any point in time to confidently determine the capacity of the system.Interpersonal Dynamics. Introducing new concepts and change into a group can be tricky. This is especially true when it involves moving people outside of their natural state (see previous post). Inevitably, there will be members on your team who resist the idea of limiting WIP, but they might not show it in obvious ways.
- #37 Earlier I touched on interpersonal dynamics and that there will be people who struggle with WIP limits in different ways. This holds true at both the team and organizational levels. WIP limit resistance can often be the most difficult hurdle to overcome. I’ve had to teach myself to be very mindful of all the different perspectives and characteristics that need to be managed when trying to reduce the amount of WIP.Even the most well-intentioned people can develop bad habits that can derail a team’s effort to limit WIP if left unaddressed. Below is a light-hearted attempt to codify some of the common behaviors, in persona form, that can impede efforts to limit WIP.
- #39 Limiting the strategic focus of the organization is less about flow and more about clear focus and direction. Examples include limiting the number of concurrent strategic initiatives, the active projects in your portfolio or the number of new product features being developed.The goal is to define the work that delivers the most value to the organization, thus giving the teams responsible for executing the work a clear vision of the bigger picture. I think of this type of work definition as structural, providing the blueprints and superstructure of the work that will be done at lower levels. Structural and systems thinking tell us that more than 90% of the root causes of problems are systemic or structural, so taking the time to get this right is extremely important.Depending on the scale of the organization, there will be varying strategic levels to consider. These can range from the executive team defining the company strategy to the manager defining initiatives for the department.Four Actions to Make Organizational WIP Limits EasierLimit your options. Strategic ideas are typically conceptualized far quicker than they can be executed. Our natural human bias is to be overly optimistic and not consider all of the risks. As a result, we tend to introduce more structural initiatives than we have the capacity to work on. This has the unintended consequence of generating 10x-100x more work for teams at the execution level. Most organizations have a near limitless number of options for their time, money and people. This is the major factor preventing organizations from gaining focus and results in context switching. If you recognize that context switching is costly at the personal and team levels, imagine the exponential cost at the organizational level.Rotate your perception of the “system” 90 degrees. Your system incorporates top to bottom capacity, as well as the entire value stream at the execution level. Understanding along both of these planes is very difficult, especially as an organization scales in size. The team of executives must not view itself as an isolated system but understand that the WIP defined at strategic level should be driving all of the work at the levels below. Therefore, they should manage their WIP (the work being delegated downward) using the same concepts applied at the team level. Loading an organization to 100% capacity at the strategic level has the same effect as it does at the execution level: total gridlock.Give yourself permission to limit WIP and strategic focus. Most managerial leaders and teams do not know what to focus on and do not have a clear direction for themselves and their teams. It takes a lot of discipline and mental gymnastics for a leadership team to come up with a compelling shared vision.Recognize that WIP limit violations can occur from the top down and the bottom up. Top-Down WIP violations occur when in-process work at the higher level exceeds the capacity of the lower level system. This tends to be a common-but-seldom-acknowledged situation in many organizations (as most of us have probably experienced). Bottom-Up WIP Limit violations occur when additional work is introduced at a lower level that does not align with the parent system’s work. It requires diligence and visibility to prevent these violations.