Several people on social media have denigrated the terms “project manager” and “program manager.” These people claim there is no need for either role in an effective team, especially an agile team because the team can manage its own deliverables. While some agile teams can manage their own deliverables, that’s not the only role for a project or program manager.
Effective project and program managers exist to support the teams. They do that with:
- Assessing and managing project or program risks for the team’s effort and the overall product.
- Facilitating the team’s collaboration
- Clarifying the objective, so everyone stays headed in the same direction.
Project and program managers who support their teams make it possible for the team to succeed.
Let me first discuss risks.
Risk Assessment and “Management”
Project and program managers assess risks on behalf of and with the team. That helps them, with the team, understand their constraints, boundaries, and floats. Once they do, the team can choose an effective lifecycle. (See the Lifecycle series.) And, project and program managers might see risks any one person cannot. That’s all in the team’s control.
But the two biggest risks project and program managers can manage are not in the team’s control. Those risks are not having a cross-functional team and multitasking. (See the article Unearthing Your Project’s Delays. Project and program managers can ask the team to measure their cycle time, to create a visual representation of the costs of having to wait for others or multitasking. The value stream map can help teams address their internally-caused delays, but not the external delays.
However, sometimes, even if the team recognizes they have internal delays, the team can’t solve that problem. In my experience, that’s because too many supposedly agile teams have team members that do not affiliate with each other. Each person works in resource efficiency, focused on their deliverables. No one sees the big picture.
Sometimes, the lack of affiliation is linked to the multitasking. Too often, people outside the team, such as managers or product managers, create the team’s multitasking. Can an individual or even an entire team stop that? In my experience, no. First, because everyone feels the death march pressure (because of multitasking). Second, because any one person or even the team does not have the title-based authority to stop the team’s multitasking.
Effective project and program managers can see the affiliation and multitasking problems. They can work on inside-the-team solutions. And because project and program managers have title-based authority, these effective project and program managers can use their influence with people outside the team.
Effective project and program managers do not beat on individuals to meet nonsensical dates.
I’ve alluded to lack of collaboration here, so let me address that next.
Foster and Support Collaboration Within and Among Teams
When I was a software developer, I loved communing with the machine and solving problems with code. I had to learn to collaborate.
I’m not alone. Until schools teach collaboration, most of the people in our industry need to learn how to collaborate.
Project and program managers can reinforce collaboration in any number of ways:
- Facilitate working agreements within the team. On a program, possibly between teams if the “teams” are component teams.
- Use reinforcing feedback often, so people can relax into what they do best.
- Set a cadence for retrospectives, so the team can collaborate as they create continuous improvement.
The project or program manager can encourage the team to measure their cycle time, not velocity, so the team can see where they are most effective.
I always assume the organization hired smart people. However, some smart people need to learn how to work with others. Effective project and program managers can support that learning and collaboration.
But only when all the people work in the same direction. That’s understanding the objective.
Clarify the Product and Team Objectives
Back in the 70s and 80s, many project teams had a “kick-off,” where the product manager came in and gave a rah-rah to the team. On one notable project, I interrupted the rah-rah part and asked these questions:
- Who is this product for? (The customer focus)
- What can they do when we are done with our work and ship the product? (The outcomes)
- What are our release criteria? (From the boundaries, constraints, and floats as above.)
I was not the project manager on that project, but my team and I needed to know the answers to these questions.
Remember, back in the 70s and 80s, we only shipped once because the cost of delivery was so high. However, we still had uncertainty. So the project and program managers continued the conversation with the product managers even as we worked.
Now, agile teams who release often might not need a project or program manager to facilitate that conversation.
But in my experience, too many teams are feature factories. They don’t have an overarching goal at any level. Not for the product. Not for the team. Why should the team collaborate if they don’t have an overarching goal?
At the top of this post, I added an image of a random, focus-less roadmap. Yes, a real program inspired me to create this roadmap.
Each team has a line of various colors, which represent different feature sets. Notice how each team “owns” (the client’s word) some yellow, blue, and red features. And, because each team was multitasking, the powers-that-be assigned features—not feature sets, but individual stories—to each team when those powers wanted that story. No team had an overarching goal. Management treated each team as a feature factory.
Effective project and program managers can make sure someone creates a roadmap to focus the team for now and to offer a look ahead.
I’ve been talking about servant leadership.
Effective Project and Program Managers Offer Servant Leadership
Effective project and program managers facilitate teams. They are servant leaders who facilitate collaboration inside the team. These servant leaders also protect the team from various interference and insufficient clarification outside the team.
The more the team can collaborate to manage their risks and deliver value now, the less they need project managers. However, most teams I know cannot assess their risks themselves. They don’t know how to collaborate effectively, and their managers have not spent the time to specify the product needs now.
Worse, when those teams need to collaborate with others, the team feels as if they must balance “their” work against the cross-organizational collaboration work.
Learning to collaborate takes a great deal of skill. It’s too easy to retreat like a turtle, back into “your” team or back into “your” work.
Effective project and program managers facilitate and support collaboration so the teams can do their work. That’s why the project and program managers might start with the context (tradeoffs and lifecycle) to create an environment of success. Assuming they work with the team, they already started a culture of collaboration. And when the project and program manager make it possible for a collaborative team to work on one product at a time, the team can deliver.
That’s how I write about and teach effective project and program management.
Read Manage It! if you are considering which lifecycle to use. Read Create Your Successful Agile Project if your agile team-based work isn’t easy or fun. (The difficulty should be in the problems to solve, not how the team works.) And read Agile and Lean Program Management to see how these ideas “scale” (a terrible word) to programs. Yes, I teach these workshops for each book remotely.
Source link