LMAX Exchange
Over the years there has been much lively debate over what constitutes best practise in software development. Whilst this is a topic that people clearly feel strongly about and one that has received a lot of attention there has never really been an industry wide consensus on the subject. Given that people have been developing software in one form or another for nearly eighty years (or considerably longer if you include people that lacked any working hardware on which to run it) you’d think we’d have figured out how to do it by now. The reason we haven’t, probably has something to do with the fact that different situations have different needs and that those needs evolve over time. Individual taste, fashion and the desire of pundits to sell more books may also be implicated. The relentless grind of technology change is probably a relatively minor factor.
| “ | Here at LMAX Exchange we use a number of software development practises that work very well for us. Many of these we pretty much use all the time. Others are employed frequently if a little more selectively. One practise that falls into this category is swarming. | †|
Swarming is a fairly simple concept that basically involves an entire team working on a single story for a period of time. That may and sometimes does include the special case of a whole team working on a story from start to finish but practicalities such as rotation and variations in resource profile particularly towards the end of a story tend to make the idealised case less common than you might think. More often we have a complete team working on a single story for most of its duration. At other times a team may be working on more than one story if none of them are swarmable at that particular time.
The idea of swarming is not unique to software development and the principle has been used in other domains since time immemorial. It’s hard to judge how common it is as a development practise as it seems to get relatively little attention. This may be due to the fact that it is so simple and obvious that it just gets overlooked.
When we talk about swarming it’s worth mentioning that we have more than one development team, just so that people don’t imagine that every one of our developers are working on the same story like the Keystone Cops enthusiastic if ineffective approach to crime fighting. As a result we do have a number of stories on the go at any one time at least one per team but often just one per team.
Pairing is another important practise for us and we pair frequently regardless of whether or not we are swarming. We also rotate developers between pairs within a team on a frequent basis again whether that team is swarming or not. Finally, we rotate developers between teams on a regular but somewhat slower cycle.
We get a number of important benefits from swarming:
- First of all it provides greater focus both at the team level and also across all of the teams;
- Having fewer stories in play at any one time means that each story gets greater analyst, tester and management attention albeit for a shorter period;
- This means less context switching and leads to greater efficiency;
- It also helps to avoid thrashing.
We find that velocity (however you measure it) is generally higher as stories are completed more quickly. This is partly due to the fact that more people are working on each story, but not just in the sense that the same amount of work is done in a shorter period. Parallelising tasks can sometimes help to reduce blockers, but more importantly can lead to greater overall efficiency. There is more knowledge, experience and general brain power available to challenge requirements, generate ideas and solve problems – all of which also help to promote greater quality.
Swarming helps to ensure that more stories are delivered within a single iteration and consequently for us also within a single release cycle. We currently release every two weeks, so getting code into production as soon as possible is a benefit. Getting complete and working code into production in one step is even better. It means we get feedback sooner and we also carry less inventory in terms of work in progress.
Psychology is an important, if often overlooked, factor in software development. How a team performs is influenced by a heady mix of considerations including motivation, morale, feedback and other team dynamics. If we think of the velocity of a team being self-sustained by some intangible force that is analogous to momentum then a swarming team seems to acquire and retain greater momentum than a pair, in much the same way that a pair has greater momentum than does an individual developer.
Another key benefit for us is knowledge sharing. Swarming ensures that more developers are familiar with each story both in terms of the requirements and the associated code. This helps to reduce defects which in turn again improves velocity. It also enables us to support our code more effectively in production.
Swarming has had a strong influence on what we consider to be our optimal team size and consequently it has also indirectly influenced how many teams we have. We’ve experimented with different team sizes over the last couple of years but have settled on 2-3 pairs of developers as being the most effective size for our teams to swarm (excluding business analysts and testers). In some other environments that might be considered a little on the small side, but an important consideration with swarming is how parallelisable the tasks in a given story are. Even when tasks are parallelisable it is advisable not to have too many concurrent development work streams, particularly where these have dependencies with one another. We have found it difficult to swarm with larger team sizes and smaller ones just aren’t really practical.
Swarming has also had some influence over the size and scope of our stories. Our business analysts who identify and write most of our development stories understand very well how our teams work and what makes a story swarmable. As a result, stories have become marginally bigger over the last couple of years as there is less need to break them down into smaller chunks. Sometimes sets of related stories will be played together and effectively treated as one.
We’ve been swarming as a conscious practise for a few years now and we definitely seem to have a consensus within LMAX Exchange that this is a useful approach for us. In fact it has become such an integral part of our development process that we rarely think or talk about it explicitly. We just do it – when it makes sense. Which is often.