In this post, we interview management consultant and coach Johanna Rothman. Her latest book is Agile and Lean Program Management: Scaling Collaboration Across the Organization.
Huimin Li and Jennifer Quraishi for Mingle: In your books and blogs, you talked a lot about management leadership. In your opinion, what criteria would you use determine if an agile program manager is successful?
Johanna Rothman: In the past, some senior managers (and program managers themselves) judged a program manager’s success by how well he or she “drove” the program to release. But when someone at the top “drives”, the program does not rely on the teams to show their work and the teams tend not to be as agile. Programs like these tended to have massive overtime, schedule overruns, bad products, and exhausted teams who had created technical debt. Now, we can use agile and lean. The program manager can be a servant leader. We can judge an agile program manager’s success by how well the program manager removes obstacles and solves problems for the program. If people can work inside the program environment successfully, that’s what counts.
Mingle: What are pitfalls program managers should avoid when organizations try to scale agile or lean?
Rothman: Here’s the biggest one: What works for one team does not scale directly to a program. If you try that, you will get bloat—too many meetings and not enough deliverables. I see people trying to use Scrum of Scrums to manage programs. Maybe you can do that for a few teams and it can work for you. But, if you have a complex product, creating a hierarchy to deal with problems creates late problem-solving.
Another problem I see is that the program waits too long to deliver working product, either internally or externally. There are many products that involve hardware. Releasing those each month is quite difficult. But if you wait until the hardware is “ready” you have a ton of problems.
I even see software-only programs who have trouble releasing because they are not accustomed to releasing. I like releasing something each month, at a minimum. I like continuous delivery if you can do it. Some large programs can. If you create an environment of delivery, you can ask people, “What would it take for you to internally release your part of the product at least as often as every month?” That generates a list of obstacles, some in the teams and some outside, that the program manager can address.
One more problem I see is planning for too much and for too long. The program product owner (often called a product manager) may create a rolling feature road map that’s anywhere from four to six quarters long. The organization wants to plan their wish-list for that amount of time.
The team product owners might try to plan an entire quarter at a time. However, when I work with teams, I see them have trouble planning more than one month’s backlog in any detail. If the product owners don’t continue to break the road map down into small stories, the teams end up with work-in-progress (WIP) and incomplete stories.
Instead, the product owners want to plan just enough and re-plan all the time. That way, the teams can implement parts of feature sets, integrate, and release often.
Mingle: In your consulting work, have you encountered PMs who maybe had either a fear of their team’s ability to self-organize or fear of letting go enough to let their teams organize themselves.
Rothman: Yes, that’s actually a very common problem. My perspective is: “What’s the worst that could happen?” Program managers can get so focused on the team not delivering, and not without reason, because sometimes they’re right. Sometimes the people would not deliver because the deliverables are too large. So in that situation I might ask them what they need to do to see daily deliverables. Their response is usually: “Every single day? You can’t do that. It’s such a big product.”
So then often I will suggest they talk to their program product owners (or the product owners in the teams) first and ask about reducing feature size, making smaller stories, because the more often you deliver, the more you build trust. That’s the basis of the trust in the program. Once trust is established, program managers can manage without having to feel as if they’re “control," because you’re never in control of other people. You can only try and manage the situation and manage the risks.
Additionally, I try to get encourage program managers to embrace servant-leadership. Sometimes managers are only confident in one way of problem-solving, so I’ll encourage them to find many ways of solving a certain problems. I also ask if they’ve actually explicitly expressed the results they want to see to their teams. We’re all human, so it’s possible they haven’t. PMs also have to know how to ask for bad news. And their response is usually, “I don’t want to hear a bad news.” That’s not possible. They’re going to have bad news so how do they make sure they’re receptive?
By the time we get to that, they’ve realized that they never had control anyway. They can control the environment of the program, but not what people do. That’s the best use of a program manager.
Mingle: In one of your posts, you were talking about team compensation. I was wondering if you had worked with companies where they had disclosed team member salaries, and if that had been beneficial for them.
Rothman: For myself, I’m a consultant. In a sense, my fees are public and I’m not afraid of that. I know what I’m worth. I know when it’s time to raise my fees. That said, I have not yet seen a management process where everyone knows what everyone else’s compensation. I once worked on a five to six-person team and we got a $10,000 bonus, which at the time was a lot of money. I said to the team, “This is your bonus, not mine. Decide how you want me to give it to you.” They said to give one team member at least 60 percent, if not 80 percent of the bonus because she was the soul behind the team. And then the team member took everyone out for dinner. If you’re at all Agile, I think team bonuses are more effective than individual bonuses because there’s nothing you do without your team.
Mingle: You blogged about small world networking and ‘scaling out, not up’: what’s the key element for a feature team to be successful in this context?
Rothman: Feature teams have to be agile or lean and release often. They need to keep their code clean—technical practices are key in a program. If one feature team incurs technical debt, it will affect the entire program. Continuous and pervasive testing provide the support each team needs to collaborate with other teamsFeature teams also need to build relationships across the organization. I realize many technical people are introverts. That means they might want to email rather than talk to people in person. That works, and the program manager might have to help these people meet at some point to build better relationships. In a co-located program, you can easily create communities of practice so people can talk about their challenges and resolutions.
Feature teams deliver completed features, manage their work-in-progress, and build relationships across the organization. They need to learn, ‘Who do I talk to about this issue?’ Feature teams have to be agile or lean and release often. They need to keep their code clean.
Mingle: How can program managers help teams to self-organize into small-world networks?
Rothman: We actually organize into small-world networks all the time. I bet on a program, each team has a mailing list. And, there are cross-team mailing lists: by floor, by function, to name just two. How many mailing lists do you belong to? Where do you participate? Where do you monitor?
The places you participate are part of your network. As soon as you participate in more than one place, you are in a small-world network. You can help bridge the knowledge from one team to another. What the program manager can do is to make sure the collaboration tools that your program needs exist. Do you need mailing lists? A wiki? Some collaboration tool that’s neither email nor wiki? How can you, as a program manager, help the people on the program collaborate and work together when they need to do so?
Mingle: What are the signals that a feature team doesn’t have a healthy status? What should program managers should do to help improve team health?
Rothman: I like seeing a product backlog burnup chart to see that the teams are making progress across the program. You look at the feature set by feature set progress over time. I also like cumulative flow to see the WIP. The teams need to see it at the team level, and the program needs to see it at the program level.
If you see a product backlog burnup chart that’s not increasing to show that the teams complete features, first you ask about the data. Maybe the team didn’t update the chart. Are you making it easy for them to update it? Maybe the team has other obligations. Can you stop the multitasking? Maybe the team didn’t know you wanted to see it. So tell them.
I have found that if you make it easy for people to bring you bad news, they will. If a specific team needs some obstacle removed, you can do that if it’s a program-level obstacle. If not, what do you need to do to facilitate the team problem solving it?
What the program manager can do is to make sure the collaboration tools your program needs exist.
Mingle: What is your advice on how stand-alone feature teams can solve cross-team dependencies?
Rothman: There are a couple of ways. The first thing that stand-alone feature teams can do is start to create communities of practice so that they can say, ‘We have an inter-dependency over here. How did you guys solve something like that?’ Communities of practice will help solve problems across the organization, but they won’t solve impediments.
And there will be impediments that the feature teams cannot resolve alone. That’s where the software program team can come into play. You may find an impediment across the program. You might realize you need to do an architectural spike because you don’t have any idea how this is going to work. You might find the team needs a lab, or some other resource. These are things feature teams cannot solve by themselves. Determining the type of problem is also important: Is it a collaboration problem to complete multiple features with inter-dependencies? Is it a function of knowledge across the organization?
Determining the type of problem will help you determine what part of the organization would be most likely to resolve it. For example, if it’s an inter-dependency problem, small world networks could really help. If it’s an impediment, the programming team could help because they solve cross-program problems. Your function is to facilitate the solution, not manufacture it.
This post was originally posted on Mingle's website.
Disclaimer: The statements and opinions expressed in this article are those of the author(s) and do not necessarily reflect the positions of Thoughtworks.