Welcome in Agile Mentors.
We're back.
This is another episode of the Agiles Mentor's Podcast.
I'm here with you as always, Brian Milner, and we have a very special guest with us today.
Very excited to have Barnaby here.
Barnabee is an agile coach, also a scrum master.
He is known to us because he is part of our agile mentors community and he's an active member there and has weighed in on several issues and helped people
and mentored people through things there.
So we wanted to share some of the wisdom of, the crowd that we have there at agile mentors, just a few select people that have really contributed and given
us some really good advice there with the podcast audience as well.
So you guys can kind of hear what kind, of stuff is there on the agile mentor's discussion forums.
But we were talking about topics here with Barnaby and about what we're going to talk about, and he proposed one that I really found intriguing.
It was focusing around the underpowered product owner, the Underpowered PO.
And I think that's probably a good place for us to start then.
Barnabee, why don't you kind of just explain to everyone what that idea is, what you mean by the underworld PO?
Sure, of course.
So in fact, what I'll do is I will explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like?
And I was working for an organization a few years back and it was a publishing organization and we had the head of the editorial team was the product's
owner for a particular scrum team.
And this head of editorial had a lot of power and influence in the organization.
They were pretty much a decision maker in terms of the products that the team was building.
And I remember a particular conversation where the theme was talking to this product owner and the teams said, look, we know you want to get this release
out this week, but we've got some technical debt.
We really need to fix it.
I'm going to let me think about this for a second.
OK, I can make the decision on this, which is, yep, you can have your time.
Communicate with others within the organization that the release will be delayed.
And that was such a powerful moment, because in that second, the product owner trusted the team.
The team completely trusted, and it felt slick and efficient and worked really well.
Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role.
So I, I have seen the situation where you have a whole hierarchy of product people and the most junior roll in the product organization is the products owner.
And what happens in that scenario is that the product owner is powerless to make a lot of decisions.
So they have to, they, have, to push them up the tree.
And in, that situation, the conversation between the team and the products owner, is the teams says, yeah, we need to do this thing.
The product says.
Okay, give me some time.
Might be a day and I'll get back to you.
Hopefully I can get in contact with other people within my hierarchy and flows broken.
What's the, team going to now?
They're going, maybe you find something alternative to work on.
It's very frustrating.
And you sometimes get the situation as well, where the, the underpowered product owner will sympathize with something the team is saying,
but will not be able to make a change because they haven't got the authority to do the change.
So they'll say, yeah, I agree with you.
I know what you're saying.
This is a really bad idea, what's being suggested, But I have no choice.
We have a roadmap.
we've got to meet the roadmap Yeah, that's a clear picture.
I agree with you that those are two stark contrasts.
And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other,
right?
It's such a dramatic difference when that person is able to make the decisions on the spot, go forward, and the team is just free to move as quickly as possible.
Whereas the other one, it's just holdups.
It's delays and obstacles, roadblocks in the team's way.
So yeah, a really clear picture there.
Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking this is trying to
understand a little bit about the why behind it.
Because I think there's just in thinking about it, I, think maybe there are several causes for this or several things that might lead to having an underpowered PO.
What's been your experience?
What kind of things have you seen that may contribute to an Underpowered Po?
I Think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend
with a team.
So you've got your head of product or the real decision makers in the organization.
They are saying, I can't spend two, three hours a week with a team.
I Can't go to a planning meeting.
You know, i'm a busy person.
i've Got things on my schedule.
So they see the product owner role as a stand-in for themselves with the team.
And the stand in has lots of time to spend with a team, which is good, and that's a powerful thing.
But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent.
Yeah, it's almost as if they just want a warm body there, you know, like it sits, It's a placeholder.
You're you're here as a, place holder for me.
Cause I can't be two places at once.
I've heard, uh, kind of a couple of things that people will, will frequently point to that a product owner needs to be successful.
And there's sort of this dichotomy of these two things, that are part of that.
That's, the, You know kind, of empowered product, owner that is, is empowered to make decisions.
versus having the availability, uh, to actually be present with the team.
And it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, Hey,
I need to make all the decisions, but I don't have availability.
and the people that they know have, the, availability they don' want to empower to, make the decision.
So they're kind of setting up their product owners to fail.
I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility.
You can just to have a scrum team and say, well, that's where we'll be agile in this scrumm team.
The entire organization as a whole has to think in the agile mindset.
And if you wanna be able to adapt to change, then one of the ways you're gonna have to do that is you have the decision makers close to the teams that
are implementing the decisions.
And so you can't have your cake and not eat it, if you see what I mean, in terms of, you, can pick and choose the aspects of agile that you want.
You need to, as an organization, adopt the whole thing.
Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when trying to decide who's the right person to be
the product for this team, those are two of the things you have to really consider strongly is does this person have the availability to is this person
empowered to make decisions?
I've run up against leaders before that don't want to empower someone.
And kind of the counterpoint I give them a lot of times is, I don' know, maybe in their head they're thinking this is giving someone free reign to really
long-term decisions on their own, when that's not really the case.
The product owner can be fully empowered, but the decisions that they are making on the spot are just a couple of weak decisions.
You know, it's not a six month decision.
There's going to be sprint reviews.
We're gonna, we're going display stuff and get feedback and we can course correct and all those things.
So once, once you can kind of put it in that frame that, you know it really just a couple of weeks that you're empowering them to make decisions.
I've had more success framing it that way.
What about you?
Yeah, I think that makes a huge amount of sense.
The fear is loss of control.
So the fear that by empowering the product owner, they might do something which they would regard as a mistake.
And they will often see themselves, because they're in a senior position, as being responsible.
If they are responsible and the products owner makes the decision they don't like, perhaps that will reflect poorly on them.
There's a trust issue here.
A good product owner is going to be consulting their stakeholders anyway, and I would think the senior product leadership team is part of their stake holders.
So you would hope that they were keeping them very, very up to date on their thinking, that there would be no great surprises,
they wouldn't do something, you know, suddenly switch from one product to a completely different product.
They would always be keeping their Stakeholders in the loop.
And in which case they would be building up the trust of the people around them.
And then you would hope that over time that they will become more empowered.
Yeah.
I kind of wonder if that's maybe part of it, that the they have a misunderstanding.
of, uh, kind of how the role works, you know, because maybe they, maybe, they see it as completely independent.
This person is just making decisions on their own without consulting anyone.
Maybe that's because that how they do their job.
So they may, may look at that as, this is, how I would do it.
Why wouldn't this person do at the same way?
Well, that not how it's designed.
Yeah, it was designed to be done in concert.
Yeah, it's a misunderstanding of the product owner role and it is also a misunderstanding of why the Product Owner role came about.
which is the reason it was there was to solve the problem of too many chefs, of two many people trying to make decisions.
So there's huge value in the role, but the value and the roll only comes about if that person can actually take ownership of the product.
I mean, the clues in name, isn't it?
They are the owner of products, therefore they can make the critical on the ground decisions, all the time talking to their stakeholders.
So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scum team.
Yeah.
I think they also have the fear of the wrong decision that somehow that's going to lock them in, or this person's not equipped to make the right decisions.
They are the knowledge expert for the product, and so they should be the one making all the decisions, they have authority.
And I have had a couple of cases where I've had to have difficult conversations with leaders to say, Well, let's examine the decision because you're looking
at them as making the wrong decision, but is it the right decision?
You know, you, your, kind of disconnected from the day-to-day of the team.
This person is fully connected to the data day and they're more likely to have more current knowledge.
And it's, it, not always the case that just because it is the, wrong, decision that it actually is, they may actually be right.
You could be wrong.
And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value.
And that is, if there is no clear understanding within the organization of a value, then decisions become arbitrary.
We decide to do x rather than y in the product.
Well, why did you decide do that?
Well because it was my decision to that.
Yeah, but is there a rationale behind it?
Do you have a definition to the value of x and the of y and why you chose one over the other?
And I think that's part of the problem as well.
The kinds of organizations that don't have empowered product owners also typically don' have a definition of value.
Yeah, I completely agree.
I know I've had conversations in classes where I talk to people about how when you're prioritizing, when your looking at things in your backlog and we
always say you prioritize according to value, Well, what's the value of doing that thing?
And so many times I think there are organizations that can't really identify what it is.
Why are we doing this thing, because it sounded cool, cause it seemed like the right thing to do.
It just felt right.
No, we're doing it so that it does something, it creates some outcome for us.
And if you can even really define what that outcome is that you're hoping it achieves, Well, isn't that the start of the problem?
And I think part of, the root cause of that as well is the tendency for these types of organizations to do long-term planning.
So what they'll often do is they will have a roadmap for the year and they say, in this roadmap, for a year, we will achieve all these things.
And then it becomes less about delivering value and more about, delivering the roadmap.
And I've had conversations with product owners where I said to them, you do realize what we're doing doesn't make sense.
And they say, yeah, of course they do.
But I'm not being measured on sense or the delivery of value.
I am being measuring on whether or not I meet the roadmap.
Right.
That's what's important to me.
You can see how all these elements are tied together within the organization.
Yeah.
No, that's an excellent point.
And you're absolutely right.
So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric.
It's how much stuff is being produced.
That's not value.
Volume does not equal value, value can be achieved with much less a lot of times.
If we're This is why sometimes I'll advise product owners in classes to say, look, start of your sprint review, maybe go back and look at some things that
you've done recently and show the metric that's you're using for that thing to see if it's successful.
Because if I've.
If the team's done something in the past three or four sprints and it actually moved the value needle some way.
is increased customer satisfaction, added new members to our site, whatever the thing is, right?
If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end,
which is the value.
Yeah, absolutely.
And the other thing I've noticed as well in these types of organizations is that the value they're focused on is not the incremental delivery.
It's usually a new feature or something like that competing.
What you often find is the teams are not end value creators.
They're often parts of the creation of value.
Rather than the whole creation value, there may be a component of it.
And because of that, people will say, well, there's no direct link between you and value creation in the organization.
I find that is very problematic and it really flies against the rationale of Scrum, which is that you want within each sprint,
you wanna deliver some incremental value.
And if you can't measure it, if can clearly define what that value is.
And as you were saying, If the product owner can stand in the sprint review and say, well, this is, the value we've delivered.
How does the team keep motivated?
How do they, how do, they keep passionate about what they're doing?
Yeah.
Yeah, I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable.
I don't know about you.
Well, sure, this applies to you as well.
But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use.
And when they come out with new releases of those things, they came out With release notes.
Now, when They come up with the release Notes, are you looking at the Release notes and going?
Wow, I'm satisfied.
There's a ton of things that's in this release.
Or are You looking through the individual items and Going?
Well, care about that.
I don't care About that on care.
About this, that thing.
Oh, yeah, That's important to me.
Right.
That's what we do.
And, and that's a clear picture of value over volume.
Yeah.
I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team.
So they often have strong self-belief.
They believe they make, they believe by definition the decisions they're making are powerful decisions.
So it's also, I think, one of the reasons why a lot of organizations aren't data driven.
You would hope they would produce a feature and then measure whether or not that feature was a success, but that's not as common as it should be.
There's very rarely business metrics tracked against deliveries.
I mean, I'm generalizing here.
There are many organizations do this very well, but I found there's quite a few organizations that don't really do that.
And it leads to a disconnect with the customers.
I can think of an example, an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got
it done and I think The expected users were tens of thousands and they got 16 users for this feature.
And at that point, there wasn't even a post-mortem.
They didn't look back and say, well, what are the lessons learned here?
It was like, oh, that's a shame.
Let's move on to the next item on the roadmap and hope that works instead.
It's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion
in the engineers and in that the team size because they're delivering things that people want and they feel connected to it.
And it means they work better and then work more effectively.
Yeah, there's no worse feeling than building something no one uses.
I used to joke with the team.
It's kind of like that old joke about if a tree falls in the woods, no, one's around as a mix.
If we build software that nobody uses, did we built it?
Yeah.
You know, it just, i-it's, not going to be used for anything.
So it didn't serve any purpose.
Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important.
What they should view is the value that that person has delivered is important, so sometimes people will say, well, you know,
yeah, okay, we delivered a feature that nobody really used, but you did your job.
You came in for eight hours a day during that time.
And that's hard for people, I think, because they feel like this is my life.
I'm investing time and energy into this.
Yeah, the money is important, of course.
So I am doing it as a career.
But at the same time, i also want to feel reward.
i want feel I can achieving something.
And i think with that element, you get so much better performance from the team if they fill that.
I agree.
There's another thing I was thinking of here too, when we were talking about underpowered POs, another cause I think that,
that maybe you've encountered or seen as well, but screwy things that people do with, with kind of personnel, like for example,
having multiple product owners for a team that leads to under power product owner or, or the opposite, even putting a product on her on too many teams,
and that's going to lead to power PO's as.
Well, what's been your experience with that?
Have you seen that I have one extreme example.
where there was an engineering team and the organisation was international organisation.
politically within the organisation, it was unacceptable to have one backlog.
They had to a backlog for the UK, a back log for US, backlog Australia, backlog for other areas of the world.
And the team then had too prioritise them kind of in this wild order.
So they would say, right, we'll take number one from UK and number from US.
There was no coherence to what they were building at all.
It was really just about satisfying people within the organization.
And it kind of brings you back to that key point about why do we have product owners?
Because product tenders, they narrow down all the ambiguity.
They narrow about down, all of the possibilities to the thing that's most effective for the team to do next.
Yeah, I like it.
I liked your example because it highlights kind of what I think about that.
Those scenarios a lot of times is that they're theater, you know, they are an act.
They're not really serving the purpose, but they, are making someone or helping someone to feel a sense of security about something that really they shouldn't feel.
It's not there, But it has the appearance of it and has, the stage set of something, that looks secure, Yeah.
I mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog.
Yeah, but we're adding 10 new items a week and we are only completing eight.
So in fact, you're moving further down the backlog.
You're not actually getting closer to being done.
And it's, it is a disconnect to gain.
This is what it all about.
Good agility, good scrum is when there's a strong connection.
If you start having that, that just doing things for appearances sake, then you lose that connection Yeah.
And it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency.
When you do those kind theater-ish things to give the appearance of something, it's the opposite of being transparent.
You're trying to make it more difficult to see the reality.
Yeah, It's on the backlog.
So you have this false sense of security.
It is on backlog, but it is never going to get done.
But that's not transparent that it will never get it done because it was on a backlog Part of that I put on the product owner a little bit,
but that could also be that the organization demands it.
Like your example with it having different backlogs across different geographies, does it serve a purpose?
Well, maybe the purpose is to make someone feel better.
Hey, my thing's number one on our list, that doesn't mean it's the next thing that's going to get done.
It was done exactly for that reason.
I mean, it was because they didn't want to alienate the heads of the individual countries.
So they wanted to make them feel like they were going to get something even though they weren't going get it.
Which is really frustrating.
Because there's a, I don't know if there is a fear that someone's going to feel undervalued if they're not called the product owner,
but it just seems like, uh, yeah, we want all these voices to be involved with it, which again, maybe it's the misunderstanding of the Product Owner role.
That's okay.
You can have multiple voices involved.
But you got to define who's the decision maker.
And if a team doesn't know that, that's going to cause a whole host of problems.
Absolutely.
I mean, I've been in scenarios where you would have multiple product owners.
The team has been instructed by a product owner to go in a direction.
Then midway through a sprint, the other product will come along and say, yeah, That's not really what I had in mind for this sprint.
Can you please switch on to this other thing?
And I was a scrum master at the time.
And what I ended up doing in my sprint report was I would say, and the team lost 20 to 30% of their capacity in switching between what one product owner
wanted and what the other product owners wanted.
That at least got a reaction because people said, well, okay, maybe that's not a good thing if we're losing output from the tea.
But it's a failure of the organization to make value judgments and make genuine decisions.
Instead, it becomes political decisions, Well, I'll give you my trick for when I when i've encountered it as a consultant a couple times.
I usually just ask one question and it'll clear it up.
i'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team.
And usually the immediate thing I hear back is, oh, no, they get along.
They usually understand.
And I always just counteract it really quickly and say, yeah, but what happens when they don't?
What happens?
When the day comes when one of the product owners wants something that's number one, and the other one wants an entirely different thing as the number-one priority,
who makes the call?
And, usually they'll point to one them and push comes to shove that one.
Got a little bit more authority, so they make the decision.
I mean, at that point, I just say, well, you just told me that's your product owner, right?
That's the product on the other person's stakeholder, which is fine.
But there's nothing devaluing about someone who's a stakeholder.
They can work all day, every day with that product.
Yeah, absolutely.
I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice.
But what's so frustrating about the situation is when you see it done well, when we see done effectively with a really good,
empowered product, a very motivated team, it's such a powerful thing.
And I mean, that's why I stayed in Agile for so long is because I know how good it can be.
And it's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well,
it is difficult for them to understand just how effective it it.
Yeah, I agree.
Well, this has been a great discussion.
I really like this topic.
It's great to focus on product owners a little bit and hopefully maybe there's a leader out there or somebody listening who heard some of these things
and thought, you know what, maybe it is time to give our product owner a lot more power.
You know, we talk about testing things all the time, inspecting and adapting as we go.
Leaders, try that.
Yeah.
Maybe just try it as an experiment.
If you're concerned, give it a go, Yeah, give it a shot and see what happens.
You may like it and you may decide this is the best way to go.
So yeah, I think that's a great suggestion.
Well, Barnaby, this has been great.
I really appreciate you making time for this and thanks for not only being on the show, but for the contributions you made in the Agile Mentors community
as well.
Thanks a lot, Brian.