What is the optimum size for an agile team?
This is an often asked (and often answered) question, but I thought I would share our recent experience at Huddle. It is important to bear in mind, of course, that an agile approach to software development does not come with rule book. It is important that teams do what works for them, in line with the principles rather than prescribed practices of agile. The retrospective is there for continuous inspection and adaptation: if something isn’t working well, change it; and if it still doesn’t work then change it again. And this is just what we have done.
I guess next I should give a little background. I joined Huddle in March 2008, and introduced an agile development process. I will aim to describe various aspects of this process, and what has gone well and badly, in future posts, but for now I will summarise by saying we have adopted the universal “mix of Scrum and XP”, influenced particularly by Mike Cohn.
I have introduced agile in a number of circumstances previously, but this has usually been into an environment where the total number of developers was clearly greater than the maximum sensible team size, and in most cases they were distributed across multiple locations so it was obvious that the large team needed to be split in to smaller units. In the most recent example at Travelocity we opted for teams of 5 and this worked well. In some ways setting up the agile process at Huddle was a pleasing “back to basics” exercise. It was a small (4 people at the time) team, (nearly) all co-located in the same (tiny) office, with the product owner within touching distance rather on a different floor or different country. However, as you may have seen in various corners of the IT press, Huddle has been going rapidly this year: in users, in revenue - and in number of staff. The Technology team is eleven-strong right now, with 4 more people joining us the in next two weeks. So at what point is the team too big to act as a single agile team?
To begin with I was hesitant to suggest splitting the team, as we were still within the theoretical recommended agile team size range (an iteration team of 9). But in a recent retrospective, after an all-time low number of points delivered despite an all-time high number of people working as part of the iteration team, a few team members commented that the team “felt too big”, that “communication was difficult” and that they sometimes “didn’t know what they should be working on”.Taking a step back this isn’t that surprising. Agile teams are self-organising teams, that rely on high bandwidth communication between team members to acheive a common commitment and iteration goal. As the size of the team grows, the number of different communication paths between individuals increases with the square of the team size, so knowing what is going on gets much harder very quickly.
Takin this feedback on board, we decided to split the team in to two (5 + 4), with each team committing to their own set of stories from a common backlog. We said we would try it for a couple of iterations and see how it went, but from the very beginning is has been a great success. As James said in the retrospective at the end of the first iteration with two team, “All of a sudden work in a million times more fun. Communication is much easier, and I feel more like part of a team, and less part of a large machine”. The velocity bears this out as a good move too: following on from our lowest ever velocity, the first iteration after the split resulted in our highest ever velocity, with more than double the points delivered compared to the previous iteration. There are other factors that mean that this level of velocity may not be sustainable, but it’s a pretty good start! There are a few downsides to the split (some related to specialist skills - to be covered in a separate post), but in general things are going much better with the smaller teams
So there is no definitive answer to the optimum size question. But I can say that for us, nine was definitely too big, and teams of four or five have been very successful. As we look to add another four people over the next couple of weeks, we will have to decide whether we want to end up with two teams of six or three teams of four, but the general feeling so far is that small is better.