How to Kill Projects and Develop Agile Programs Part 2

In How to Kill Projects and Develop Agile Programs Part 1, I listed the first steps in moving from projects to programs. Embrace but control projects, execute the agile process, identify and measure productivity impediments.All three are important. What you need to demonstrate is that you have a team that is transparent, productive, and can execute on business priorities. You want business stakeholders to be a part of the process, gain  credibility with them, and leverage success to fuel future demand.In your agile program, there are a number of areas to focus on. Do you have the right team and skills? Are you measuring velocity and is it consistent? Are you using retrospectives to address quality issues and can demonstrate improvements? Are you capturing technical debt? Are your deployments efficient?

But most important – do you have a well defined backlog and is there a product vision for new products and enhancements?

Getting to Agile Programs

Once you have an efficient team in place, the leap to programs becomes easier. Both business stakeholders and technologists have incentive to leverage the expertise of the the team and give them another assignment. There are some challenges in prioritizing work; do you enhance the current product, or develop features for the next product? This is a prioritization issue that agile provides tools to address.

There is also a financial issue. If you require financial approvals on projects, how do you run agile programs? This is also not as complex as it seems. If you require a financial approval, package the benefits and costs for a collection of releases and schedule the approval. In the end, this is a timing issue that you have a backlog and business backing to justify the team’s next set of development priorities.

The main thing to address with Agile Programs is to govern and manage issues that arise when you have long standing teams developing new products and applications. For another post…