Last year, whilst preparing for the Scrum.org certification series, I often encountered questions regarding the unavailability of the Product Owner. The effectiveness of the Scrum Team can indeed be affected when the Product Owner is absent.
What if the Product Owner is always available?
Would it have an impact on the team’s effectiveness?
What should the Scrum Team do when the Product Owner is unavailable?
As a team member with multiple accountabilities, I take on the accountabilities of both Scrum Master and Product Owner simultaneously (and occasionally even a Developer when urgently required). Influenced by and misunderstanding the implications of the questions regarding the Product Owner’s unavailability, I initially made myself as available as possible during the early stages. Whenever the developers needed clarification, I would always be there to ensure that all Product Backlog Items were transparent and well understood.
Initially, when the Product was simpler, this approach worked well. The Developers approached me with questions, I provided answers, and they continued with their work. However, as the Product grew, things became more complicated and complex. There were times when the Product Backlog became chaotic. As the Product Owner, I should restore transparency to the backlog.
Unfortunately, the developers often came to me for help. I quickly provided them with answers, and they returned to their desks. However, a few moments later, they approached me again, requiring further assistance. This cycle repeated itself until I could no longer tolerate the interruptions and escaped for a break.
The Product Owner has a lot more work to do than making the Product Backlog Items transparent. In addition to the jobs described in the Scrum Guide, the Product Owner also formulates Product Goals and the Product Vision, orders the Product Backlog, and establishes the Roadmap. Most of this work occurs outside of the Sprint. If a Product Owner becomes too consumed with the work within the Sprint, attention at the Product level can suffer. What should we do after the current Product Goal has been achieved? How should we proceed when the Product Backlog is empty?
According to Gerald Weinberg’s book “Quality Software Management: Systems Thinking,” task switching can significantly decrease the effectiveness of each task performed in parallel. The situation I found myself in was constant task-switching. The mental effort required to refocus on my tasks was substantial, resulting in potential delays in satisfying the developers’ requests and completing my work.
Efficiency leaks when parallel tasks increase
Occasionally, I observed that the developers were capable of resolving issues independently. They often asked questions simply to seek validation or approval. This was a dangerous sign. The more they relied on me for answers they should already know, the more it hindered their ability to practise self-management. Eventually, it will lead to an unwanted hierarchy and damage the growth of the entire team.
Hence, an always-available Product Owner can hinder the team’s progress. What is the solution to this situation?
Engage in a conversation with the developers, expressing your desire for uninterrupted focus on the work outside the Sprint. Suggest specific timeslots for discussions rather than ad-hoc interruptions. This approach allows for a cool-down period, where the developers jot down any questions in a parking lot. As the developers continue working on the Product Backlog Items, some of these questions may have been resolved.
A Product Roadmap drives a series of Product Goals, and each Product Goal shapes a set of tentative Sprint Goals. Having a well-understood Product Roadmap leads to well-understood tentative Sprint Goals. This helps the Product Owner effectively manage the Product. Some developers’ questions may arise from unclear Sprint Goals or Product Goals. When they have questions, always encourage them to refer to the Product Roadmap, Product Goals, and Sprint Goals. Address the “why” and “what” aspects, and then empower the developers to handle the “how.” If they still raise questions, it indicates that not everyone fully understands the Product Goals, and it is now the Product Owner’s job to address these matters.
A short feedback loop is essential to discover new opportunities and deliver enhanced value for a high-performing team. However, it is crucial not to take this to the extreme. A feedback loop that is too short can introduce excessive overhead and hinder effectiveness. The Product Owner should strive to make the Product Goals well-understood, enabling everyone to understand the importance of their work to the customer, rather than being constantly interrupted by developers regarding the work within the Sprint.