Agile In A Small Team
Scrum states that the right size for a development team is 3-9 people. I have seen that when teams are larger than this they tend to break themselves to smaller sub-teams. This lowers the risk of attempting Agile with large teams, and if managed properly can make it easier by effectively replacing the larger team with the sub-teams officially.
When teams are smaller than this it may seem nearly impossible to properly “Do Agile.” An important thing to remember right off the bat is that Agile Is Not Scrum. It’s also worth remembering that Agile is a journey.
Take Pair Programming for example. It either is or is not happening. There are different ways of doing it. It can be tweaked a little over time. At the end of the day though, you either are or aren’t Pair Programming and if your process doesn’t change neither does that fact.
Agile is not like that. There is no end state where you can say you are Agile. If you think you’re at such an end state you have succeeded in no longer being Agile. Being Agile, or working with Agility as it were, requires the ability to change. Being Agile means one will constantly be open to inspection and adaptation. A static end state is completely at odds with this concept.
In a small team it can feel like it’s harder to “properly” do Agile. This is partly due to Scrum’s prevalence as previously mentioned. Another contributing factor is that change may be less noticeable. It’s also possible that the team doesn’t produce enough to make it obvious that it is rapidly responding to change.
Process in business is often there to normalize how things happen among many people. This may be internal or in response to regulation from outside. Fewer people involved in a process means it is easier to implement changes to that process. It also makes adopting new processes more rapid. The lack of friction to change may mask some of the change that happens.
It is also possible that the small team is able to make changes without alerting outside sources. This can be bad. Imagine a team that decides to just “get it done” and then make all the pieces “look right” after the fact. Depending on the industry this could be cause for alarm. As a counter point the small team might be able to iterate themselves through multiple stages of testing a new process before the larger organization figures out how to do one. To better support this they may iterate through without alerting the organization at every step, but summarizing it at the end instead.
Another idea is that small teams might struggle to produce as much as larger teams. This may not be as clear as most of us give it credit for though. I think it was something Johanna Rothman wrote recently, but I’m not finding it so it could have been someone else, that put this in perspective. It was a piece on seeing large teams struggle to deliver good products on time while a single person could build and maintain a large product quite well. If I manage to find it I’ll come back and update this. The point was clear though. There is a point of diminishing returns in adding people to your software projects, and it’s likely a smaller number of people than we all think. In any event, a lower value delivery rate will mask how rapidly a team responds to change as compared to a greater value delivery rate.
Being in a small team doesn’t mean Agile is not possible. I would argue that it’s the opposite. It might mean certain specific flavors of Agile are out. It might mean less formality around the process of gathering feedback and responding to change.
What differences have you seen in implementing Agile on small versus large teams? Is one inherently easier or better than the other? If so, how and why?
