Introduction

When we use WIP limit, we limit the number of concurrent tasks. It could be a limit to each column of a Kanban Board; it could be a limit to the whole system; or even a limit to a set of steps of the process.

The idea behind limiting the work in progress is to work side-by-side with Little’s Law and try to improve the flow of the system, diminishing the lead time (LT) of a work item. And that works like a charm for machines. For software development? The relationship between WIP, LT and throughput is not that straightforward.

People are different

When we have a chain of machines linked together, in which the output from one feeds the input of other, everything is easier to predict. Now, imagine a situation in which:

• Items entering the first machine are not always the same size. And the machines don’t follow a linear relationship between size and time to complete a task.
• Each machine can, unpredictably, change its behavior. One week, it may receive an input of size x and generate its outcome in 1 hour. In another week, it will, unpredictably, take 3 hours to produce the same result.

Things start to get tricky, right?

WIP Saturation Chart

From my experience, some readings and even the way I work, I saw that different people work best with different workloads. I believe that a chart of WIP by the throughput of a person follow something like this:

This chart was taken from https://www.infoq.com/articles/how-kanban-works.

Some people work best with more than one task at a time. For different reasons. They might get unmotivated with few responsibilities, or it might be easy for them to rapidly change focus between tasks, for example. On the other hand, other people have a really difficult time changing focus and handling many tasks at once.

Other than depending on the person, it also depends on the project: it might involve third-parties that regularly block their work, it might have a testing process that takes weeks or months to finish, etc.

So, how can we come up with a single number that will magically fit all those curves under the same process? You can’t. But that doesn’t mean you shouldn’t.

So what? Should I just go crazy and forget limits?

As I said, it is just impossible to get a number that limits the work of everyone in an optimal manner. But that doesn’t mean you shouldn’t use one. I see, until the time of this post, two options for two different contexts:

1. You have someone looking at your process. If you have a Project Manager, an Agile Coach, a Scrum Master or other person that takes care of your process, you don’t need WIP limits. You need WIP management. This person can better understand how each person works and alert people to the amount of WIP according to each individual necessity as well as the type of project. I’d only use WIP Limits here to give process ownership to the rest of the team. This means that the person looking at the process would be actually temporary.
2. You don’t have a process guru. In this case, limiting the WIP with numbers and trying to tune it with time will give you a better process. It will not give you the optimal outcome, but it will unquestionably give you a better result.

Conclusion

WIP limit works. It will improve your process. But it is not a silver-bullet (I feel like a parrot repeating this). Look at your context (people + project) and use whatever delivers a better outcome.

What do you think? Do you believe in WIP Limits or not? Leave your comments below!

The post WIP Limit – A further study first appeared on Plataformatec Blog.

I will offer guidance in situations like this with five strategies in a recommended sequence. They are aligned with Lean principles and will work as a guide whichever method you use, be it Scrum, Kanban, XP or any other.

These strategies came to my attention while attending a course called SoftwareZen, by Alisson Vale. Alisson is a Kanban pioneer here in Brazil and I strongly recommend his course to all Portuguese speakers out there.

The strategies were complemented with our experience at Plataformatec and the content I presented (here the slides in Portuguese) at Agile Floripa 2016.

An overview of the strategies

A work system, like any other system, has an input, a processing area, an output and a feedback loop:

To be generic, let’s call “work items” all things that flow in a working system. The processing area deals with work items related to the present, the system’s input has work items that will be processed in the future and the output has items that had already been worked on.

It’s a good practice to start improvement by looking at the “Present”. This will give good leverage to the actions applied. It doesn’t mean that “Future” and “Past” are not important, they are complementary. Learning with “Past” work items can make your “Future” ones better.

Having this in mind, this is how the strategies are related to the system areas and the recommended sequence to apply them:

In the following weeks, I’ll post the first two strategies, “Start with work in progress” and “Reduce work item size” as a preview of an ebook I’m writing, 5 Strategies to improve software development workflow. The e-book will feature the content below:

• Start with work in progress: The first strategy shows why it’s a good idea to start looking at your system’s work in progress (WIP). Also, you will get to know how to do it through these practices:
  • Making the current workflow tangible;
  • Managing capacity;
  • Promoting tactical coordination;
• Reduce work item size: Slicing work into smaller pieces helps creating a healthy workflow and is one of the principles of Lean thinking. I will recommend some techniques to do it with different types of work items.
• Promote collaboration: Which characteristics do you have to pursue to achieve collaboration in team and organizational levels? And which ones do you have to avoid? That will be addressed in the third strategy.
• Do the right thing: Capacity is precious. Working in stuff that doesn’t matter is pure waste. The fourth strategy is all about techniques to help ensure you are working on the most important thing at the moment, in business, product and team levels.
• Make results tangible: The last strategy brings some tips on giving visibility to achievements, mainly with metrics. This will help with predictability, sense of progress and also with data to drive continuous improvement.

The ebook will be available to download very soon. If you want to get the Portuguese version, click here.

Until then, leave your comments below and stay tuned for the upcoming weeks!

The post 5 Strategies to improve software development workflow first appeared on Plataformatec Blog.