The relationship between the Product Owner, Scrum Masters and Developers is critical to an Agile Team’s success. It’s a symbiotic relationship that relies on clear communication, aligned goals, transparency, and is founded on trust. Building a product that is widely adopted or continuous improvement is the usual goal, but the cohesion and dynamics of the team can determine how smooth and pain-free that process is.
We wanted to learn more, so we went out to find a Product Owner to share their insights and stories.
Following his product roadmap presentation at the Perth Agile MeetUp, we sat down with Adam Mullett, author of the book From “No” to “How?: Get Buy-in and Lead Change and a Product Owner to ask him for his take on the level of involvement a Product Owner should have in a retrospective.
What we got was more than just an answer to a question, but a demonstration of the role of the Product Owner and a renewed appreciation of trust, transparency, and discipline.
The relationship between Product Owner, Scrum Masters, and Agile Team
Adam seemed somewhat taken aback when asked if a Product Owner should be involved in the retrospective.
The question stemmed from the observation that some people involved in agile perceived the presence of the Product Owner at the retrospective as optional, or even a hindrance.
After only a brief pause, his response was an emphatic “yes!”
He went on to outline ‘why’ –
One of the important aspects of Agile is that it is not about being fast, but about being adaptable- which leads to more success, such as better adoption of a product.
When it comes to running a team’s retrospectives, not only is it important to facilitate the process but it’s equally important to manage the culture. The team relies so much on the direction and the input of the Product Owner as a subject matter expert. The Product Owner fosters an environment in which a can team can strive to be high performing, being responsible for outcomes, and self-managing so that they remain accountable to their stakeholders.
Trust and transparency
Adam perceives that fundamental to the fabric of a Product Owner is trust and transparency.
“For me, being transparent is a gift because you are sharing what you think or what you know. If the team can’t get that out of you, then you aren’t giving them what they need to make them successful.”
“There should be no secrets between the team, the Scrum Master, and the PO. For me, I would zero in on those things. I’d rather raise the issue and dive into conflict rather than leave it to fester.”
“Being able to discover something that is stopping a team from going forward is really valuable.”
Adam offered an example of two team members who weren’t not talking to each other in a team he once coached.
“It was unfathomable! So, if there was a comment connected to the issue made during the retrospective, I would keep diving in, drilling down into the ‘why’, until they realized that their lack of communication was the problem.”
Although the approach was somewhat confrontational, once the issue was brought to the fore it was easier to address, and team members were later thankful the matter had been sorted.
“Sorting out these types of issues could be as simple as offering different working hours. Not talking to another was simply not a good reason to not be a high-performing team. “
Bring people into the conversation
A Product Owner should keep collaboration front of mind, which is why Adam aims to co-create.
“If I’m doing something, I want to do it with you, not to you. No change will ever be successful if you’re doing it alone”
“Because team collaboration is needed for co-creation to take place, it’s important to know how and when to bring people into the conversation. Choosing the way conversations happen can make a big difference.”
“For example, it’s easier to show someone your work, rather than having to convince them. A one hour prototype that you can talk to is much more effective sometimes than a big planning session where you are trying to sell your idea. Other times it might be better to co-create.”
Be disciplined with process and outcomes
When discipline is viewed as a platform of support rather than a barrier to flexibility, it can act as a mechanism of team empowerment.
Discipline can be as simple as starting a meeting on time, finishing on time, and having a strict definition of ‘ready’. They are the small, agreed behaviors to which team members adhere with a view to mindfully improving team cohesion and respect.
It’s Adam’s view that with discipline, healthy habits can be fostered that support high functioning teams.
“I was a Product Owner in a project where there were 23 teams and a general mindset of getting through this sprint, then another sprint, and another sprint, and so on, just get through the sprint however we could.”
“Then we started to become more disciplined in the sprint.”
“Yes, it was tough in the first month because we were trying to do two things at once. But after that, it was smooth sailing. And the team was able to continue improving and growing as a high-performing team. In fact, others in the organization were wanting to be part of that team.”
It was also observed that the teams that lacked discipline would experience problems.
So what should happen if team members didn’t embrace a disciplined approach?
“If someone comes unprepared, then it’s important to make the purpose of the meeting clear and how their actions do not support that purpose.”
“It’s about focus. During product grooming, for example, if people start to talk about a particular ticket, then it’s about bringing the focus back to why we are having this meeting and what we are aiming to achieve as an outcome for that ceremony.”
Of course, the Scrum Master helps keep this discipline.
In terms of their retro, Adam added that once a team understands and appreciates the structure their discipline has built, they are far more focused and efficient, without having to engage in System 2 thinking, as described in the book Thinking Fast and Slow by Daniel Kahneman.
“Having a clear process keeps things easy. Teams don’t want to have to worry about things such as which room or which technology they are using. Their focus is on the actual problem.”
Build up your team as they build solutions
As far as Adam is concerned, there is no lack of clarity as to the role of the Product Owner; if you are a Product Owner, you are part of the agile team.
“I feel like it’s the Product Owner’s role, with support from the Scrum Master, to build the culture and create clarity for the team.”
“Teams hate not knowing where they are going. They turn on each other, they get antsy, they try to look busy, and all sorts of other dysfunctions. If you can give people a reason, a ‘why’, a strategic direction, then they will say ‘okay, cool. Got it!’ So it’s about being loosely coupled but tightly aligned. That way we all know where we are going then allow the team to get there.”
Adam has worked with fully in-person, remote, and hybrid teams. For 18 months, he worked with people spread from Sydney through to India. No matter the make-up, one of the success factors of a high-performing team was the understanding of what would happen next.
“So if one thing happens in our retrospective, then someone would go off to create a ticket in Jira. People could still work together even if they weren’t always in the same room. Having strong ways of working helped to accommodate that”.
The role of the product owner in an agile retrospective
Circling back to the question of the role of the Product Owner in the retrospective, Adam noted the Product Owner is a participant.
In his opinion, the retrospective itself can be run by anyone in the team, with his preference that the facilitation be rotated amongst team members so that those skills can be developed and appreciated by the team.
“I think the team wants the PO to be honest and to be open as they participate”
In terms of what a product owner hopes to help achieve at a retro, Adam’s response is simple – it’s for the team to get better at what they are doing.
Why?
“Because the PO is accountable for outcomes to the organization in terms of how long something took through to resources used. The team is responsible for delivering the outcomes. So the Smart PO will attend the retrospective to listen. They won’t tell people what to do, or that they should do it “this way”. If the team already knew, they would have done it.”
Adam views the retrospective as an opportunity for the team to –
- discover solutions
- to find things out as they go in order to be a high performing team and
- to move up the maturity ladder.
The Product Owner wants to help build a high performing team for many reasons –
- to improve predictability
- to have good, solid, regular user story management
- to improve overall confidence and quality
as features get developed over time.
Encourage and enable changes at your retros
So why do retros work?
“I think it’s because the team is empowered to come up with things that they can change. They can define SMART goals that they can put into effect over the next two weeks. They are coming up with the problem that impacts them, so they are self-directed to the change.”
It was noted that some people may fear change because something is being done to them, and they don’t feel like they have the control.
“Something I reference in From “No” to “How?”, is the sphere of influence and loci of control. It’s important to help the team focus their conversations on where their locus of control lies so that they are empowered and feel capable of making changes.”
“They should feel they can lean on the PO to leverage their influence or social capital to influence beyond the team’s sphere of influence.”
“In the meantime, if an agile team feels like they are in control of their destiny, then they can change their world and make things happen. They feel more empowered to do things and can then go ahead and get things done.”
How a Product Owner can guide a team away from dysfunction
We couldn’t let Adam go without asking for his advice as to how to transition a team from dysfunction to high performance.
The key take-aways:
- Ensure everyone knows where they are going, their purpose and ensure they are all on the same page.
- Make sure there’s good communication; whether it be team member to team member, to Product Owner to Scrum Master, communication needs to be open and honest.
- Discipline! Give people the platform for creativity. Start on time, focus on what the meeting’s about. It provides a structure so people can flourish.
- Always tell them ‘why’
- Call out dysfunction. Identifying problems, conflicts and errors is great because something has been discovered.
Do you have any other insights or stories to share about how you have improved working relationships between your scrum team and product owner? We’d love for you to share with us.
About Adam Mullett
From “No” to “How?: Get Buy-in and Lead Change encourages the sharing of outcomes from failed improvement attempts with peers and the boss as a way of both cementing the lesson and sharing the learning with others.