If you have an agile project larger than two or three feature teams, you have an agile program. A program is a collection of projects where the objective is one business deliverable. If you’ve managed programs before, you know how difficult it is to keep programs on track. With bigness comes more risk.
One of the best ways to make sure your agile program is successful is to think about how to make everything smaller–not in what the program delivers, although you’ll have the opportunity to deliver early if you follow these tips. But if you think about “smaller” for organizing the agile program, you might be able to manage the risk better. Here are six tips for making your large efforts “smaller” to achieve maximum benefit from your agile programs and to help them maintain progress.
Agile Tip 1: Keep Your Iterations Short
Remember, the length of the iteration is the length of work you can afford to throw away. That’s the amount of time you have between feedback from the customer or product owner to the team. The more people you have on the program, the more inertia the program has. Imagine you have a program of 100 people. If you have a three-week iteration and you have problems with that iteration, you might have to throw that iteration’s work away. That’s better than throwing a release of work away. But do you want a three-week iteration where you have 100 people times three weeks of work you might have to throw away? The more people you have on the program, the shorter you want the iteration to be. Maybe you can only afford a one-week iteration. Consider how long you want the iterations.
And for those of you who are saying, “We don’t know how to make our stories that small!”, that’s a program impediment and a risk. You need to learn that, and pronto–because if you maintain long iterations, Murphy will come sit on your project and you will have a long iteration you will have to throw away. You know you will. Keep your iterations short.
Agile Tip 2: Keep Planning Short
If you have short iterations, you don’t need a lot of planning time for each iteration. You do need enough planning time for each iteration. Each team needs to know how many features they can take for their iteration, and they need to know if they have dependencies with other teams. This is where small features help with planning. If you have small features, you don’t have to spend any time estimating how long the features take. This is one of the reasons I like features that are so small that you don’t have to estimate their size. The team can say, “Oh, we can do that in a team-day.” The teams just take in the features they know they can take into a sprint.
But this does mean you’ll need to have a feature roadmap for the product and maintain the feature roadmap during the entire program. A feature roadmap is a living document. I’d expect the roadmap to change based on which features finish and which features you no longer want in the release. You know more about features early in the roadmap and less about features later in the roadmap.
Since you’re thinking of short iterations, the early features are smaller and well-formed. The later features are larger and more vague. It is the Program Product Owner or the customer’s job to continue to work on breaking down the later features into smaller features for easy consumption later.
Agile Tip 3: Make Architecture a Just-in-Time Activity
Ideally, you’d want architecture to occur as it’s needed, to evolve the architecture by refactoring as you would on a regular agile project. But on a very large program (especially once you have more than nine feature teams), you might want more planning than when you just see a need for architecture because you don’t have to have many feature teams waiting for architects to do their thing.
Architects can look at the roadmap and do some prototyping in advance; they can do some wayfinding or exploration. The architects or feature teams should resist the temptation to do any big design up front. They should always let the features guide their exploration and refactor to patterns. Okay, I’m saying” always” here, which probably means that there is at least one exception to this guideline. But think hard and long about whether your agile program is an exception to this tip. The longer the architects or anyone works in front of when the actual feature is requested on the roadmap, the less likely the exploration is the right exploration–and the less likely that exploration is in touch with the current code base (and more likely that the exploration is a waste).
You want the feature teams to incrementally refine the architecture. That means the architects have to be embedded onto the feature teams. If they are not, that is a huge risk to the program. One of the deliverables I have requested for every iteration in an agile program is an updated picture of the architecture to see how the architecture evolves, bit by bit. You might request that, too, as a way of managing risk.
Agile Tip 4: Integrate Continuously Across the Program
Continuous integration within feature teams is necessary in an agile project. That requires small stories to be integrated every day or so. What is not always given is continuous integration across an agile program. The larger the program, the harder this is. And the larger the program, the more necessary it is. Again, the more feature teams you have, the more inertia you have. If you don’t start integrating from the start of your agile program, you will incur technical debt. So the best way to avoid technical debt is to integrate.
Are there some programs where you cannot continuously integrate? Maybe. I have not yet met one. Start by using continuous integration inside each team. Make sure that teams understand that “done” means they can build and demo the entire product, not just locally but for the entire program. Then make sure that each team integrates across the program so that the entire system is built as often as necessary and is green at the end of each iteration (and “demo-able” at the end of each iteration).
The larger the program, the more your program might need help, especially if this is a legacy product. Your first set of features for the program might have to be a re-architecture of the build system so that the feature teams can build independently and continuously integrate—if not independently, with minimum assistance from an integration team.
Agile Tip 5: Encourage Teams to Communicate Like a Network, Not a Hierarchy
With feature and iteration smallness comes a need to communicate often. People can’t wait for a standup on other feature teams to talk to each other–they need to know right now what is going on with features, with integrations, with architecture, with testing issues. And you don’t want feature team issues to have to be escalated to you–you want people to solve problems themselves. Encourage people to act like a network.
My picture of a technical program team looks like this:
You might have many kinds of feature teams. Some, like Sally’s, have several teams working in that one project. Sally’s project is a program itself. Joe, Tim and Henry have just one team working on their set of features. All of these feature teams are cross-functional and have everyone they need to deliver their features. And because they all know who each other is, they can communicate with each other when they need to. Don’t force a hierarchy on the feature teams.
Think Small to Go Large
The larger you need the agile program to be, the smaller you need to think. It sounds funny, but it’s true. You have an epic feature? Break it down into small features. You want to accomplish more? Try shorter iterations. You want to make sure you have the product ready for release? Use continuous integration at the beginning of the agile program, everywhere in all feature teams. You want to make sure you have an architecture that works? Integrate architecture into every team’s work. Want to make sure the teams know what’s going on? Think network communication, not hierarchy.
Try these five tips and see how your agile program proceeds. I bet you too will find that going smaller will allow you to scale your agile program larger.
This article was originally published on projectmanagment.com