Embracing the Zen of Program Management

Posted by Jen Q.

21 July 2015

In a series of two blog posts, we interview management consultant and coach Johanna Rothman. Her latest book is Agile and Lean Program Management: Scaling Collaboration Across the Organization.

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.

book cover

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.

“What works for one team does not scale directly to a program.”

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 roadmap 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 roadmap 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.

“PMs have to know how to ask for bad news.”

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.

comments powered by Disqus