The Life of a Awesome Product Owner – Hiria Te Rangi  

Join Shane and Blair as they chat to Hiria Te Rangi on her experience of being and coaching awesome product owners.

Resources

Find out more about Hiria’s social enterprise focussed on sensors that tell you when your home is making you sick over at https://www.wharehauora.nz/

Subscribe

| Apple Podcast | Spotify | Google Podcast  | Amazon Audible | TuneIn | iHeartRadio | PlayerFM | Listen Notes | Podchaser |

Read along you will

Shane Gibson: So today, we have Hiria Te Rangi. Hiria is going to talk to us about product ownership and her experiences across the board. Thank you for joining me or myself and to the AgileBI podcast. You’re kind of 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 posts are coming if it was LinkedIn or Twitter, about going from being a product owner that works for customers and 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 to introduce to agile and how did you kind of get where you were? And how did it all happen for you?

Hiria Te Rangi: Thank you 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. So I 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 taking the magic of creating and using code. So 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. At that point in time, if it worked. So because I’m quite a chatty, 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 BI were leading delivery. And because we knew the product that we had to build. And effectively, we had two divs 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, is I’ve been around for a long time. And I’ve pretty much seen everything you can possibly say and then built almost everything you could possibly. And I just the thing that I liked about agile versus the whole traditional thing is the personal relationships. That you’re not creating a product, you’re creating a team. And you’re just giving them the inspiration, and setting up their vision in order to hit it. And that whole celebratory knowing that you’re doing good, knowing that you’re working well, knowing that you’re hitting these things, and you that you’re a badass, that’s something that 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.

Shane Gibson: So how do you find that we’re in what we learned from Agile is you become a product owner and you have a bunch of stakeholders, but the stakeholders typically are internal. Normally, you’re the horrible tumors, one throat to choke, but you’re the person there to talk to for tradeoff 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 typically business people, senior management must go to things. In my experience, it’s very rare for the product owner to actually be talking to the customer. So for you when you’re the CEO, your stakeholders, maybe some shareholders and those kinds of people, but your stakeholders are actually the person that gets the value. How do you find that transition? Was that a transition, or was it just natural? How did that work for you?

Hiria Te Rangi: 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 normally. And I have a real problem with being told what to do, especially when someone thinks that they have a 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 the build modular so that people could put them together themselves. And then we took them out to the community, we thought we were prepped. Because these kits were really simple, we tested them with my kids. 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 are really scared. They were really encouraged and they really wanted to do it but there was hella scared. They thought they might break things. They thought they didn’t know how to use a screwdriver. They thought just basic things like is it going to electrify me? So having to pare it back to basics of lefty loosey, righty, tighty for the screwdriver, and you can’t get an electric shock from AA batteries, especially if you don’t charge. And so it was it that same thing that you would do with your regular development team. You need to make them feel comfortable, you need to make them feel trust. And so spending time in doing it at a community center where they’re all familiar with the area, feeding them, letting them bring their kids and providing childcare. And then like just having a taught just like here’s our screwdrivers, work like this. 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 base it, pick it right back before you start the actual built

Shane Gibson: So the definition of minimum viable. So you talked about then you are naughty product owner, because you actually talk to the end user to see what the value might be. Which actually is what we’re meant to do as product owners. So do you find that when we’re working in a commercial world or an organizational kind of sense where we haven’t third hierarchy already? I talk about business agility versus agile delivery. So we’re 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?

Hiria Te Rangi: Absolutely. And it’s a carryover. And because people feel fear, so it’s a completely human condition to feel like this, because you’re being paid to do a thing. And this is how you used to do it. This is how your manager 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 and 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 just do it. Because people will imitate if they see someone else do it first. And especially it means that because as a contractor you are used to getting balled out, 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, , that there are going to be certain behaviors that you will display that perhaps your stakeholders will not like, and that’s okay with me.

Shane Gibson: So what we find is we’re talking about Scrum Masters and agile coaches. The whole thing now where people were reading some stuff on Twitter and some of the posts around to be an Agile Coach, you actually have to have done it for a few years. So you’re gonna 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 two 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 owners should mean and make them safe. So if you if you kind of think of it from a coaching point of view, did you have any views on how if you were coaching a product owner how to be a good product owner, but that product owner was an incumbent, they weren’t a contractor that.

Hiria Te Rangi: They’ve got to look at the decisions.

Shane Gibson: Got the ideas on what we should do with making them safe, but also helping them get outside their comfort box and growing.

Hiria Te Rangi: So I’ve done this before. Because as a contractor, you shouldn’t be replacing yourself. You should never be a contracting product owner for a specific product for too long, because you’re gonna 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, actually, 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 that environment for them. So that means going and talking to the manager saying, 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 values and then you’re saying no. So let him do his job.

Blair Tempero: And I find myself doing that as a scrum master of actually being the product owner coach. So it’s interesting to hear how a contract product owner can come into a business and do that role, that’s something I think about.

Hiria Te Rangi: Because it is whole thing of when as a business you’re building a product, you’re putting a shit ton of money into getting this up and running the team up and running, the team costs a lot just by themselves. And so when you bring in a contract product owner, you need to trust them straightaway, which means they need a large amount of experience, really to hit the ground and it should be completely okay with conflict. But at the same time, people get comfortable with people like myself, and then they don’t want to leave.

Shane Gibson: Because you’re good product owner and you’re delivering the value and the team trust you, and you’re engaging with the right stakeholders. And therefore, we know when you change a member of an agile team, the team believes velocity then 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 initially thought about the contract problem. Is that when you’re a contractor, you’re not planning to be there for five years. And you probably don’t want to be there for five years as part of why you contract.

Blair Tempero: I was thinking would part of your coming on board. The scope should be to actually do that training.

Hiria Te Rangi: Absolutely, replaced that.  

Blair Tempero: So they could say 10% is actually being able for me to walk out after ‘X’ amount of months or years, have that ready replacement?

Hiria Te Rangi: 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 to at the incident to place the process as how they’re going to push the stakeholders because the PA should be doing.

Blair Tempero: And it’s just a product owner. Is it just one of the Head’s, the person you’re training up? Or is it something they have to juggle with their everyday existence?

Hiria Te Rangi: I think I might have had him for about a month for the first couple of months until we could get a replacement.

Blair Tempero: So I find the strugglers to actually get their product owner with enough time to actually get them to do their job so that I don’t end up having to do the backlog grooming.

Hiria Te Rangi: I know, there’s a massive problem with it. That’s why whenever I come across this, even though usually I’m in full time, when I see it in other times, 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 pipe 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.

Shane Gibson: Because we’re not pairing their business is successful. And that’s for me,  that’s one of the techniques I tried, but I find it hard and I find it fails multiple times where I say, we all agree in theory, the product owner was one of the most important parts of the team. So are you really going to commit to seven people spending $200,000 a month 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 are often as the too busy? Or did you find that you often get given a person that’s available that probably isn’t the best product owner?

Hiria Te Rangi: Absolutely. So I’ll say that like multiple ways. So I’ve also been product owner by proxy. And I’ve also been a BA and a product team where the product owner wasn’t available, and it gets skinny. So you can just go through your previous sprints, look at the functionality that about 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 and division. And you can pretty much go through well, good two months, previous three months, if you’ve got it worth of functionality to 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.

Shane Gibson: So when you walk into an environment where the customer wants to do product ownership by proxy. And so how hard asked do you get it? 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 on why this is important. And then if you don’t make a change, I’m not doing it. Because I struggle with this, I struggle with the team agree that the customer is trying to achieve something cool. We should be able to iterate and learn or do it all the time. Do you hear people say just walk away? No product owner, no me. What do you think?

Hiria Te Rangi: So that’s because I’ve done it too many times, then you’re responsible for a half asked product launch.

Shane Gibson: But you won’t give them a period of time where you coach them on what good looks like and then?

Hiria Te Rangi: Because, the thing about being a product owner is that, in my opinion, you should only put something that you understand. And I’ve been given products that are way filled, and being 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.

Shane Gibson: So one of the things we do in the data space that I try is, and I know it’s against some of the rules is often we will engage and there’ll be a product owner that shows all the behaviors of a product owner. So they’re available to the project team at least 50% of the time. And they have good relationships with the key stakeholders and can make the value decisions and can get us on block when we need to. And they love the product. And they see the value and the head of vision. So they have all those behaviors. But because we’re in a data and analytics space, there’s quite a lot of technical decisions that need to be made amongst a team. And the team is not yet at a stage where they can describe the tradeoff decision to the product owner in a way they understand. Because often we’re working with quite technical teams. And we’re not doing what I call WebEx where 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 comes out of a BA pool, but we have to be very careful about the behavior of the BA. You’re working for the product owner to explain the tradeoff decisions a team had given you. You’re not a proxy, and that you cannot make the decision, the product owners who makes the decision, but you’re the Babel fish. You’re helping them understand some of the words when you hear all we want to do type two dimension, you’re explaining to them in a way what that feature means. And when the team is giving you a tradeoff decision, which involves some technical debt. The feature owner is making sure that the product owner is clear on what that deep means. Because otherwise we often we can take the short path or the long path, and there’s a cost here and sometimes a product on it. Do you find that? Have you ever tried that technique? Did it work for you?

Hiria Te Rangi: So I was working on API’s, and API’s themselves are quite simple. It’s the underlying services that are difficult, especially if they’re going into say, legacy systems. So I have no understanding of service layers or API’s.

Shane Gibson: You mean then, you know now.

Hiria Te Rangi: But actually, that work actually fit into freeholder so I’m very grateful. 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 him and even though I get it. So, in that role, my job was to make the calls. So all you need really is to be clear on who’s responsible for those calls, because a lot of people want to make the call, but they don’t want to be responsible for it. And for this particular product, everyone wanted to make the call. And so my BA 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 will go off and go and do the detailed digging. Because as a product owner, you usually don’t have time for this, because you’re trying to get the vision on to figure it out of what comes next. So they were like, my twice a year, 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 we just call a stakeholder. And just say, Look, I’m happy to take this responsibility. Let the stakeholders know if there’s any fallout, which he usually isn’t. Because it’s not like it’s like, 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.

Shane Gibson: Give them a screwdriver and see what happens.

Blair Tempero: A lot of the time and then in the BI world, that is the case. It’s Greenfields, we haven’t done this stuff before. So it’s really hard to actually time box it properly.

Hiria Te Rangi: As long as you know what you’re trying to get out of it. And maybe it’s a metric, like analytics or something, or you want something to work, when you’re trying to just output a thing, you just got to check that everything is there for the output to happen first and this.

Shane Gibson: So one of the things we found as we bought in different product owner. So one of the things that I really loved about it was you need somebody that understands it, and isn’t that domain, and you’re not bringing in somebody that’s learning about. Learning other things like the product owner, but the thing we’re producing, they understand what that data is, why it’s used and that was great. But the challenge was that often was as you changed what you were delivering you got new product ideas. So you’ve finished training, working with a product owner and coaching them to be successful, and then you get the next person then yet rinse and repeat. And I think we always struggled with a process for that. But the other thing we struggled with was making them safe. So I think that was one of the things I picked up from you just them was they’re gonna learn. And they need a safe place to go to ask the dumb question. And you can do that within the team and the retrospective and it’s the same 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, if you’re a new product owner, this person has 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 how they what they did. Well, they’re gonna tell you they haven’t dealt with that.

Blair Tempero: We’ve kind of got a sort of as we’re getting more and more product owners in that. And don’t have that knowledge of the product. There’s a lot of busyness, and a lot of running around. So we do rely on that companionship, and I push it. And we’ve got a couple of favorites that we use for that.

Shane Gibson: So people who are good mentors.

Blair Tempero: Which one sort of really worked well and our team?

Shane Gibson: I mean, have you found any other ways of making a new product owner feel safe. Given that everything’s gonna be uncomfortable for them.

Hiria Te Rangi: But effectively, that’s what I did. 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. The team is still your central repository of knowledge. But at the same time, no one knows personalities especially stakeholder personalities. And when you have to say, change tactics, give some bad news, things like that. The previous product owner knows those personalities, a whole heap better than anyone else will. 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’re gonna do this and how to figure it out the tactics?

Shane Gibson: So I suppose one thing I’ve found with the coaching I’ve been doing for the last few years is, so it’s all common to a customer and they’ll got this data table, the SQL team. Let’s be agile. And we’re talking about the journey. And that’s good because there’s an expectation of we’re going to fail to begin with the team, we’re going to lose. And so with the development team, it’s great. We’re working with them, and we’re helping them be successful. And then typically, we’re coaching the scrum master or the scrum master is helping me coach the team because they’re a contract scrum master all that. Well, that’s great. But I don’t typically get to coach the product owner. I’m not coaching the product owner myself in the moment. So I’m certainly going talking to you and going holy Bologna’s, there’s a whole area of coaching that I’m just not doing. When I got, Blair, he just naturally started coaching the product owners, but sometimes people aren’t as confident as Blair was and picking that role up. So would you recommend that actually, when somebody’s taking the team on this journey, they should actually have both an Agile coach and a product owner coach, and that is our coaching part that’s taking and specializing and dealing with the areas that they’re good at? Is that?

Hiria Te Rangi: 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, I just do the course. Courses are great for basics of how to do the thing. But that is still a tick box method in my opinion. No one teaches you especially in digital, there are strategies that product owners use in order to get the Sprint’s 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. And I’ve very rarely seen product owner trainers or mentors, very rarely.

Blair Tempero: It’s a new concept to me. I mean, in our organization, the scrum master, or the Agile Coach brings that coaching aspect.

Hiria Te Rangi: I think it’s that whole mindset of if we’ve got a project manager, and then switch it over to a product owner, and they’ll just keep doing the same job.

Shane Gibson: Anybody that has worked with me in the past, or anybody that’s gonna listen to these podcasts in the future is going to hear me bang on about patterns. 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. And I was like, this looks kinda like something that 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, this is a whole thing. This is a really valuable, but there’s a whole terminology, there’s a whole facilitation process. It’s not do a half day course in your industry members. And it’s definitely not do a half day course, you’re a great value stream mapping, and you can take a room, facilitate them and coach them on how to do value stream mapping. So then I kind of went that’s a problem for me, because the value stream mapping would be a great tool for a product owner to use all the help to use at the right time. And now I’m going okay. One of the tools are out there for product owners that I’ve never thought about because I’m not a mature product owner coach. I’m probably a bad product owner, because I know too much. And I’m like just do it. So have you ever seen a pod of product owner coach and an agile or scrum master coach work together to help a team?

Hiria Te Rangi: 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 like, because product ownership is such a mystery, because 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 it’s going to be hard. Because when budget comes around, who’s going to speak for you? And you need to make them remember you in. So the other thing is straight up leadership. So I don’t know how where you get these tools from, but understanding that where you fit within the team because I know we live that whole definition of what a product owner is, but knowing that you will shift umbrella that anything that comes down from the stakeholders that is shipped to you or you’ve to catch it.

Shane Gibson: I used to remember it all the time, anyone the coach or the customer. You’re right that you’re are a shooting umbrella. You’re here to protect the team, and allow the team to be successful. And often, you don’t have so many people protecting you.

Blair Tempero: Find your tag team in that role with the scrum master as well.

Hiria Te Rangi: I had once scrum master and I love her. But she just won’t stay with me. And so me and her, we were an army of two, in my mind. Every damn time we were together on a team, we would hammer it out.

Blair Tempero: And just leave the development team to just do their job.

Hiria Te Rangi: Do their thing. Because it was our job to make it simpler and easier. That environment change and release, getting that out, making it as simple and easy for them as possible, taking away all of the noise like how it can get, and workplaces with political stuff and emotional stuff talking about.

Shane Gibson: Because we always talk about forming, norming, storming. And I went to a presentation the other day, one of the Meetup’s where one of the one of the people that founded one of the agile consulting companies are willing to actually do really good work. He was saying one point that came out in this talk that I really stuck in my head was being an agile coach is incredibly lonely. Because you’re typically working in an organization and a role. We’re assuming there’s some people overseas that I’ve talked to off and on. And she’s been in been lucky enough to be in organizations where actually this mobile agile coaches, and in what she said work 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 that was, like, wow, that’s cool. But those two things kind of came back to me and see. 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 the point of Agile is creating a team that work together. And we know that the team will get good over time. Soon as we break a member of the team, the team regress. But we don’t treat that for the coaching side. We don’t go, actually prop this product owner coach, the scrum master or scrum master coach, and this agile coach will just tell us 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, 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’d say maybe overseas we do.

Blair Tempero: We don’t do it. And informally, maybe into a little small degree, but sounds promising.

Hiria Te Rangi: Because as soon as I can pay her enough, I’m dragging her out of whatever damn check she got. And we’re going to because that’s what we want to do is appear. Because I know that right now I’m CEO of Kaiwhakahaere. But I’d rather be working with teams. Do you know what I mean? The question and the build is where the magic is for me. And I don’t like that whole upper tier management stuff to me, it’s just product. So 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 will like it. And that’s the whole purpose of this thing.

Shane Gibson: You’ve find this that’s the buzz. There’s watching a team grow, watching a team loving what they’re doing. Joy enjoying it delivering, but you hit sometimes.

Blair Tempero: But deliverance, is the key, isn’t?

Hiria Te Rangi: It is. And it’s that whole autonomy, that team you’ve got to make it so that the team can build and release as they plays, when they plays.

Blair Tempero: I liken it to a team sport. You’ve all got the same common goal. They might be superstars, they might be plotters, but if you run for sure.

Shane Gibson: Do you find it? I mean, my presentation I did a while ago. I brought up if you picked out every superstar player for a football team across and then you put them on a field and gets a team that have played together for a long time. The team that played together for a long time we’re going to kick your ass because you’ve got a team of superstars but they haven’t gelled. Do you find that as well? That is the concept of the superstar product owner there actually will make it worse because the other superstar in the hero and they’re not actually a senior leader like a scrum master.

Hiria Te Rangi: They’re not creating the environment.

Shane Gibson: But dictatorial maybe, did you find that?

Hiria Te Rangi: 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. So all the claps are for you. And so you find that some product owners aren’t available, because they’re chasing that. And I’m like, bro, we can’t do your job. Because the team sees it, they’re not stupid. They know that they’re the ones that are actually producing and you are supposed to be there making it as easy as possible for them to produce. So I very much do not like it.

Blair Tempero: So demo days, what I the difference on the show case? And that’s a good place to really share the team’s good work. Put them in the limelight. Some of them don’t like it. Some of them.

Shane Gibson: Look at this is what I struggle with. So again, everything I read, everything I learned is the product owner does the demo. Because that’s the definition of done that as they can do it. And I might here I go, because I work in data and analytics but it’s never possible. I’m probably opting out.

Hiria Te Rangi: I don’t like to do the demos, because I get enough face time. 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 bought 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 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.

Blair Tempero: So what we do is, I introduce the demo day and put the whole package together as scrum master. And I find that the product owner role and in our organization is sitting next to their stakeholders and selling it to them. So it’s like, 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, I haven’t been wasting the last three weeks. This is what we’ve produced. And it’s a good sales tool for them.

Shane Gibson: And actually, one of the things I teach from, or kind of talk to teams about is I used to do my bucket open I used to do we’re talking today. So what we find with data is because we can create a small database object on a screen, we probably should be able to, but I’ve never managed to achieve that with a team where iteration, or release train, where we can really quickly build a thing that has high value and demo. So there’s often like the API’s, there’s lots of plumbing and code that has massive value, but isn’t sexy. So I talked about as proof that prove what you did. Prove that it’s done, or prove that it runs, prove you’ve documented that because we documented the agile. So then a lot of the team I’m working with now, the team agile, 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 when I see those look, and in the previous sessions when we start leading the rest of the business coming, because I tend to say to the team, it’s run a couple of previous sessions, where you talk to yourself. So you’re learning the process. You’re a bit uncomfortable that how to stand up and show what you did. And you learn the mistakes. And if you don’t actually plan your private session that’s going to go badly, it’s not going to be an hour or be three hours and I do that. But then those kind of will, the scrum master can introduce the process. And what the previous session is about, because the ceremony master, that’s the role. The product owner can stand up and talk about the value they asked the team to deliver why it was very important and the team show he helped deliver. But anything I read, and they really like you listen to says and then do you think because agile started out really as a doing ‘X’, did we have ‘X’? Were you the product owner, it worked and that was actually an acceptance test.

Hiria Te Rangi: I just think that is part of our learnings. So when you click a button and it works, then sure it makes your acceptance criteria, but where does it say? Because I click that button, and now it works 3% faster, we now get more customers through the workflow. You’ve got to put that functionality into context. And so that’s why when I talked 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.

Shane Gibson: And you got be careful, because we talk about that in Slides. We’re talking about getting at least one number. I mean, when we talked on the other day. He’s always said, even if it’s just a count of customers and the number is just a number on some form of dashboard or UI that’s got value. It prove that in terms of we’ve got all the way through, and it’s a number that is now locked in as a testable number. But when we start, we tend to pipeline, we tend to have a little bit of plumbing, hopefully not as six months with iteration zero, but there’s always we’re teaching the team that actually, they can do those steps in one go and one iteration, and that’s hard for some reason. So that’s okay, that helps me to put that in context, because it’s one that you look at what you do, and you go, maybe I’m doing this wrong.

Blair Tempero: We don’t go through the environment for that thin slice and have that, that bell or whistle at the end.

Hiria Te Rangi: It can be hard. Especially 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 too much and they’ll go. But this changes at one point or now you’ve turned it into five, it was because that’s how we get into end.

Shane Gibson: We’ll spend more time defining the acceptance criteria and the automated testing when we’re writing that piece of code but that’s okay. Because it makes us safe later. We’ll do it the code for that can be maintained as automated. There’s a whole lot of other benefits outside there. That’s the one of the areas that it gives us.

Hiria Te Rangi: And this is also why I don’t like contract product owners is because as if you’ve got six months, it’s very easy for you to go cheap, buy cheap way, cheap way, and then leave all the technical debt to after you’ve gone. Very easy to do that.

Blair Tempero: Take all the glory.

Shane Gibson: 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. And then what I quickly learned over time was, the Build Team would hand something over to the BAU team that it may or may not have been visible. When we send 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 your time cannot be maintaining that production release. So you’re gonna have to automate it, because otherwise in terms of what we were looking to achieve, you’re going to fail. Because you BAU believe or production will fail at the right time that you’re trying to finish that last feature and test it. So then it’s ready for release. But again, that’s a challenge. That’s most organizations are set up for a project goes and hands over. I’ve never thought about it that way that a contract product owner. I has a bunch of success criteria, which is not coaching a team. So actually putting that back, kind of 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 an employee, not a member of the team, or the organization. Actually, we need some acceptance criteria, some definition of done and it’s that a product was created. But actually, it’s also that the organization has a way of creating mentoring product owners, and we leave something that’s a way of working, not just a technical or project thing.

Hiria Te Rangi: That’s why I really favor the approach of giving the product someone to hand off to that as permanent because they are most likely to take over operations or any other variations.

Blair Tempero: And the same can be said for scrum master if you have a contractor as well.

Shane Gibson: I struggle with that because often scrum masters a role that a contractor fills really well. And the acceptance criteria as be the scrum master made 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 for me for the same reason.

Hiria Te Rangi: It’s just because I’m old and gone through quite a few scrum masters

Shane Gibson: Didn’t you having a one scrum master that you want to work with from now on?

Hiria Te Rangi: I really good asked my teams

Blair Tempero: Scrum master support group.

Hiria Te Rangi: Actually, one of my clients didn’t do that. But after he did well, but the thing that I have seen happen is that you can see it on some job descriptions now will you get scrum master/project manager?

Shane Gibson: All the time. All the Scrum Master/Agile Coach. I can coach a scrum master, but you would never want me as a scrum master that makes sense.

Hiria Te Rangi: To me, it’s just the difference in levels. The difference in levels is quite huge. And it’s very different approaches. Because the whole scrum master project manager, which I’ve come across too many times, is that who makes the calls, and who’s responsible? And the thing I’ve had it happen as a product owner, and you get new scrum master, you tend to step back just to let them do their thing and give them space. One time I had a scrum master stack the prioritization for the backlog, and then say the team did it.

Shane Gibson: So when you have this person, that person set it as a way of setting some safe places to go, that I’ve never had that. You will not lie is that person?

Blair Tempero: Was that guy or did by a girl?

Hiria Te Rangi: So we clashed a lot. Well, conflict is completely normal for me. And it should be for product owners in the right way. And in the nicest possible way. Well, it just didn’t work. And the outcome was that, our reports looked okay. But if you dug and figured out exactly how much functionality meet the vision, or the goals that we’re supposed to be hitting, didn’t occur. And then you hit hands off where someone would go, why is this in the backlog? What is it? And I’d 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?

Blair Tempero: Do you go to the scrum master or to go to the team?

Hiria Te Rangi: Well, we heard that.

Blair Tempero: There’ll be a retrospective.

Shane Gibson: And then when the team says the scrum master did it, it’s like holy bananas, we’ve got a problem here. How we’ll fix it?

Hiria Te Rangi: And we did, my team was very strong and capable. And so we talked a lot and then adjust no change code. And so the only point that a PR can do in that instance, is hit up the scrum master. And it started work.

Shane Gibson: But again, the agile process is, 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 a routine, but doesn’t focus on it. And they’re not making that change. Because often people don’t know. They come from a background where they’re not used to it, you don’t know you’re doing that. Now, once it’s pointed out to you and you helped. If you don’t make that change, what I say to teams is, 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. Scrum Masters, their role to make sure that’s the same process and people can change their behavior in the right way. But at some stage, and I’ve seen it before, the team will go this. This team members costing us more time and they’re not changing, and we can’t keep investing. And that’s really interesting that happens. But as long as it’s done in the right way, it is one of those.

Hiria Te Rangi: So I’ve been on both ends, where on behalf of the team or with the team, I’ve asked someone is the somewhere else that you would rather be. Let me make those introductions for you. Let me see what we can do for you. Because sometimes that isn’t the thing for them in person. And there’s nothing wrong with it. From my point of view. It’s when you just go not, you’re up 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.

Blair Tempero: Does he hold his Gantt chart?

Hiria Te Rangi: Well, it was actually picture seen the start of a Gantt Chat that we make.

Shane Gibson: And then the release with all the estimates.

Hiria Te Rangi: In six months out, we only go two months ahead, I mean two Sprints ahead, come on. And so once that was no one, then it was easier.

Shane Gibson: Talking to the, Blair, right thing at the moment with his current challenge but was fine. Did you find it that often people will opt off the island themselves? They will go because they’ve been put on this team. 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 know, it’s bad to say, but I don’t want to do this. And that’s okay, and that is very rare we get to the person having to be removed off the island and that’s okay.

Hiria Te Rangi: I really enjoy. Because I always try to ensure that my team members know, if you’re 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’re a part of this family that I’ve created and to not care about your family who you’re trying to feed, that’s what it comes down to is 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 types is just what we should do, because it’s a good human being thing to do.

Shane Gibson: In terms of the leads of this iteration, I think we’d love to have you back another time as well. Because you find somebody that’s got such experience and such cool stories about real life been there, done that got the scars. But just before we close out, I know you’re doing this really cool stuff from a phone and social good point of view. I haven’t actually briefed Blair on any of it. Give us a couple of minutes, just tell us what you’re doing. Because I saw you’re been in startups when you pitch and you rock that. And those kinds of things, they 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 Corporation more money. Sometimes it’s what we have to do. But if we can do both in this call, and that’s what you’re doing. Tell us about it?

Hiria Te Rangi: Sure. So I’m Kaiwhakahaere or Whare Hauora. Kaiwhakahaere means CEO. And Whare Hauora means charity. We’re probably going to move into social entrepreneurial enterprises. 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 then tell you if your home is making you sick. So there’s a range of temperatures from, if your home is 16 degrees or under for long periods of time, do you have a higher incidence of asthma, eczema, because that’s my population and mold growth occurs at 16 degrees or under. And for humidity, I have a lot of my numbers. Now it’s 70 is bad. 17 was bad, and encourages that kind of growth. But we’re starting to look at mental health now too, because at one time, 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 say. And so all we’re doing really is telling you what’s going on your home, and letting how it’s affecting you.

Shane Gibson: And hopefully people take action from that. 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 are in control of that as much as they can be.

Hiria Te Rangi: We’ve partnered with community energy network that looks after sustainability trust. So it means that there’ll be able to supply people with sensors and hopefully get some funding and we’ll support them to do that. So those low socio economic areas or can afford one because we’ve bought it down to about $110 a kit, hopefully, I don’t know what freight or GST costs? And because all we want really is to say, my home is cold and damp. How do I heat it in a way that’s more sustainable for me? And that won’t cost this. Or how do I get simple steps that will increase the amount of heat that’s kept in my home and just pushing people off to those organizations that can help them do that.

Shane Gibson: So somebody’s listening, and they want to help you do some of this good stuff. How do they get ahold of you? How do they contact you to see how they can help?

Hiria Te Rangi: You can email me on hiria@wharehauor.nz or go and visit the website wharehauora.nz.

Shane Gibson: Alright, I haven’t figured out how we put extra information on the podcast when I publish one. But I’ll once a week did with those links on there, so anybody who wants to get ahold of you can. Excellent. Hiria, thank you really appreciate your time.

Hiria Te Rangi: You’re welcome