Starting Agile with a Program

The good news is that agile has name recognition. The bad news is that a number of organizations are trying to start agile in a big-bang way, especially on programs.

Program management is hard enough without throwing a new approach to projects into the mix. Since so many of you are emailing me about this, here is a draft of what I've written from the program management book. (This is unedited. It's my rough draft. Please do review 🙂

  1. Start one team on an agile project to make a build system that builds the entire product in under one hour. If you already have a product, and your build and system test takes longer than one hour, invest the time to bring that build duration to under one hour. If you don't already have a product, this is your opportunity to set up a build system for your product that allows you to build and system test in under one hour.
  2. Start another team on an agile project to create an automated test system for unit and system tests. I don't care if they buy, build, or “steal”, as in use an open-source system, but I do care that the testing system exists, and is automated. The automation goal is to automate the system test to provide a pass/fail within one hour.
  3. Start a third agile team doing a Hudson Bay Start, or a “Hello World” application using the build system and the automated test system.

Organize these three teams into one program. Keep the iteration to no more than 2 weeks. (No, not 4 weeks. That's too long. 2 weeks max. One week is even better.) See what happens with their need to discuss state with each other. See what happens with their backlogs. See what kinds of status they and you need. Make sure to do a retrospective at the end of the iteration.

Now, based on the retrospective output, you have a program backlog of what you need to do to create a successful agile program. Can you? Can the teams? If you can't, don't start an agile program. Start a staged delivery program. Start an iterative program. Start with an iterative approach to architecture and then move into feature-based development. (I have pictures for these lifecycles. Do you want to see them or are you tired of seeing lifecycles in my blog posts?)

I strongly recommend against your first agile attempt being a program. If you feel you cannot wait to start agile on a project and you must start with a program, start this way. You'll have more success and you'll be set up for success.

One Reply to “Starting Agile with a Program”

  1. Great point!
    I do definitely agree on not having big bang approach.

    However, here are my 2 cents:
    On Point 1:
    What about if the product (and more a system) is not done by one single team?
    One team hold one (or n) feature (or component) instead of a complete product.
    Each team should be aligned with a program strategy reducing integration.
    This can be done incrementally of course, but still remain lots of integration phases.
    Branches must be used of course, one per feature, and a main branch for the complete system with a strong continuous integration process

    On Point 2:
    It can be good to have one independent team to make unit and system tests for another team.
    But what about the engagement and responsibility of the first team to deliver quality against done/done requirement?
    I use a second team when legacy code doesn’t have automated non regression tests in order to provide a “minimum” tests base. Then product teams should get the tests maintenance back to them.

    On Point 3:
    Agree on that point.

    On retrospective outputs that make a program backlog. Why not? I have a doubt on that it will focus on customer added values. But I need to try it first 😉

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.