AgileData #3 - The life of an awesome product owner

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.

So today we have Hiriya Tarangi. Hiriya is going to talk to us about product ownership and her experiences across the board.

Welcome, thank you for joining Blair and myself and to the Agile BI podcast. You're kind of our our third person that's been kind enough to come and visit, so that's great. I suppose what tweaked my interest to kind of have a chat to you today was your post, I can't remember if it was LinkedIn or Twitter, about going from being a product owner that works for customers in some form of contract or employee to help them, to moving to be the product owner of your company and what you're doing and what your passion is. And how that was different. So I suppose to get started, what we tend to do is say to people, tell us about you, your life, how did you get introduced to Agile, and how did you kind of get where you were, and, you know, how did it all happen for you?

Yeah, kia ora for that. So I've been in tech for about 18 years. My kids are about to turn 21. I'm not sure how I feel about that one. And so I am Started way back in, I don't know, 1998 or something like that, 1999, who knows. But effectively, the internet taught me a whole heap of the basis of what I loved about tech and the magic of creating using code. So, you know, learning HTML, JavaScript, that whole bit. And then I realized that design was great and I really sucked at it, so I switched back to coding.

Because code can be ugly, right? Yeah.

At that point in time, if it worked.

Yep, if it worked.

And so, you know, because I'm quite a chatty wee thing, I ended up being a project manager and a business analyst because I like talking to people. And that's pretty much the introduction into Agile because I was working at Ministry of Social Development as a digital business analyst and they went Agile. And it was a long time ago. I think I worked there about 10 years ago maybe. And we had our first crack at it where the BAs we were leading delivery. And because, you know, we knew the product that we had to build, and effectively we had two devs that did the testing between each other and the build, and then did the pushes as well. And so that was our first real kick into Agile. And so I've been around for a long time, and I've pretty much seen everything you could possibly see, then built almost everything you could possibly build. And I just, I The thing that I liked about Agile versus the whole traditional thing is the personal relationships. That whole, you're not creating a product, you're creating a team. And you're just giving them the inspiration and setting up that vision in order to hit it. And you know, that whole celebratory knowing that you're doing good, knowing that you're working well, knowing that you're hitting these things and that you're a badass. That's something, the gift that you can give to your team. And that's why I talk about that whole thing about confessions of a product owner turned CEO, because in my mind there's not much difference, truth be told.

So how do you find that where, you know, in what we learn from Agile is you become a Product Owner and you have a bunch of stakeholders, but the stakeholders typically are internal, right? Normally you're the, you know, the horrible term is one throat to choke, but you're the person that the team talk to for trade-off decisions and for an understanding of where the value might be for the organization, and then you're engaging with what we call stakeholders, which are typically business people, senior management, those kind of things. In my experience, it's very rare for the Product Owner to actually be talking to the end customer, right? So for you, when you're the CEO, right, your stakeholders may be some shareholders and those kind of people, but your stakeholders are actually the person that gets the value. How do you find that transition? Was it a transition, or was it just natural? How did that work for you?

For me, because I'm really naughty when I'm a product owner, so I'll go out and find my customer because I can't test anything without building something if I don't talk to them first. Do you know what I mean? And I have a real problem with being told what to do, especially when someone thinks that they are the customer. I want to test that theory first. And so when we got the chance to, so we built sensors that measure temperature and humidity. We got them built in New Zealand. We had them built modular. So that people could put them together themselves. And then we took them out to the community. We thought we were prepped.

Yep.

Because these kits were really simple. We tested them with my kids, see? And they could put it together really easily. But I was blinded by my own privilege, let's say. So my kids have grown up with tech. They've grown up with screwdrivers. They've grown up with this stuff. And here I was with a bunch of 8, adults who were really scared. They were really encouraged and they really wanted to do it, but they were hella scared. They thought they might break things. They thought they didn't know how to use a screwdriver. They thought, you know, just basic things like, is it going to electrify me? And so having to pare it right back to basics of lefty loosey, righty tighty for the screwdriver, and you can't get electric shock from AA batteries, especially if they're not in.

Did you do the tongue trick? Well, that kind of scares them a little bit because it'll be a short jump.

Come on, Shane, encouragement.

Not social experiments.

Well, touch this on yourself, look.

Yeah.

Just ignore the little burn marks on my tongue from where I've done it 100 times.

Yeah. And so it was that same thing that you would do with your regular development team, right? You need to make them feel comfortable, you need to make them feel trust. And so spending time and doing it at a community centre where they're all familiar with the area, feeding them letting them bring their kids and providing childcare, and then like just having a tutu, just like, yes, our screwdrivers work like this. Yes, you can just pull out the batteries, don't put them in yet, we'll put it together and then we'll test it. Just basic, pare it right back before you start the actual build.

So true definition of minimum viable, right?

Yeah.

So you talked about then about you were a naughty product owner. Yeah. Because you actually talk to the end user to see what the value might be.

Yeah.

Which actually is what we're meant to do as product owners. Yes. So do you find that when we work in a commercial world or an organizational kind of sense where we have an inferred hierarchy already, I mean, I talk about business agility versus agile delivery. So we were in an organization that isn't actually doesn't have agility as a business, they have some incumbent behaviors that we have to deal with. Do you find that they do tend to create internal stakeholders as proxy rather than dealing with the true end user that gets value?

Yes, absolutely. And you know, it's a carryover, right? And because people feel fear, so it's a completely human condition to feel like this because, you know, you're being paid to do a thing and this is how you used to do it, this is how your manager is expects you to do it, and this is how they are used to receiving whatever it is that you're giving them. And so to step out of that, and even though all of the documentation training states that you need to talk to your end user, it's really hard for people to make that step. And so that's why, as a contracting product owner, I'd be bad and I'd just do it. Right. Because people will imitate if they see someone else do it first. And especially, and it means that, because as a contractor you are used to getting balled out, right? That's part of your role and you're there to make it go faster, get it done, and clean it up as much as you possibly can. And so as part of that role, you know that there are going to be certain behaviors that you'll display that perhaps your stakeholders will not like, and that's okay with me.

So what we find is, when we talk about Scrum Masters and Agile Coaches, right, is the whole thing now where, you know, people were— I was reading some stuff on Twitter and some of the posts around, you know, to be an Agile coach, you actually have to have done it for a few years, right? So, like, you don't coach a soccer team, I think they said, without actually knowing how to play soccer. And we've had a little bit of a problem now where you can do a 2-day course and be a Scrum Master or a coach. But one of the things that Blair and I did when we worked together was We were lucky enough to bring in a couple of different product owners over time, and we learned that each product owner was different, and we kind of experimented ourselves with how do we bring a product owner on and kind of teach them what product ownership means and make them safe. So if you kind of think of it from a coaching point of view, have you got any views on how if you were coaching a product owner on how to be a good product owner, but that product owner was an incumbent. They weren't a contractor that, you know, were disposable.

Yeah, they've got to live with their decisions, right?

To a degree, yeah. You got any ideas on what we should do with making them safe, but also helping them get outside their comfort box and growing?

Yeah, and so I've done this before, because as a contractor, you should be replacing yourself. You should never be a contracting product owner for a specific product for too long. Because you're going to leave, and it's unfair for the team or the business and the product for you to just ditch. And so generally, I always try to pick up at least one person that's already in the team and get them to do the role. Now, this doesn't work all the time, but when I do that, what I end up doing is allowing the person that's coming in to do all the day-to-day. So prioritizations, we talk it through, things like that, backlog, strategy, things like that, how our sprints are going to look. But my job is actually to prep the environment for them. So that means going and talking to their manager, saying, hey, they're going to be doing this, this, and this. All those things that you like about me, they're going to be doing too. But remember, you didn't like it when I first started doing it. And so when you see these behaviors from this person, and it's going to look like this, you can't give them grief for it because effectively you're asking them to build you this product with these value— these values, and then you're saying no, So let him do his job.

Yeah, and I find myself doing that as a Scrum Master, is actually being the Product Owner coach. So it's interesting to hear, you know, how a contract Product Owner can come into a business and do that role. That's something I'll think about.

Yeah, because it is that whole thing of when, as a business, when you're building a product, you're putting a shit ton of money, right, into getting this up and running, the team up and running, the team costs. A lot just by themselves. And so when you start to, when you bring in a contract product owner, you need to trust them straight away, which means they need a large amount of experience, ready to hit the ground, and they should be completely okay with conflict. But at the same time, people get comfortable with people like myself, and then they don't want you to leave.

Yeah, because you're a good product owner, right? You're delivering the value, and the team trusts you, and you're engaging with the right stakeholders, and therefore We know when you change a member of an Agile team, the team lose velocity, right? They regress. So if you're there and you're doing an awesome job, why would they replace you? But that's the problem. I hadn't actually thought about the contract problem, right? Is that when you're a contractor, you don't, you're not planning to be there for 5 years and you probably don't want to be there for 5 years. It's part of why you contract.

Yeah, I guess I was thinking, would part of your coming on board, the scope should be to actually do that training.

Absolutely, replace by the—

yeah.

So they could say 10% is actually being able for me to walk out after X amount of months or years and have that ready replacement.

Yeah, and because the product owners are like managing up, they should have time with the stakeholders, like actual time, because they need to reintroduce the new incumbent too, right? And then set into place the process as to how they're going to push the stakeholders, because a PO should be doing that.

Yeah, and is this product owner, is that just one of their hats, the person that you're training up? Is it something they have to juggle with their everyday existence?

Yeah, for, I think, I think I might have had him for about a month, for the first couple of months until we could get a replacement, yeah.

Yeah, because I find the struggle is to actually get that product owner with enough time to actually get them to do their job, you know, so that I don't end up having to do the backlog grooming.

I know that whole— there's a massive problem with that. That's why, yeah, whenever I come across this, even though usually I'm in full-time, um, when I see it in other teams, I have to go and talk to someone because I'm like, you're putting all this money and effort and time and you've got a half-pie product owner, and it's not their fault. You've got to clear their plate. This is what's going to happen if you don't.

Because they're not empowering that person to be successful, right?

Exactly.

And that's, for me, that's one of the techniques I try, but I find it hard and I find it fails multiple times, where I say, we all agree, and anything you read, the Product Owner is one of the most important parts of the team. So are you really going to commit to 7 people spending $200,000 a month in salaries and not give a person who's going to tell them what's important? Really, is that the conversation we're going to have? But the answer often is they're too busy, or did you find that you often get given a person that's available but probably isn't the best product owner?

Absolutely.

Did you find that a lot?

Yep. So I've seen it like multiple ways. So I've also been product owner by proxy, and I've also been a BA in a product team where the Product Owner wasn't available and it gets skewy. So you can just go through your sprints, your previous sprints, look at the functionality that we've outputted and then try and put that against the value that you're supposed to be delivering and you can see it's heinous and it's confused. The team will be confused, the outputs will be confused, you won't actually hit any of your themes or goals or you will and it will take a long amount, large amount of time because there's no consistency in the vision. You can pretty much go through a good 2 months previous, 3 months if you've got it, worth of functionality out of that team. You can give them a number of how much money that they've wasted. Because all you have to do is line it up with the vision, right?

So, when you walk into an environment where the customer wants to do product ownership by proxy, and so, how hard-ass do you get, right? Do you go, 'No product owner, I'm not doing it,' or do you go, 'I'll do it for a while to show you some metrics of why this is important, and then if you don't make a change, I'm not doing it,' or do you— I mean, because I struggle with this, right? I struggle with the team are great, the customer is trying to achieve something cool, we should be able to iterate and learn, and but—

Yeah.

Or do I just, you know, a lot of times you hear people say just walk away. No product owner, no Brodie, right? No, no, no, no me.

Yeah.

What do you think?

So yeah, walk away. That's— because I've done it too many times, then you're responsible for a half-assed product, aren't you?

But you would give them a period of time where you coach them on what good looks like and then— okay.

And say— because, you know, the thing about being a product owner is that, in my opinion, you should only PO something that you understand. And I've been given products that are, like, way out in left field and been the product owner by proxy, that means I'm going to make a bad decision. It's just innate in the job. I don't know enough about the domain in order to call good decisions.

So one of the things we do in the data space, or the things that I try, is, and I know it's against some of the rules, is often we will engage, and there will be a product owner that shows all the behaviors of a product owner, right? So they're available to the project team at least 50% of their time, and they have good relationships with the key stakeholders and can make the value decisions and can get us unblocked when we need to, and they love the product and they see the value and they have a vision. So they have all those behaviors, but because we're in a data or an analytics space, there's quite a lot of technical decisions that need to be made amongst the team, and the team's not yet at a stage where they can describe the trade-off decisions to the Product Owner in a way they understand, right? Because often we're working with quite technical teams, and we're not doing what I call web apps, where, you know, there's a screen and database, and it's a little bit easier to show iterations faster. So we will often introduce a feature owner, which actually typically comes out of a BA pool, but we have to be very careful about the behavior of the BA, where we say, right, you're working for the Product Owner to explain the trade-off decisions the team are giving you. You're not a proxy, in that you cannot make the decision, the Product Owner still makes the decision, but you're helping them, you're the Babelfish, right, you're helping them understand some of the words, you know, when you hear, oh, we want to do an EC2 type Type 2 dimension, you're explaining to them in a way what that feature means. And when the team are giving you a trade-off decision which involves some technical debt, the feature owner is making sure that the product owner is clear on what that debt means. Because otherwise we often, you know, we can take the short path or the long path, and there's a cost there. And sometimes the product owner— do you find that, have you ever tried that technique, and did it work for you?

So I was working on APIs. And so APIs in themselves are quite simple, right? It's the underlying services that are difficult, especially if they're going into, say, legacy systems. And so I have no understanding of service layers or APIs.

You mean then, you do now.

Oh yeah. Now.

Try to forget, but it's in your groups. Yep.

That actually, that work actually fed into Whare Hauora, so I'm very grateful for that. And so we had a BA and we also had a very incredibly technical team. And so usually I can't, I wouldn't be able to keep up with them, and even though I get it-ish. So in that role, my job was to make the calls, right? So all you need really is to be clear on who's responsible for those calls, 'cause a lot of people wanna make the call, but they don't wanna be responsible for it, right? And for this particular product, everyone wanted to make the call. And so my BA, I like to think of them as advisors. And so the team would give an outline of what they think might be happening, and then they would go off and go and do the detailed digging, right? Because as a product owner, you usually don't have time for this because you're trying to hit the vision or figure it out of what comes next. And so they were like, my Tuaiseach or whatever, because I could ask a question and if we didn't know between all of us, they could go and find it. Or I would just take the hit because there are some things that you don't know will happen until you do it. And then if you're— and then we just call a spike, right? And just say, look, I'm happy to take this responsibility. Let the stakeholders know if there's any fallout, which there usually isn't because it's not like it's live, right? And then figure it out, because that's how you're going to have to do it at some points in time, because there are some products that you're going to build that no one has ever done before.

So just give them the screwdriver and see what happens, and then do it from there.

A lot of the time in the BI world, that is the case. It's green fields, we haven't done this stuff before, so it's really hard to actually timebox it properly.

Yeah, that's what we've found. Yeah, as long as you know what you're trying to get out of it, maybe it's a metric or analytics or something, or you want something to work, or you're trying to just output a thing, you just got to check that everything is there for that output to happen first, and that's by this.

So one of the other things we found is we brought in a different product owner, right? So one of the things that I really loved about it was, I think your comment was, you need somebody that understands it and is in that domain, and you're not bringing in somebody that's learning about, yeah, they're learning a lot of things about being a product owner, but the thing we're producing, they understand what that data is and why it's used. And that was great, but the challenge with that often was as you changed what you were delivering, you got new product owners, right? So you finished training, working with a product owner and coaching them to be successful, and then you get the next person and you have to rinse and repeat. And we still, I think, we always struggled with a process for that. But the other thing we struggled with was making them safe, right? So I think that was because one of the things I picked up from you just then was they're going to learn, right, and they need a safe place to go to ask the dumb question. And yes, you can do that within the team in the retrospective, and it's a safe team, but actually the Product Owner is kind of outside the team to a degree. We always thought about having a framework where the previous Product Owner was the safe coffee buddy of the new one, where it was is if you're a new product owner, this person's done the role, if you've got any questions that you don't want to ask the team or ask the coach because you just don't feel comfortable, go have a coffee with them and they're going to tell you what they did. Well, they're going to tell you they haven't dealt with that and then we can do it.

So we've kind of got that sort of— Yeah, we've got that. Is that working? It is, just we're getting more and more product owners in that don't have that knowledge of the product. You know, there's a lot of busyness, a lot of running around. So yes, we do rely on that companionship and I push it. Yeah. And we've got a couple of favorites that we use for that.

So people who are good mentors and good coaches.

Yeah, the ones that have really worked well in our team.

Yeah.

Did you, I mean, have you found any other ways of making the new new Product Owner feel safe, given that everything's going to be uncomfortable for them?

Yeah, but effectively, that's what I did.

Okay.

Yeah, and it is time, because even if they're new, they don't know the product or the domain, they can learn that over time, right? And the team is still your central repository of knowledge. But at the same time, no one knows personalities, right? Especially stakeholder personalities. And when you have to say, change tact, give some bad news, things like that. The previous product owner knows those personalities a whole heap better than anyone else will. And so that's why I find it really hard to leave my teams, and that's also why even when I've started a new job, they've still called me and we've talked over the phone about how we've got to do this and what their how to figure it out, the tactics for it.

So I suppose one thing I found with the coaching that I've been doing for the last few years is I'll often, so I'll come into a customer and they'll go, got this data team or this analytics team, let's be agile. And we talk about the journey and that's good because there's an expectation of, you know, we're going to fail to begin with, the team are going to learn. And so with the development team, it's great, right, we're working with them and we're helping them be successful and then typically we're coaching a Scrum Master or the Scrum Master's helping me coach the team because they're a contract Scrum Master, all that's great, but I don't typically get to coach the Product Owner or I'm not coaching the Product Owner myself at the moment, right, so I'm sitting here going, talking to you, going holy baloney, there's a whole area of coaching that I'm just not doing and When I worked with Blair, he just naturally started coaching the product owners, but sometimes people aren't as confident as Blair was in picking that role up. So would you recommend that actually when somebody's taking their team on this journey, they should actually have both an Agile coach and a product owner coach, and that there's now a coaching pod that's taking and specializing in dealing with the areas that they're good at?

Yeah, absolutely, because it's a dearth that I've found. So I've seen many product owners burn just because they've got no one that's teaching them. Everyone goes, "Oh, just do the course." Courses are great for basics of how to do the thing, right? But that is still a tick box method in my opinion. No one teaches you, like, especially in digital, right? There are strategies that product owners use in order to get these sprints out so that they don't block themselves. Lots of Product Owners don't realize that they can block themselves, and only another Product Owner can teach them that, or someone who's done it before, right? And I've very rarely seen Product Owner trainers or mentors. Very, very rarely.

Yeah, it's a new concept to me. I mean, in our organization, the Scrum Master or the Agile Coach brings that that coaching aspect to the product owner.

Yeah, I think it's that whole mindset of, "Oh yeah, we've got a project manager," and then switch it over to a product owner and they'll just keep doing the same job.

Yeah, and look, I mean, anybody that has worked with me in the past or anybody that's going to listen to these podcasts in the future is going to hear me bang on about patterns, right? Yeah. And so I look at it and I go, I was doing some work with a customer a while ago and identified a pattern called value stream mapping. Mapping, right? And I was like, oh, this looks kind of like something that I was doing, a pattern I was doing, but I wasn't doing particularly well. And then I started researching Value Stream Mapping, and then I was like, oh dear, this is a whole thing, right? This is, you know, this is really valuable, but there's a whole terminology, there's a whole facilitation process. It's not a do a half-day course and you get Value Stream Mappers. And it's definitely not do a half-day course, you're a great Value Stream Mapper, and you can take a room, facilitate them, and coach them on how to do Value Stream Mapping, right? And so then I kind of went, right, that's a problem for me, because the Value Stream Mapping would be a great tool for a Product Owner to use, or be helped to use at the right time. And now I'm going, okay, what other tools are out there for Product Owners that I've never thought about, because I haven't, I'm not a a mature Product Owner Coach. And I'm probably like you, I'm probably a bad Product Owner because I know too much and I'm like, "Yeah, let's do that." And it's like, "Why are we doing that?" "I don't know, just do it." Okay, let me step back again. Retro for myself. Yeah, so have you ever seen though a pod of a Product Owner Coach and an Agile or a Scrum Master Coach work together to help a team?

No. I've been brought in to other teams to support them because they've been newly spun up. They've got a Scrum Master, they've got an Agile Coach, and because product ownership is such a mystery, because it is, if we think about the magic that goes into creating a product, because the other tools that I would suggest for a product owner, if you're looking to be one, is that storytelling. Storytelling, being able to inspire the shit out of your team, as well as connect yourself to your stakeholders. So your stakeholders will give you a vision, but if you can't relate it back to what your team is doing and give them something plausible and something that they can get behind in order for them to champion you, then, well, it's going to be hard. Because when budget comes around, who's going to speak for you?

Yep.

And you need to make them remember you. And so the other thing is straight-up leadership. So I don't know how or where you get these tools from, but understanding where you fit within the team, because I know we learned that whole definition of what a Product Owner is, but knowing that you're the shit umbrella, that anything that comes down from the stakeholders that is shit, you are there to catch it.

Yeah, I use the term umbrella all the time. Sometimes I use the first word.

Sorry, I'm a swearer.

No, no, but depending on the culture of the customer and that, yeah, you're right, you are a shit umbrella, right? You're there to protect the team and allow the team to be successful, and often you don't have so many people protecting you.

Do you find you're tag-teaming that role with the Scrum Master as well?

Yeah, I had one Scrum Master and I love her. But she won't, she just won't stay with me. No.

I wonder why? No, no, no, no, because she's a badass product owner as well. Okay. Where's my product? Where's my product? We're shipping. Ah, the penny's dropped.

Yeah. And so me and her, we were an army of two in my mind. Every damn time we were together in a team, we would hammer it out.

And just leave the development team to just do their job.

Yeah, do their thing. Because that was our job, to make it simpler and easier, that environment, like change and release, getting that out, making it as simple and easy for them as possible, taking away all of the noise, like, you know, how it can get in workplaces with political stuff and emotional stuff.

What are you talking about?

Yeah.

No, never. That's really interesting because we always talk about, you know, forming normal storming. And I went to a presentation the other day, one of the meetups, where one of the people that founded one of the Agile consulting companies in Wellington that actually do really good work, he was saying, one of the points that came out of his talk that I really stuck in my head was, being an Agile coach is incredibly lonely because you're typically working in an organization in a role where it's just you. Now, there's some people overseas that I've talked I talk to off and on. Lynn Winterbottom is one of them, and she's been lucky enough to be in organizations where actually there's multiple Agile coaches, and what she said worked really well was they used to have lunch together every day if they could make it. It was an informal conversation about how's it going, same customer, and that was lovely. I like, ah, that's cool. But those two things kind of came back to me and said, actually, as an Agile coach, how do I make myself better without talking to people, and what you've just said kind of makes me think, if we talk about, you know, the point of Agile is creating a team that work together, and we know that the team will get good over time. As soon as we break a member of the team, the team regress. But we don't treat that for the coaching side, right? We don't go, hey, actually, this Product Owner Coach, the Scrum Master, or Scrum Master Coach, and this Agile Coach, or just two of us depending on how good we are, we don't form a team where we understand each other where we know each other's personalities, where we can just go, "Yep, that's you. Can you go and have that conversation please, because I can't at the moment." We don't do that. In New Zealand I don't see it, maybe overseas we do.

We don't do it. Informally maybe, and to a little, a small degree, but sounds promising.

Yeah, because as soon as I can pay her enough, I'm dragging her out of whatever damn contract she's got and we're going to because that's what we want to do as a peer. Because I know that right now I'm CEO of Whare Hauora, but I'd rather be working with teams, do you know what I mean? The creation and the build, that's where the magic is for me. And I don't like that whole apātea management stuff. To me, it's just product. And so, you know, finding that other person, it's just like finding co-founders, that click, because we know that we can make any team run. And run hard and they'll like it. And that's the whole purpose of this thing.

And you find that's the buzz, right? Is watching a team grow, watch a team loving what they're doing, enjoying it, delivering, being happy sometimes. Yeah.

But delivering's the key, isn't it?

It is. And it's that whole autonomy. The team, you've got to make it so that the team can build and release as they please, when they please.

I liken it to a team sport because you've all got the same common goal. There might be superstars, there might be plotters, but if you win, then it's everyone, right? Yeah, for sure.

Did you find that? I mean, you know, my presentation I did a while ago, I brought up the, you know, if you picked out every superstar player for a football team across the world and then you put them on a field against a team that have played together for a long time, the team that played together for a long time are going to kick your ass, typically, because you've got a team of superstars but they haven't gelled, right? Do you find that as well? That, is there a concept of a superstar product owner that actually will make it worse because they're the superstar, they're the hero, and they're not actually, they're not a servant leader like a Scrum Master is, but they're not creating that environment.

Yeah, they're more dictatorial, maybe, Yeah, yes, I've seen it quite a few times, especially so those that like to chase the kudos, because when you're in charge of product, you get to be the head, right? And so all the claps are for you. And so you find that some product owners aren't available because they are chasing that. And I'm like, bro, nah, get back and do your job.

Get in behind me.

Because, you know, the team sees it. They're not stupid. They know that, you know, they're the ones that are actually producing, and that you are supposed to be there making it as easy as possible for them to produce. And so, yeah, I very much do not like it.

So demo days.

Yeah, demo days.

Oh God.

That brings us on to the, you know, the showcase.

Yeah.

And that's a good place to really share the the team's good work and put them in the limelight. Some of them don't like it. Some of them—

yeah, look, this is what I struggle with, right? So again, everything I read, everything I learn says the Product Owner does the demo. Because that's a definition of done-dad, right? Is they can do it. And I don't know, in my head I go, because I work in the data and analytics space, that's never possible. I'm probably opting out. But so, no?

Yeah, I don't like to do the demo. Because I get enough face time, right? And by the time demo rolls around, stakeholders should know exactly what's going on. The team should know what's going on because they're the ones that built it. And I reckon that whoever built the functionality should do the demo. They know it better than you do, say, especially if it's like services for an API. And yeah, I just really shy away from that because that whole kudos thing should go where it's supposed to go, and that's the team.

Right, so what we do is I introduce the demo day and, you know, put the whole package together as Scrum Master. And I find that the Product Owner role in our organization is sitting next to their stakeholders, you know, and selling it to them. So it's like, hey, look at this, this is what we've been up to, and it's a bit of a showcase for them, and it's really their way of saying, hey, I haven't been wasting the last 3 weeks, this is what we've produced. And, you know, it's a good sales tool for them.

And actually, yeah, one of the things I teach, I kind of talk to teams about is, I don't use the word demo if I can help it, I use the word proof of day. So what we find with data is because we can't create a small database object in a screen, we probably should be able to, but I've never managed to achieve that with a team yet where, you know, an iteration or a release train where we can really quickly build a thing that has high value and demo it, right? So there's often, like the APIs, there's lots of plumbing and code that has massive value but isn't sexy, right? And so what I talk about is prove it, prove what you did, right? Prove that it's done, or done done. Prove that it runs, prove you've documented it, because we document in Agile. So, and then, like, the team I'm working with now, you know, the team are great, and the delivery team. We've got a Scrum Master that we're helping coach up to be an internal Scrum Master. We are going to get a Product Owner, and what I've said is, look, in the private sessions, you know, when we start letting the rest of the business come in, because I tend to say to the team, let's run a couple of private sessions where you talk to yourselves. Yeah, so you're learning the process, right? You're being comfortable that you know how to stand up and show what you did, and you learn the mistakes that if you don't actually plan your private session, it's going to go badly. It's not going to be an hour, it'll be 3 hours, and don't do that. But then it's kind of, well, the Scrum Master can introduce the process, right, and what the private session's about, because as Ceremony Master, that's their role. The product owner can stand up and talk about the value they asked the team to deliver and why it was valuable, and then the team show you how to deliver it. But everything I read says that's wrong, right? Everything I read and everything you listen to says— and is that, do you think, because agile started out really as doing apps, web apps, where the product owner—

where there is a UI.

Definition of was click and it worked, and that was actually an acceptance test.

Yeah, I, you know, I just think that as part of our learnings that— so when you click a button and it works, then sure, it meets your acceptance criteria, kind of. But where does it say, because I clicked that button and now it works 3% faster, we now get more customers through the workflow? Do you know what I mean? You've got to put that functionality into context. And so So that's why when I talk about the Product Owner not showing functionality, that's when they should be having those talks. "Hey, this part is going towards this and this part is going towards that." Because the thing about function, especially when it's in data or something that doesn't have a UI, is that it's very easy to have your stakeholders on one end and your team on the other. And so you really need to connect them, and that's what you provide the context for.

And we've got to be careful because, yeah, we talk about thin slice, right? We talk about getting at least one number. I mean, Sam, when we talked to him the other day, he said, you know, he's always said, even if it's just a count of customers, right, and the numbers, just a number on some form of dashboard or UI, that's got value, right? It's proven value in terms of we've got all the way through and it's a number that is now locked in as a 10 digestible number. But when we start, we tend to pipeline, right? We tend to, we have a little bit of plumbing, hopefully not a 6-month iteration zero, but there's always, yeah, we're teaching the team that actually they can do all those steps in one go, in one iteration, and that's hard for some reason. So that's okay, but yeah, you're okay, that helps me to put that in context because it's one that, you know, you look at what you do and you go, maybe I'm doing this wrong.

Yeah, I'm not very good at it. We don't go through the environment for that thin slice and have that, that bell or whistle at the end.

Yeah, yeah, it can be hard, especially if you've come from a, you know, if you're transitioning and you've come from a Big Bang approach, it can be really hard to get them to think, oh no, you have to go through all of your servers and then get to, and then talking to them about automated testing and things like that on top of it, it can all seem a bit bit too much, and they'll go, "But this change is a one-pointer. Now you've turned it into a five." It's like, yeah, because that's how we get end-to-end.

In fact, we'll spend more time defining the acceptance criteria and the automated tests than we will actually writing the piece of code. But that's okay, because that makes us safe later. There's no technical debt. The code fits. It can be maintained. It's automated. There's a whole lot of other benefits outside that one area that it gives us. Absolutely.

This is also why I don't like contract product owners, is because if you've got 6 months, it's very easy for you to go, "Yeah, cheap way, cheap way, cheap way," and then leave all the technical debt to after you've gone. It's very easy to do that.

Yep, take all the glory.

Yeah.

The same as, this is a conversation I was having the other day, is I used to think about the build team being Scrum and the BAU team being Kanban, right? And then what I quickly learned over time was the build team would hand something over to the BAU team that had debt. The debt may or may not have been visible. When we said to the build team, actually, you've got to maintain this puppy, and we really want to focus on BAU bleed, because after you've done a few releases, 80% of of your time cannot be maintaining that production release.

Absolutely.

So you're going to have to automate because otherwise, in terms of what we're looking to achieve, you're going to fail because you'll be a u-bleed or production will fail at the right time that you're trying to finish that last feature and test it so that it's ready for release. But again, that's a challenge, right? Most organizations are set up for project builds and hands over. Yeah. I never thought about it in that way, that a contract product owner has a bunch of success criteria, which is not coaching a team.

Yep.

So actually putting that back, I mean, for me, for closing it out, I kind of think about, would we not then say that when you bring on a product owner as not a member of the team or the organization, actually we need some acceptance criteria and some definition are done, and yes, it's that a product was created, but actually it's also that the organization has a way of creating and mentoring product owners, and we leave something that's a way of working, right? It's not just a technical or a project thing.

Yeah, and you know, that's why I really favor the approach of giving the product owner someone to hand off to that is permanent. Because they are most likely to take over operations or any other variations.

And the same could be said for Scrum Master if you have a contractor in as well.

Yep.

I struggle with that because often Scrum Master's a role that a contractor fills really well, and the acceptance criteria is, is be the Scrum Master and make the team successful, not create a Scrum Master culture and a way of fostering Scrum Masters and then exit. And I struggle with that one, right? For me, for the same reason.

Yeah, it's just, you know, because I'm old and gone through quite a few Scrum Masters.

Hence you having a cohort of one Scrum Master that you want to work with from now on.

Pretty much.

They can survive you.

Hey, I'm really good. Ask my teams. That's—

I meant to say that Scrum Master support group. They meet every Tuesday.

Actually, one of my clients I once did do that, but—

Sort of retrospective, right?

The after-here. But the thing that I have seen happen is that you can get, like, you can see it on some job descriptions now, where you'll get Scrum Master/Project Manager. Yes.

Yeah.

All the time.

Yeah.

Or Scrum Master/Agile Coach.

Yes.

I can coach a Scrum Master, but you would never want me as a Scrum Master, if that makes sense.

Yeah, and to me, it's just the difference in levels, you know, the difference in levels is quite huge. And it's very different approaches, it's like, mm. But yeah, because you know, the whole Scrum Master, Project Manager, which I've come across too many times, is that who makes the calls? Who makes the calls and who's responsible? And, you know, the thing where I've had it happen where, as a Product Owner and you get a new Scrum Master, you tend to step back just to let them do their thing and give them space. But then, then, well, one time I had a Scrum Master stack the prioritization for the backlog and then say the team did it.

Oh, okay. Yeah, so when you have this person, that person. As a way of setting some safe places to go. I've never had the, "You will not lie," as that person, but, "Don't be that guy," or, "Don't be that girl." Yeah.

And so we had, we clashed a lot. Well, conflict is completely normal for me, right? And it should be for product owners.

In the right way.

Yes, in the nicest possible way. And, well, it just didn't work. And the outcome was that, yes, our reports looked okay, but if you dug and figured out exactly how much functionality met the vision or the goals that we were supposed to be hitting, didn't occur. And then you had hands-off where someone would go, "Hey, dear, why is this in the backlog? What is it?" And I'll be like, I don't know. And then of course I get my butt handed to me and then I go to my team and go, what's this?

Oh, would you go to the Scrum Master or would you go to the team?

Well, we have that—

That would be a retrospective type item, wouldn't it?

Go to the team and then when the team says the Scrum Master did it, it's like, holy bananas, we've got a problem here and how do we fix it?

Yeah. And we did. My team was very strong. Strong and capable. And so we talked a lot and then just no change occurred. And so the only point that a PO can do in that instance is hit up the Scrum Master. And it still didn't work.

But again, it's part of the agile process, right? Yeah. As retrospective tells us how we need to change our behavior because something's happening that we need to get better at, we say that actually we're going to focus on that, and if over time we don't focus on it, or a team member doesn't focus on it, and they're not making that change— because often people don't know, you come from a background where you're not used to it, you don't know you're doing that, right? But once it's pointed out to you and you're helped, if you don't make that change, and what I say to teams is, you know, there is a stage we get where the team will vote somebody off the island. It's the role of the coach and the Scrum Master and the Product Owner to make sure that that's a safe process. Actually, it's not the Product Owner, sorry, the coach and the Scrum Master, it's their role to make sure that's a safe process and people can change their behavior in the right way. But at some stage, and I've seen it before, you know, the team will go, this team member is costing us more time and they're not changing and we can't keep investing. And that's really interesting Yeah. That happens, but as long as it's done in the right way, it is what it is, right?

It is. And so I've been on both ends where I've, on behalf of the team or with the team, I've asked someone, is there somewhere else that you would rather be? Let me make those introductions for you. Let me see what we can do for you. And as you know, because you know, sometimes data isn't the thing for that person, and there's nothing wrong with that from my point of view. It's when you just go, "Nah, you're out. That's wrong." The other way that I've seen it, especially in that Scrum Master/Project Manager, is that we didn't know that he was a Project Manager. And so, as a team, we didn't realize, and he didn't tell us until we went over his head and went to his manager. That's when we realized.

Did he hide his Gantt chart from you?

Well, it was a Actually, seeing the start of a game chart that went, "Make me that." Oh, shit.

And then having the release promises, right?

Yes.

The team hasn't even estimated it or even publicized it.

And it's 6 months out. And you're like, "We only go 2 months ahead." I mean, 2 sprints ahead is like, "Come on." And so once that was known, then it was easier.

I think you're talking to Blair the right language at the moment with his current challenge. But the other thing I find, Did you find that, that often people will opt off the island themselves?

Yes.

They will go, because they've been put in this team, right? Often, you know, often teams are formed without— you've been placed in that team rather than put your hand up to say, I really want to do this thing. And they look at it and they go, look, I'm sorry, you guys are rocking this, but it's not for me. And I really— I know it's bad to say, but I don't want to do this. And that's okay. They opt It's very rare we get to the person having to be removed off the island. They often get their own boat, and that's okay.

Yeah, I really enjoy— because, you know, I always try to ensure that my team members know, if you are not happy, let me know. I mean, if there isn't something that I can change within the team or some way that I can help you, because you are a part of this family that I've created. And to not care about your family who you're trying to feed, right? That's what it comes down to, is like really crap. And so as a product owner and a leader, we have to care about our people like that. And when they are unhappy, then it's not their fault that they make everyone else unhappy too. And so supporting them into finding other work or other places, other teams is just what we should do because that's a good human being thing to do. I do.

In terms of the length of this iteration, it's good. I think we'd love to have you back another time as well, because to find somebody that's got such experience and such cool stories about real life, you know, been there, done that, got the scars. But just before we close out, look, I know you're doing this really cool stuff from a social good point of view. I haven't actually briefed Blair on any of it. Give us a couple minutes, just tell us what you're doing because I saw you at BNZ Startup when you did that pitch and you rocked it and those kind of things, you know, I often say to people I'd rather work with organizations where as well as creating a team we're creating some form of change in the world apart from just making a corporation more money.

Yeah.

Sometimes that's what we have to do, but if we can do both and that's cool, and that's what you're doing. Tell us about it.

Sure, so I'm Kai Whakahaire of Whare Hauora. Kai Whakahaire meaning CEO, and Whare Hauora is a charity. We're probably going to move into social entrepreneur— enterprise-ness, but effectively we build sensors that measure the temperature and humidity in rooms and homes, and then we dashboard that data so that we can compare it against the World Health Organization recommendations for healthy homes and will tell you if your home is making you sick. So there's a range of temperatures from, um, if your home is 16 degrees or under for long periods of time, you have a higher incidence of asthma or eczema, um, because dust mite population and mold growth occurs at 16 degrees or under. And for humidity, 72— sorry, I've forgotten my numbers. No, 70 is bad. 70 and up is bad, um, and encourages that kind of growth. But we're starting to look at mental health now too, because in winter, if you spend 90% of your time in your home and it's cold and damp, and you have previous anxiety or depression, then that's going to increase the issues that you're probably going to see. And so all we're doing really is telling you what's going on in your home and letting you know how it's affecting you.

Cool. So, and hopefully people take action from that, right?

Yeah.

They've got some choices to make and hopefully they're able to make a change that will give them a better outcome and they're in control of that as much as they can be.

Yeah, and we've partnered with Community Energy Network that looks after Sustainability Trust, so it means that they'll be able to supply people with sensors and hopefully get some funding, we'll support them to do that, so that those in low socioeconomic areas or can't afford one because we've brought it down to about $110 a kit, hopefully. I don't know what freight or GST costs at the moment. And because all we want really is to say, okay, my home is cold and damp, um, how do I heat it in a way that's more sustainable for me and that won't cost the earth? Or how do I get simple steps that will increase the amount of heat that's kept kept in my home, and how, and you know, just pushing people off to those organizations that can help them do that.

So if somebody's listening and they want to help you do some of this good stuff, how do they get hold of you? How do they contact you to see how they can help?

You can email me on heria@wharehaura.nz or go and visit the website of wharehaura.nz.

Yeah, cool. All right, well, I haven't figured out how we put extra information on the podcast when I publish one, but I'll— once I work that out, we'll have those links on there so anybody that wants to get a hold of you can. Excellent. Hey, look, thank you. Really appreciate your time.

You're welcome.

Awesome.

You've been listening to another podcast from Blair and Shane, where we discuss all things Agile BI. For more podcasts and resources, please go to agilebi.guru.