Agile practices have worked well with small teams comprising of five to nine people. But what if the customer wants more software and is prepared to spend more money to get it. How can you increase productivity by safely ramping up an Agile team?
Martin Fowler warns against a premature ramp up of an Agile team as it can lead to a break down of communication and can also break down the cohesion of code base itself.
This break down occurs because the new people don't understand how the code base currently works, so they do something at odds with it, like adding a competing framework. If there are too many new people around, the team leadership can't keep track of it all and the code base sprouts problems. These problems then reinforce each other because nobody can find a consistent way to do things
Martin suggests starting with a small team and ramping up slowly.
One of the firmest bits of advice I've heard from people who do large projects (anything over 50 people) is that the project should start small, maybe with just a dozen or so developers. They should figure out the key design elements and interactions of the system by building early parts of it. Only once that design has settled down should you think of increasing the team size to its full size.
Esther Derby talks about practices beyond Scrum of Scrums that can be useful for scaling a team.
- Organize teams around context boundaries rather than component boundaries wherever possible (Context could be a feature group like “Order entry” in a sales system).
- Make communication across context boundaries explicit. Use integrating teams to agree how to handle the interface and integration between systems. Integrating teams should write acceptance tests that confirm integration across boundaries.
- Add “Component Shepherds” who work towards maintaining integrity of components or shared services by reviewing code and coaching teams.
- “Tech Councils” (made up of integrating team members, component shepherds, and test experts) should attend to the integrity of the whole system.
James Shore suggests creating high performance work cells which are based on the Lean principle of “one-piece flow”.
The Lean work cell maps almost perfectly to the Agile idea of the cross-functional, co-located team using simultaneous phases. Rather than using the phase-based approach of handing off responsibility from group to group (requirements, then design, then coding, then test), an Agile team takes responsibility for one or two features at a time and works on them as a whole until they're done.
Siddharta Govindaraj offers a similar method called Feature Teams and provides a practical example on structuring the same.
Consider a new story that is not yet started. Team members from the main team will decide who wants to be a part of the feature team for that story. In the simplest case, you may have one or two developers and a tester volunteer to be a part of the feature team. This decision can be made either at the start of the sprint, or just in time later on. Once the feature team is formed, it is their responsibility to work together and deliver the story. Once delivered, the feature team breaks up and each team member signs on for a new story, joining a part of a new feature team.
What practices have you benefitted from when ramping up an Agile team?
