Once upon a time, there was a company with a smaller internal IT development team (somewhere between 3 and 10 people, I can’t remember). They were working on a few critical and not-so-critical software systems of the company, doing various developments, bug fixes, and some maintenance tasks. The company did great in their market, they were developing and growing well, but they had to move fast if they’d wanted to stay ahead. There were new customers, new products, and new ideas. This meant a lot of work and pressure for our poor IT department because the future depended on it. There was always much more to do than possible with this handful of IT people. The business came up with newer and newer ideas and development requests. On top of that, everything seemed to be extremely important and very urgent.

So what did our poor IT department do? They felt the pressure and knew that the future of the company was in their hands, so they tried to work harder and harder and hoped it was going to work out somehow. But the work seemed to always be more than a week ago. It seemed as if they were moving backward, not ahead. ‘If only there were a week of undisturbed work, we could finally catch ourselves,’ they said. They didn’t have time to administer tasks or build a system with processes. They didn’t have the capacity to measure, estimate or plan anything because they were always in an emergency mode, only trying to put out the fire. They had to keep swimming or they would just sink like a stone.

Later they tried to create task-lists in different spreadsheet files, but those soon got outdated and out of hand because the new requests were just flowing in uncontrollably. Always something new, something else, something more important and more urgent.

The Consequences

Poor people in the team were always tired and stressed-out. The harder they worked, the less they seemed to accomplish. Their work was chaotic, and the quality of the developments was weak, full of bugs and misunderstandings. The business was furious. ‘These IT guys are a bunch of ignorant idiots. We can never count on them,’ they said, ‘they make promises all the time, but deliver nothing.’

The executives tried to ask them nicely and roughly, but nothing seemed to help. ‘We have no idea what they are doing, or if they are doing anything at all. They are like aliens to us,’ they used to say. And indeed, they were angry and dissatisfied with the IT department for good reasons:

• Their processes were chaotic from the inside and opaque from the outside
• The lead time (the time from idea conception to delivery and going live) was incredibly and unpredictably long, causing enormous losses and competitive disadvantage to the company
• They had dozens of tasks in progress, but they didn’t seem to be able to finish anything properly to produce any real revenue or value to the company
• When they were asked about status, they always said ‘We are 90% done‘, but the last 10% always took weeks or months to finish
• They spent countless hours with the business on endless prioritization meetings, creating huge Excel files, organizing and prioritizing tasks into different categories, without any palpable effect on actual delivery
• Whenever they were lucky enough to deliver something, it was full of bugs that took another weeks or months to fix
• Whatever they did was completely unpredictable, they could never deliver their promises, so after a while, the business didn’t even ask about delivery dates
• Because everything took so long, they wasted crazy amount of time and energy with constant re-prioritization, task-switches, and hand-overs. The accumulated knowledge about a problem or a solution got amortized over time in people’s head and needed to be rebuilt after every restart of the same development.
• Very often other people needed to pick up a task that was suspended earlier. Sometimes developments took so much time that the people requested or worked on it initially were not even working at the company by the time it finished. This is an even bigger waste because some information was lost forever and needed to be recollected and rebuilt again.

The Key Characteristics

Stories like this have a few common elements that need consideration:

• Unlimited WIP (Work In Progress): every team member has an unlimited and seriously overloaded task-list where practically everything is in progress. New requests are flowing in unrestricted and uncontrollably.
• No visualization of tasks: there is no transparency, nobody knows who is working on what. Sometimes even individual people don’t have a comprehensive list of their own works.
• No measurement and estimation: even if there is a somewhat transparent task-list for everybody, nobody measures how many tasks the team does in a given time period (in a week or in a month), let alone estimating the time needed to deliver the developments in progress.
• No clear prioritization: since everybody is overloaded, and everything seems to be extremely important and urgent, there are no clear guidelines to task priorities. Prioritization decisions are made ad-hoc, based on accidental factors (who is asking it louder, who came last time with an angry-enough case, which user the developer likes better, which task is easier to develop or the favorite area of the developer)

Limiting Work In Progress

The situation cries out for help, and the Kanban method offers a simple solution of the problem’s root: limiting the number of tasks that are in progress. To accomplish this, you need to implement a few fundamental changes to the current processes.

1) Create comprehensive task-lists and visualize them

Creating a transparent task-list with different states is the essential first step that everything else is built upon. You can use a simple white-board with sticky notes, or software tools like Trello or JIRA. It doesn’t matter what you use, but you got to use something that everybody agrees upon and everybody uses on a daily basis because it has to be up-to-date, at least once a day (every morning for instance).

2) Measure team performance and estimate

With a transparent task-list you can easily measure team performance or velocity, even if you don’t differentiate tasks by size, just consider them all equal size (which is a false assumption of course, but better than nothing). It is highly recommended to use some effort estimations to your tasks. Using a relative estimation scale is much better than using a linear one (like person-days for example).

With this, you can measure how much the team accomplishes in a week. Knowing this number is critical to set work-in-progress limitations right and make sensible prioritization decisions (see the next two steps). This step is probably the hardest: it is not uncommon to turn out, that promised/expected/desired performance for the next week is 5, 10 or 20 times higher than realistically possible, based on past performance. With no transparency and no measurement, nobody can face the reality of this.

3) Limit work in progress

The first two steps have just set the stage for implementing the real difference: limiting work in progress. This limitation comes at two levels.

Personal level

Instead of doing everything parallel and changing priorities on a daily or hourly basis, team members should limit their actual work in progress to a small limit, to a number between 1-3 (the lower the better). This is a significant change in work culture. It means that it is forbidden to start a new task until one is finished. By finished we mean that the development can potentially go live.

This is called a pull system: instead of pushing items to the task-list of people when they arise, pulling things to the list when there is free capacity in it.

When someone faces an obstacle to move forward with a task, instead of starting something new, he or she needs to shout, and the number one priority of the team (and business people) is helping to move that obstacle out of the way.

Of course, this not always possible to do. There are external dependencies that we have to face and accept. Sometimes the person who requested the task is on vacation or sick, etc. This is why setting the WIP to 1 is unrealistic, but you have to keep in mind that the higher the WIP limit, the longer the lead time (time-to-market), the more expensive, and lower quality the end result. With some shift in culture, WIP limit can actually be surprisingly low, much lower than you thought was possible.

Team level

A pull system needs to be implemented at the team level as well, with setting a WIP limit. The concept is the same: instead of pushing tasks to the system based on business demands, the system pulls items from the business when something gets finished, and the team has a free capacity (WIP goes below the limit).

The WIP limit needs to be set to a minimal level which provides enough work to keep the team busy, even between the time from an item gets finished and the next item can be pulled to the system (based on prioritization decision of the business). This WIP level should be set empirically and changed later on based on experiences, no much or in-depth analysis is needed. Just keep in mind: the lower the limit, the better the performance.

4) Make realistic prioritization decisions

Prioritization decisions can be made on-demand (after a task is finished), or on regular prioritization meetings. I recommend regular meetings first, which can be later changed to on-demand prioritization if needed or possible.

The goal of prioritization is very different than before: much easier and much more efficient. Earlier you might have endless lists of various tasks, categorized into several different priority levels. Organizing tens or hundreds of tasks into different categories and keeping this up-to-date is very challenging, while usually, even the top priority tasks are many times more than the team could implement in the foreseeable future (in the next month for example).

Instead of organizing all the tasks into one long ordered list, you only need to do one simple thing: select a few items that provide the team enough work for the next prioritization meeting, namely fill up the missing slots to the WIP limit. Prioritizing the rest of the tasks is complicated, time-consuming and entirely useless.

Benefits of WIP Limitation

These steps seem like very simple and minor changes, but their impact and power can not be overestimated. It usually results in profound improvements and performance boost in the organization:

• Visualization results in transparency. The business people can see for the first time what those good-for-nothing IT guys are doing, and why their requested development is coming late (because there is something that really is more important for the company than their request).
• For the first time, the IT can make promises (based on realistic estimations) and have a real chance to deliver on time and frequently. When the business agrees to put something into the queue, they can be sure it will be delivered on schedule, or at least with manageable delays.
• This predictability builds enormous trust very quickly towards the IT department.
• Lead times reduce from unpredictably and infinitely long to manageable, predictable, and dramatically shorter.
• This results in shorter time to market, which increases the competitiveness of the company.
• Reducing work-in-progress to a reasonable level results in a steady and sustainable pace, and puts an end to constant pressure, stress, tension, and overloading of the team and people within.
• The radical decrease of task and context-switches, task re-starts or handovers produce much faster (thus cheaper) and higher quality work. The effect of this can easily be measured by comparing actual team performance with the past when WIP limits were higher or non-existent. The difference is usually dramatic.
• Prioritization decisions are much simpler, easier, and quicker. This frees up a lot of time for the business executives. Besides, these decisions have a real effect on the order of when things will be accomplished and go live.

Why Is WIP Limitation So Difficult to Implement?

If this is so easy as it sounds, then why are there so many chaotic stories like ours above? The easy answer is that the people in these tales are stupid, unprofessional or ignorant. But I don’t buy that. In many cases, quite the contrary is true: we are talking about well-educated, smart professionals with the best of intentions, who really care about their work and the company. Why is this still happening over and over again then?

I don’t know the perfect answer, but I have some hands-on experiences and strong guesses, that explain large parts of the story. In my opinion, the biggest challenge is of psychological and cultural nature. The steps are not more complicated than I described it above, but these involve some fundamental changes in the way we see and do things, which always induces some amount of resistance in organizations.

Creating Transparency

Creating transparency by administering and visualizing every task requires additional work and discipline, from everybody. When some people are not willing to do this or hate the administration system itself, nothing is going to work. Other people hate transparency in itself, usually the underperformers and ‘corporate politicians’ who like to hide behind their unseen, long-lasting, always hindered tasks, or managers who want to avoid conflicts.

Measurement and Estimation

Measuring and estimating performance is hard because we have to face the numbers that come up, which can be a very inconvenient reality. Realizing and admitting that we actually need ten months to deliver (instead of the two months you promised) requires self-criticism, humility, and maturity. Saying something like ‘Dear business, the tasks that we promised before are actually 5 times more than what we can do in reality, so which 20% is that is the most important?’ is a character-shaping experience that requires a lot of courage.

WIP Limit for People

We all know that the last 10% of every work is always a pain in the ass. You’ve finally understood what the business wanted, you’ve come up with a solution concept that you could somehow sell to them, you’ve done all the coding, you’ve done some testing, and it seems to work fine. You are 90% finished, almost there. And now comes the tedious part: committing the code, deploying the development to the test system, asking the user to test it, answering his or her annoying questions, arguing about why it works the way it works, pressuring him or her to decide what more they want to change. Making newer and newer versions with minor, insignificant changes, writing a few lines to the user manual, administering in the ticketing system, and sending a mail about the development. You call the user, but he is unreachable. How much easier is it to just start something else? You’re almost done and hate that asshole user anyway.

Or you have a task you don’t like. Still, you somehow convince or force yourself to start working on it. You work 10 minutes when you face an obstacle, and you need the help of someone else. But you see that your helping hand is really deep into something, or she is not even at her desk. What do you feel? You are relieved. Now you have a perfectly valid excuse to start working on something else. After all, you have another dozen extremely important and urgent tasks, and you sought help with this one but can’t proceed because of her. You might try tomorrow, or rather next week.

Or think about the other side of the coin, when someone tries to focus on one thing only, but faces a problem and comes up to you for help. But you have ten active tasks, all extremely important, can’t he see that? Of course, you won’t help and send him away, you have more than a valid reason to do it. How dare he even ask? Doesn’t he have another task to deal with!?

Furthermore, how good does it feel to see how much you work, how much you do, how many tasks you can handle, and how good you are already doing with most of them. Nothing is done, nothing is ready yet, nothing produces any real business value yet, that is true, but you are almost there already. These finishing touches are just mere formalities, anyone can do that (but nobody does), you have a more important task to figure out right now.

Or imagine you work in an environment where work in progress is strictly limited. You never have more than one or two tasks at a time. Just think about how much bigger responsibility that means! If you experience a road-block or have to discuss something with someone, there is nowhere to hide. When the status meeting comes, you can’t come up with the regular excuses because it is your responsibility to work through that obstacle somehow, you have nothing else to do. How much more convenient was it when you had ten other tasks that you could hide behind. Who can call you to account when you have a dozen tasks to do? Anything proceeding too slow can be blamed on the rest. You can always say there was something else to do. Who can realistically expect anything from you? Maybe you are almost done with most of them, only there is always something a little more important. Who knows? Who can even possibly know what the hell you are doing? It is no wonder you don’t want to let go all those tasks that give you all the comfort and safety!

WIP Limit for the Team

Setting WIP limit for the team is difficult because the business has to accept “no” very often, but some people or organizations are not mature enough to take this. They are forced to select only a small portion of the previously and usually promised amount of work, that can be realistically done in a given time period. This is hard to ask and hard to accept, but this is the price we have to pay. While we all know how much easier it was to promise everything, believe the lie, and come up with excuses later on.

Imagine yourself sitting on the IT prioritization meeting with the CEO and other senior executives. They want everything because everything is very important and even more urgent. They force you to make irresponsible promises. You feel that saying no or drawing even thin lines can have lethal consequences. They make you feel that way. Of course, you don’t want to measure performance or make estimations. Why would you? Do you need the discomfort of reality? Do you need that conflict? Isn’t it easier to promise, hope blindly, and explain failure later on?

Let’s see another situation. The leader of the marketing department comes to you and says there is an urgent task to do, right now. Who are you to say no to him? Isn’t it better for everyone to just obey, throw away everything else and start doing it? Only for him to come back again tomorrow and ask something new and even more urgent? Do you really need the conflict of lecturing him about how ineffective this is?

Other Examples and Limitations

Although my primary expertise and experiences are in IT, the principle of pull systems and WIP limitation is a general concept that can be applied to several other kinds of work and area of life, where certain circumstances are met:

• Project-like tasks with definite beginning and end
• The order of task execution is flexible to some degree
• Work is always significantly more than what can be done
• The external dependencies are limited or manageable

In different circumstances WIP limitation is irrelevant or not applicable:

• Continuous tasks with no definite end
• Order of tasks or timetable of work is fixed (therefore no need for prioritization decisions)
• Many external dependencies which always stops task executions for a longer time (therefore you have to work on several tasks parallel not to be idle half the time)

I collected a few other examples where I applied and experienced the positive effects of limited WIP:

• Implementation of management-level initiatives and projects in a company
• Projects and tasks in a marketing department
• On a personal level, doing work at home (writing this blog for example), or prioritizing my own tasks at work

All the above circumstances are valid in these areas as well. Always more work than available time and resources, flexible prioritization, and project-like tasks with an end. And very often this results in constant pressure, frittered away attention and focus, many parallel works in progress, constant task-switches, projects in 90% status for months, and incredibly long lead times. In these situations, WIP limitation can make a real difference.

Conclusion

In many circumstances, unlimited WIP is very ineffective because of several reasons. It results in long and unpredictable lead times, inconsistent delivery, wasted efforts, poor quality, stress, and chaos. This can be changed by implementing a pull-system with reasonably limited work-in-progress. Such a system is based on simple principles but can be surprisingly hard to build, mostly because of psychological and cultural challenges.

When these hurdles are bypassed, it very often results in profound and dramatic improvements in transparency, predictability, frequent delivery, radically reduced lead times, and significantly higher performance. These results are usually much more significant than what can be achieved by investing in individual people.