Less is more..?
Probably many of you heard about slang in Kanban community such as ‘less is more’, ‘slow is smooth — smooth is fast’ and similar? At first when I’ve got to work with Kanban and I heard ‘less is more’ phrase I blamed my English. I thought I didn’t understand well so it must be me a problem here. But then when I’ve got to work with WIP limits soon I understood the power in these simple words that changed quite a bit of how I was approaching my day to day tasks.
I always follow 6 Kanban principles: Visualise, Balance your work in progress, Manage flow, Make your policies explicit, Introduce feedback loops, and experiment and collaborate on everything you do. It's a shame that most of the time teams starting Kanban think-well, we got everything on the board now, everything is visual so the job is done! Not quite yet. There are many reasons why there is more than one principle that should be applied if you really want to succeed in running Kanban in your organization. And there is one principle that everything fits around it — balance your work in progress. There is nothing more frustrating than taking up more and more work on and deliver — 0. Let's agree none of the stakeholders will be happy to see no results in the end, right?
Just purely explaining to teams that balancing or otherwise limiting your work in progress is a good thing not always get so much support. Especially when there are deadlines and other interactions on the way and project managers keep asking when something will be delivered, the last thing people will agree on that if you lower your WIP limits it will make it better and faster. There is this understanding that ‘I need to start something now otherwise I will have nothing to do and we will not finish on time’. Then all team members start more and more work and this can be illustrated like this:
So the top picture shows WIP limits going through the roof and the bottom picture shows how much work was delivered in that time when everyone tried to take up a task to do. A simple example shows that when more and more work is brought into the system, less and less work leaves the system. Why? There are few possibilities why this could slow the team down, but imagine how quick are you when you are working on your own and when you pair on stuff? How quicker you are to deploy stuff when there are fewer interactions on the same branch rather when there are multiple people working on it? How quickly do you get your PR’s approved when there are fewer requests rather when there are loads of them coming through? And how quickly can someone jump on your ticket to validate/test it when there is one ticket ready or when there are 3 queuing up? It all depends on team size, infrastructure, process, and people. But when you stretch your system to very high limits, it becomes difficult to manage, especially when something goes wrong and the whole delivery is blocked...
Having high WIP limits in the system means more work sits for longer around waiting to be picked up, slower delivery, less delivered, more possibilities for blocked items to appear, dependencies, and deployment hell. And the most important — unhappy customer on the right-hand side — waiting for something to be delivered and not knowing when it will be done. Being unpredictable leads to trust issues with your end-user and stakeholders. There should be always a desire to improve your flow efficiency and to become more predictable. Example of lower WIP limits and change in Throughput:
On the top, you see lowered WIP limits to 3 instead of 4 and at the bottom it shows that delivery improved significantly — delivering few days in a row, clearly seeing weekends where nothing gets out. More predictable service, happy customers, efficient team.
I would love to tell you the recipe and say that it will definitely work, but unfortunately, it would be too easy. As a team here at Corlife we are still checking our boundaries and trying to understand what else could we do to improve it even more. There is no right number that could be applied to every single team, otherwise it would be already done. But playing with that number and looking at your data will help you understand if you are going in the right direction. WIP limits are core to build better, smoother flow. Using the word ‘limit’ is not advisable. We are all humans and we get defensive when it comes to what we can and can not do. So use a more friendly word such as let's balance our work in progress. Let's understand how much work leaves our system in order to understand how much can we take in. WIP limits affect lead times and cycle times too. You want something quickly out there to be able to test your assumptions and to be able to adapt to change and feedback.
As Klaus Leopold said ‘working costs money — delivering makes money’. I say perfection does not exist, we always try to improve and beat our previous performance to be better. That should be the aim of continuous improvement. After all, we all want to be more agile and deliver successful products to our customers!
