Join Shane and Blair as they chat amongst themselves on maturing the product owner capability.

Read along you will

PODCAST INTRO: Welcome to the “AgileBI” podcast where we chat with guests or sometimes just to ourselves about being Agile with teams who are delivering data analytics and visualization.

Shane Gibson: Welcome to the AgileBI Podcast. I’m Shane Gibson.

Blair: I’m Blair Tempero.

Shane Gibson: And today is just Blair and me having a chat about something that we’re excited about. So Blair, I think we’re gonna talk about the journey you’re going through at the moment of increasing the maturity in your organization around product owners?

Blair: So we’ve been Agile for about three years now maybe more, we 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 one thing that we really have had to deal with as the business catching up with us, so we’ve found ourselves actually being the drivers of information products, we will take someone from the business along for the ride. And they will be a product owner with one hat, and they will also have a day job. So we found that for the state 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 leaving from the front. So product ownership became a focus. And it was, during one of these podcasts that I came across an awesome product and a coach. And the penny dropped that we need to get someone in that’s got the expertise to coach product owners, to show them the value of eventually leading the development and taking a bit of the responsibility of the Scrum Master to bring the backlog and to lead the direction of the development.

Shane Gibson: So are you finding that the chasm of not having strong product owners available, the Scrum Master was kind of filling the role of our proxy product owner is to help the team get across the line?

Blair: 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, the current state, and what’s the most important thing to do at that stage without having the business input into this, this function is really important because it will save us ‘X’ number of PPAs, ‘X’ number of hours, none of that analysis was actually been done, we were almost picking the low hanging fruit. Okay, this will give us off to a really good set. This is falling off from that that seems logical. So none of that actual value was being analyzed.

Shane Gibson: So almost a builder and they will come excellently because they were no strong product owners coming out of the organization, so must have no choice of doing nothing, or have a guess of where that value was and deliver it and see whether you hit the target?

Blair: So do nothing wasn’t an option because we wanted to get on a roll. And we did actually have some product owner’s they were naturally good. And they did care about the product. And they were and we found that there was the trial and error of who was going to be caught just an organic fine 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.

Shane Gibson: So your team’s data and analytics executing, right.

Blair: They’re not doing web development, they are focus purely on data and analytics and visualizations.

Shane Gibson: Did you find that influence the availability of product owners and what they’re actually finding product owners, that where data literate interested in getting something built, information product built there. Use of data and analytics available to help make business decisions. Did you find that made it harder or easier to find partners?

Blair: Well, it definitely we found it hard to define the data literacy as a problem. So that’s where we filled in the void. And really laid along the product data, but the strong mindset and data savviness and knew what the development was replacing with the Merida spreadsheets that they wanted to evolve into a BI product, for instance. It was a mixed bag.

Shane Gibson: So when you kicked off insurance five or six years ago, you did have some strong product owners coming out of business groups. And I just ensuring what would happen if there was a dearth of new product owners be made available, that those people would keep fulfilling the role of product owner prioritizing, the areas that admissibility to them and the parts of the organization. So they were just constantly getting freebies right there. They were driving, because nobody else was standing up and saying, I needed something as well. But it sounds like Did they leave? Did they back off? What happened there?

Blair: It’s a big restructuring. So next we’re the pioneers of our product ownership moved into different roles. We also consciously wanted to share the love arounds, and make sure that we have a wide variety of product owners. That we didn’t have a dedicated product owner, in any of our previous developments with it, it’s totally they have.

Shane Gibson: To struggle internally because if you think about a Dev team, Scrum team or a team like that, what I find is that when you start your journey, lots of investment around, new ways of working, financially, or coaching as well. But you make that investment, and then the team gets a certain level of velocity and going back off some of that investment in that area. But with a team, they often seem to people leave, New people come in and everything through their journey. So we’re starting from zero. And so there always seems to me to be almost top up the tank again, to help keep that velocity or accelerate to the next level. I hadn’t caught a thought about it from a product ownership point of view, but what you’re going the same thing, you started off building capability. And then over time, for a whole raft of reasons it slowly degraded and you needed to reinvest them, bringing that capability back up to you up to speed and potentially accelerate it to the next level.

Blair: So that sort of prove that not only the velocity was impacted on, change within the development team that year, product data 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 event teams specifically for their product. And then we would break that up. And then form another team with the resources available. Go searching for a product owner. No one was knocking on the door. We had a list of priorities from the business. But none of that had this business going to lay to an owner. Hence, the idea that we needed to focus more on product development.

Shane Gibson: So what’s the first thing you did to start that focus?

Blair: So the first thing we did was, we slowly introduce you to the team started. So bring a coach to help you invest them in changing the level of maturity around. So we had a plan to go top down. So we booked a number of sessions with the C suite. So we got into level three management so that the product manager came together a scale to that group. But then we slowly move down. So we then talk to individual teams, will then process, the team late. That’s a part of the same.

Shane Gibson: So obviously, having the sense work first to get permission and endorsement and try to go to the next level and say, we’re doing this, we have the backing of the people above us. So we have not doubt, this is what we’re doing. That’s not what mandating, they’re not asking for permission.

Blair: And we didn’t have product you want to develop. So we were using that time to build our own capabilities and product owner and showcasing. So that was one of the key objectives.

Shane Gibson: And then the other one is, when you move from the C suite to the next level down as you move down the organizational roles in the hierarchy, did the messaging change slightly, that the way you presented to receive level of what this is and why it’s important and how it works? That changes you with lower and lower?

Blair:  With this C Suites, there is an improvement to the business. If you’re doing that to the lower level as well, but it’s more about this is how you do product and you can actually sell it for the C suite. But it’s also what are they going to get out of it as a business. And we’ll get somebody that will really know the product and sign out as quicker. Now you’ll get something deliverable a lot quicker. Somebody says make those calls. And as we’ve got to the lower level, it’s more about, the functions of the product. Value Stream, Mapping, and prioritize what, what to ask or what to build, and what order. It got into more about how the product owner fits into the development team. And that whole scrunching fixing.

Shane Gibson: Cool, so what I’m hearing is when you started the talk, is that often the conversation of why, why are we doing this? Why would we do this? What’s the reason? Where is the value? And sometimes that why is that becoming by the what? So why are we doing this to prove the way the organization works. What are we going to do, we’ve got the single product owner, this is a bit of a framework around that, and what it is, and then as you get lower and lower on the shearing, you’ll then move into the how, quick why, that more of the what and the lots of detail how. How does it work? What tools do you use? What are the pros, so that why, what and then, how, as you go down to more details.

Blair: we see how quickly market to get, so we saw the idea of continuous improvement or the iteration. So that you’ll get something that’s fun. That’s really selling the idea that you’ll start to see benefit straightaway. We might go away for six months, build our requirements document. So it’s really was the Agile versus waterfall.

Shane Gibson: So I meet up someone from an Agile company and meet up a little while ago. And what was interesting, there was this idea that we should go for waterfall because, for certain ways of working. Waterfall is actually fit for purpose. I’m not sure we all do it. Lots of us. It’s either founder or the environment that I’m in around data and analytics, I find Agile is a better way than waterfall. Potentially you’re in 20 more years, there’ll be a new thing comes out that’s been an Agile refined version. Give an Agile has a mindset newer approach, I do think that the mindset will change, maybe the tools that you need to use will, sound like an education process to go through and see some of the vision.

Blair:  And then we started to bring into some of the existing developments. We had a couple of projects going at the time, that proxy product owners exists, observation stage where we will get feedback on, are we really that broken? What’s going on? Well, what’s not, doing some earnings on existing technology or the way that people are going like product ownership role, and then taking that feedback, starting to build in from the next development differently.

Shane Gibson: Okay, so this is retro experiment with new ways of working, try them and see if they improve.

Blair: That’s right. So that was around that stage where we got an opportunity to sue him for a new BI product development. So, we really choked up the product ownership side. So we had a brand new product owner, we had the coach that we’ve brought up, we’ve also got a trainee kind of coach, and also a very experienced BI, wrapped around the new product owner. So we’ve really made that sign up. Which slider down to start with, but we do ready for that pain. And then on the other side, we had the developer and another thing.

Shane Gibson: And we had some learnings from that as well. We were about to have a retrospective.

Blair: Yes, the product owner side was coming along nicely, that will lead to new things that are going with, to the business, to the users. And we started to introduce user experience to the max. We’ve never had that and the product owner side. We have developers waiting for that UX to start.

Shane Gibson: So sounds like you split the team though. So previously, you had a proxy product owner that was embedded in the scrum team. So the scrum team, were connected with the stakeholders around what they want. Getting understanding of the effects or user stories or functions. Understanding what success look like, seems criteria or those kinds of things. And then you’re introduced, the role of economic seller, will mature towards the 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 in early understood all that and then came back to the dev team. So how did that work?

Blair: It didn’t work particularly well. So we put all of our focus on this, 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 it’s to keep that whole team time. So we did find that we slipped away.

Shane Gibson: Do you think that’s because you bought in an external coach to help build some capability, do some observation on area, find out areas of where you could improve or accelerate. So therefore, because there was an external person coming in, and there was an investment to get that data, and I doubt that was time bound, that all your energy and focus went on proving that side of the equation? So you naturally late on the other side, because you potentially could not fix it later, or actually don’t realize that it’s unbalanced.

Blair: And also, on the product owner side, we still don’t have a dedicated product owner with 100% of their time. And they were also going through a restructure. And here roles was being 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 make builder based, on what we think the product owner wants. So we lost a lot of momentum, because we’re waiting for their side to come to the pain. And they were very pains, that I suspected what would happen, because you’re actually saying, we’re going to wait for you to come to us. And that’s an unnatural behavior for our development.

Shane Gibson: But if you waited 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. Because change is constant. So 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 is building. So just do it and manage the risks.

Blair: Let’s hold back, let’s wait for them to come as a nice way, 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 anxiously for the product owner to come to the party.

Shane Gibson: I know you’re going to be grumpy. Beside that, we are trying to beef up this side or that side of the development. Be with us, during rush we are here to make assumptions. So that’s what we’ve done in the past.

Blair: And I think if you were going to try that, 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 you should 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 need to unlearn or break the current behavior to increase our maturity on the product owner side, which will give us that buyer, the velocity and make sure we do the right things.

Shane Gibson: Yes, not just to do something in the future. So you have to have that permission to be able to do that, or you won’t be safe, true.

Blair:  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.

Shane Gibson: So first of all, 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 the retro start making in some experimentation and ways we’re working consistently, and withdrawing on that to improve another eight and do that. And then for me, I suppose the next logical step would be having that ability to carry on that behavior, without the external coach. So be able to onboard new product owners, be able to have somebody internal in your organization, there is 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?

Blair: Yes, we have, every intention was to be to have a product coach and to be to train the trainer. So we will never fill in the void something that needed fixing quickly, we need a product owner build us. 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 this school before we even start the development. So that’s going to be one mark negotiable, from the development side is that product owner needs to process training.

Shane Gibson: So who do you think’s going to do that? Who’s going to be the person in your organization or role that helps onboard and mentor and train?

Blair: Some of us. So we’ll try and be the center of excellence that the Agile, we’ll supply the product owner coaching as well as giving Scrum Masters and AgileBIs to projects. So they’ll come to us. 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 just like that makes development.

Shane Gibson: And again, Blair and 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, identify areas of experimentation to accelerate your internal coaching team to the next level.

Blair: Yes, definitely. It’ll be interesting to see where we’ve gone in six months.

Shane Gibson: Again, you probably don’t need an external, what you need is, as 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 coaching team and you’re developing, if we see, rather than deep sprint, what we’re doing developers, we’re going to do a way of working acceleration, iteration where the coaching team actually stopped working on development or they’re actually spending iteration themselves. They’re going on, doing the retros to themselves and observing each other and 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. While you’re waiting for the next product development opportunity, because so many of my heroes thought about it as bring me to them. And that has massive value. But there’s that secondary value by investing in that money, you are thinking investment time, by giving yourself permission to invest the time. Would you get the same benefit from it machine experimentation?

Blair: Meanwhile, we are experimenting with someone continuing to build up the backlog of products in the business, probably trying so that they formed.

Shane Gibson: I’ve done a little bit of work, looking at, what’s called the Spotify model, where those big argument that model or not, and so that has a concept of squads, teams, genders, and guilds and the tribes. And they cross over. So it’s not a hierarchy, its matrix. I really liked the idea they have of chapters more around your school and whatever engineering chapter and then a guild becomes a group of people that have a similar interest. And, are wondering whether that’s effectively we’re going to keep up with it, as your views over alumni is really a product owner groomed, where if you’re interested in foreign ownership. Now you have that like minded people together. And then the question I suppose, is, how do you encourage that? How do you reinforce that as they are, our product owner, one day, get together with an unconference or a conference, again, you’re giving permission for people to invest the time and growing group?

Blair:  We’re at the moment, I set the business as a job advertised. So a functional team of product that will work on multiple products. And they will come to us and say this is Job, is going to be the product development and react to get product owner to do research on what they’re actually building and doing the UX and then the stakeholder engagement, but coming from an experience, point of view, rather than us doing all the driving, so it’s going to be really now.

Shane Gibson: So close it out, what any other words of wisdom from what you’ve learned, the last couple of months?

Blair:  I’m looking forward to the conflict between scrum master and product owner.

Shane Gibson: Hopefully, it’s a collaboration, we’re a little bit more of a separation of role or responsibility or accountability. But still closely working together that would be nice to see.

Blair: I am looking for the natural intertwining of ideas, articulated well, we want a product. I know that’s going to push out, we’re going to hit that.

Shane Gibson: Because you’re Scrum Master is a good Scrum Masters.

Blair: Yes.

Shane Gibson: So the product leaders for the team that are making the team healthy, and helping the team grow. By doing that, they’re not naturally going to take a business view of value, which is I want more. Now, we can’t more deliver that because I really need it. So they are quite rightly, behaving like good Scrum Masters.

Blair: This is evolving thing that a lot of chat about, would say a few months down the track and see how we go. I have some success stories. I probably had some more learnings.

Shane Gibson: Let’s design that for maybe the podcast 24.

Blair: Excellent.

Shane Gibson: All right. Well, it’s a lot from us. So catch you later.