Agile Zone is brought to you in partnership with:

Johanna Rothman helps managers and teams solve problems and deliver products. Her most recent book is Manage your Project Portfolio: Increase Your Capacity and Finish More Projects. You can read her blogs and other writings at jrothman.com Johanna is a DZone MVB and is not an employee of DZone and has posted 129 posts at DZone. You can read more from them at their website. View Full User Profile

Musings About Agile Program Management

04.21.2011
| 1175 views |
  • submit to reddit

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:

  1. You must pay attention to architecture, not just from the beginning, but all the way through the program.
  2. 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.
  3. If you have more than one product backlog, everyone will be confused.
  4. 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.

References
Published at DZone with permission of Johanna Rothman, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Muhammad Faiz replied on Fri, 2012/04/13 - 9:00am

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?

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.