Limited work in progress in scrum

The only thing that Scrum really calls for the end of each iteration is some completed code, ready to ship. Features ship as soon as it makes sense, but the details of how different organisations achieve the production readiness of their code is up to them. Generally, code does not go live inside an iteration, but why not?

Today, terms like “continuous deployment” and “continuous delivery” are a popular way to describe the idea that code could ship at any time, as long as the quality is there, the feature is autonomous, and make sense to get it out there.

Kanban is an agile development practice which supports this idea very well. It does away with iterations and time boxed commitments, allowing each individual unit of work to be re-prioritised, right up until the moment it starts. Work tickets of one kind or another progress through a series of workflow stages, and teams usually limit the amount of work in each phase, to reduce bottlenecks.

I don’t think Kanban lends itself particularly well to longer term project planning. Iterations do that nicely. That said, I like the idea of limiting work in progress, so that teams “stop starting, and start finishing”.

So can these two ideas work together? Sure can.

One of our teams recently made a change to the way they work. A very simple change that insisted a developer not begin work on a new user story, until the last one they did is “done”. This means testing is finished, all code reviews are complete, design consisteny signed off, everything. The code is all checked in and merged, ready for deployment.

In our workflow, there are five stages of testing, checking and make-ready that follow “development in progress”. Normally, a developer would push his work through testing and then begin something new. Of course this means that when the tester reports an issue with their code, they need to stop what they’re doing and refocus on the previous item. They make the fix, push it back to testing, pick up the second job again,…..rinse and repeat.

What might at first seem the most logical thing to do (get started on something new as the testers inspect your work) encourages unproductive context switching.

The one-story-at-a-time pipeline changes this dynamic completely. Once the user story goes to testing, the developer waits for it to pass. They do nothing but wait. The same for every subsequent phase, all the way through to done.

They can play ping-pong if they like, stalk their old school buddies on Facebook, yoga, anything they like, but they may not start anything new, until the user story they just completed passes all phases of testing, post-development. The effect this has been interesting. For creative software developers, Facebook does stay interesting for that long.

So what do they do? Well firstly they try to make sure that user stories will not fail testing. Remember, all developers work under the same rules, so if your story is kicking around in testing for days, holding up those of other developers in your team, you look bad. Developers in this team say they now do better quality control of their own work than they used to, in an attempt to get their stories through testing first time.

Secondly, they help. They’ll sit with the tester, describing what they’ve done, adding to the test cases and speeding the testing process enormously. They are more forthcoming during code reviews, hoping to demonstrate the quality of their code quickly, to get that off their plate. Product owner being tardy in accepting completed user stories? Watch the developer as he grabs the product owner by the collar, and drags him to a workstation pointed at staging.

In short, the developer does everything he can to improve the quality of his work, and make the lives of everybody else involved easier.

This is just the third iteration in which these practices are being used. It’s a new team, so it’s hard to say whether these practices are directly responsible for the amazing productivity they display. (It’s a gun team anyway). Anecdotally though, there’s a lot of good smells. Certainly, the team members would attribute much of their success so far to the idea of limited work in progress.

We still use the iteration, and I’d say they’re a scrum team using a kanban idea rather than the other way round.

There’s plenty of support for these ideas elsewhere too. “Kanban and Scrum – making the most of both”, by Henrik Kniberg and Mattias Skarin is one of those terrific InfoQ ebooks, that shares the experience of a software team with others, so that we don’t all have to do work things out from scratch every time.

The book is a very detailed but simple instructional manual for the construction of teams that mix Kanban and Scrum as a philosophy. It’s a free read, and a great way to get started if you want to explore these techniques.