Delivering Projects Faster With Limited Work In Progress (WIP)

I've written previously about the advantages of having only full-time people working on projects.

A powerful sibling to this strategy is that of limiting work in progress ("WIP").

Limited WIP is a concept made famous by the "lean manufacturing" approach developed in the "Toyota Production System," formalised in the 70s and 80s by the car manufacturer. This approach gave the Japanese company a market dominance in the car market over their international competitors for decades.

In the noughties, a number of "agile" proponents in software engineering began borrowing and formalising "Kanban" ("visual signal" or "card"), developed by Taiichi Ohno as part of Toyota's system. Central to Kanban is the concept of limiting WIP.

In essence, limiting WIP is about doing fewer things at once. At first, this can seem counterintuitive. Surely if we do more things at once, we get more stuff done in a short period? The reality, though, is the opposite.

Humans, it turns out, need to expend more energy and concentration to switch between tasks than they do to focus on one task until it is complete. This has a knock-on effect on smoothing and speeding up the flow of work through a given team.

I consider lean software development the third wave of trial system development. In the early days of agile, we had "extreme programming," followed by "Scrum," with "lean" becoming popular after both. Having been through all three of these waves, I strongly favour "lean" as the central mechanic for my projects.

While I also use the (very compatible) "extreme programming" principles, I generally avoid "Scrum" as I find it tends to encourage multitasking and, in my opinion, is grossly wasteful.

One of the biggest reasons I became enamoured with the lean concepts is that my teams found them immediately intuitive. This is in contrast to Scrum in particular, where I would typically have to train up a team in the methodology before starting the project. Also, in contrast to Scrum, I found that using lean principles immediately impacted how much software we delivered per month.

A really good example of this came on my first Kanban-based project for an online car sales website.

We were developing a new version from the ground up and testing it on a small scale with a subset of website visitors. This allowed us to move fast, because we weren't taking the risk of breaking anything for the larger audience – and we could quickly reroute traffic back to the original site if something did go wrong.

We were typically issuing a new release every one to two days.

The Limited WIP lightbulb went on almost immediately for me as we were building a new approach to handling ads with respect to car colour.

We had the feature built in a morning but were stuck with the values to put in the drop-down box relating to car colour. Originally, this would simply have meant we put it on pause and carried on with another feature. But this is against the "limited WIP" approach of Kanban.

So instead, we treated this as a high-priority red flag. Two of the team wandered around the building looking for any of the developers originally involved in coming up with the full set of car colours so that we could leverage this work.

In the end, it turned out that this developer was on leave. Recognising that dropping this task was less efficient than completing it (even in a non-perfect state), we went ahead and took a look at our own website and those of our competitors and came up with our own list.

Less than one hour later, we were able to issue our release.

We moved on to other work, finding that the solution was perfectly adequate for our website visitors. Once the developer in question was back from leave, we had a quick chat and made some further modifications to bring our changes in line with some backing system requirements.

The point is, we completed the task and moved on – circling back with a minor adjustment weeks later. This allowed us to gain valuable user feedback in production, rather than context switching and holding up the release.

This philosophy has now become the centre of my delivery machine and is instrumental in my ability to deliver projects that have previously failed.

I can't recommend this approach highly enough. It's easy to try, easy to drop, and the potential upside is terrific.

Give it a go :)

Andrew Walker
Technology consulting for charities
https://www.linkedin.com/in/andrew-walker-the-impatient-futurist/

Did someone forward this email to you? Want your own subscription? Head over here and sign yourself right up!

Back issues available here.