Agile adoption strategies

[Mjeff Wilson]

I've got the following questions for James and Shane:

How do you adapt agile processes to very large teams? I am part of a project with 30-40 developers on my system. In turn, my system is one of a dozen systems all working towards the same release of the larger project.

What compromises will you have to make to adopt an agile process on a subteam of a very large process such as the one described above? How do you deal with the waterfall method and artifacts being imposed by the larger project on such a subteam?

Thanks.

[James Shore]

Hi Jeff,

It seems like you really have two separate questions: first, how do you use agile on a very large team; second, how do you use agile when the larger team isn't.

Using agile on a very large team involves partitioning the work, just as with any software development project. One of the challenges you'll face is keeping the design & architecture stable as the project evolves. I've seen several approaches to this:

1- Use a standard producer/consumer model, in which technology teams provide core technology for feature teams to use. This might work well in an environment with clearly defined technical boundaries, but it runs the risk of the technology teams creating ivory tower technology that feature teams have to work around. There's greater risk of stovepipe systems in this scenario.

2- A roving "architecture team" model, in which members of feature teams meet regularly to share their recent enhancements and changes, and jointly decide which improvements to push to each other. An important element of this model is that the "architects" are senior programmers who actually work on feature teams. In a variant, the "architects" swap between teams every so often in order to gain new perspectives.

3- A collective ownership / continuous integration model, in which each feature team shares responsibility for the entire codebase. This could work well if combined with the architecture team model, and if the overall team size wasn't too big.

4- The "start small and grow" model, in which you start with one team and then grow and split over time. I know of one company that started with a single team of seven developers and grew to nearly thirty teams over two years. This model has the advantage of stabilizing core components before splitting.

Those are some of the basic ideas. I'm sure there's more that I'm not thinking of right now.

With regards to being agile inside a larger non-agile organization, this can be difficult. The most common approach seems to be to sacrifice somebody (often the project manager) to providing a traditional facade to the larger organization. In other words, the team looks like a nice compliant non-agile team from the outside, but is busy being agile on the inside.

Since a lot of the advantages of agile development come from the way it plans and interacts with customers, this has technical benefits but isn't my preferred way of working!

Cheers,
Jim

[Ilja Preuss]

Another good resource for large teams is Jutta's book: http://www.jeckstein.com/agilebook/

You will probably want to read Jame's book first, to get a grip on the basics of Agile development, though.