This post is what you do when you are a program manager and not everyone knows what “agile” is, when you create a new product, when you are introducing that much cultural change? (In the book, I will talk more specifically about change and what to do. This post is the highlights.)
Project management and program management are all about managing risks. How do we bring the management of change and management of risk together in an agile project or a program?
Let’s review the principles again:
- Separate the business decision for product release from the software being releaseable all the time. That means you want the software releaseable all the time, but you don’t have to release it. I talked about this in Design Your Agile Project, Part 1.
- Keep the feature size small for each team, so you can see your throughput.
- Use the engineering practices, so you don’t incur technical debt as you proceed.
- Understand your potential for release frequency.
Are you doing these things now? Are they part of how you work every day? If not, you need to change. I’m going to address what the program needs to do to succeed.
Your Program Represents the Teams
In a sense, the program will represent the state of agile for the teams. Think of it as Conway’s Law exposed. (Conway says the system design reflects the communication structure of the designers.)
You might think you need to standardize your approach to agile or lean. You might think you need to be rigid about how you move to agile.
You would be wrong about the process. You would be more correct about the engineering practices.
You need to create the most resilience for the organization. Here’s what I mean.
If you have autonomous, collaborative teams, you will have uncoupled, collaborative code. If you look at the Cynefin framework, you get that on the right side, without too much trouble. (I’m not saying this is easy. Just that it’s more possible.)
But, what if you have geographically distributed teams, or your teams are new to agile/lean, or you are still responding to requests from all of the program because the rest of the organization doesn’t quite understand agile? What happens then?
You are on the Complex or Chaotic side of the Cynefin framework. Maybe you don’t use the Good Practice that we already know for program management, right? Maybe you don’t use what we already know about for the projects, because they won’t scale for the program.
That’s why each team needs to review Part 2 and Part 3, especially if they are part of a program.
That’s why program management needs to be servant leadership at the core team level. See Which Program Team Are You Managing? Some program managers think they are managing technical teams. They might be. But, they might need to manage a core team in addition to a technical team.
What Does this Mean for a Program?
- If you are trying to change everything, you have many unknowns. You are not in the right side of the Cynefin framework. You are somewhere on the left side of the framework. Agile “out of the box” is not going to work.
- Teams need to practice being agile as a team, before they are part of a program. They can come together in service of a program. And, because each team designs its agile project, no manager can change people on a team, unless the team requests that change. No “I can move people like chess pieces” business. Managers serve the teams.
- Beware of hierarchies. They will slow your program. What is a hierarchy? Scrum of scrums. Hardening sprints, especially where other release teams integrate for the feature teams, can create hierarchies. Why? Because it’s too easy to say, “My part is done.”
If you are designing your agile project to be part of a program, you want to consider, “How will we make sure we deliver on a consistent basis to the rest of the program?”
This is not about maximizing throughput. This is about meeting deliverables, and making sure that the teams know about their interdependcies long enough before they have to meet them. Then, the teams can meet them.
In a program, you always have interdependencies. Always.
Design Each Team’s Project to Optimize at the Program Level
If you are part of a program, it’s not enough to design your project for your team. You have to consider the needs of the program, too.
Each team needs to ask itself, “How do we deliver what the rest of the program needs, as the program needs it?”
You might want to watch Phil Evans Ted talk, How Data Will Transform Business. In a hierarchy, we have too-high transaction costs. (In geographically distributed teams, we have too-high transaction costs, too, but that’s a different problem.) Note how he says “Small is Beautiful.” Hehehehe. Gotta love it.
Hierarchies are slow to respond. They impose barriers where you don’t need any. The problem with programs is that they are big. You want to decrease the problems of bigness where you can. One way to do that is to decrease the effects of hierarchy. How? By not involving hierarchy whenever you can. That means using small world networks to solve problems between and among teams. That way you solve problems where the problems exist.
If I ran all the programs in the world, what would I do?
- Have feature teams everywhere, not geographically dispersed project teams. I prefer collocated teams, but I realize in very large programs that is not always possible. (Sigh.)
- Have a core program team (cross-functional business team) that runs itself using kanban. If you need a cadence, use a one- or two-week iteration for the team’s problem-solving.
- For the technical program team, run itself using kanban. Same idea with problem-solving cadence.
- Have the project teams use their own approaches to agile and lean, recognizing that their job is to reduce batch size, get to releaseable all the time, and not incur any technical debt as they proceed. The more the project teams are autonomous in their approaches to agile, the more they will collaborate with each other. The more they will feel free to explore what they can do.
- Have the program architect (who represents the business value to the core team) look for examples of bad implementations of Conway’s Law all the time in the product. That will help create architectural business value. Yes, there is more that the architects do.
- Encourage Communities of Practice for the functional areas. Encourage cross-pollination between the communities. The “plain” developers need to know what the architects are thinking, as do the testers. The developers need to know what problems the testers are solving, and so on. Organizing and facilitating CoP might be a management job. It might be a program management job. It’s a servant leadership role. It’s definitely not a command-and-control role. (“It’s Tuesday at 4pm. It’s time to learn.” Ugh. No.) The word here is “encourage,” not mandate.
- As a program manager, you need to be aware when people need more training in understanding deliverables or what those deliverables are. Do they understand flow? Do they understand agile? Do they understand feedback? Do the teams need coaches? Do the teams need help in project management (yes, the teams are doing project management)? Do the teams need help in agile or lean? Do the teams need help in the interpersonal skills? Do the teams need help in the engineering practices that will help them deliver a clean feature every day or so into the code base?
Those are just your deliverables to the program. That’s nothing about what you deliver to your management team.
Keep these three words in your pocket for your teams: autonomy, collaboration, and exploration. The teams need to be autonomous. It’s their deliverables that you care about. Not the teams being in lock-step.
You care about the teams collaborating. How do you encourage that? With small features and product owners who have well-defined feature backlogs and roadmaps. The more often the teams check completed features in, the fewer collisions, and the more manageable the collisions are. You get momentum that way. I talked about momentum in Organizing an Agile Program, Part 3, Large Programs Demand Servant Leadership.
The exploration occurs when the teams (which include architects) spike or explore what the team(s) think the options are. Or, when teams talk among themselves to solve problems. Teams can first solve problems themselves. They do need a small world network and to know that you want them to solve their problems. They don’t need a hierarchy to solve problems. These people are smart. Isn’t that why you hired them?
Okay, all the previous posts in this series are:
Design Your Agile Project, Part 1
Design Your Agile Project, Part 2
Design Your Agile Project, Part 3
Design Your Agile Project, Part 4
Sorry this series took me so long. Travel and our new house interfered. Being a product owner is all-consuming.
| Reference: | Design Your Agile Project, Part 5 from our JCG partner Johanna Rothman at the Managing Product Development blog. |
