One of our founding principles here at Yellow Pencil is that we keep improving — as individuals mastering our craft, as a team perfecting our delivery, and as partners with our clients, helping them be their best in the digital space.
About a year ago, we embarked on a journey to transform the way we work by introducing lean software development principles and practices into our processes. In the early Fall, we implemented Kanban. This meant a fundamental change in the way we planned, scheduled, scoped, and executed our projects. It also meant changing our project management tool. In March, we moved to a multidisciplinary two-team model, which once again changed the way we planned, estimated, resourced, and executed our projects.
Setting new limits
Like biological systems, major evolutionary shifts in organizations are often followed by a punctuated equilibrium, where changes to process and tools are slow and small. But every once in a while a small change can have (pleasantly) unintended consequences and result in a dramatic shift.
In our case, that small change was the implementation of WIP limits on our previously delimited buffer or "ready to continue" lanes, and the significant impact it had on the way we work and our performance.
If you’re not familiar with ready to continue lanes in Kanban, these are basically buffer lanes in a manufacturing process, where work temporarily stops on a particular item in its transition from one step to another. In car manufacturing, for example, this would be a temporary stop between the welding of the body and the beginning of the paint process. In IT, this would be work stopping on a piece of functionality between coding and QA. The reason “ready to continue” lanes exist is because different steps in the process happen at different rates, and having a queue of work to pick up from means people are always working. People never have idle time, and management is happy. Now, this sounds great — in theory.
When buffers go unchecked
If your only metric of success is utilization, then you can stop reading right here and implement buffers into your processes. In practice though, unrestricted buffer lanes create problems that are much worse for the company than less than 100 per cent utilization would be.
When buffer sizes increase, the cycle time or amount of time it takes for work to get from the start of the system to completion is longer. Sometimes, it actually allows work to be forgotten in the system, sitting in a buffer lane while work of higher relative importance always takes priority. Eventually, when you get back to the forgotten work, you may have to spend additional time trying to figure out where you left off. Worse: you may have even forgotten what work was performed in the first place and have to start up all over. In effect, buffers create the illusion of 100 per cent utilization, but do so at the cost of efficiency!
So why not kill buffers entirely? In an ideal world, where a piece of work flowed through multiple steps, and each step took exactly the same amount of time to complete, with no breakdowns, etc., this would be possible. But because work in our space is variable, this is impossible. So the best we can do is to limit how much buffer we’re carrying.
Reigning in the buffer
So what happened when we introduced buffer WIP limits? Here are four benefits I’ve noticed so far:
- More time and attention: The first thing that seems to have happened is the team paid more attention to the work they were starting. They spent more time considering what needed to be done before beginning to work. After all, no one wants to pick up work that will be blocked pretty quickly down the line. That takes up valuable space in the buffer.
- Better effort: The second thing is when cards are or appear to be blocked, the team made a more concerted effort to remove that blocker, raising issues to the PMs more quickly or seeking input from clients earlier.
- Improved quality: The next area of improvement is quality. When buffer sizes are reduced between development and testing, testers were able to test work that developers finish more quickly, and any work sent back to developers got picked up sooner. This reduction in lag meant that developers and testers were working on things that they’d produced more recently, and with the details fresh in mind (recency is important).
- Focused priorities: Finally, the team became better at pushing back on stray work that flowed into the process. When priorities shifted previously, the team would often stop work on issues in progress - even if the new work was of a pretty trivial nature. Because doing that now would impact their own buffer WIP, teams became better at assessing and managing higher priority work.
Stop starting, start finishing
The end result is that we "stopped starting and started finishing" work. We decreased the amount of time it takes between work starting and its final completion by making sure that work in progress is completed before other work is taken on.
Limiting our buffer lanes is something we had always planned on doing, but never got around to. The reasons were numerous and compelling in the moment, but mostly predicated around our assumption that limiting buffers would impact our overall flow and negatively affect team morale. We believed that restricting lanes would cause the Kanban board to raise red flags more often, especially considering work that could not be continued because it was blocked by external factors. We feared implementing WIP limits, not realizing how much of a performance improvement it would make.
If you’d like to know more about Kanban or how it has worked for us, reach out to us in the comments or email me