WIP is waste

I have been referring to this article: "WIP is waste" from Thoughtbot by Jared Turner on multiple occasions and sharing it with my colleages. I know it is an opinion piece, but it echoes my own experience and perspective on work, projects, and tasks.

The article is short, but it carries some good material. The essence is to get tasks out of WIP (Work In Progress) as fast as possible, because the longer something is in WIP and just having something in WIP is wasted value and postponed outcome and opportunity.

The article outlines these examples:

• It’s done, I’m just waiting on a review
• It’s complete, I just need to do some final testing
• It’s ready, I just need to merge and deploy

And the conclusions:

• Before a task is shipped it provides zero value.
• Any work in progress is pure cost.
• Two tasks in progress adds cost, for no value.
• Only after shipping do you create value. Always ship.
• One task shipped is infinitely better than 4 tasks “almost done”.
• Ship something of value first. Then begin something new.

My own experience and observations are variations of the examples above, so here are some additional examples:

• In a setup with multiple roles, hand over between roles causes delays
• Running too many things in parallel/multitasking causes delays
• Lack of focus causes delays
• Code in branches not merged is not value
• Pull Requests not reviewed and merged is not value
• Work not deployed is not value

This is not to say that everything must be rushed through, but rather that the focus should be on getting things done and out of WIP as fast as possible. This also means that if something is not moving forward, it should be evaluated if it is worth continuing or if it should be terminated.

Another good argument for getting things done, is that the work in the future, will be based is based on what be delivered now. Both the learnings and the actual deliverables. So the sooner something is delivered, the sooner it can be used as a foundation for further work.

You need a balance between start and closing of tasks. If you start too many things, you will have too many things in WIP and not enough things done. If you close too many things, you will not have enough things in WIP to work on. You need to find a balance that works for you and your team.

I have experienced a team, keeping starting too many bug fixes meaning that the bug fixes got delayed getting finished and deployed. A proper triage and prioritization of bug fixes, would have helped. Focusing on getting a few bug fixes done and deployed, would have been better than having many bug fixes in progress and fewer deployed and at some point the same bugs are being reported again and you end up in a bug administration soup.

Another lack of focus example, was a collague keeping starting new initiatives and features, but when as they got developed and tested, they ended up not being deployed for several sprints awaiting UAT. It seemed as if the focus was on starting new things, but as it was started it was no longer interesting. Compared to other examples of WIP, this was very expensive, since the work was done.

So my conclusions are:

• Focus on getting things done and out of WIP as fast as possible, keyword is focus
• If something is not moving forward, evaluate if it is worth continuing or if it should be terminated
• Prioritize and triage tasks to avoid too many things in WIP

• Focus on getting a few things progressing, completed and deployed, rather than many things in slow progress

• Find a balance between starting and closing tasks

• Use what is delivered as a foundation for further work