What Happens When Product Owners Slide Into Project Management?
Be careful! What was vital in project management might destroy your Scrum Team.
Vital project management aspects might destroy your Scrum Team.
Many years ago, Project Managers were crucial players for software development teams. But with the rise of agile frameworks, Project Managers lost their positions in the team. Nowadays, teams are self-managing. They don’t need anyone to decide for them who does what until when.
Unfortunately, some Product Owners are harmful to the team because they behave as Project Managers.
I’ve worked with many Product Owners who came from project management, and thus they often showed signs of their old habits. It’s fine to transition from project management to product management, but many changes have to happen. Otherwise, success becomes unattainable.
The problem is that command and control don’t come only from professionals with a project management background. I’ve observed many Product Owners behaving as if they were the Scrum Teams boss. This outdated behavior is unsuitable to Scrum. Still, it’s shocking how often Product Owners slide into this misconception.
Let me share three common traps when Product Owners slide into project management. Hopefully, after reading this post, you will be able to avoid these dreadful mistakes.
1. Scope Obsession
In project management, three variables are critical for success: time, cost, and scope. When project managers perceive a sign that one of these variables may deviate from the plan, they run to handle that because it’s a risk for the project.
A traditional approach to project management is: create a perfect plan and ensure everyone follows it. But for software development, that generally doesn't work due to its unpredictability. Let me bring a thought from the military world which resonates with digital product development:
“No plan of operations extends with any certainty beyond the first contact with the main hostile force.” — Helmuth von Moltke, German Marshal
I like adapting this sentence to “No plan can survive contact with the customer.” When we take too long to empathize with the customers, we produce waste by building what they don’t need. That’s why our learning speed is a critical factor in avoiding waste.
Adapting to the agile mindset isn’t trivial for traditional Project Managers. For example, the core of Scrum is empiricism. To succeed with it, you have to embrace learning. You accept you don’t know everything at the beginning. The more you move further, the more knowledge you acquire. Still, when someone cannot leave the scope obsession in the past, the following will happen:
The scope is what matters: the goal is to deliver what was promised. The Scrum Team doesn’t have any time to inspect and adapt; instead, they focus on delivering what is in the plan.
Changes require intense negotiation: the team cannot embrace changes because that leads to distraction from the scope. Changes are not perceived as learnings; they are treated as something terrible to prevent at all costs. The change management process evaluates whether a change is worth pursuing or not, but generally, sticking to the scope is the recommendation.
Solutions versus problems: most refinement sessions are all about refining how to implement the solution agreed upon. Understanding the problem is undervalued; delivering the solution on time is what matters.
These behaviors are anti-pattern to Scrum and will block the teams from thriving. It’s a win-lose situation for the customers because once the focus is on the output, the quality is often compromised. Ultimately the result is not satisfying. To avoid that, Product Owners should set clear goals to pursue while empowering the Scrum Team to find alternatives to reach the desired outcome.
Solid Scrum Teams are comfortable with the unknown, but they are uncomfortable with following a pointless plan.
2. Obey Your Master!
In the past, Project Managers were often in a higher hierarchy level than software developers. Generally, they were the commanders, and they defined what everyone would work on. But the agile world is different. For example, Scrum has no hierarchy; everyone is on the same level. That’s why it’s hard for a Project Manager to understand the dynamics of a Scrum Team.
I’ve said that in many of my articles, but I have to repeat: Product Owners are not above the Scrum Team; they are part of it. When someone fails to understand that, the Scrum Team becomes dysfunctional.
Product Owners destroy the Scrum Team when they try to be the boss.
Leading the team is different from managing them. I don’t limit this misconception to those who came from project management; somehow, too many Product Owners try to micromanage the team. Let me share some examples of what happens with this anti-pattern:
Daily Scrum: instead of planning how to get closer to the Sprint Goal, developers report the tasks’ status to the Product Boss Owner. The Daily Scrum transforms into a status report meeting owned by the Product Owner.
Refinement: the language switches from ‘we’ to ‘you.’ The relationship between the Product Owner and developers is like a service provider, where the Product Owner demands and developers execute. Refinement becomes a moment to estimate efforts instead of building a shared understanding.
Sprint Review: the Product Owner takes the stage to show the increment(s). While presenting, stakeholders may ask questions to the Product Owner. Generally, they direct developers as the Product Owners’ team instead of part of the Scrum Team. Stakeholders perceive the Product Owner as the team’s manager.
These are only some examples, but I could continue for a complete article. The point is: Scrum has no place for command and control. Everyone is on the same level, responsibilities are different, but the Scrum Team shares the same goal and collaborates to achieve it.
3. Arbitrary Deadlines
I think teams give too much attention to deadlines. In my opinion, in software development, most deadlines are arbitrary. Let me as you something, does the world become worse when a team misses a deadline?
In traditional project management, deadlines are set in stone. Worse than that, they are often agreed upon without the project team's consent. Also, everyone ignores the outcome because the focus is to match the deadline. A terrible result is often unavoidable; months of work lead to something nobody needs. Still, if it meets the deadline, it’d be seen as a successful project.
A fundamental point in traditional project management is a limiting aspect in the agile world: deadlines. Don’t get me wrong, I am not against setting a date to achieve something, but I am against inflexibility to adapt it after gaining more knowledge about the goal. For example, in Scrum, the sprint has a deadline, but the team has the space to inspect and adapt to reach the Sprint Goal. It’s not about delivering features until the deadline; it’s all about reaching a meaningful goal.
It’s unsustainable to push the team to deliver something until the deadline just for the sake of matching an arbitrary date.
Subjective deadlines usually compromise the quality. Product Owners fail when they use deadlines as an argument to pressure the team. Strong Scrum Teams strive to learn as fast as possible; they focus on the outcome they want to deliver. Therefore, they prioritize small batches over bigger ones.
I think a better approach to deadline is collaboration and transparency. Top-down deadlines will never work because they lack ownership from the Scrum Team. When transparency takes place, everything becomes easier. For example, the sponsor shares the budget, and the Scrum Team evaluates whether that is suitable to solve the problem. Still, embracing learning is vital; the budget might not be enough as the team gains knowledge on the problem.
“Everybody in the real world will agree — the moment a project is behind deadline, quality assurance tends to go out the window.” — Alan Cox
Bad Project Management Don’t Fit With Scrum
The traditional project management mindset has no space with Scrum. One of the critical aspects of succeeding with Scrum is to embrace the unknown. Solid Scrum Teams have clarity on the goals they pursue while enjoying the discovery process of figuring out how to get there.
To finalize this article, I’d like to highlight the following points:
If your plan doesn’t change as you acquire more knowledge, it’s a clear sign you are failing. Foster the discovery process and embrace change.
Empower the Scrum Team to pursue goals and let the results surprise you. Trust your team; they are the best to figure out how to reach the impact you want.
Don’t let arbitrary deadlines compromise your product quality. A bad product will damage your image, but delaying a delivery will be easily forgotten.
Do you want to write for Serious Scrum or seriously discuss Scrum?