Key takeaways
|
The book Agile and Lean Program Management: Scaling Collaboration Across the Organization by Johanna Rothman explores how to scale lean and agile processes to work in large programs. It explains how to collaborate across the organization to create and steer an adaptive, resilient program. As a result of transitioning to agile and lean in the teams, and using adaptive program management, the organization can obtain better delivery-to-market speed.
Rothman mentioned following principles of agile and lean program management in the book:
1. Take a product perspective. The principle is:“Business people and developers must work together.”
2. Agile and lean approaches encourage a holistic approach to the product where you can change more easily to meet current needs. The principle is: “Welcome changing requirements. This is a competitive advantage.”
3. Program managers are servant leaders. The principles are: “Build projects around motivated individuals,” “Trust them to get the job done,” and “Empower the team.”
InfoQ interviewed Rothman about how agile and lean together is helpful for any program and how management can support a program to succeed.
InfoQ: Why did you write a book about Agile and Lean program management?
Rothman: I saw people struggling with programs.
Some people did not realize they were managing programs. They thought they were “scaling” agile from one team to several.
Some people were using the common frameworks and not getting the results they wanted and needed.
Some people were trying to use Scrum as a management technique. Sure, you can make that work, but managers who collaborate on a program rarely work together as a team. They are a group with a common goal, but they do not work together. That means Scrum is not optimal for them and they needed other ideas for how to work together. They can see if the core team approach can work for them.
InfoQ: Who are the target readers of this book?
Rothman: Project and program managers definitely. Program managers come in many different stripes: software program managers, hardware program managers, core team program managers.
In addition, Scrum Masters, technical leaders such as enterprise architects, and other people who try to help agile and lean teams collaborate across the organization. You do not have to be a program manager to read the book and get value from it.
InfoQ: How traditional program management is different from Agile and Lean program management?
Rothman: More traditional program management tends to work in this way:
Management says, “Do this program. Here’s 300 people. Have it done by next August.” The traditional program manager realizes early on that either she has too many people, or not enough time, or that the requirements are going to change, or something else horrible. Along the way, people don’t deliver, because they have other responsibilities. The program—which is the most important job for the program manager—is not at the top of these people’s (very long) lists of work to do.
A more traditional program manager tends to tell people when she needs this done. That is because a more traditional approach works backwards from the deadline to accomplish the deliverables.
If you ever worked on a stage-gate program, it’s a mess before the second stage. Requirements take forever. Architecture boxes the program into a narrow place and by the design/spec stage, the people realize they can not work in the architecture. Or, they realize it by the coding stage and the architects are long gone.
The technical people work like crazy, and that’s when the program manager has to make crushing decisions: do we reduce scope or testing? We all know what happens: we have a less-useful product that does not work.
In contrast, agile and lean program management takes a holistic approach to the program and invites change. Instead of the program manager directing and attempting to control, the agile and lean program manager facilitates decision-making and delivery at all levels.
The core team program manager helps people at the business level for the program deliver. The software team program manager helps the software organization deliver.
Program managers don’t demand the feature teams deliver. If they demand anything, it’s to make sure that the people at the program level deliver their deliverables so the feature teams can deliver features.
That means the program product owner and the product owners deliver agile roadmaps that lead to ranked backlogs.
That frees the teams to manage themselves to deliver value, as often as possible.
The program managers and program teams remove obstacles for the teams, clearing the path for the teams to deliver.
Agile and lean program managers exhibit servant leadership. So do the architects, product managers, and product owners. Instead of optimizing for any one person or department, the program optimizes for the product delivery.
InfoQ: How Agile and Lean together is helpful for any program?
Rothman: Agile helps us invite change. Lean helps us see the whole. When you combine these two powerful ideas, you realize program management is about optimizing for product delivery. What is the best product we can deliver in our constraints?
Every program has constraints. And the program communication paths are enormous. Who do you need to talk to and when? The more you talk to people as a program manager, the better the program will be. You’ll know where the risks are without having to wait for them to show up, and the people are more likely to talk to you about potential problems.
With the transparency and trust we get from agile and lean, we can trust people to do the right thing. Will they choose right every time? No, and that’s okay. Since we are agile and lean, we can recover from risks, as long as everyone has the transparency and delivers something all the time.
With agile and lean, we get an environment of delivery. Everyone—the feature teams, the program teams, everyone—delivers something every day. When you deliver every day, you need less planning, less risk management, and less replanning. All that planning is helpful and the shorter you can keep the planning, the better. That is because things will change. If you can do just in time planning and replanning, you don’t need big plans or big replanning. You don’t have big surprises, you have little surprised.
InfoQ: You mentioned about Cynefin Framework in the book. How can it be used in program management?
Rothman: I find Cynefin helpful because it guides my problem-solving. Where am I in Cynefin? How can I create small safe-to-fail experiments? Do I need to ask internal experts about this problem over here? Do I need to find external experts who can guide us? Do I need to run an all-program experiment or can I run something over there and see what happens?
Programs, by their very nature are not in the Obvious quadrant. It might get there by the end of the program, but when we start, we are either in Complicated or Complex. We might be in Chaos, but that’s unlikely. I find it helpful to understand if we have known unknowns or unknown unknowns.
I might ask for different information or ask the teams what they can deliver when so I understand more of the risks.
Cynefin helps me understand what is unknown, and as a program manager, what do I need to do to expose those unknowns and move more of them to knowns? That helps me facilitate the teams to deliver.
InfoQ: What are the important aspects of creating a good Agile program management team?
Rothman: Since the program team is a problem-solving team, I need to know that everyone there can help resolve problems and remove impediments. I need people who can represent their area and have the time to participate.
Here’s what I do for the software program team:
1. Ask each team to decide if they need someone to participate on the software program team. If several feature teams work together, they might need just one person to participate at the program level.
2. Ask each person who says they will participate if they have the time and ability to work across the organization and participate on the program team. If yes, we are fine. If not, I work with them to determine someone who will have time.
For the core team, it’s similar. For the core team, I want to make sure that the person participating can speak for the function, not just him or herself.
InfoQ: How management can help to make a program successful?
Rothman: Management can help with this kind of support:
1. Make sure the Program Product Owner knows what management wants/needs in a roadmap. The roadmap is key to everyone’s ability to deliver. Too often, management wants to decree a feature set in a date with a specific cost. That’s way too constraining for the PPO and the program manager. Instead, ask management to help with defining what success looks like.
2. I see organizations who do not have sufficient agile training try to be agile in a program. People don’t know what to do. They don’t understand collaborating in a team, never mind across the organization. People need training. They might need coaching. If you want success, plan for how to achieve it.
3. Do not over-staff the program. I have been the recipient of too many people before we were ready. With agile and lean, you might not even need all those people.
4. Organize by feature teams. Do not use component teams or service teams. Those kinds of teams create interdependencies that are difficult to see and risks that pop up when you ca not take another risk.
InfoQ: Would you like to give any message to readers?
Rothman: Here is my core message: Scale collaboration, not process.
Process helps. Once you understand the principles of agile and lean, you can do almost anything. And, successful programs require collaboration across the organization. Program teams and small-world networks all help people collaborate. Using rolling-wave planning for deliverables, and delivering at least as often as once a month will help everyone see progress, what you still need to do, and where your risks are.
The more often you see progress, the more often you get feedback at all levels in the program. If the leaders use their servant leadership, they can accomplish great things.
About the Book Author
Johanna Rothman, known as the “Pragmatic Manager,” provides frank advice for your tough problems. She helps leaders and teams see problems and resolve risks and manage their product development. Johanna is the author of more than ten books, including: Agile and Lean Program Management: Scaling Collaboration Across the Organization, Project Portfolio Tips: Twelve Ideas for Focusing on the Work You Need to Start & Finish, Diving for Hidden Treasures: Finding the Value in Your Project Portfolio (with Jutta Eckstein), Predicting the Unpredictable: Pragmatic Approaches to Estimating Project Schedule or Cost See more of Johanna’s writing here.