⏩ Introduction
Are you tired of constantly feeling overwhelmed by the never-ending list of tasks and features to develop in your software development projects? Do you want to deliver value to your customers as quickly as possible while minimizing waste and maximizing efficiency? Then it's time to explore the importance of limiting Work In Process (WIP), one of the foundational principles of the Lean Methodology. By setting a maximum number of tasks that can be in progress at any given time, you can reduce context switching, multitasking, waste, and rework, while increasing visibility, collaboration, and overall efficiency. In this article, we'll delve deeper into the benefits and challenges of limiting WIP, and provide you with actionable tips on how to effectively implement it in your software development process. So, buckle up and let's dive in!
📢 Get the Right Things Done the Right Way
Hey there, fellow developers! ✋
✌️Today I will explore with you one of the simplest yet most powerful practices that I learned and used in the past to maximize the throughput of the team. So, let's get started! 🚀
If you never heard of Lean, is a methodology focused on optimizing processes and reducing waste to create value for customers. Lean manufacturing originated in Japan at the Toyota Motor Corporation in the 1930s and 1940s, a period in which the company was trying to improve efficiency, reduce waste, and increase productivity in order to survive.
At its core, Lean is all about getting the right things to the right place at the right time while minimizing waste and being open to change.
One of the core principles of Lean is limiting Work In Process (WIP).
This means focusing on the most important tasks and delivering value to customers as quickly as possible. But how do you strike a balance between meeting customer demands for new features and reducing WIP? In this issue, we will dive into the benefits and challenges of limiting WIP, and share some tips on how to implement it effectively.
🚦What is WIP and How to Limit it Effectively?
WIP, or Work In Process, refers to any task that has been started but not completed. By setting a maximum number of tasks that can be in progress at any given time and not starting new ones until existing ones are completed, teams can improve flow and efficiency, reduce waste and rework, increase visibility and collaboration, and coordinate their efforts more effectively.
As you can imagine, limiting WIP is not always easy to implement, especially in environments with high demand for new features and changes. Teams must resist the temptation to take on more work than they can handle, manage expectations and communication, and adapt to changing requirements and priorities.
To limit WIP effectively, teams should define clear and realistic goals and scope, use a visual management system like a Kanban board to enforce their WIP limits, and implement a pull system so they only start working on new tasks when there is a demand from the next stage of the workflow, and embrace feedback and learning.
🚨 Warning Signs You May Be Ignoring Lean Economics
Ignoring the economics of product development can lead to many warning signs, including heavy multitasking, costly context switching, slow and painful deliveries, lack of accuracy when predicting the delivery scope and dates, low product quality, and constant rework. All of these can lead to a very frustrated team overloaded with work that never seems to get completed.
📏 What is the Right WIP Limit?
There is no “ideal” or “perfect” WIP limit in general, but the boldest opinion on this is Single-Piece Flow, where the limit is 1.
I know it may seem absurd to some, but there’s even a “crossover” between Single-Piece Flow and Mob Programming that is very pushed in the Mobbers crowd, which puts that limit at a team level! Yes, you read it right: there are teams out there always working in Mob and doing one thing at a time - and they achieve AMAZING results.
The key point in all this Limiting WIP thing is understanding that productivity arises when we complete work, and to complete work we have to start less work and focus more.
Stop starting, start finishing.
💡 Effective Use of WIP Limit
Effective use of WIP is when the team takes on a small amount of work, focuses on it, and works it to completion in a short period of time before pulling any additional work. This approach enables a consistent flow of value from the team and is considered much more desirable than context-switching across multiple efforts in parallel.
When the team is able to limit WIP in a positive way, can benefit a lot from the consequences: they can focus more on that single task and complete it in a way that doesn’t cause it to be bounced back, but there’s more.
They can also support each other more, favouring knowledge sharing and team collaboration, and they can also dedicate spare time to ancillary useful activities like learning (is always a good idea to read something useful!), creative thinking, testing, etc.
🎉 What's the Big Deal?
Applying WIP allows us to "stop starting, and start finishing".
Some advantages of using WIP limits include the improved flow of value through your team pipeline, productivity gains due to less context switching, ability to focus, identification of bottlenecks and waste – leading to subsequent remedy, improved cycle time, promotion of cross-training, and encouraging a focus on quality!
Learning Lean methodology and Limiting the WIP approach in particular can be a game changer in your career: productivity is pretty counterintuitive, and you have to accept that by starting less work you can complete more of it!
Until next time, happy coding! 🤓👩💻👨💻
Dan’s take 🙋🏻♂️
Limiting Work In Process is one of the principles I love and stick to the most in my daily work and one of those I always start with when I have to discuss the productivity of the team.
There are multiple reasons why I believe this is a great technique:
-
first of all, I don’t believe in multitasking: we are not made to do multiple things at a time, we are far better at doing one thing well and then moving to the next once it’s finished - context switching is one of the most expensive things we can experience, check "Programmer Interrupted: The Real Cost of Interruption and Context Switching" blog post in “Go Deeper” section to discover more on it.
-
the second point is that it is proved that parallelizing work in a system leads to waiting time and issues (PRs waiting for approval is a great example of waiting time) and the more we respond to that waiting time starting new work, the less we are able to finish (have you ever started a new branch while waiting for a PR? please stop!)
The most important thing to say about Limiting WIP is that there’s plenty of evidence demonstrating that it works! For example, in the “Go Deeper” section you will find the link to a case study from Oslo University that makes a very bold statement at the end:
Based on the data presented in this work, the conclusion is that WIP-limits matter in software development.
I really believe in the power of experience and demonstration thou: it’s very hard to believe in something just because someone says to you, even if he brings objective evidence. If you are able to do experiments and exercises to prove your point, you will likely make it understood by a lot more people.
That’s why I described here below a couple of exercises and tools you can use to prove yourself (or anyone else) the impact of limiting WIP and avoiding context switches.
🔠 🔢 Letters and Numbers
Take a piece of paper and a pen to set up - the exercise is made of three parts.
-
First step: write all the letters you can, starting from A, in 5 seconds. Example: A, B, C.
-
Second step: write all the odd numbers you can, starting from 1, in 5 seconds. Example: 1, 3, 5.
-
Third step: write all the letters and odd numbers you can, starting from A and 1, alternating between letters and numbers, in 10 seconds. Example: A, 1, B, 3, C, 5.
You will notice something similar to the image: even if the third step was asked to do the same amount of work as the first two steps, in the same amount of time, putting the two pieces of work together caused that we were able to complete less of both - context switch did his job here.
You can also notice that progress is slower, and we can highlight this even more by removing the time constraint and checking progress to reach number 9 and letter I with the two approaches. As you can see from the image below, in the first approach, where the WIP limit is 1, progress is much more visible and comes sooner (50% of progress when the first task is finished) - with the second approach, there is no progress until we are done, and this brings to more stress and delay.
🚥 🚗 🚙 🚕 Traffic Simulation
At this link, you can find a traffic simulator I typically use to make experiments on WIP limits and other concepts connected to the flow of the work and maximizing throughput. WIP is represented by the number of cars that goes through the street.
Here are 3 of my experiments that highlight the impact of WIP on the flow of work:
- See how it works with default options: you will notice that initially, the number of vehicles per hour (4500) seems fine, but in the mid-term, it is actually too much, and very soon the traffic becomes very high and cars start stopping.
This makes me reflect on the fact that building a team that is able to work at a sustainable pace is not a one-shot task but instead, something we have to continuously reflect on to ensure that it remains this way.
- Reduce flow to fix traffic: reduce the number of vehicles per hour to something around 2500 to see that traffic goes away and the flow starts again - here there are two possible situations:
-
if you start from a problematic traffic situation, it will take some time
-
if you set it up as soon as the page start, traffic will never stop
This is a great simulation of real life: of course, it’s easier to make something work well from the beginning instead of fixing it after problems arise.
- Reduce flow AND politeness: one more interesting experiment is to keep the flow low (2500 is always good) and then reduce politeness - even a small reduction from 0.1 to 0 will make the traffic more complex and, after a while, traffic will be blocked.
This is another great simulation of a real-life situation: rules and constraints exist to give the team a unique direction - even a small change of direction can cause problems and stop work from being finished if not agreed with the team. Stick to what the team agrees - if you want to change something you think can be improved, talk about it with the team and agree on a change or experiment.
💪 Extreme WIP Limit
The most extreme version of WIP Limit is the Single Piece Flow, where WIP Limit is set to 1: work on one thing at a time, do that one thing only and do it well.
When I talk about Single Piece Flow, I’m typically looked like an alien - that’s ok, that’s normal and is probably the same thing you are thinking right now.
That’s normal because once you start reading and learning about productivity you learn a lot of powerful things that, at first sight, are counterintuitive:
- You should focus on outcomes, not output ➡️ Outcomes are what we want to achieve, while outputs are the result of the actions we do to achieve it.
At first, it seems obvious that the two are related, so measuring output seems a good idea, but it’s not. For example, suppose users want to save their favourite song quickly (desired outcome): we may add a “heart” button feature, close to the song name to allow them to save it as a favourite (the feature is the output). If we measure the output, we are done once the feature is shipped - but if we measure outcomes, we are happy if a certain percentage of the users are now saving songs in their favourites. Output is not enough and can be misleading.
-
To achieve more, you have to do less. ➡️ More specifically, to achieve more you have to START less work. “Start finishing, stop starting”, remember?
When we face a blocker and we are waiting for it to be removed, it’s easy to respond by starting something new. This is the worst idea ever. Really. Simply, don’t. Of course, we can’t expect people to be happy to be stuck, so it’s important that we share some common rules: what is a person allowed or expected to do when waiting for some blockers? I typically suggest to the team a list similar to the following:
-
Ensure you have done everything possible to remove that blocker: for example, if the blocker is a PR to be approved, ensure you have noticed the team that you have a PR in waiting - and push them after a reasonable time (another good idea is having a rule for this - I typically suggest that a PR should be approved within 30 minutes, in order to allow someone to end a Pomodoro without distractions). If the blocker is something that needs a manager to handle, be sure that he/she knows using the best communication channel possible, and send periodic reminders (always wait a reasonable time between those reminders)
-
Ask if someone needs help, and if someone does need it, go pair with him to help and learn something more about the product and codebase
-
If someone is working on something interesting for you (both personal interest and company business interests are fine here!), ask him to pair
-
Just use the application (if there is a safe way, better in production) to discover things you don’t know, make some tests, try a feature you know little about, etc
-
Check old merged PRs about topics you don’t know much about to discover a bit more about it
-
Learn something new: if there’s nothing really useful immediately related to work, is always a good idea to fill waiting time with learning - reading a chapter from a book, newsletters or blog posts, taking a lesson from an online course, listening to a podcast - anything that brings learning and improvement is allowed here, and sharing the learning with the team is a plus!
-
Limiting WIP, especially if you apply Single-Piece Flow (at least at a team member level) has an incredibly positive impact on the productivity of the team and its throughput. It’s a real game-changer.
My dreamy team setup is actually a cross-functional team that works in Single-Piece Flow at a team level, doing Mob Programming with everyone at the table, following the best setup rules (for example, having regular team breaks + any personal break whenever needed + Pomodoro technique for driver switch).
Go Deeper 🔎
📚 Books
-
The Toyota Production System Journey - This book focuses on the factory to help readers understand the fundamental ideology of the Toyota Production System.
-
Implementing Lean Software Development - This book incorporates their gained knowledge and understanding of what works and goes steps further to provide hands-on guidance for implementing a Lean system.
-
Lean Software Development: Efficient Deployment Strategies: An Expert's Guide - This book builds from the previous books in the series by Gary Metcalfe and delivers a deep look at some of the more advanced issues and problems you will face when implementing Lean in your organization.
-
The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win - Bill, an IT manager at Parts Unlimited, has been tasked with taking on a project critical to the future of the business, code named Phoenix Project. But the project is massively over budget and behind schedule. The CEO demands Bill must fix the mess in ninety days or else Bill's entire department will be outsourced.
📩 Newsletter issues
-
Product Development in a Lean and Agile World - [Akinrinde’s Newsletter by Akinrinde]
-
Conducting Lean Experiments - [Product Mindset's Newsletter by Product Mindset]
📄 Blog posts
- How do you balance the demand for new features with the need to reduce work in progress?
- Lean Economics 101: The Power of WIP Limits
- Agile/Lean is the best-known way to create software
- Programmer Interrupted: The Real Cost of Interruption and Context Switching
🎙️ Podcast episodes
- Habits of Successful Software Engineers - Getting to Code Quickly and Model Thinking - [Developer Tea podcast]
👨🏻🏫 Online courses
- Lean Software Developer - [Coursera]
- Lean Software Development Fundamentals - [Pluralsight]
- Design Thinking, Lean & Agile - [Skillshare]
🕵️♀️ University Research
- Does Limit on Work-In-Progress (WIP) in Software Development Matter? - research from the Department of Informatics at the University of Oslo