3 Essential Practices for Scaling Agile from One Project to a Program

Johanna Rothman, known as the "Pragmatic Manager," offers frank advice for your challenging problems. She consults with leaders and teams to help them learn about practical and possible options. They can then decide how to adapt their product development. Her most recent book is "Project Lifecycles: How to Reduce Risks, Release Successful Products, and Increase Agility." See www.jrothman.com for all her books.

  Agile  

What does “scaling agile” mean to you? For me, there are two ways to think about scaling: one is moving from one project to a program. The other is sharing agile across the business.

Let’s talk about moving from a one-team project to agile programs. A program consists of several projects across the organization. While each project is valuable, the real value is in the total deliverable, when all the projects deliver the product.

Here are three essential practices when you move from one agile project to an agile program:

1. Let teams decide how they work as a team. You might work in an organization where someone in a PMO or in management says, “All teams should work the same way.” I can see why people might want that, but it’s not a good idea and it’s not necessary.

Each team needs the autonomy to manage its own process. The more interrupts a team needs to manage, the more they need kanban. The more a team has to use spikes to learn, the more they might need the structure of a timebox to make sure they deliver features and learning. A team might want to use both kanban to monitor their work in progress (WIP), their cycle time (average time to release a feature) and iterations to provide a cadence for retrospectives and demos. (See Timebox or Kanban—A False Dichotomy for some ways to think about flow-based and iteration-…

Please log in or sign up below to read the rest of the article.