By Nick Butler
Tags: Agile
A successful Scrum team is like a well-oiled machine. To help Scrum Product Owners understand how to get all the parts meshing smoothly, I dragged some real-life developers away from their keyboards and asked them, “what works for you?”.
What I learned was:
Developers work most effectively when a Product Owner knows the product well, and communicates this knowledge responsively and decisively.
This is the first thing that the developers mentioned. The Scrum Product Owner brings the vision for the product. You’re the voice of the end user. You know the personas — the different types of users and how the product will make their lives better — and you bring a big picture view.
“A Product Owner can see things a developer won’t see because we live inside the code. They can see the whole user experience,” is how one developer put it.
You also have a product roadmap, a flexible, high-level plan for the future. You’ve mapped the stages along the way to building a valuable digital relationship with your customer, from first date to long term commitment. The plan helps developers make technical decisions that mean that later stages can be delivered without having to waste time revisiting past work.
A developer told me about a time the development team asked the Product Owner to sketch out the future direction of the product. The Product Owner put together a roadmap which let the development team suggest a better way of achieving their goal. This cleared away technical debt (outdated, clunky code, tools or infrastructure). The new approach was faster and more stable for end users, and future development will also be faster, so it will cost less to implement new features.
It’s a great example of the collaborative strength of the Agile process. Your product knowledge combined with their technical expertise produces a whole that is greater than the sum of the parts.
To communicate the product vision well you don’t need to be a technical expert — to have what one developer called “complete system knowledge” — but you do need a technical appreciation. You need to learn the lingo, develop shared concepts and a shared vocabulary.
This can take time. “Developers can be too nerdy,” said one I spoke to, “they can be hard to understand.”
Because miscommunication can be frustrating it helps to have the patience to keep asking questions until you both understand. Repeating back an explanation in your own words is a good way of making sure you’re on the same page.
This means you need to be good at listening. (“You also need to know when to stop listening,” I was told, “sometimes developers want to go into too much detail.”)
This shared understanding that you’ve developed oils the wheels of the machine, making it faster and more powerful.
Developers also thrive on feedback. When they’ve got more work to do it’s best if you’re “direct without being negative” and when they’ve nailed it, let them know.
The developers also mentioned the effectiveness of good user stories as a communication tool. To learn more about this, check our series of posts on user stories.
This is often called being available.
Developers frequently have questions or need to get tasks checked and hopefully accepted. The faster you respond the less downtime there is, ramping up productivity. The slower you respond, the more work in progress (WIP) builds up, reducing efficiency. Check out this case study on reducing WIP to increase efficiency when the Product Owner has limited availability.
Another way Product Owners can make themselves available is by embracing the ceremonies of Scrum. Some, like sprint planning, backlog refining and sprint reviews are must-dos.
The daily stand up/scrum meetings keep progress visible and get problems resolved before they snowball. Since face-to-face communication throws up the fewest barriers it’s ideal if you can attend in person.
And the retrospectives are great opportunities to improve how things are going. One developer told me about a situation when work had ground to a halt because the Product Owner didn’t have time to respond. After chatting about the issue the Product Owner made themselves more available. “The wheels started moving much quicker,” the developer said, “which means the developers stay busy and you get more features in the product.”
Some people don’t think Scrum Product Owners should come to retros because their presence might stifle discussion but at Boost we feel that Product Owners are part of the team and you’ll get the best result by having the whole team attending. Love to hear your take on the question.
To do all this you need to be empowered by your organisation.
You need the authority to make decisions. If you have to consult on each one it slows down the work, meaning you get less bang for your buck.
Ideally you also have the head space to make decisions. The developers said that a project runs better when the Product Owner is solely focussed on that one project.
Probably the most important decisions you’ll make will be about priorities. You need to be ruthless in pursuing the top priorities first. You need to know what the Minimum Viable Product is and not push for a full-feature, big bang release because that means you get none of the benefits of the “fast proof”, iterative nature of Agile.
Many developers also like having customers use the fruits of their labours so regular releases keep them motivated (as well as letting you regularly test that the product delivers want the users need).
“Being a Product Owner is a lot of responsibility,” one of my developer informants told me, “It’s not an easy job.”
The importance of the role is shown by a clear correlation we’ve found at Boost. Successful projects have an engaged, empowered Product Owner, unsuccessful projects don’t.
Want to know more about the product owner role? Check out these posts:
How to maximise your impact as a Product Owner on a Scrum project.
