Organizing An Agile Program, Part 4: Start From the Teams and Work Up

We got here because I started with Managing the Stream of Features in an Agile Program. That got me to Organizing an Agile Program, Part 1:Introduction, Organizing an Agile Program, Part 2: Networks for Managing Agile Programs, Organizing an Agile Program Part 3: Large Programs Demand Servant Leadership. Sorry I got behind. Life interfered.

Some Principles for Large Programs

In this post, I'm going to talk about what the teams need to do, and how you, as a program manager will manage those principles. These principles are:

  1. Batch size matters. You need to make sure the batch size, the number of features the teams address before they integrate is as small as the teams can manage. Yes, that means you want to get the entire program as close to continuous integration as possible.
  2. Iterate on the backlog and the roadmap. You want to see if you can finish the program early. I realize the schedule advances are rare in a program, but you want to allow for them.
  3. Encourage the idea that not all features in an area need to be complete before the product owner can proceed to another area. This is why the product owners need a community of practice and why there needs to be a Program Product Owner and a program roadmap, and a program burnup chart (maybe) to see the progress on all the features. You don't need to see completion on features. You need to see if enough has been done on the features before you proceed to other features. In Manage It!, I said the project manager needs to ask “How little can you do?” You want to ask the product owners this question for each feature set also. (If you look at that post, note that I wrote it in 2003!)
  4. This means that the architecture has to iterate, also. This is going to stretch the minds of the architects something fierce.
  5. Make sure the program releases something every six months, if not before, preferably to the customers. (If you have hardware, maybe not to your customers, because the cost of that becomes prohibitive.) But, if you have a software-only product, whether it's SaaS (Software as a Service) or a boxed product, the larger the program, the more the requirements will change. Even with a roadmap to see where the product is headed, other people, aside from the sponsors need to see and feel and smell the product.

So, release the product. Let them touch it, play with it. That means the product needs to get to done at least every six months. Yes, the program—the entire program—needs to get to done at least every six months. Do you see why the batch size matters?

Okay, based on these principles, let's discuss specifics.

The Larger the Program, the More Technical Practices Matter

One of the things I've noticed is that I have rarely seen a successful team transition to agile without adding many of the XP practices. I don't know how a team gets to done at the end of an iteration without continuous integration, TDD, refactoring, test automation, and some form of review of the code. And that's just a single team. Remember I said back in Part 2 that larger programs do not linearly scale? In larger programs, I don't see how you succeed without the XP practices. Well, you can if you want to. You folks are very smart people. You can make anything succeed. It takes you much longer. Without the XP practices you will incur technical debt. You will have to pay off the debt at some point. Probably before you release to your customers.

Some programs have transitioned to using kanban/lean as a way to manage the problem of how to integrate as the teams proceed. Especially for teams who don't choose Scrum, this is a great idea. You don't need iterations.

Lean enforces the reduction of WIP (work in progress). Teams don't have to worry about the issue of “did we take enough for this iteration?” They just take the next item off the ranked backlog. They integrate it as they finish it. If you use lean, and you keep your stories small, you are likely to keep your technical debt down. This is one way of reducing batch size.

In a program, the program manager doesn't care what the teams do. The program manager cares about results. That's all. What the program manager does care is that the teams can deliver results week in and week out. Or, iteration in, iteration out, and that the iteration is short. This is why having a small batch size is critical.

The larger the batch size, or the longer the iteration, the less predictable anything is. The less predictable, the higher the risk. High risk is bad. Low risk is good.

High risk leads to inertia. Low risk leads to momentum. Remember Organizing Agile Program Part 3, Large Programs Demand Servant Leadership? I discussed inertia and momentum there.

With small batches, you can invite people to use continuous integration. The larger the batch size, the more continuous integration is out of your reach. Then you can throw predictability out the window.

Manage the Program Backlog Iteratively

Remember I said you needed roadmaps to tell you where you needed to go? You also need to manage the backlog. Your program and project backlogs are not static. No, sirree. Your product owners are going to pick and choose across the program what they want you to work on next, based on what they see, each iteration.

This means that the technical people do not get to decide what to do. This is critical. The technical people need to get to done at the end of a feature. They need to get to done at the end of an iteration. The technical people do not get to decide what to do next.

However, the technical people should absolutely discuss, plead, argue and wheedle with the product owners about the direction of the product. There is no reason that they should not. But the product owners have the final say. Always. That's because the product owners understand the business value of the features. The technical people might not.

That's especially true when the product owners say, “We have done enough in this feature set and it's time to work on that feature set.” The team might say, “But we are the Fuzzy Button feature team. You're telling us not to work any more on Fuzzy Buttons. Now we have to work on Smooth Rivets. We don't know much about Smooth Rivets. We're going to have to learn about Smooth Rivets. You know that, right?”

The product owner is going to say, “Yes. I'm sure you will have a learning curve. That's fine. We'll start slow. You'll do something and I'll provide feedback for you. You see, we need to have enough across the product, so we have a fully-featured product. That's because we are going to release a version of the product in less than two months from now, because we are four months into this release.

“So, even though we call you the Fuzzy Button team, you're also the Smooth Rivet team. Would you like to change your name? It's fine with me. It's up to you. You're going to have domain expertise across more of the product. For the next few iterations, it's Smooth Rivet time. Here's our new updated roadmap.”

This is when the architecture might well change. Oh well. Better that you know now than at the end of the program, right?

But we have technical debt!

Oh, I can sympathize with you. The question is this: how much technical debt do you have, and how transparent is your debt?

Is your debt transparent enough that you can see it each and every iteration, or every time you make the choice to take another item off the backlog for the next feature? This is when the Product Owner job is critical. Can one Product Owner do this job for an entire program? Of course not. You need a community of Product Owners for anything but the smallest of programs (3 teams) and you need a small world network to support that product owner's decision-making. How else will your product owner be able to make great decisions? This is why I recommend a Program Product Owner at the core team level, and a product owner for feature teams.

This is why you can share product owners for large (greater than 9 teams) programs across several teams, and still succeed, if you have communities of practice. But, if you attempt to share product owners for feature sets, the product owner is multitasking. Don't do that, unless you want the program to fail. When will the product owner actually talk to the real customers?

But the point of this post is that you do not want to create any more technical debt. In a program, more technical debt creates inertia, not momentum. We discussed inertia and momentum a little bit in Part 3: Large Programs Demand Servant Leadership.

Teams Are Responsible for Their Own Technical Practices

Yes, I said that teams are responsible for what they do. If you are the program manager, you can request. You can wheedle, beg, influence. You can also entice. But, you cannot impose. You cannot command-and-control. You can measure to show the effects of not doing certain practices. You can request or suggest that the teams measure certain things to show their technical debt.

It also means the product owners cannot play the feature-itis game. Remember, no one can make you work in any way other than your best work.

The more people on your program, the more important it is to not add to your technical debt. Or, if you choose to take on technical debt, to make that decision consciously.

This is why each team has to be responsible for itself, and report on its own work. This is why each team cannot report on velocity as if that measure meant something globally.

Where we are now

When you organize an agile program, you cannot only start from the top and work down. That doesn't work. You can explain your principles:

  1. Small batch size: small features.
  2. Iterate on the roadmap so you can determine when to release.
  3. Implement features as they need to be implemented, across the program, not just because they are in one feature set area.
  4. Iterate on the architecture, making it more robust.
  5. Release something at least every six months.

Now you have explained the results you want. These results lead the teams to want to perform the XP practices, to use continuous integration, to inspecting and adapting as they proceed.

For those of you who are not agile across the organization, I have advice. Hang in there. For those of you transitioning to agile, I have advice. Hang in there. Part of the advice will be driven by what you see in the measurements.

In part 5, I will attempt to tackle measurements. Hopefully everyone in my house will stay healthy and it won't take me months to do the next post.

See the final part of this series: Organizing An Agile Program, Part 5: Measurements That Might Mean Something to a Program.

One Reply to “Organizing An Agile Program, Part 4: Start From the Teams and Work Up”

Leave a Reply

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