SpotFlow: Tracking Method Calls and States at Runtime
Why Limit WIP?
1. • Why it’s important
• 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, CEO and 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
3.
4. What is Work-In-Process?
all materials 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
Development Time
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
Development Time
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 / 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
9 days (70 total)
approx 13%
What is Work-In-Process?
13. Ready
In Process Done
Development Test
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
Development Test
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
Development Test
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
Development Test
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
Development Test
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
Development Test
Done DeployIn Process Done
F1F2F3
F4
D1
F5
(3) (3)Ready
(6)
F6
F7
F8
F9
Day 6
19. In Process Done
Development Test
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
Development Test
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
Development Test
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
Development Test
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
Development Test
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 Systems Work
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
26.
27.
28.
29. Three Kinds of WIP Limits
• Personal WIP Limits
• Team (Execution) WIP Limits
• Organizational (Structural) WIP
Limits
30.
31.
32. The Zeigarnik effect:
When we finish tasks, we
get closure and move on.
When we don’t finish
tasks—we don’t.
33.
34. Managing Team (Execution) WIP Limits
• Why: To Improve Flow
• Challenges:
–Variability
–Constraints
–Personal WIP
38. Managing Organizational (Structural)
WIP Limits
• 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
48. Resources
• The Phoenix Project, 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 Limit WIP: 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
Notas do Editor
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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.