Lack of Product owner – What to do?

I often hear from ScrumMasters and Agile Coaches stating, that you cannot have a succesful Scrum implementation without a Product Owner. The importance of the Product Owner can not be discussed, but there are “everyday situations” out there where a Product Owner for some reason is not available, as much as desired, and for sure won’t be for  period of time. Telling the Product Owner to be more available won’t help anything, and calling off the desire of becoming more agile, doesn’t seem to be the solution as well.

This is in fact one of the most common problems in implementing Scrum, and the consequences can be devastating if not dealt with. In any situation in life, it is hard to explain others, that they need to think differently and change their behaviour. It is hard to convince management to appoint a Product Owner if they do not believe and/or understand the role. It can be difficult to tell the Product Owner to change his/her way of working. And it can be difficult to tell your wife/husband to stop doing that thing, that annoys you so much. Not only is it difficult, the result is expected to be poor, and will most likely not solve the problem. Yet, this tend to be the solutions people stick to.

If you really want to change people’s mind radically you need to focus on two things:

• Trust people.
• Show don’t tell.

Trust people
“Regardless of what we discover we must understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.” This is the Prime Directive for retrospectives by Norm Kerth, which is a fundamental for creating a trusting environment in a team. This prime directive is worth having in mind, in any situation where you need people to change for the better.

Show don’t tell
People are more willing to accept different ways of doing things, and to change their behaviour, if they can litterally see the value of the change. Therefore you should seek ways to show what works and what don’t, instead of just talking about it. Make your strategy “to deliver”. Use this strategy to initiate the agile transformation from the bottom, rather than convincing people from the top.

A Case Study

The team was frustrated about the Product Owner not having time enough for the team, which to some extent made them feel unimportant. The Product Owner was not used to writing userstories, and felt that learning it was just an extra task in a completely overbooked calendar. The Product Owner was not available full-time, due to other duties, that was (also) crucial for the business. Management were fully away of the issue, and had started the recruiting process to get rid of the bottleneck. Nevertheless, we had to start dealing with the issue of immediately.

Obviously, the solution of standing firm and demanding the Product Owner to be more available and to learn writing good userstories, wasn’t going to solve the challenges on a short-term basis. We had to find other ways.

I conducted a retrospective with the team to cover the topic “How can the team help the Product Owner to make the stories ready for coding?”. In the beginning, it was hard to find other solutions, than “The Product Owner needs to change this and that“. Then we reminded ourselves of the Prime Directive. Believing that everybody is doing their best, and reminding ourselves that we all share the same goal, helped the team refraining from blaming the Product Owner. Instead we started focusing on what the team could actually do, and what they could influence.

The team identified the need of having consensus of a “Definition of Ready”, which all stories taken into sprint must fulfill. At the same time the team wanted the authority to reject any story the do not meet the criteria at sprint planning, because it they could not commit to them. The team also agreed to allocate time during sprints to work on getting stories ready for next sprint. As this was the team’s own findings and agreements, this was very easy to help along as the ScrumMaster. The agile transformation now started in the Team, and soon they would be influencing the their surroundings with this transformation.

The team started spending time writing the 1st draft of stories, and acceptance criteria, even though they felt this was a Product Owner task. They did it because they needed it. It magically changed the dialogue between the team and the Product Owner. The easy tasks, were only discussed if the Product Owner did not agree on the story and acceptance criteria. As for the more complex stories, a whole new level of details were shared during discussion. Because the team wrote down their initial thoughts of what the story was all about, this helped the Product Owner to clarify only the needed details, which saved a lot of time for the Product Owner.  Standing firm on the team’s “Definition of Ready” helped the Product Owner and the team to an agreement of scope of each story. Changes or new ideas were likely to come afterwards, in fact we encourage those, but from here on it didn’t turn into a discussion if this change was a part of scope or not.

Conclusion

Reminding the team to trust that everyone is doing the best in the given circumstances, changed the dialogue instantly, from blaming the Product Owner to thinking of what the team could do to help. The team took the lead, and showed what they needed. Not by talking about it, but by doing it. And it turned out to have a significant impact. Even though the team was doing, what is considered Product Owner tasks, they saved a lot of time coordinating and discussing, and the team found the effort valuable. Now we look forward to seeing how much further it can take us, when we actually have a Product Owner available full-time.