Using story swarming to reduce WIP

Some years ago I was on a training course on lean thinking and one particular exercise has stuck in my mind ever since; Teams of six or so were given a piece of A4 paper and were told to arrange themselves so that none of them were in contact with the floor. The solution most people took was simply to get all of the team to stand on the paper at the same time. The tutor then folded the paper in half and told us to repeat the exercise. It was still possible on one foot for the team to stand on the paper. But the paper was folded again and again until people were resorting to climbing on one another or declaring the task impossible. Finally the tutor took the piece of paper away entirely. Suddenly one team realised that the paper was completely surplus to requirements and the goal could be achieved even with no paper at all by having the whole team jump on the count of three. The point of this exercise was to demonstrate “Muda” or waste and how the presence of a tool or resource tends to make people use it even if in practice it is not needed at all.

One of the tenets of lean production, which as you will know is one of the foundations of the approaches to software development collectively know as agile, is the reduction of waste in all its forms. Inventory that is not being used and work in progress (which is product that is not yet ready) is an example of one of seven “wastes”. In software development code is inventory, if this code is not usefully in production it is my conjecture that this is waste and we need to find ways to minimise it.

One way of addressing this waste will be familiar to any practitioner of agile development; namely the use of an iterative approach, one of the benefits this gives is that we deliver useful features into the production code every iteration hence reducing the wasteful inventory of code that is work in progress. We also strive to prioritise our work so that the most important feature is delivered first and we do not put wasteful effort into less important features and to ensure that we do not “over deliver” excess inventory that is not yet needed..

You’ll hear it stated frequently that having a single product backlog that is ordered as a single queue is essential to a successful agile project. The idea being that work is done in strict priority order. In practice what often then happens is that each pair will grab the top available card in the backlog and begin work on it, the next pair will grab the second and so on. What this means is that in a team with six developers you suddenly have three cards running in parallel typically all placing conflicting demands on your QA’s, BA’s and the customer at the same points in an iteration which then leads to features being held up or bugs being found late in the day. Worse still it could be your top priority card gets held up because of some problem with a lower priority card that conflicts with (either through necessity or some error in the solution).

A consequence of which is that some or all (and not necessarily the lower priority ones) end up being incomplete at the time of cutting a release. Subsequently juggling of features which are ready or perhaps not wanted yet has to occur. Methods to tackle this include “feature branching”, “branch-by-feature” and “feature switches”. These allow us to switch on or off particular features either by clever use of version control systems or with a code switch to “turn off” code that is not ready. You will hear proponents of both approaches. But it seems to me that whichever approach is used the wrong problem is being addressed in that they are all ways of dealing with excess code inventory be it code that is not ready to put into production at the end of an iteration or code that delivers a feature that is not wanted yet.– there are great tools to help with this to be sure but my point is that if this is needed at all;

(a) There is excess inventory either in the form of unfinished code or in the form of features delivered ahead of when they are wanted or needed

(b) A process has been introduced purely to deal with this excess inventory, which in itself is a form of waste.


So what else can we do to deal with this excess inventory? Well the thing here is to eliminate the excess in the first place.

An alternative approach to the pair by pair grabbing of stories, and one which is getting some attention, is to have your entire team “swarm” on a story until its done. This basically means that the whole cross functional team (Devs/QA/BA/Customer) works on the top priority item together breaking down the whole feature into small manageable tasks (often each of these takes less than a couple of hours for a pair to complete)

We have been swarming on stories for quite a while now and I would like to share my observations on some of the benefits we have seen;

  1. Our top priority story gets all the attention this means it gets delivered first and sooner than it would if the team was spread out on other stories we have found that even unusually large stories that we would have previously expected to take most of a two week iteration often get completed in a few days.

  2. The team delivers testable functionality early on in an iteration keeping QA’s busy and revealing bugs quickly

  3. The customer is focused on the item most important to them and has a clear view of the progress being made and what the team is working on

  4. More robust to absence whether planned or unplanned as all of your team knows about the feature being developed we have found for example that there is better pair rotation and BA’s and QA’s get included more frequently in those pairs.

  5. The code delivered ends up coherent as the context switching that can occur with pair rotation and multiple stories in play does not occur.

  6. And of course it encourages small frequent commits and CI

  7. We have found that we rarely need to “turn off” features with this approach at the worst case scenario you have a single story in play at the point you want to release and in practice this has not often occurred but where it has a relatively simple approach with feature toggling has sufficed – its only a single feature switched off and it won’t be in production switched off for long after all as its our top priority story for the next release.

In summary I think if you are finding the need to use advanced version control tools to manage feature branching, or regularly using coded feature toggles to manage multiple “in progress” features you are probably suffering from Muda in your process and I would highly recommend that you give swarming a try after all do you really need that piece of paper or can you just jump?

Tagged , , ,

One thought on “Using story swarming to reduce WIP

  1. […] the most important thing first and optimise for flow of delivery over resource utilisation (see managing your backlog for more on […]


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: