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 🙂
- 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.
- 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.
- 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.Tags: agile, team, testing, timebox