Win a copy of Succeeding with AI this week in the Artificial Intelligence and Machine Learning forum!
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
  • Campbell Ritchie
  • Paul Clapham
  • Ron McLeod
  • Liutauras Vilda
  • Junilu Lacar
  • Tim Cooke
  • Jeanne Boyarsky
  • Knute Snortum
Saloon Keepers:
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • salvin francis
  • fred rosenberger
  • Frits Walraven

Agile adoption strategies

Posts: 4
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
    Posts: 46
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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!

    Posts: 14112
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Another good resource for large teams is Jutta's book:

    You will probably want to read Jame's book first, to get a grip on the basics of Agile development, though.
    I didn't like the taste of tongue and it didn't like the taste of me. I will now try this tiny ad:
    Two software engineers solve most of the world's problems in one K&R sized book
      Bookmark Topic Watch Topic
    • New Topic