Want to do more. Consider doing less. Limit your work in progress (WIP). Value completeness over an abundance of work in progress. Let’s examine how this strategy can actually make your teams more productive.
“Do a few things insanely great” reflects a quote from an executive at a previous company where I worked. What is interesting, the company developed software using traditional project management with long development cycles and large number of features planned upfront. Schedules were commonly delayed in order to ensure quality levels and handle complex code integrations from the large number of changes. The executive was suggesting a different approach for working.
I use the quote in my Scrum and Kanban training to emphasize the importance of limiting WIP. In Kanban, the WIP constraints are part of the columns built into the Kanban board. In Scrum, there are WIP constraints defined within the Sprint Backlog. The team decides during the sprint planning meeting which items will be worked on during the sprint. All other items remain on the Product Backlog and will be considered for future sprints. The team just focuses on the items from the Sprint Backlog with the goal to complete these to agreed upon quality standards.
So how does limiting WIP make us more productive?
Quality and creativity generally increase when working on a few items. When people are focused, attention can be given to detail which often results in better design, coding, and testing. Mistakes tend to occur more frequently when people are overworked. Some built in slack time allows for time to consider better alternative solutions which may otherwise be overlooked.
Flow is increased and bottlenecks are reduced. I give the analogy of the freeways in California. At the end of the on ramps for the freeway, there is a stop light. The purpose is to space out the traffic entering the road and create a better flow which helps to reduce bottlenecks. This principle could have been used at end of a concert where everyone converged to go down the stairs!
I was managing an employee who came to me overwhelmed and paralyzed with number of tasks which she was trying to multi-task. We refined each task and ranked them based upon importance and urgency. The employee was grateful to realize that she could focus on a few items and schedule the others for later. There was also a personal satisfaction in seeing progress with items completed and removed from the “plate”.
Completeness has a higher value over work in progress. Traditionally, we have valued those who can balance a lot of tasks instead of those who “complete” work. An engineer once told me with pride that he was simultaneously working on 17 items so it would be impossible to quickly update the team with his daily work. I suggested that it was time to follow Henrik Kniberg’s recommendation to “Stop starting, start finishing”.
The example also reminded me when I asked a team to provide me with weekly status reports (requested by higher ups). I quickly noticed that almost every line in the reports said “working on (a feature)”. I told the team members that I wanted to only see items in the report starting with the word “Completed”. The team soon realized that in order to report anything, they had to break the feature down into smaller tasks which could be completed within the week. Smaller is better!
Progress can be measured more accurately when looking at completed work. If we maintain working software, we can calculate metrics based upon completed work to remaining work. Often in progress work is estimated as a percentage complete, such as the task is 80% done. Generally, these estimates are less accurate because the amount of work for late integrations and bug fixing is still unknown. Often the estimates are optimistically based upon the number of remaining days left on the project schedule and not reality (such as suggesting you can reduce testing time).
Limit WIP to become better at prioritizing. If you are only allowed to work on a few things, pick the ones to work on first that provide the most value. Consider business factors from adding new functionality, reducing risks, time constraints, quality enhancements, performance, etc.
Limit WIP to increase technical health. As release projections slip, teams often struggle because they take on too much work during a sprint to “catch up”. Managers or other project members may pressure the team to add items to the Sprint Backlog. Invariably, this will result in team burnout, less quality due to mistakes, and acceptance of work with less than shippable quality. This is like the wrong stock market strategy of “buy high because market is doing well, and sell low when market is not so well”. Adding more work when the team is not delivering quality and missing forecasts is the wrong strategy, get back on track by limiting WIP.
More satisfaction and celebrations with completed work. It is certainly more rewarding to have a job “well done” than one that is “done but not well”. Work on creating a sustainable pace while achieving done with quality. If the software is not of shippable quality, then it is not done. Allow slack time for creativity.
Do more and work better with less. Think about limiting WIP and “doing a few things insanely great”.
Please contact me if you have examples from your projects on how you were able to reduce WIP and the impact this had on your teams and productivity.
