≡ Menu
Pawel Brodzinski on Software Project Management

Limit Work in Progress Early

Limit Work in Progress Early post image

We’ve just started another project. One of things we’ve set up at the very beginning was a Kanban board. It wouldn’t be a real Kanban board if we haven’t had work in progress limits. There are two common approaches I see out there in terms of setting WIP limits.

One is to work for some time without WIP limits just to see how things go, get some metrics and get a decent idea what work in progress limits are suitable in the context.

The other approach is to start with pretty much anything that makes sense, like one task per person plus one additional to have some flexibility.

Personally, I like the latter approach. First, no matter which approach you choose your WIP limits are bound to change. There’s no freaking chance that you get all the limits right in the first approach. And even if you did the situation would change and so should the WIP limits.

Second, you can get much value thanks to limiting work in progress early even if the limits are set in a quick and dirty mode. In fact, this is exactly why I’m biased toward this approach.

In our case one last stage before “done” has been approval. We’ve had an internal client (me), thus we haven’t expected any issues with this part. We weren’t far into the project when first tasks started stacking up as ready to approval.

As I initiated the discussion about us hitting the limit in testing (the stage just before approval) I was quickly rebutted “maybe you, dear client, do your goddamn job and approve the work that is already done, so we can continue with our stuff.” Ouch. That hurt. Yet I couldn’t ask for a better reaction.

Lucky me, I asked about staging environment where I could verify all the stuff that we’ve built. And you know what? There was none. Somehow we just forgot about that. So I eagerly attached blockers to all the tasks that were waiting for me and the team could focus on setting up the staging environment instead of building more stuff.

An interesting twist in this story is that setting up the staging has proven to be way trickier than we thought and we found out a couple of flaws in the way we managed our demo servers. The improvements we’ve done in our infrastructure go way beyond the scope of the project.

There are two lessons here. One is that implementing WIP limits is a great knowledge discovery tool that works even if the limits aren’t yet right. Well-tuned WIP limits are awesome as they enable slack time generation, but even if you aren’t there yet, any reasonable limits should help you to discover any major problems with your process.

There’s another thing too. It’s about task sizing. In general the smaller the tasks are the more liquid the flow is and higher liquidity means that you discover problems faster. If it took a couple of weeks to complete first tasks we’d find out problem only after that time. With small tasks it took a couple of days.

So if you’re considering whether to start with limiting work in progress on a day 1 of a new project, consider this post as an encouragement to do so. Also you may want to size first few tasks small and make sure that they go throughout the whole process so you quickly have a test run. Treat it as a way of testing completeness of the process.

in: kanban

4 comments… add one

  • David Lowe October 10, 2013, 11:15 am

    Hi Pawal,

    Thought you might be interested in my video about why limiting WIP makes sense: http://youtu.be/W92wG-HW8gg

    Would appreciate your thoughts & comments,


  • Pawel Brodzinski October 11, 2013, 2:12 pm

    @David – You used one of the classic examples that is exploited to describe how WIP limits work and added nice and easy to understand graphics. So far so good.

    I would, however, point that this example is oversimplified. The process is linear with no interactions whatsoever. There’s no hand-off time. There’s no context switching cost taken into account. The slowest sage of the process is (conveniently) the last one…

    While the example may make some of decision-makers think about limiting WIP, I’d say it is prone to “it doesn’t work this way in my context” argument. Also I potentially see more depth with things like non-linear process or context switching, which typically work even more in favor of aggressive WIP limits.

  • David Lowe December 18, 2013, 4:56 am

    @Pawel – I agree that it is very much oversimplified. That was the aim because I believe in limiting “concepts in videos”. I considered chucking everything into one video, but it would cloud the point and make it unapproachable to newcomers to the topic.

    I’ll add the other points to my list for future videos. Cheers.

  • P Marc Schwartz February 17, 2014, 11:35 am

    Can you help me? I am working on a doctoral dissertation titled “What Are the Factors of Failure in the Implementation of New Project Management Technology Utilizing Dashboards as a Tool to Measure Key Performance Indicators (KPI): A Qualitative Inquiry.”

    Specifically, I am seeking participants for my research project. The participants will log onto a secure cloud-based site. When a subject’s responses reach a level of 80% of the research requirements, a letter of implied consent will be available to be read, electronically signed, and securely stored. The intended sample size is 25 interview participants. This study is a generic qualitative research project (Creswell & Plano-Clark, 2011). The database will give weight to the size of the sample (Cohen, 1962).

    The units of analysis for this research will be open-ended interviews with individual project managers from extant project management companies of good reputation. The users for this research will have a minimum of six months experience in implementing new dashboard technologies in project management
    This project will begin after I have obtained approval or an exempt determination from Capella University’s Institutional Review Board (IRB), which will review my study to ensure the adequacy of my plan for protecting participants. I will provide you with a copy of my IRB approval or exemption letter before beginning my research. My projected start date is July 2014, and I expect that this project will end in September 2014. These dates are subject to change, and I will notify you if there are any significant changes or delays.

Leave a Comment