Win a copy of Reactive Streams in Java: Concurrency with RxJava, Reactor, and Akka Streams this week in the Reactive Progamming 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
  • Liutauras Vilda
  • Junilu Lacar
  • Jeanne Boyarsky
  • Bear Bibeault
  • Knute Snortum
  • Tim Cooke
  • Devaka Cooray
Saloon Keepers:
  • Ron McLeod
  • Stephan van Hulst
  • Tim Moores
  • Tim Holloway
  • Carey Brown
  • Piet Souris
  • Frits Walraven
  • Ganesh Patekar

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.
    What are you doing? You are supposed to be reading this tiny ad!
    Java file APIs (DOC, XLS, PDF, and many more)
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!