Can Agile Scale?

A common misconception is that agile doesn't scale to large and/or distributed teams. Many of the agile methodologies focus on smaller teams, but that doesn't mean that their usefulness is limited to that context.

Large, distributed teams present their own challenges. These situations can be more difficult in any project management approach (including waterfall). Agile has proven to be compatible (I would argue superior) with these scenarios.

To start off, the teams should do release planning together. Key members should be flown in so that critical mass is achieved at a single location. This is the most important time to get everyone together. The goal is to supercharge the planning process.

An approach that has worked well is to have release planning last a week. The first four days are for discussions of the backlog. How to approach things, how to distribute the work, etc. The final day is about laying out the iterations and getting a feel for what the release is going to accomplish. Important note: this is not a commitment, this is a projection which will be updated every iteration based on new information.

Each iteration should be coordinated between teams. This can involve discussions before and after planning to synch up. It can also involve teams sending representatives to other teams' meetings. Rather than doing things in sequence (Team A does their part in iteration 1, Team B in iteration 2, etc.), try as much as possible to break things down so that each iteration produces additional user value. Also important is that the iteration should stand on its own (i.e., if you stopped work on the feature after the iteration, nothing would be wasted).

Scrum has a concept called a scrum of scrums. This is taking the daily stand up meeting (where you answer what you did yesterday, what you're doing today and what is blocking you) and doing it at a meta level. Instead of each individual representing themselves, each individual represents a team. Every team participating in the coordinated release should have a representative.

Two critical success factors to this. First, you have to keep the meeting short (ideally under 10 minutes). This means sticking to just the points that are relevant to the other teams (i.e., what work are you doing that is most likely to affect them). The second critical success factor is that blocking items need to be taken seriously. The goal is to get them resolved by the following day (i.e., given priority). If they're not, they should be brought up again and again (until they're resolved). This focus on resolving dependencies quickly can make a huge difference.

Another thing that can bring teams together is to have one demo (involving all teams) rather than several smaller ones. This keeps the teams aware of what is going on with the larger effort.

At the end of the release, all teams should participate in a retrospective to identify what went well, what went poorly and how things should be done differently. This ensures that you're continually improving things and tweaking them to what works best for your teams.