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 Hidiya Terangi. Hydya 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, 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 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 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 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.

Point in time 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 were leading delivery because 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 a wound for a long time and I've pretty much seen everything you could possibly see.

And built almost everything you could possibly see.

And I just. 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 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 horrible term is one throat's a 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 to whom? 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. So for you, when you're the CEO, right, your stakeholders, maybe 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. Cause 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 eight 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. 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 pair 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 tun?

Well, that kind of scared him a little bit because it'd be a short job.

Come on, Shane. Encouragement.

Not social experiments.

Punch, just on yourself. Look, just ignore the little burn marks on my tongue from where I've done it a hundred 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 base it, pair 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, which actually is what we 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 behaviours 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 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 because people will imitate if they see someone else do it first.

And it means that because. 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 behaviours that you'll display that perhaps your stakeholders will not like. And that's okay with me.

So what we find is when you talk about Scrum Masters and Agile coaches, right. These, the whole thing now where people were, I was 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. Right. So you go and 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 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 they've.

Got to live 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 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, what I end up doing is allowing the person that's coming in to do all the Day to day. So prioritisations, we talk it through, things like that, backlog strategy, things like that, how our sprints are gonna 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 as 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, 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 cost 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'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.

Yeah.

So I was thinking would part of.

Your.

Coming on board the scope should be to actually do that training.

Absolutely. Replace by the way.

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 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, you know, push the stakeholders. Because a PA should be doing that.

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

Yep. 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 whenever I come across this, even though usually I'm in full time, 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.

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, a product owner is one of the most important parts of the team. So are you really going to commit to seven 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.

Do 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 owner 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 large amount of time because there's no consistency in the vision.

And you can pretty much go through a good two months previous three 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.

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 proge, right? No, no, no, no. Me?

Yeah.

What do you think?

So, yeah, walk away. That's that. 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, 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 technique 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 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. Because often we're working with quite technical teams and we're not doing what I call web apps where there's a screen and a 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 a decision, but you're helping them. You're the babelfish, right? You're helping them understand some of the words. When you hear, oh, we want to do an ECG2 type of 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 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. 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 APIs.

You mean then you do now? Oh yeah, now trying to forget, but continue groups.

Yes. But that work actually fed into whare haora, so I'm very grateful. And so we had a BA and we also had a very incredibly technical team. And so usually 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 want to make the call, but they don't want to 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. Cause you're trying to hit the vision or figure it out of what comes next. And so they were like.

My 2ic 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 life, 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.

Just give them the screwdriver and see what happens and then do it from there.

A lot of the time in the. 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 time box 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 the output to happen first. And that's what that is.

So one of the other things we found is we brought in a different product owner. 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. They're learning a whole lot of things about their 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. So I think that was 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 and 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, 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 be. They're going to tell you how they. What they did. Yeah, 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. It is just we're getting more and more product owners and that don't have that knowledge of. 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.

And we've got a couple of favourites that we use for that.

So people who are good mentors and coaches.

Yeah.

Ones that have really worked well in our team.

I mean, have you found any other ways of making the 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're going to do this and what they're doing, 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 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 is 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 there going, talking to you, going, holy baloneys. There's a whole area of coaching that I'm just not doing. 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 roll 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 and dealing with the areas that they're good at. Is that.

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 their 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 rarely.

Yeah. It's a new concept to me. I mean, in our organization.

This grandmaster 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 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 patent called Value streaming. Right. And I was like, oh, this looks kind of like something that I was doing, I had 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 a 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 industry members 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 value stream mapping would be a great tool for a product owner to use or be hooked 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.

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? No, no, 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 works 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 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 that 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 you know, 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 your 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.

Why?

No, no, no, no. Because she's a badass product owner.

Where's my product? Where's my product? We're shipping straw.

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 because that was our job, to make it simpler and easier. The 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, yeah, we always talk about, you know, forming normal. Storming. 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 did 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 organisation in a role where it's just you. There's some people overseas that I've about talked talk to off and on. Lynn Winterbarrow is one of them and she's been lucky enough to be in organisations 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. That was love. Oh, 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 about 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. 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, this Scrum master or Scrum Master coach and this agile coach will just tool us, depending 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.

Yeah.

We don't do it informally maybe and to a little 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 Haora, 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 RBA tier 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? It's watching a team grow. Watch a team loving what they're doing, enjoying it, delivering, being happy sometimes.

But delivering is 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.

So 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, one 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 their ass because you've got a team of superstars, but they haven't gelled. Right. Do you find that as well? 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.

They're not creating that environment.

Yeah. They're more dictatorial, maybe.

Did you find that? 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 him behind.

Get in the house.

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.

That brings us onto the, you know, the showcase, and that's a good place to really share that the team's good work and put them in the limelight. Some of them don't like it. Some of them.

Yeah, look, and this is what I struggle with, right? So again, everything I read, everything I learned says the product owner does the demo because that's the definition of Dundalk, right? As they can do it. And I don't know. And in my head I go, because I work in the data analytics space, that's never possible. I'm probably opting out.

Yeah. I don't like to do the demo because I get enough FaceTime, 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 put the whole package together as grandmaster. And I find that the product owner role in our organization is sitting next to their stakeholders 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 three 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, but I use the word true today. 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 where you in an iteration or a release train where we can really quickly build a thing that has high value and demo it. 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, prove that it's done or done done. Prove that it runs, prove you've documented it. Because we documented Agile.

And then the team I'm working with now, 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 previous sessions 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. And if you don't actually plan your private session, it's going to go badly. It's not going to be an hour, it will be three hours. And don't do that. But then it's kind of, well, the Scrum Master can introduce the process, right? And what the proven session is about, because that is Ceremony Master. That's the role the product owner can stand up and talk about the value they ask 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 is doing apps, dev web apps, where the product where.

There is a UI definition of was.

Click and it worked. And that was actually an acceptance test. Do you.

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 click 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 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. 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 slides, 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 there is now locked in as a ticket number. But when we start, we tend to pipeline, right? We tend to, we have a little bit of plumbing. Hopefully not a six month situation. 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, 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 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 too much. And they all go, but this changes a one pointer, now you've turned it into a five. It was like, yeah, because that's how we get end to end.

We'll spend more time defining the acceptance criteria and the automated test than we're actually writing the piece of code. But that's okay because that makes us safe later. There's no technical debt. The code fits, that can be maintained. It's automated. There's a whole lot of other benefits outside that.

Absolutely.

That one area that it gives us.

And you know, this is also why I don't like contract product owners is because if you've got six months, it's very easy for you to go. Yep, 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, you know, I used to think about the build team being Scrum and the BAU team being K. 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 baubled because after you've done a few releases, 80% 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 your bauble 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 a project build and hands over contract. I never thought about it in that way that a contract owner has a bunch of success criteria which is not coaching a team. 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 and 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 approaching thing.

Yeah. And you know, that's why I really favour 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 Masters a role that a contractor fills really well. And the acceptance criteria 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. Well, 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 because they can survive you.

Hey, I'm really good. Ask my teams.

Scrum Master support group.

They meet every Tuesday.

Actually, one of my clients to do that. But.

The. After he.

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. 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. 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. 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 prioritisation 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. Yeah, I've never had that. You will not lie as that person.

But, yeah, 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 there, 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'll be a retrospective type item, wouldn't.

I show 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? Yep. And we did. My team was very strong, incapable, and so we talked a lot and then just no change occurred. And so the only point that a PI can do in that instance is hit up the Scrum Master.

And.

It still didn't work.

But again, it's part of the job process.

Right.

Retrospective tells us how we need to change our behaviour 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 when 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 the 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. Actually, it's not a product owner, sorry, the coach and Scrum Master, it's their role to make sure that's a safe process and people can change their behaviour in the right way. But at some stage, and I've seen it before, 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, 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, nut 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 realise and he didn't tell us until we went over his head and went to his manager. That's when we realised.

Did he hide his Gantt chart from you?

Well, it was actually seen the start of a game chart that went. Make me there. Holy gosh.

And the release promises, right. The team hasn't even estimated it or even emphasized it.

And it's six months out and you're like, we only go two months ahead. I mean, two sprints ahead. It's like, come on. And so once that was known, then it was easier.

I think you're talking to Blair in the right language at the moment with his current challenge. But the other thing I find, I don't. Did you find 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 offer, you know, it's very rare we get to, you know, 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. I do.

Look, in terms of the length of this iteration.

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 glare 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. 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. 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 Whakahere of Whare Haora. Kai Whakahere meaning CEO and Whare Hawera 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 if Your home is 16 degrees or under for long periods of time, you have a higher incidence of asthma or eczema because dust mite population and mould 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 and it 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. 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 socio economic areas or countries afford one because we've brought it down to about $110 a kit. Hopefully 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. 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 in my home? 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 heerehauera NZ or go and visit the website of wharehaura nz. Yeah, cool.

Alright. 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 those links on there. So anybody that wants to get 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.