Many companies fall into the infinite bandwidth fallacy. They believe the way to earn more is to work more. They measure how much they’re working with timecards and performance reviews. They rationalize, if we’re all working harder, surely we’re doing better, right? If we could simply deliver everything that everyone wants, then everything will be good. They continually ask, “How can we get our teams to work faster?” Overtime becomes the default way to solve problems. The solution, they believe, is to push the team to deliver infinite work. However, there is a better answer for driving value, and that’s working with product owners for the most impact.
Agile companies focus on value, not work
Wise agile companies focus on value instead of work. They understand that no individual, team, or business has infinite bandwidth. So, instead of working more, they create more value with their current work capacity. They measure velocity, ROI, and defect rates. They prioritize so that they can maximize value with a finite amount of bandwidth. They focus on the effectiveness of the work, not just the efficiency.
These companies continually ask, “How can we increase the value of the work our teams are delivering?” They understand that the team will pull work as they’re ready. How do we make sure the next thing they pull will be the most valuable?
Not all dollars are equal
Think of it this way – not all dollars are equal. When your business gains a dollar, it spends something to get that dollar. There were wages, materials, and production times involved. Some dollars, you spent 20 cents to earn. Others you spent 80. So, while each dollar has the same purchasing power, the business’s value from the process to get that dollar varies.
Maximizing value is choosing which dollars to pursue. This is also applicable, even if you’re a research or non-profit entity, and dollars are not your primary measure of value. Not all results are equally valuable to those you are serving.
Product owners are central to value maximization
The product owner plays the central role in maximizing the value of the product that a team creates. A product owner prioritizes the backlog, so the team delivers the most valuable things first. They also understand that value takes multiple forms.
Most items on the backlog are features for which customers are willing to pay. But there are also technical debt items to address to reduce risk. There are planned upgrades, ensuring the support for the technology stack and up-to-date security. Additionally, there are internal improvements to increase the team’s ability to deliver value, such as automating tests or deployments.
Since the product owner role is so critical to the value of the organization. Others need to understand how to work with and support them. Working with product owners to deliver the most impact is essential for any organization.
While the product owner is solely responsible for prioritizing the backlog (and thus the value the team delivers), they don’t do this in a vacuum. Let’s look at how other roles can best interact with the product owner.
Scrum master
The scrum master helps the product owner in multiple ways. First, they may coach the product owner in how their role fits within the team and organization. They may also help them understand different prioritization techniques (such as weighted shortest job first, value matrices, etc.).
They can also help with forecasting and using the team’s estimates. The scrum master can also assist with keeping these forecasts up to date, alleviating some of the product owner’s workload. The scrum master is a leader who serves the team, and this includes the product owner.
In addition to coaching, the scrum master also helps the organization learn how to best support the product owner. This includes management, developers, and internal stakeholders.
The scrum master supports the product owner role to protect the team. For example, if someone approaches a developer to request work, the scrum master steps in to politely inform them the team takes their work from the backlog in priority order. They will advise the person that the product owner is their contact for getting the item on the backlog. This keeps the team from getting side requests (thus protecting the sprint). It also helps the product owner have the most information to make informed priority decisions. It’s difficult to maximize value if work flows to the team from other sources without the product owner’s knowledge or input.
The scrum master also makes sure to include the product owner in the scrum team’s process, such as the daily scrum and retrospectives. A good rule of thumb is product owners should be spending half their time with the team and the other half with stakeholders. Their voice is essential, and they also need to hear and recognize the perspective of others.
Finally, and this one may be counterintuitive, the scrum master enables developers to understand it’s acceptable to push back on the product owner. That pushback may be because the team’s overburdened, under pressure, or susceptible to the infinite bandwidth fallacy.
They may press for the team to work more or let quality lapse a bit for earlier delivery. The scrum master knows these practices lower velocity in the long run. He/she serves as a counterbalance to the product owner to maintain a sustainable pace and deliver a quality product. This sustainable pace is maintainable by keeping the system as a “pull” system (the team pulls in work that it feels it can deliver), instead of a “push” system (forcing work on the team). The scrum master empowers teams to have critical, aligning conversations beneficial to all.
Developer
Here we use the word “developer” the same way as the scrum guide. Developers are responsible for the product creation (it doesn’t have to be software) by implementing the value the product owner wants to achieve. That means they also help the product owner by maintaining high quality and keeping technical debt low.
High-quality products make maintenance and future work easier. That lowers the cost to deliver future value. The team is also responsible for the technical solutions to the problems the product owner needs to address and may suggest alternative methods to solve customer needs.
Developers must provide estimates of the relative effort of work, which the product owner uses to prioritize. For example, a customer requests two features and is willing to pay the same amount for both. If the team estimates that feature B is half the effort of feature A, that offers the product owner insight that feature B is more valuable (same benefit to the customer, less effort) and should have priority over feature A.
Developers working with product owners also collaborate throughout the sprint on features, shortening the feedback loop by seeking it early and often. By the time of the sprint review, the product owner would have already approved any work completed.
Management
One of the ways management supports the product owner is to respect their decisions. It’s impossible to make decisions that make everyone happy all the time. Some product owner decisions will face disagreement from management. Don’t override the product owner!
If management overrides the product owner time and time again, the role is no longer empowered to prioritize. They are now a proxy to a committee, and multiple people review every prioritization question. Questions that the product owner would be able to answer in an hour now take a week for the team to receive a response. All value delivery will slow down in these situations. It’s often better to let them go and keep delivery high. The cost of delay is expensive!
Be aware, this behavior of constant overriding or unempowered product owners can sometimes have other names, like steering committees or change review boards. It can be acceptable to have groups to discuss product direction. If product owner decisions need to run through groups, or the groups dictate actions, you have a committee instead of a single product owner and will pay the same costs of delay.
Management also supports the product owner by making sure they don’t have too many other responsibilities. Product owners need to collaborate with the team, interact with customers, and evaluate the value of different options. These things all take time. Don’t lower the team’s value by trying to get the product owner to “just take on one more little role.”
Management backs the product owner by not giving work directly to the team but by allowing them to prioritize. Developers know who signs their paycheck. If a manager walks in and asks them to do something, they often say yes. Suppose you have work coming in through means other than the product owner (sometimes referred to as phantom work). In that case, the product owner can’t prioritize based on value to the customers and organization.
Also, how many managers are there above any individual developer? If there are many layers, then all these leaders can ask them for different things. In this scenario, priority is whatever the last request was to the developer. Do you want to impact the value of the team in this arbitrary fashion?
Stakeholders
If you’re an internal stakeholder or represent customers somehow (sales, marketing, etc.), then the product owner definitely needs you. The product owner wants to know how to serve the customer best, what problems they face, and what would make their day easier.
Stakeholders work with product owners to create reasonable expectations for customers. The product owner should approve dates and scope before communicating them. Also, understand that what is priority number one for you, as a stakeholder, may not be the same for everyone else.
Also, stakeholders should attend the team’s sprint reviews and be honest with your feedback. The sprint review is a working session to inspect the work from the sprint. Feedback on features influences the backlog. This enables the team to deliver the best product possible to customers.
Feedback doesn’t need to be limited to the sprint review. The team may ask you to look at things they’re still in the process of creating. The shorter the feedback loop, the lower the cost to arrive at the final solution.
Working with product owners; every role matters
No matter your role, the way you interact with the product owner, can help maximize value. As you support the product owner’s vision and decisions, amazing things can happen. These practices can become habits and part of your collaborative culture.
Have finite bandwidth and want to make the most of it? Reach out to us; we can help with a portfolio of agile services, including assessments, training, coaching, and mentoring.
