Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Musings About Agile Program Management

DZone's Guide to

Musings About Agile Program Management

· Agile Zone
Free Resource

The Agile Zone is brought to you in partnership with Techtown Training. Learn how DevOps and SAFe® can be used either separately or in unison as a way to make your organization more efficient, more effective, and more successful in our SAFe® vs DevOps eBook.

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.

Adopting a DevOps practice starts with understanding where you are in the implementation journey. Download the DevOps Transformation Roadmap, brought to you in partnership with Techtown Training

Topics:

Published at DZone with permission of Johanna Rothman, DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}