I've been working with organizations who want to move their programs to agile. They've been successful with small projects. But now, they want to make agile work with large programs, programs that involve hardware or firmware, programs with many pieces of interdependent software features, programs of 50 to 300 (or more!) people.
Now, you might say that we should not even try to do programs of 300 people. That 300 people are too many and it's too difficult to manage their interactions. And, besides, they can't know each other. Well, they don't all work together. And, if you have a large product and you want to finish it in a year or less, you may need that many people. Several of my clients do want to complete large product releases in a short time and use agile, because agile reduces many of the technical and schedule risks. And I want to help them be successful.
Here's what I know about agile program management:
- You must pay attention to architecture, not just from the beginning, but all the way through the program.
- If you try to define the architecture up front, you will be wrong. And, you will discover you are wrong after the predicted middle of the program. If you are really unlucky, you will discover this when things start to break near the end.
- If you have more than one product backlog, everyone will be confused.
- If you try to mix up the teams, you can no longer predict any velocity. Remember, velocity is personal to a team. Teams will be consistent in themselves, but once you've changed the team, the velocity may well change.
These ideas lead me to say that in programs, you need to address architecture throughout the program, that you need one product backlog for the entire program, and that teams need to be relatively static. None of this is easy. I'll be sharing the guidelines I develop as I see them.
Dear Johanna,
How does ‘agile’ reduce Technical and schedule risk?
Where does this differ from ‘plain’ program management?
regarding 2, I can just as easily claim that if you don’t have a clear architecture vision up front, “you will be wrong”. You’Lessons Learned just as likely find out half-way through that your first assumptions were wrong, because you didn’t see the whole picture.
What kind of products are being created through an ‘agile’ program?
Best Regards,
Stephan
Wouldn’t it be possible to take a team of 300 developers and find a way to break up a large product into various components and sections to develop simultaneously so that you could have say 30 teams of ten working on these components? Or would that violate your ideas of agile?
Hi Johanna.
Even when building huge products, don’t you think that could be useful, having smaller teams, working in difference parts of the product? I think that the sense of being part of a team that is working to achieve a common goal is a really important in an agile approach, and the bigger the team the smaller this sense, due to communication, and the problems others you already know.
I’ve experienced some cases where two teams were working in the same product but in different projects running in parallel. It worked very well.
Good luck in this challenge. I’ll be following your next posts.
Thanks for sharing your experiences.
Best Regards,
André Faria
Very much interested in the knowledge/experienced shared in the large agile team arena.
If the 300 person team is focused on building a brand new product without any legacy dependencies, then I assume the exercise is more straight forward.
If thee 300 person team is an amalgamation of various IT resources, more a virtual team extending existing systems, then I believe the challenge is increased exponentially as those virtual resources are pulled in multiple directions, technology road maps cross or don’t cross when needed, etc.