Managing the Stream of Features in an Agile Program

One of the challenges in a program is how you manage the checkins, especially if you have continuous integration. I am quite fond of continuous integration, no matter how large your program is. I also like short iterations. (Remember Short is Beautiful?)

But imagine a product where you have a platform and layers. I'm separating the GUI and the API for the GUI, so you can see the application and the middleware and the platform. Now, this architecture is different from separate-but-related products that also might be a program.

architectureThis is an archetype of an architecture, not your architecture. I am sure you have more than 3 middleware components or 4 app layer components. The product I'm thinking about had 12 middleware components, about another 12 platform components and about 50 app layer components. It was a big program with about 200 people working on the program for over 2 years. I wanted to simplify the picture so we could have a conversation.


implement by feature
The features cut through the app layers and the middleware layers. The colored lines are the features. Now, multiply these lines by each project team and each feature, and you can see what happens in a program. Imagine if I added colored lines for 25 features for 25 different feature teams.

It could be a problem.

However, if project teams limit their WIP (work in progress), and swarm around features, integrating as they proceed, they have fewer features in progress. And, if they are networks of people, so they have communities of practice, they have ways of talking to each other, so they don't have to wait to sync with each other.

Technical Program with Communities of Practice
Technical Program with Communities of Practice

People talk with each other when they need to. That's it. When features are small, and they integrate every day, or every other day, people expect to discuss integration issues all the time. And, while I am not a fan of integration teams, even I admit that on a large program, you might need an integration team to help keep things moving. This is in addition to what everyone does of syncing with the main line everyday: taking down the new additions to the main and syncing just before putting new changes up.

If you keep a stream of features moving in a program, even with many feature teams, as long as the project teams keep talking to one another, you are okay.

You are not okay if someone decides, “I own this code and no one else can touch it.” Now, you might decide that all middleware code or all particular component code has to be reviewed. Or it all has to be smoke tested. Or, it all has some other gate that it has to go through before it can be changed. Or you pair on everything. Or, you have situational code ownership. That's perfectly okay. You decide on the technical mores for your program. It's a good idea to have them.

But, the larger the program, the less you can have one gatekeeper. Because that person cannot be in one place, holding their fingers in the figurative dike. This is why I don't like czar-like architects, but I do like embedded architects in the teams for agile programs.

When the product reaches a certain level of maturity, you can work on a particular component as a feature, and swap it in or out once you change it as a feature. This takes significant skill.

If you want to be agile for a program, you need to be more agile and lean, not less. You need to have smaller stories. You need to work by feature, not by architecture. You need to swarm. Well, that is if you don't want program bloat.

Okay, what's confusing to you? What have I forgotten? Where do you disagree? Let's discuss.

6 Replies to “Managing the Stream of Features in an Agile Program”

  1. Hi Johanna,

    Liked your blog. My project is going through the same situation.

    Preparing builds once a new feature gets added for different customer is really painful. Continuous Integration and smoke testing using Selenium I thought would lessen the issue. But I have never been able to do that for some other reasons.

    I still dont know, whether Continuous Integration and Selenium testing will really help me or not?


    1. Aha! Your question provides part of the answer. Well, I’m trying to mind-read, sorry. You say different customer. Are you preparing slightly different products for different customers? If you have one-offs for different customers, you will have PAIN, my friend. There is no way around that. Continuous integration and lots of regression testing underneath the GUI will help as much as possible. The question is this: Where do your products start to change?

      If you have the problem of this-customer-wants-this-feature and that-customer-wants-that-feature, you are in the early adopter phase of your product. You happen to have a program. I explained this in Manage It!. You want to release as often as possible and satisfy one customer after another, as quickly as possible. So yes, I think CI and as much testing as you can do as you proceed will help.

  2. Hi Johanna,

    Thank you for the excellent blog post. To comment, in response to your response of the original comment by Pranjal (say that 10 times fast), I believe there are opportunities for team organization and/or perspectives that allow relative diversity in the product feature set and/or work streams that do not necessarily have to be shared with all customers, whereas some sharing is both preferred and necessary.

    For instance, using an architectural approach like the SEI’s Software Product Lines, you can achieve the separation of reusable core assets that are shared across the product family without introducing customers to the variable (customer-specific) features, within the context of a set of related features where variability in the family allows for more rapid adoption and/or development turnaround.

    This is certainly a different discussion than your original post, but if you intersect what you’ve said here with the notion of product families and the approach of Software Product Line engineering it presents an interesting opportunity on Lean delivery in the context of a larger scope of effort, which seems very fitting in the context of this blog post.

    At any rate, thanks again for sharing.

  3. Thank you for a great explanation.

    I’d have to imagine that most of the mgr’s I’m working with would say this is an ideal state you are describing. We don’t currently have this, nor anything near this state. So how does one go toward this state of feature development? They might argue that it is easier for them to manage if the teams just work on their component layer, all this collaboration you talk of would just slow the workers down.

    1. David, you take small steps. First, who are these managers? Are they project or program managers? Will they be anywhere near Indianapolis on Mar 7? I am leading a one-day workshop on agile project management, that might help them understand how to lead projects or programs to get to this state.

      If they are functional managers, why are they making decisions about code or features? Why are team members not making decisions about code? Why are team members not in charge of their own code ownership, and what a feature looks like or how features look? Why are managers making decisions?

      Managers are great for many things. But they tend to get in the way of decision-making for a program. They might even introduce delays in a program. The project teams need to be feature teams and the feature teams need to take (tremendous) responsibility for the features and the business value of the architecture and design and keep the program moving.

      I realize this is a different view than many people have. Some of you might be gasping. If I had not lived this with programs, I would not tell you to do this.

      You start with project teams who know how to be agile, end-to-end, so you have practice in the small. It’s ideal if everyone can do this. I know that not everyone can. This is why teams need coaches and facilitative agile project managers. If you look at the picture called “Technical Program with Communities of Practice,” one of the jobs for Joe, Tim, Harry, and Sally, Sam, Stuart, Sunny, etc. is to facilitate each of their project teams’ feature development end-to-end.

      You keep people focused end-to-end. Do you ever work across the architecture? If you need to. You look at your decisions and ask, “Is the best decision I need to make now, given the information I have at hand?”

      When people have asked me this, I have used the Rule of Three and we have generated more alternatives so we did not need to work across the architecture. That’s me. Your mileage will certainly vary. I am allergic to working across the architecture. Did people work across the architecture in my programs and not tell me? I am sure they did! “Let’s not tell JR and keep her happy!” However, every time they did, they incurred some technical debt. As long as it was just a little, we could pay it back.

      I am not advocating anarchy. I believe in management. I believe in networks of technical teams even more. You have serendipitous advances in the program that way.

      My backlog for posts for program management includes how to start a program and how to organize a program. Let me know which one you want first.

      1. Thank you for the detailed response Johanna. I actually believe in this agile mind set and want to believe I represent it, as I coach teams. I’m trying to channel the thoughts of the population I’m dealing with, and not being as successful as past engagements. So I’m searching for the differences, me, the culture, the system, them, etc.

        I’d like to elevate the “how to organize a program” item on your backlog.


Leave a Reply

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