The boundary between Scrum culture and organizational culture has been porous. This has resulted in the infusion of Scrum values and principles within the corporate confines. However, the mass adoption of Scrum and Agile ideologies is dotted with numerous unseen faux pas. Withstanding assumptions, failures of countless projects that incorporated Scrum are attributed to these critical gaps in Scrum integration. The foremost factor behind project failures is the chain of deadly mistakes committed by the Scrum Product Owner.
Much explains why too many SCRUM projects are failing!
Recent Agile and Scrum failures
It is best to dissect with facts. Data extracted from PMI’s 2016 Pulse of the Profession Report (Version 1) show some statistics from the survey conducted to understand Scrum failures.
“38% of the respondents stated that the inconsistent approaches to Agile adoption have contributed to project failures in their organizations”
Ill-defined Scrum Product Owner roles have been identified as the prime contributors to such project disasters.
In hindsight, Agile and Scrum experts have examined the primary causes that triggered these failures. Here is a quick rundown of the most important ones-
- A Scrum Product Owner with little or no clarity of his role
- Lack of proper Product Backlog Prioritization
- Knowledge deficiency of the Product Owner
- Let increase story points arbitrarily
- Not taking care of the irregularity in daily stand-ups
- Not supervising the creation of well-planned retrospectives
- Neglecting the team’s failure to meet sprint deadlines
- Handling more than 2 teams
- Focusing only on the customers and not the teams
The deadly mistakes!
This section will discuss some of the Scrum Product Owner’s flaws that can be detrimental to project health-
Lack Of Clarity On Role
A new, often inexperienced, Scrum Product Owner mostly lacks clarity on the role to be played by him. This mostly arises from the absence of demarcation between the discrete responsibilities of the Scrum Master and the Product Owner. While the Scrum Master is in charge of facilitating daily stand-ups and removing possible impediments, the Product Owner is responsible for understanding the product features from end-users’ perspective. An overlap of these two roles is unacceptable.
Fig: Organizations wrongly merge the Scrum Master and Scrum Product Owner’s roles
Takeaway: The roles and responsibilities of a Scrum Product Owner and a Scrum Master are mutually exclusive and should not merge at any point of time.
It should also be noted that a Scrum Product Owner is by no means the “project manager” The latter has a completely different set of roles and responsibilities.
Improper Product Backlog Prioritization
The Scrum Product Owner is expected to create and maintain product backlogs for any project. These should be accomplished at the outset of the project, prior to Sprint planning. One major problem is observed at this stage of product planning. Ideally, the Product Owner is not supposed to allocate the amount of work for each sprint. But in many cases, the Scrum PO does not make a reciprocal commitment of “not imposing new requirements” during the sprint. This often leads to disharmony in the team and affects productivity.
Fig: A Scrum PO should conduct a methodized Product Backlog Prioritization
Takeaway: A Scrum Product Owner should sit with his team and carry out a methodized ‘Product Backlog Prioritization’ and should not impose additional requirements later. The meeting where it happens is called Backlog Refinement and should not be skipped.
Lack Of Product Knowledge
The Scrum PO is expected to know the product inside out. He/she is supposed to have both development and marketing perspectives germane to the product. In real-time projects, however, the Product Owners are often found to perceive the product from a developer’s angle rather than the consumers’ viewpoint. The end result is a product that is not customer-oriented.
Takeaway: A Scrum Product Owner should have adequate product knowledge and should be able to bridge the gap between the developers and the end users.
Allowing Teams To Arbitrarily Increase The Story Points
The Product Owner does not have direct control over the story points. However, they should not be oblivious to the way the story points are organized by the respective teams. There are instances where story points are increased arbitrarily. This increases the risks of non-delivery of the promised story points. The team must be able to base the number of story points of the current sprint on the number of story points that were delivered in the preceding sprint.
The team’s failure to do so will to some extent prove the Product Owner’s ineptitude to minimize risks.
Takeaway: The team should plan the story points rationally and self-assess their bandwidth to determine the number of story points achievable in a certain period.
Not Attending Daily Stand-ups As An Active Listener
Daily stand-ups meeting is a proactive process of information sharing within the team members. You should remember that it is not a waste of time. It brings transparency to the work process and makes the team members more responsible.
A Product Owner is not directly accountable for the daily stand-ups. But that does not make him any less responsible, especially there is a stark absence of daily stand-ups. POs should at least be heedful about regularizing daily stand-ups. They should be present in those meetings as active listeners even if their contribution is minimal.
Takeaway: A Scrum Product Owner should be very particular about daily stand-ups and the daily/weekly execution of the allocated tasks.
Not having retrospectives
Many regard retrospective meeting as a mere formality and avoid it. Skipping Retrospective meeting is a bad practice and can generate risks. If you are a Product Owner and are not being an active listener in these meetings, you are missing not only the important feedbacks from the team but also a chance to start the next sprint in a right way. The retrospective meeting provides the positivity towards the next sprint, helps mitigate the risk and put the limelight on the need-improvements aspects, to avoid recurring mistakes in the next sprint.
Takeaway: A Scrum Product Owner should be an active listener in the retrospective meetings to understand the project constraints and ways to resolve them.
Not meeting sprint deadlines
The undesirable fact in Scrum is when you are failing to meet the sprint deadlines. This can occur in case you fail to accomplish all your commitments. This may be due to some technical problems or any of the team members falling sick and absence of additional team members to cover that task effectively. It may create a stressful situation and the inability to meet the task timelines. As a result, the scope of the sprint does not get accomplished within the specified sprint duration and becomes a major problem later.
To avoid this, the Product Owner should always help the team accomplish their commitments within the stipulated time bracket.
Takeaway: A PO should always keep an eye on the progress and help the team in removing any blockade related to functionality, scope, and goals.
A Quick Summary: What a Scrum Product Owner is and isn’t
- Requirement Analysis
- Business Process Analysis
- Product Lifecycle Management
- Program Management
- Organizational Marketing
Industry-wide studies have shown that a vast number of Scrum projects have failed owing to the fallacious assumption that a project is completely immune to failure if it has a Scrum Product Owner. Organizations have blindly dovetailed Product Owner’s role with projects, without much clarity on the pros and cons. This has naturally resulted in gross Product Owner’s errors and consequent debacles in the projects.
Agile teams on the verge of project failures should, therefore, appoint Scrum Product Owners who can act as a proxy client for the Scrum team and product expert while interacting with the customers.