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 Temporo.

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 3 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. 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. We take someone from the business along for the ride, and they would be a product owner with one hat, and they'd also have a day job. So we found that, you know, 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 the development, taking a bit of the responsibility off the Scrum Master to groom the backlog and to 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, this function is really important because it will save us X number of FTEs, X number of hours. None of that analysis was actually being done. We were almost picking the low-hanging fruit. Okay, this will get us off to a really good start. This is, you know, following on from that, that seems logical. So none of that actual value was being analyzed.

So it's almost a build it and they will come.

Absolutely, yep.

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.

Yes, I 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, or 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.

Yes.

Did you find that influenced the availability of product owners somewhat, that actually finding product owners that were data literate, interested in getting something built, you know, 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 owners?

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, it was a mixed bag. Am I answering that? Yeah.

So when you kicked off, and I'm sure it's 5 or 6 years ago you guys started this journey. 5, maybe 6.

Time flies when you're having fun.

Yeah, it does. You did have some strong product owners 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, um, the love around and make sure that we have, you know, a wide variety of product owners. Um, yeah, but, but, but we didn't have a dedicated product owner in any of our previous developments where that, that's totally their hat.

It's kind of interesting because if you, if you think about a dev team, you know, 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, you know, sure, it could be good coaching as well, but you kind of make that investment and then the team gets to 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, you know, people leave, new people come in that haven't been through that journey, so they're starting from zero. And so there always seems to need to be, you know, 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 the same kind of thing, right? You kind of started off, built 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 speed and potentially accelerate it 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 ownership can really affect that as well. And you find that when we move in, because we didn't keep the team together to build numerous products, we would put 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, the, um, you know, the idea that we needed to focus more on the product ownership development.

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

Right, so the first thing we did was obviously introduce her to the team.

So bring a coach in?

Bring the coach in.

To help you kind of invest in changing the level of maturity around entrepreneurship?

That's right. So we had a plan to go top-down. So I booked a number of sessions with the C-suite. So we got into level 3 management. So the product manager coach gave a spiel to that group, but then we slowly moved down. So we then talked to individual teams within the business and their team leads. Just to plant the seed.

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, you know, the people above you, so, you know, you're not allowed to opt out. This is what we're doing. That's right. 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 in product ownership 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 move down the organizational roles or hierarchy, did the messaging change slightly? Did the way you presented 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?

With the C-suite, it's, you know, 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 know, you sell that to the C-suite, but it's also what are they going to get out of it is the first question that they'll ask. And it's that you'll get somebody that will really know the product inside and out. Quicker. Now you'll get something deliverable a lot quicker if somebody's there to make those, those good calls. And yeah, as we got to the lower level, it was more about, you know, the functions of the product owner. We got into value stream mapping, what had priorities, what task or what benefit to build in what order, and got into more about how the product owner fits into the development team, how that whole Scrum team 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? What's, you know, 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 the way the organization works, 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, you then move into the how. So you have a quick why, a bit more of the what, and then lots of detail on 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 into more details.

And the C-suite also wanted to know how quick to market you'll get. So we sold the idea of the continuous improvement or the iteration, so that you'll get something in Sprint 1, you'll also get something in Sprint 2. So it's really selling the idea that you'll start to see benefits straight away. We worked our way for 6 months, build our requirements document, and came up with this new gem. Yeah, so it's really the— it was the Agile versus Waterfall, like, um, sales pitch. Mhm. Give Waterfall a bit of a hiding.

Yeah, yeah. Look, I, um, I was at a meetup, uh, so an Agile coaching meetup, um, a little while ago, and, um, 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.

There's some in this room that probably do.

Yeah, yeah. It's because for, I don't know, even 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, you know, in 20 more years, there'll be a new thing comes out that's better than Agile, or a refined version. But given Agile is a mindset, not an approach, I actually don't think, you know, that the mindset will change, maybe the tools and techniques we use will.

Yeah.

Okay, so, so, start off on an education process, right, to go through and and, as you said, Silver Vision.

That's right. Um, and then, then we started to, um, bring her into some of the existing developments. We had a couple of, couple of projects going at the time that, uh, had proxy product owners. So it's, it was that observation stage where we would get feedback on, you know, are we really that broken? Um, 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, you know, taking that feedback and starting to build a plan from, for the next development, how we do it differently. So kind of a retrospective on the go.

Okay, so observe, retro, experiment with new, 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 chunked up the product ownership side. So we had a brand new product owner. We had the coach that we brought in. We've also got a— we had a trainee. Product owner coach and also a very experienced BA 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 BA. 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 right 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, 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, the success criteria, all those kind of things. And then you introduced the role of, kind of accelerate or mature, try to focus on maturing the role of the product owner. But it sounds to me that you almost created a product management/product owner group that went in 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 it's because you brought in an external coach to help build some capability, do some observation, and find out areas you could improve or accelerate? 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 was being redefined. So, so, um, it's also the pains of trying to do something different that if I— if you remember what I mentioned earlier, we would drive the development and we would go ahead and we'd build it based on what we think the product owner wants. So we lost a lot of momentum because we're 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 is an unnatural behavior for our development side.

But if you waited for the perfect storm, if you waited for, you know, the change in that business part of the organization to stop and everybody to settle and be, you know, mature sure, 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—

manage the risk. —experiment to say, No, let's hold back. Let's wait for them to come. It's us and them. 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. 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 development. Be with us. Don't rush ahead 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 shit 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 not just do something in the future, right? So you have to have that permission to, to, yeah, to, to be able to do that, or you won't be safe. Yeah, true.

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

Okay, so, so first of all, you know, explain the why, then the what, then the how, and do the education. So So, 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 in 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 or 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 catalog 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 the 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 onboard and mentor and train? Someone on my team.

Someone on your team? Yeah, yeah. So the business development team needs to work alongside product itself. We'll try and be the center of excellence for Agile. So we'll supply the product owner coaching as well as giving Scrum Masters and Agile BAs to projects. Okay. Yeah, so they'll come to us. Yeah, so we've got a product owner coach. We're finishing off our time 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, 6 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, right? Yeah, yeah, definitely. Yep. That'll be interesting to see what— how we've gone in 6 months. Yeah.

Again, you know, you probably don't need an external, right? What you need is— 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 see rather than the typical deep 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 or that and actually spend an iteration themselves figuring on, you know, doing the retros to themselves and observing each other is figuring out what's next. It actually becomes an internal process or a way of working because you're focusing on investing that time to make that change.

So keep the band together while you're waiting for the next product development 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 investing in that money you're effectively investing time by giving yourself permission to invest that time, would you get the same benefit? Yeah, probably an interesting experimentation.

Yeah, well, we are experimenting. Yeah, well, with that, so we'll continue to build up the backlog of product owners that we've got in the business that have been properly trained so that they sort of form a 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, you know, that they will need for new product owners 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 concept 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, or you might— and then a guild becomes a group of people that have a similar interest. I'm wondering whether that's effectively where you're going to end up with, is your version of an alumni is really a Product Owner Guild, where if you're interested in product ownership, you have that like-minded people together. 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 an unconference or a conference where, again, you're giving permission for people to invest their time in growing that guild.

Well, the, ah, 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 example. Main product owners that will work on multiple products. Um, and they will come to us and say, hi, this is Joe, he's going to be the product owner for this development. And we have to— that product owner to do research on what they're actually building and doing the UX and doing the stakeholder engagement, but coming from an experience point of view rather than Yeah, with us doing all the driving, so it's going to be really good. Cool.

So close it out. What, any other kind of 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 a collaboration with a little bit more of a separation of role or responsibility or accountability. 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. I don't know how to articulate it, but we want a product owner that's going to push our team, right? We'll never get 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 it, Shane. I mean, this is an evolving thing, but I'd love 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, look, 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.