When agile fails: SCRUM master and product owner

This blog post is part of the When agile fails series. This time I’d like to share my experiences of how teams end up with a SCRUM slave rather than SCRUM master and an unqualified product owner.

SCRUM slave

I think the SCRUM master (short SM) has one of the toughest role in a SCRUM team. I’ve a lot of respect for the challenges of an SM, which involve:

• Coaching the product owner and stakeholders
• Removing obstructions which might occur during a sprint
• Protecting the team from external influences, such as politics

A SCRUM master needs to have a strong personality, must master enterprise politics and have a keen agile mindset. Because we want to avoid hierarchy in any way, the SCRUM master is horizontal role and is working closely together with all team members. Thus, the acceptance of this person in the team is inevitable. The SCRUM master needs to be aware of all the issues the team is dealing with. She/he needs to protect the team, and support them in solving the issues.

I experienced SCRUM masters who knew the rules, but were missing the right mindset. In theory they knew how SCRUM works, but they had neither the experience nor the mindset to support their team. I’ve also seen way too many passive and disengaged SCRUM masters, who had no idea what their team was dealing with. However, the opposite extreme doesn’t help either. Dictating and forcing the team into something is only damaging the team morale.

In the end, the SCRUM master must find the sweet spots in regards of handling politics, communication skills and solving problems. This is not an easy job, and quite often underestimated.

Verdict:
The SCRUM master is a tough role! A keen agile mindset, as well as the capability of supporting and protecting the team are key factors for this role. Look for a strong personality if you want a SCRUM master rather than a SCRUM slave.

Unqualified product owner

Developing and maintaining a product can be a challanging task. In SCRUM all those challenges will be split and stored in a backlog. However, someone needs to be in charge of managing the backlog, and that someone is the product owner (short PO). It may sound simple, but managing the backlog requires a distinctive customer mindset. Have a look at SCRUM.org to see what managing a backlog means.

To manage the backlog and to drive the product, the product owner needs to have a product vision, strong domain expertise and understanding of customer & business needs. The latter requires a distinct customer mindset. I like to see the product manager as a kind of gatekeeper for all kind of user requests. She/he stands between the development team and end users. Thus, the product owner also must handle all user requests and do a lot of expectation management. It’s crucial that the team respects the product owner, her/his decision and the backlog. Only the product owner can force the team to work on a specific topic – no one else!

Unfortunately, I experienced several flaws in SCRUM teams, just because they elected the wrong person for the role as product owner. The most common one is the absence of domain expertise. A product owner without domain expertise isn’t capable of managing the backlog properly. The second most problem I experienced, is missing expectation management on both sides – the development team and end users. Without communicating clear expectations to developers and end users, agile projects rapidly become chaotic. Last but not least, I’ve seen teams sharing the product owner role in a collective – which obviously doesn’t work – never! The product owner might represent the desires of a committee, but it’s always a single person who’s responsible for her/his decisions.

Verdict:
The product owner manages the backlog & stands between the development team and end users. It’s the gatekeeper for user requests. Domain expertise and expectation management is imperative for the role as product manager.