AgileData #12 - Maturing Product Owner Capability

Welcome to the Agile Bi podcast where we chat with guests, or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations.

Welcome to the Agile Bi podcast. I'm Shane Gibson. I'm Blair Temporary and today it's just Blair and me having a chat about something that we're excited about. So Blair, I think we're going to talk about the kind of journey you're going through at the moment of increasing the maturity in your organization around product owners.

Yeah, that's right, Shane. So we've been agile for about three years now, maybe more. You lose count. So we've got really good at having a development team using Agile. Scrum Masters are all up to speed. We've got a management structure that supports us in information.

So the, the one thing that we really have had to deal with is the business catching up with us. So we found ourselves actually being the drivers of information products and we'd take someone from the business along for the ride and they would be a product owner with one hat and they'd all also have a day job. So we found that for the start of our evolution that was fine, but we needed to hand over a bit of the reins to the business to get them to start actually leading from the front. So product ownership became a focus. And it was during one of these podcasts that I came across an awesome product owner coach. And the penny dropped that, you know, we need to get someone in that's got the expertise to coach product owners to show them the value of actually leading them the, you know, leading the development, taking a bit of the.

Responsibility of the Scrum Master to groom the backlog and to, you know, lead the direction of the development.

So were you finding that the.

The.

Chasm of not having strong product owners available, the Scrum Master was kind of filling the role of a proxy product owner to help the team get across the line.

Absolutely. So I was the first Scrum Master and found that I was actually prompting the development team to sort out the value stream mapping, you know, the current state and what's the most important thing to do at this stage without having the business input into. Well, actually this function is really important because it will save us x number of FTEs, x number of hours. None of that analysis was actually then done. We were almost picking the low hanging fruit. Okay, this will get us off to a really good start. This is following on from that. That seems logical. So none of that actual value was being analyzed.

So almost a build it and they will come.

Absolutely.

But because There were no strong product owners coming out of the organization. So must have been a choice of do nothing or have a guess of where that value is and deliver it and then see whether you hit the target.

Yeah. So do nothing wasn't an option because we wanted to get on a roll. And we did actually have some product owners who were naturally good and they did care about the product, and they were. And we found that with the trial and error of who was going to be product owner just by just an organic find was that if they had skin in the game, then they were going to be a good product owner. At least they were going to be able to help a proxy to make those good calls.

So your team's a data analytics dev team.

Right.

So they're not doing web development. They're focused purely on data and analytics and visualizations. Did you find that influenced the availability of product owners somewhat? They're actually finding product owners that were data literate, interested in getting something built, information product built, that had data and analytics available to help make business decisions. Did you find that made it harder or easier to find product labels?

Well, definitely, we found it hard to find the data literacy aspect up front.

So that's where we kind of filled in the void from our development team and really lead along the product data. But the strong ones that had data savviness and knew what the development was replacing because they had a myriad of spreadsheets that they wanted to mold into a BI product, for instance.

Yeah, it was a mixed bag.

Yeah.

So. So when you kicked off, and I'm sure it's five or six years ago, you guys started this year.

It does, you did have some strong product owners kind of coming out of those business organizations or business groups. And I just assumed what would happen if there was a dearth of new product owners being made available, that those people would keep fulfilling the role of product owner, prioritizing the areas that had massive value to them and their parts of the organization. So they were just constantly getting freebies. Right. They were driving because nobody else was standing up and saying, hey, I needed something as well. But it sounds like, did they leave? Did they back off? What happened there?

Let's throw a restructure into the mix. Let's throw a big restructure into the mix where.

The pioneers of our product ownership moved into different roles. We also wanted, consciously wanted to share the, share the love around and make sure that we have a wide variety of product owners.

But we didn't have a dedicated product owner in any of our Previous developments where that's totally their hack.

It's kind of interesting because if you think about a dev team, a scrum team or a team like that, what I find is that when you start your agile journey, lots of investment around, new ways of working, potentially good coaching as well, but you kind of make that investment and then the team gets a certain level of velocity and you can kind of back off some of that investment in that area. But with a team, they often seem to. People leave, new people come in and have been through their journey. So they're starting from zero. And so there always seems to need to be almost top up the tank again to help keep that velocity or accelerate to the next level. I hadn't kind of thought about it from a product ownership point of view, but what you're saying is same kind of thing, right. You kind of settle off, build that capability and then over time, for a whole raft of reasons, it slowly degraded and you needed to reinvest in bringing that capability back, back up to. Up to speed and potentially accelerate it.

To the, to the next level. Yeah. So that sort of proved that not only the velocity was impacted on change within the development team, but yeah, product owner can really affect that as well. And you find that when we move in, because we, we didn't keep the team together to build numerous products, we would with that team specifically for that product. Right. And then we would break that up. Right. And then form another team with the resources available, go searching for a product owner. No one was knocking on the door, right? Yeah. Okay. We had a list of priorities from the business, but none of it had this person is going to love it and own it. Right.

Hence.

The idea that we needed to focus more on the product ownership development film.

So what, what's the first thing you did to, to start that focus?

Right. So the first thing you did was obviously introduce her to the team.

So. So bring a coach in. Bring the coach in to help you kind of invest in, in changing the level of maturity around ownership.

So we had a plan to go top down. So we, so I booked a number of sessions with the C suite. So we got into level three management. So the product manager coach gave a skill to that group but then we slowly moved down. So we then talked to individual teams within the business and their team leads just plighting the scene.

So obviously hitting the C suite first to get permission and endorsement.

That's right.

To go to the next level and say we're doing this. We have the backing of the people above you. So you're not adult out. This is what we're doing. So not mandating it, but not asking for permission.

That's great. And we didn't have a product yet to develop, so we were using that time to build our own capabilities and product initial coaching. So that was one of the key objectives.

And the other one is when you move from the C suite to the next level down, as you went down the organizational roles or hierarchy, did the messaging change slightly? Did the way you present it to the C level of what this is and why it's important and how it works, did it kind of change as you went lower and lower?

Well, with the C Suite, you're selling an improvement to the business. You're doing that to the lower level as well. But it's more about this is how you do product ownership. You sell that to the C suite, but it's also what are they going to get out of it? Is the first question they'll ask. And it's that you'll get somebody that will really know the product inside and out is quicker now. You'll get something deliverable a lot quicker if somebody's there to make those big calls.

And yeah, as we got to the lower level, it was more about the functions of the product owner. Value stream mapping, what prioritize, what task or what benefit to build and what order and got into more about how the process product owner fits into the development team and that whole scrunching fits in. Cool.

So what I'm kind of hearing is when you start at the top, you start off with a conversation of why? Why are we doing this? Why would we do this? Where's the value? Yes, that's right. At some stage that why will start becoming backed up by the what.

Right.

So why are we doing this? We want to improve the know the way the organization works or whatever.

What are we going to do? We've got this thing called Product Owner. This is what it is. So a bit of a framework around.

The what it is.

And then as you get lower and lower on sharing that, you then move into the how. So you quick why? Bit more of the what and then lots of detail, the how, how does it work? What tools do we use, what are the processes? So that kind of why, what and then how as you go down and do more details.

And the C suite also wanted to know how quick to market, you'll get right up. So we sold the idea of the continuous improvement or the iteration.

So that you'll get something in Sprint one, you'll also get Something Sprint two. So it's really selling the idea that you'll start to see benefits straight away.

We won't go away for six months. Build our requirements document this year. Yeah. So it's really the. It was the Agile versus Waterfall.

So sales pitch.

Gave waterfall bit of a hiding.

Yeah, yeah. Look, I was at a meetup so an agile coaching meetup a little while ago and.

What was interesting there was this idea that we shouldn't bag waterfall because you know, for certain ways of working, waterfall is actually fit for purpose. But we all do it. Well, I don't actually rephrase it. I'm not sure we all do it. Lots of us and someone this room that probably does.

Yeah, yeah.

You know, it's because for. I don't know but for me I found in the environment that I'm in around data and analytics, I find agile is a better way than waterfall.

That's right.

Potentially in 20 more years there'll be a new thing comes out that's better than Agile or a refined version. But given Angel's a mindset, not an approach, I actually don't think that the mindset will change. Maybe the tools and techniques we use. Okay, so.

Start off on an education process to go through and. And as you said, silver vision.

That's right. And then we started to bring her into some of the existing developments. We had a couple of projects going at the time that had proxy product owners. So it was that observation stage where we would get feedback on.

Are we really that broken?

What's going well, what's not doing some learnings on our existing methodology or the way that we were doing that product ownership role, taking that feedback and starting to build a plan for the next development. How we do it differently. So kind of a retrospective on the go.

Okay. So observe retro experiment with new ways of working.

That's right.

Try them. See if they improve.

That's right. So it was around that stage where we got an opportunity to step into a new BI product development. So we really choked up the product ownership side. So we had brand new product owner.

We had the coach that we brought in. We've also got a, we have a trainee product owner coach and also a very experienced EA wrapped around the new product owner. So we really beefed that side up which slowed it down to start with, but we were ready for that pain. And then we had. On the other side, we had the developer and another va. Yeah. And we had some learnings from that as well. We're about to have a retrospective. Yeah. The product side was coming along nicely. They were learning new things, they were going away to the business, to the users. And we started to introduce user experience to the mix. We've never had that in the product owner side. We had developers waiting, waiting for that UX to start.

So it sounds like you kind of split the team though, right? So previously you had a proxy product owner that was kind of embedded in the Scrum team. So the Scrum team were connecting with the stakeholders around what they want, getting understanding of the epics, the user stories, the features, understanding what success looked like, seams criteria, those kind of things. And then you introduced the role of you kind of excel at or try to focus on maturing the role of the product owner. But it sounds to me that you almost create a product management product owner group that went and early understood all that and then came back to the dev team. So how did that work?

It didn't work particularly well.

So we kind of put all of our focus on that on the product owner side and that's probably a rookie mistake. We certainly won't do that again. And for me it showed the importance of the Scrum master role and that's to keep that whole team tied. So we did find that we slipped away.

Do you think that's because you brought in an external coach to help build some capability, do some observation, find out areas of areas you could improve or accelerate. So therefore, because that was an external person coming in and there was an investment to get that done and no doubt that was time bound, that all your energy and focus went on improving that side of the equation and so you naturally lighten the other side because you potentially could fix it later or actually don't realize that it's imbalanced.

Yeah. And also on the product owner side, we still didn't have a dedicated product owner with 100% of, with her time. So. And they were also going through a restructure and her role has been redefined.

So it's also the pains of trying to do something different that if you remember what I mentioned earlier, we would drive the development and we would go ahead and we build it based on what we think the product owner wants. So we lost a lot of momentum because we were waiting for that side to come to the party and they were growing pains that I suspected would happen because you're actually saying, hey, we're going to wait for you to come to us and that was an unnatural behavior for our development.

But if you waited for the perfect storm, if you waited for.

The change in that Business, part of the organization to stop and everybody to settle and be mature. And that never happens.

Right.

Because change is constant. So it's always, in my view, you had an awareness of the uncertainty and the risk of doing it now. But waiting probably may or may not have reduced the uncertainty, but it wouldn't have helped increase the value of what the dev team's building. So just do it. And there's no risk experiment to say.

No, let's hold back, let's wait for them to come.

Let's wait for them to come to us and push us. It didn't work because it's just a totally different mindset for the business side and there were literally developers waiting earnestly for the product owner to come to the party.

Yeah, they got grumpy.

Yep, yep, yep. And you know what I said, I know you're going to be grumpy. Yep. But I'm sorry that, you know, we are trying to beef up this side of the side of the development. Be with us. Don't rush your head and make assumptions. See, that's what we've done in the.

Past and I think, you know, if you're going to try that, you know, if you're going to do this type of experimentation in your own organization.

You have to be very clear with the people that are driving the change in the organization and being that umbrella to keep you safe, then actually the velocity and the throughput that's coming out of the dev team is markedly going to go down because we kind of need to unlearn or break the current behavior to increase our maturity on the product owner side which will give us that buy in and velocity and make sure we do the right things, not just do something in the future. Right. So you have to have that permission to.

Be able to do that or you won't be safe. Yeah, true.

Yep. And in hindsight I don't think we would have done anything differently on the product side, but I would have made the developments that I feel safer.

Okay. So first of all, you know, explain the why, then the what, then the how and do the education to get everybody ready to start that journey. Second step coach helps understand where you're at, where we can improve. Bit of a retro, start baking in some experimentation and the ways we're working and consistently retroing on that to improve and iterate and do that. And then for me, I suppose the next logical step would be having that ability to carry on that behavior with out the external coach. So being able to onboard new product owners, be able to have somebody internal in your organization that's assuming the role of product owner, coach or product owner, product owners or whatever you want to call it. So have you got to that stage?

Yeah. So we had every intention was to be to have the product coach come in to be to train the trainer so we were never filling a void that needed something that needed fixing quickly. Hey, we need a product owner to build this. It's more about building those capabilities. So we've built up a catalogue of documentation that we will train the next product owner and we'll put them through that school before we even start the development. So that's going to be one non negotiable from a development side is that product owner needs to come.

Past this training.

So who do you think is going to do that? Who's going to be the person in your organization or the role that helps on board and mentor and train Some of my team. Some of your team.

Yeah, yeah. So the business development team. So work alongside product. That's helpful. We'll try and be the center of excellence for agile. Right. So we'll supply the product owner coaching as well as giving Scrum masters and Agile design to projects. Okay. Yeah. So they'll come to us.

Yeah. So we've got a product going to coach. We're finishing off our time with the.

Yeah. With the external contractor. Got a few more hours of support and Yep. Just wait for that next development.

And I think you know again retro on this one is actually booking out that in a certain period of time, six months, a year, you need to bring that coach back in for another short period of observe feedback, you know, identify areas of experimentation to accelerate your internal coaching team to the next level.

Yeah, yeah, definitely. Yep. It'll be interesting to see what go with gone in six months. Yeah.

Again you know you probably don't need an external.

Right.

What you need is we use the externals as a way of us forcing the investment of that time or typically that money which forces us to put the investment of time actually if we looked at the coaching team that you're developing if we said rather than technical debt sprint like we do with developers, we're going to do a way of working acceleration iteration where the coaching team actually stop working on a development and actually spend an iteration themselves. Figuring on doing the retros to themselves and observing each other is figuring out what's next then actually becomes an internal process with a way of working because you're focusing on investing that time to make that change.

So keep the band together.

Yeah.

While you're waiting for the next product, develop an opportunity. Yeah, totally, yeah.

Because for me in my head, as I thought about it, is bring the expert in and that has massive value, but there's that secondary value by, by investing in that money, you effectively invest in that time. By giving yourself permission to invest that time.

Would, would you get the same benefit? Yeah, probably. Interesting experimentation.

Yeah. Well, well we are experimenting. We're well worth it. So we'll continue to, to build up the backlog of product owners that we've got in the business that can properly train so that they still form alumni. We've already got that to a certain degree with the product owners that we've got through already but with less formal training that they will need for new product names coming on. But this is just beefing it up that extra level.

Yeah. So I've done a little bit of work looking at what's called the Spotify model, although there's a big argument about whether it's a model or not. And so that has the kind of concept of squads, teams, chapters and guilds and then tribes and they cross over. So it's not a hierarchy, it's a matrix.

I really like the idea they have of chapters more around your skill sets. They might have an engineering chapter and then a girl becomes a group of people that have a similar interest.

And I'm wondering whether that's effectively where you're going to end up with is your version of an alumni. There's really a product owner guild where if you're interested in product ownership, you have that like minded people together. And then the question I suppose is how do you encourage that? How do you reinforce that? Is that a product owner one day get together with of, you know, an unconference or a conference where again you're giving permission for people to invest their time in growing that build.

Where we're at at the moment is that the business has a job advertised for an experienced product owner. So hopefully that's the start of the business actually beefing up that side of things. And they will form a guild, will actually be a functional staff, product owners that will work on multiple products.

And they will come to us and say, hi, this is Jo, she's going to be the product owner for this development and be up to that product owner to their research on what they're actually building and doing the UX and doing the stakeholder engagement but coming from an experience for theory rather than, yeah, us doing all the driving. So it's going to be really good.

Cool.

Yeah.

So close it out.

What?

Any other words of wisdom from what you've learned over the last couple of months?

I'm just looking forward to the conflict between Scrum Master and product owner that we've never had.

Hopefully it's collaboration with a little bit more of a separation of role or responsibility or accountability. Yeah. But still closely working together. That would be nice to see.

Your words. Your words are better. Just looking for that natural. That natural sort of.

Intertwining of ideas.

Articulate it. But we want a product owner that's going to push our team. Right. We've never had that.

Because your Scrum Masters are good Scrum Masters, right? Yeah. Servient leaders for the team that are making the team healthy and helping the team grow. But by doing that, they're not naturally going to take a business view of value, which is, you know, I want more, I want more. No, you can't not deliver that, because I really need it. So they are quite rightly behaving like good Scrum Masters.

No, I think that's a chain. I mean, this is an evolving thing. But I'd like to have a chat about, let's say, a few months down the track and see how we're going. I'll have some success stories, hopefully, and some more learnings.

Yeah, let's put that one in. And the same for maybe, I don't know, podcast 24.

Yeah, sounds good.

Excellent. All right, well, that's a lot from us, so catch you later.

See you later.

Sa.