
Myth: Product Owner vs. Developers
Variations:
- The PO wants more than the team can do
- The team refuses to do as much as the PO needs
- During Planning, the team haggles the scope with the PO
- "Scope Commitment"
Category: Planning myths
Danger: High
The basis of the myth
The Scrum guide states the following things about planning:- The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
- The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team.
In general, the Scrum guide adds this statement about the Product Owner:
- [The Product Owner is responsible for] Optimizing the value of the work the Development Team performs
This is then misconstrued as: "The Product Owner says how much the team should do, then the development team says how much they can do.", then stretched even further out of proportion: "Planning is a bargaining session where the Product Owner haggles with the team about the amount of work to be done.". In
Why is it a myth?
The myth is created from a misconception about Scrum teams and the Product Owner role.First, the Scrum team includes the Product Owner as well as the developers. Planning is a collaborative exercise of the Scrum team. In a functional team, people pull in the same direction. The Product Owner should not even consider pulling in the opposite direction.
The second basic misconception is that the Product Owner negotiates work. The developers own the work, while the PO owns the goals. The developers are experts of the "how much", the PO is the expert of "what".
Negotiations can and do take place in a functioning Scrum team, but more along the lines of priorities, that is "Well, if we can't do both A and B, we should get A done first", or "Well, if A, B and C is too much work, maybe we can reduce the scope of A, so that at least we can see something from C"
Assumption #1: Capacity is negotiable
After a while, teams should understand their capacity. Taking more work than capacity results in unsustainable development. Either, people need to make overtime or they will take dangerous shortcuts, such as hidden quality reduction - often a combination of both. Typically the first things disappearing under overload are innovation and continuous improvement.In the absence of good data about the team's capacity, it is acceptable to experiment with capacity. However, when capacity is known, the Product Owner needs to accept reality.
Assumption #2: Give 100%
Even when less than 100% of the team capacity is utilized for development of new features, there is still a capacity limit.Planning for 100% capacity utilization is very dangerous, because the slightest deviation from plan will result in failure. The proverb "Plans based on average fail on average" comes to mind.
In general, no more than 80% of capacity should be allocated for the Sprint Goal, because the team will be spending capacity on the following:
- Refining topics for the subsequent sprints
- Innovation
- Technical housekeeping, e.g. Refactoring, data purifications etc.
There are even reasons why teams should plan for lower numbers. For example, unplannable customer requests or "flu season" are very good reasons not to plan for high utilization in terms of Sprint goals.
Depending on the level of legacy technical debt resulting in defects or customer complaints, teams might even be hard pressed to allocate even 50%.
Rather than trying to push the capacity allocated towards the Sprint Goal, the Product Owner should strive to understand what impedes the team from allocating a higher percentage.
Assumption #3: Lazy Developers
"Theory X" thinking suggests that developers need to be pushed to diligence. "Theory Y" thinking, on the other hand, suggests that motivated people do their best. When a Product Owner observes that developers do not care about the product's (and therefore, their own) success, it would be a good time to hold a Retrospective and use the Scrum Master's facilitation skills to discover what demotivates the developers and how to improve their conditions: Why would they not want to do work they can do, if that work is sufficiently meaningful?
Consequences
Once people start to feel cheated or pressured, trust within the team is broken. Collaboration turns into defensive CYA behaviour. Productivity declines even further, to the point where neither the PO will get any useful results, nor the developers see any meaningful progress in their work. Both will blame the other, when they should act as one party with a shared interest.
Wrong focus
While the focus in planning should be what is the best way to deliver the most value, planning becomes an interrogation session shifting towards how people work. Instead of focusing solutions, impediments are turned into excuses. Developers will think of good reasons for doing less rather than smart ideas how to do more. The Product Owner will look at what people are doing rather than at what the product can do.
"Contract based planning", where the Product Owner tries to maximize capacity load and the team tries to minimize overburden has failed. It might be better not to plan at all than to plan anticollaboratively.
Remedies
The longer the "Contract game" continues, the lower productivity will be. If the "Contract mindset" is not broken, the team may become completely dysfunctional.
As Scrum Master or coach, have a keen eye for questions or remarks hinting at haggling going on.
Actively intervene when discussions turn from solutions to excuses.
Stop the "contract game". Educate everyone that the purpose of planning is to come up with a collaborative plan for the upcoming Sprint, not to discuss how people work.
Direct a Retrospective towards examining capacity utilization. Create transparency why certain things take as long as they do.
Observe team morale and ensure team members are able to do meaningful work that allows them to achieve Drive: Autonomy-Mastery-Purpose.
As Scrum Master or coach, have a keen eye for questions or remarks hinting at haggling going on.
Actively intervene when discussions turn from solutions to excuses.
Stop the "contract game". Educate everyone that the purpose of planning is to come up with a collaborative plan for the upcoming Sprint, not to discuss how people work.
Direct a Retrospective towards examining capacity utilization. Create transparency why certain things take as long as they do.
Observe team morale and ensure team members are able to do meaningful work that allows them to achieve Drive: Autonomy-Mastery-Purpose.
No comments:
Post a Comment