AgileData #16 - Plan Continuation Bias

Welcome to the Agile Bi podcast where we chat with guests or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations.

Welcome to the Agile Bi podcast. I'm Shane Gibson.

I'm Blair Temporo.

And I'm Tony o'. Halloran.

Hey Tony, thank you for joining us today. I've been a long time fan of yours. I think I went to one of the Agile Welly meetups probably last year or the year before and saw you speak and it was one of those talks that kind of made mental notes and then went away and actually adopted some of the things you talked about, which was pretty cool, I'd have to admit. There were a whole lot of things you talked about that I thought I should have adopted and haven't quite got around to it yet. But you know, we'll work on that.

That's kind of you to listen to me. A lot of people don't bother.

Oh, I think it was alcohol.

No.

Cheese will get people in. Yeah.

If I remember, I think it was actually partly your slide deck, you know. Cause it was the presentation style you used was they were there as supporting evidence. So you know, you brought up a slide, it was behind you and then it told us the story.

Yeah, so like I got into a habit recently of like just hand drawing all of my slides, which seemed like a cute idea at the start, but now I find that it just takes hours and hours and hours. But I sort of, sort of laid myself down with it and it's just a good way of thinking through, thinking through something.

And it's different, right, because it's not stock art, it's not, you know, a photo or you know, the standard now seems to be some kind of pretty photo in the background with a couple words. So that uniqueness of visual badly drawn, I don't remember it being that bad, was probably better than stick figures. But anyway, what we do for somebody that's new on the show, we kind of ask them to tell us a little bit of a background on how they kind of came to this agile thing and their journey and where they're at now. So why don't you kind of give us a bit of background about yourself?

Yeah, so I'm an agile coach. I work for a company called Nomad8. We're spread across Auckland and Wellington and Christchurch. So we've got about 13 of us now and it's. We're all kind of really, our kind of core interest, our shared interest is agile and helping to make New Zealand organisations better.

So as you can hear from my accent, I'm not Wellington, born and bred, slightly offshore. So I'm from Ireland. I've been over here about nine years. But my background originally was in electronics so I did electronic engineering and masters in microelectronic design. Then I started working for a company as a software engineer. But around the microelectronics space. I don't know if I. Yeah, I loved software engineering and I loved being a programmer.

I don't know, I was probably with questionable quality.

I cared more about the people side of things about like technical purity.

Really cared about like what I was doing and who I was doing it for.

And then I ultimately I moved to New Zealand for the mature reason of wanting to be able to ride my mountain bike after work and surf after work. And that was about nine years ago.

So I had started it when I was working in. When I was working in Ireland. I was working for a large company and I kind of got involved in the project space. I was still, still working as a, like a programmer, but I was like leading a few things and.

For about three years we were working on this one like major new product. There's probably about 30 of us working on it for about three years. And we all really cared about what we were doing and worked nights and weekends and we kind of released what we said we were going to do when we said we were going to do it. So it's not like the traditional. Everything blew up and it took three times longer and seven times the budget. We kind of released what we said we were going to do.

It's good to hear a good story.

Yeah, hang on.

Because I think this was the theme of the talk that I listened to.

However, it's always at home. Yeah. So the however is we released it and nobody really cared.

Yeah. So like we were, we were ultimately, we're ultimately like unsuccessful in like with the product that we were releasing. But we had been like really sort of efficient and we had worked well together and all those sorts of things. And I got really curious about why that was. It was really deflating for me. So I decided that project management was the answer. So I went off and I put myself through project management school, got a qualification working at night and working over the weekends and doing, you know, exams and projects and all that. And we had these guest speakers that came along from different industries and one of the last guys that came to us was, was he worked from. At an incubator and he said hands up who works in product development and software.

So Put my hand up. And he said, all right, pretty much everything that you've learned in this course up until now is relatively useless to you and here's why. So and he introduced us all to agile there and that kind of made me really, really curious.

Slightly depressed, but very curious. And that kind of started me off into a bit of a binge of reading and mainly kind of self driven at the start. So I ended up like kind of naively introducing a bunch of practices around the stuff that I was working and then fairly, you know, kind of navigating in the dark. There wasn't a huge amount of agile awareness or groups around Dublin at that time.

But I was trying stuff and learning for good or for bad I guess. And then I moved to New Zealand, started working for a company here and then realized that sort of I was going to encounter some of the same problems again. So we ended up kicking off some teams and at fairly good scope to be able to make change there. And we kicked off teams and introduced agile and those teams are still going to this day, which is something that I'm really proud about. And then kind of my journey, kind of, that was when I kind of downed tools from then on, still with an interest and still obviously with a kind of a background in technology. But that was pretty much when I stopped being dangerous with a keyboard.

So I remember one of the sessions at JAFIC was a lot around certification and Scrum Masters and Agile coaches. And people often ask me what the difference between a Scrum Master and Agile coaches. And what I tend to say now is, well, originally Scrum Masters were the coaches and then certifications came out where you could do a two day course and get a certificate saying you're a Scrum Master. So those who've been coaching for a while kind of invented the title Agile Coach A to keep the rates up, but also to say that it takes a number of years of being on the war front to learn things and be able to help coach people.

So you know, nine years ago that must have been back where you know, was, was Agile coach actually around them? Was it really, you know, you were an experienced Scrum master and you coached the team and that really was the only role.

I don't think I really had a role at that stage. And I think it's probably to the point that those role names and the differentiation between them is largely kind of a valueless conversation anyway because there's people calling themselves both things without any previous, any previous knowledge or experience. So I think the title itself is largely, you know.

It'S largely, it's largely wasted conversation but you know, it's useful if people want to search for one of you on LinkedIn.

Yeah, true.

That's why I still haven't completely got it.

And I'm sure, you know, as we do in it, we'll do it in the agile world where there'll be a new title come out in a couple of years, which is the new.

Delivery managers with delivery coaches. And like ultimately I don't really care like what it actually means or I think if you're getting to the point of that's not my job or that's not my scope, I think either role, that's not really where you want to be. I think if people look at Scrum Masters as being, that's just the team thing. You just play in that domain. I think that's a description of, I don't know, do people swear? But that's a description of a shitty Scrum Master, in my opinion. Or not a shitty Scrum Master. That's a shitty imagining or like a limited imagining of what a Scrum Master can be. A Scrum Master should be.

Able to influence that leadership, should be able to influence the organization or should be aiming to.

Fighting the good fight.

Yeah, exactly. Yeah. You need to think about the people themselves. You need to think about the teams, but you also need to think about the system around them and the organization around them.

And when you're bringing new members into the team you're coaching by, you know, by default anyway. So I'd say unless you're a team that's steady forever, you're, you're a Scrum coach, agile coach.

But then if you're a team that's steady, you're not really adopting the agile mindset, right?

Yes.

Because you can always inspect and adapt what you do. Yeah, right. Yeah. Nothing's ever perfect. There's always something you could work on to see if, if you can improve it. So yeah, you might be a well forms team with velocity, but there's always your ways of working that you can look at and go, well, what could we change to make it slightly better?

Yeah. And it's going to come to, it'll get to a point really, really quickly that those things aren't necessarily things that just that team needs to change or sometimes those things maybe not things that that team has, I guess the influencer, the control to change. So you might need to, you might need to work with people outside of the team.

But it's definitely not a Scrum Master does this and an Agile coach does that. There's like all this proliferation of enterprise agile. All of that is slightly pointless. You really do what's needed to do to support your team and to doing great stuff and not wasting three years of their life on a project.

But at least you delivered on time.

This is too soon.

I think it was over nine years ago, so I think it's always going to be.

Everything is venting. I've made a career out of my own therapy.

So nine years ago, what was Wellington like as a, as an agile kind of environment? You know, was it all new? I mean we, we had Agile Pete Tansley. Agile Pete on last year and, and for me he was one of the people that first introduced me to the concepts and I kind of like was like, right, you've been doing this for in my view long time for how I saw him. And you know, in Wellington at least you. I know a lot of the practices of Agile, you know, XP and that have been around for a long, long time. But in Wellington I get the impression that nine years ago was probably at a bit of a bleeding itch. Was it?

Or I think Wellington was still and like New Zealand in general still fairly advanced worldwide. As you, as you go around and you talk to people, I think, you know, I think it's something to be really proud of and I think if I look back to then, there was actually still quite a healthy scene. There's still a lot of people I remember I got to see like through communities like Agile Welly, I got to see like Jeff Patton and a bunch of other international speakers coming to Wellington because you know, there was such an active scene and a great community and those communities have kept on going and have grown since then, which I think, you know, speaks to really. It's been a really healthy thing. It's been a really healthy thing for a while here.

Oh, cool. So before we kicked off we were kind of talking about what we're going to talk about and you mentioned three little sentence and I looked at you blankly because I'd never heard it before and I just had a brain fart and I can't actually remember what it was. So why don't you tell us what it was and then what it means.

Yeah, so I've just been binging recently reading about planned continuation bias, which is kind of the topic of a talk that I'm working on now.

And it's just about ready. But.

So like the, it's really kind of come into the fore a lot of People talk about it with airline travel and pilots. A really common example is if weather is kind of sketchy and pilots approaching the Runway, even if they think it's marginal. There's a bias to stick to your plan. And because you've got a plan set in mind, it makes you. It makes you slightly discard the signifiers around you or the information that you might actually be on the wrong path. So you've got a bias to stick into that plan rather than taking into account those external influences.

So I suppose.

In previous lives, for me, we talked about the concept of, well, I've spent $100,000 trying to put this product in.

I really can't write that off. I can't throw that 100,000 away. So let's do the change request right back in the old ways.

Whereas, you know, a lot of the times you actually say, well, good, you've only wasted 100,000. You know, there's no justification to throw another hundred thousand at it. You know, you've got to actually look and say, is that next hundred thousand actually worth it? Is. Have you got a better chance of success? And so we did. We had that bias of, well, we started, we might as well finish. Even though there was no signaling that you actually were ever going to finish.

Absolutely, yeah. So that would be the. So sunk cost is quite. What you're talking about is like really related. But it's. Even if you haven't invested money in it, if, if you just have that plan, there's a tendency to, you know, to, to stick to that plan and to, to sort of be blinkered to information that, you know, that plan may not.

You probably had to sell that plan to someone in the hierarchy and going back on that.

Yeah, exactly.

Yeah.

You put time in it. You like, you own that idea. You've probably done loads of things, loads of vision me, so exercises.

Stood up and preached it.

Yeah.

Can't believe it's not working because it was the perfect plan.

Yeah, yeah, yeah. So.

So one of the things I always struggled with was, you know, when talking to somebody senior and they, and you're starting the journey with them and they go, well, you know, we've got this thing we need to deliver. Outcome might be described in a better way. How long is it going to take? You know, and, and you, you know, it was typically, well, you know, it'll take as long as it takes for the team to build it. You know, they haven't built it before, so, you know, we don't know. We can give you a guess. But you know, we're just guessing, you know, and you know how much it's going to cost. Well, if we take that guess and we times it by the number of people we got, that's how much it's going to cost. So, you know, it's bringing back that uncertainty because we haven't done it before. So therefore any certainty we give you is a complete guess.

And you don't give them that nice number that's a lie. But it's still a number. Yeah.

Which then becomes the fixed plan, you know, the promise. And you get whacked if you don't get anywhere near it. Whereas it was like the guesstimate. I use the word guesstimate, not even estimate, because it's a complete guess based on some science or fact or experience typically. But it's still a guess that doesn't go down particularly well. So people don't like that lack of. Most people don't like that lack of certainty. So I suppose what I'm kind of hearing you're saying is we then start introducing some ways of planning to understand the vision or the scope a little bit more, decompose it down so we can maybe roadmap some.

Different ways. We might want to stop and have a look at how we're going and see if what we thought we should do is still what we should do. Is that what you're kind of saying is once we start that behavior, then it becomes a plan and as soon as we see it as a plan, we don't want to deviate from it.

Yeah, yeah. And I'm not like the message out of this is do not plan.

Right. I thought it was like no estimates, no plan, no code. You know, these are the new buzzwords is know anything?

No, no. And I don't, I wouldn't, I wouldn't say that that's the point of it at all.

One of the, one of the outcomes in one of the papers I was reading about, about this bias is that those sort of flaws aren't things like initially it was like you'd punish. If we'd go back to the pilot analogy. Those pilots, you know, it's always queer, why do these pilots mess up? But when you're working in complex situations with pressure, especially with pressure, which, you know, we all work in relatively pressure filled situations. Those, those accidents or those mistakes or those errors aren't human mistakes, or it shouldn't be viewed as just, we need to punish this person or train this person. You should be looking at those things as system errors. So something about the systems that we're working in, regardless, I'm not talking about Agile or waterfall, regardless of those people, there's something about those systems that's a problem because those sorts of things happen with pilots all over the world and have very varied experiences. But it's a regular thing that happens and it's no different with those outcomes that we're trying to achieve or somebody's working on a project or a feature are trying to achieve something, those biases and those errors still occur.

So obviously you've done a lot of research around the concept of bias and the danger of a plan. When we bring that bias in, have you got as far enough to give us an answer? What do we do when we know that we can't go in without a plan? We shouldn't go in completely blind. Anything that looks like a well formed plan and immovable, we have a natural bias to try and follow. Have you worked through in your head yet? What, what Some, some patterns or. Yeah, we could use to.

So, so like for ages. Like one of the, one of the things that I've loved kind of battering is the, it's the Sprint review. I've seen them kind of just be.

Relatively worthless and a lot of times like facilitated worthless ones in them where it's like, it's sort of like story point theater or you're talking about these JIRA things have been done and it's. We're getting feedback from stakeholders and telling stakeholders about things.

Those things are good things. But I think it's.

A short step of what we should be aiming to achieve. With Agile.

I kind of care about feedback from stakeholders. I really care about data from users and customers.

If I think back on that again, I'm going to rant about that project.

That I worked on only nine years ago.

We got a lot of positive feedback on it.

We were actually showing off what we were doing and we got feedback but not the right type of feedback.

So what I think we need to do when I said that these things are system errors, I think we need to systematically build in a forcing function that we actually ask these things because when it's your plan or when you're in the team and it's your plan, you're wedded to it. So what you actually need there is some external perspective and somebody to say that the king is not wearing any clothes. Right? So I think one question that I think people aren't asking in Sprint reviews but I'd like to see there is what have we learned or what data do we have to show that we shouldn't cancel what we're doing right now? What have we learned in the last whatever X weeks? So what I'd actually like to do is build a forcing function that we do get real feedback that we're on the right path. And you've got external people that are outside of the team to ask those questions and to be part of that discussion that gets what Sprint reviews could be. But sadly I see a lot of PowerPoint and yes, we've got this new shiny button, but ultimately, who cares? I want to see them being used as an actual real feedback loop.

I like that term forcing function. Yeah, I got to steal that. One thing I like about these podcasts is I get great ideas that I can steal or borrow or share or reuse however you want to do it. So what I find is especially because I work with data analytics teams more than apps development teams only.

The naturally what happens is when I go in to help a team, we naturally want to try a Kanban approach. It just naturally feels right for the way they work.

Sure.

And every time I've tried.

Seems to fit the way they've always worked. And therefore we don't really introduce any change. There's change, but not real change. And we don't achieve any benefits. The things we want to achieve as a group don't happen. And so if we then move to a Scrum model for some reason that breaks everything and you can see the benefits starting to come out in terms of team self organizing, changing the way they work, focusing on the things they want to work on next, delivering things a little bit better or faster and those kind of faster later. But you know, actually delivering you into production, all those kind of things. And what I say to them is, look. And I got, I think I got it from the metacasters, you know, let's do Scrum for a while and then when you're ready, you can move back to Kanban. When you think you've you've got either. The way the metacast guys talk about is you've earned the right to do it. I kind of like the concept, but not the wording. It's more when you think that actually you've adopted enough agile practices that Kanban's gonna work for you. So that word forcing I kind of like because we're implementing a practice that's forcing a change or forcing something to happen, because if we try to do it unconsciously, it's not gonna work. And then we'll consciously focus on it until it becomes an unconscious behavior that we've adopted. Does that make sense? So yeah.

So yeah, like the thing.

You see like Kanban done well takes a lot of discipline.

And it's. But it is an evolutionary approach to change as opposed to a revolutionary. Here's a new process. Right. But the evolutionary part of things, it's important to focus on some of the practices that people kind of don't look into. They'll put it to do doing dun board and say we're doing Kanban. But I'd say it's missing out on the implement feedback loops practice.

And it's missing out on that we agree to pursue change, collaborative change, using the scientific method as a team. Right. So I think it's, you know, it's always worth bringing, bringing those back to a team and saying how, how are we, how are we actually living up to these practices within Kanban? Because you know, starting off where you are certainly I think is really valid, really valid approach. And if, if a team's nature, if the nature of their work has more of a support or a reactive nature to their work, I think throwing scrum at them would be detrimental and can burn people, you know. You know, like, like everything we say. I'm gonna try and not say it today, but it depends, like context is so important. Yep. And talking about any team's process without, without knowing more about it and like working really closely with them kind of sets you off down the wrong path.

Yeah. And as opposed to like earn the right to do Kanban.

I don't know, that sort of grinds with me a little bit. Yeah.

No, like I said, I said it's. I think I like the idea that you, you have changed the way you work. That your maturity means you can be successful with Kanban because you are collaborating, you are communicating, you're micro planning, you're doing all those things kind of naturally now. That's why the earn the right was like I said, it was a word that kind of didn't sit comfortably. But the working towards that, if that's the way you want to work, kind of made sense.

Yeah.

So I suppose I give it a little bit of research around no estimates. Because when I'm working with teams I still start off story pointing. But what I say to them is again, we're going to force the story pointing estimation process so we can learn how to collaborative estimate and get better at it. And then once you mature, you'll naturally just estimate the same as a group anyway. So we can ideally remove that forced Behavior, we can remove that ceremony if you're just constantly sizing stories the same and they're fitting and you're delivering them. We don't need a ceremony to point them. Yeah, but you've got to get to that stage where that's happening just the way you're working rather than a learned behavior, if that makes sense.

Yeah, yeah. And some teams like that I've worked with go on and they use story points for forever. Like because I think that a lot of the people's real problem and a lot of the no estimate stuff is around when story points or whatever estimates the team come up with are used as a way to beat them over the heads. It's like, right, you said this amount of story points, your velocity is this. That's a commitment right there and then. So I thought yeah, be good seeing it just like re termed as like no shitty companies or.

Yeah, yeah.

Because I think like a lot of teams like want a way to talk about relative sizes and complexity of things in a way of like sharing, you know, this, structuring that discussion about complexity.

And you know, it doesn't, you know, if that's the. If the anti pattern is that they're being taken as commitments and as for what they are from. If they're being taken as commitments, then that's the root cause and the behavior. If you take away estimates, then they're going to use something else to. To kind of force that fake commitment. So you should deal with that behavior and that symptom rather than just taking away estimates.

And I think same thing with retros. If the team are constantly talking about how they can work on the process they're using and improve it, then we don't need a retro process at the end of every sprint because they're naturally inspecting and adapting and focusing on what they want to work on next. So again, in my view, we kind of force that retro ceremony to start that journey.

Right.

To get them understanding that focusing on changing a couple of things and then delivering it and seeing if it's actually made, you know, the way you work better or worse is a really important process.

Yeah, yeah. And like Karma talks about that. It doesn't say user retrospective. I worked with a ton of Kanban teams that do retrospectives and it works well. There are like, they're like, I think of anything of any of the other ceremonies or events or whatever you want to call them that people have. You could cancel a lot of them or kill a lot of them. And if your retrospectives are good enough Then those things are something that will replace those things or get, that outcome will come back. But if you, if you're not like working on how, how you're going to improve as a team, that's.

You know, they can be such a great thing, you know, retrospective. So.

Yeah, they could be fun. They should be fun.

Yeah, yeah.

I think it's like story pointing though, right? They can be used for good.

Yeah.

And they can be used for evil. Right. You know, they can be used as a weapon to hurt a team rather than something that can help a team.

Oh, for sure. Yeah, yeah, yeah, yeah. I saw recently.

One of these, you know, people love playbooks at the moment for some reason. Okay, yeah, big thing. Gotta have a playbook for some reason.

And this playbook specifically said that.

You know, because I don't know why you wouldn't just look at your Scrum guide or whatever or whatever other guide. There's a million and one web pages that tell you what a retrospective is. But this one said the retrospective is an opportunity for the Scrum master to come to the team and give them a list of things that they're not doing right.

Yeah.

Well.

I'm sure, you know, you can adopt any pattern that works for you. That's my view. I'm not sure that's a pattern that I would adopt personally.

But my point is there are ways of doing these things. Well, like you were saying, doing them, doing them in a way that can damage a team self organization.

Yeah. And we see that a lot because most of the times I'm working with groups, I'm coming in bottom up, you know, I'm coming in to help a team accelerate. I don't think I've ever yet been lucky enough to work in an organization where there was true business agility and a top down, you know, change to that organization. So, you know, the challenge there, and you know, we had some people on last year, we talked about it was, you know, the challenge for me is the team get really good at adopting a mindset and some patterns that make them their way of working better. But then they've got these unnatural constraints above them, which is the organization working outside of that cycle. So they're given a project budget that somebody made up and then they've held that as a commitment that they have to meet, even though there's no way it would be delivered on that money. And they didn't, they didn't do any of the work to say that that was possible. So again, you see these, these handy patterns at an Organizational level and you.

Struggle to get product ownership as well. I find, you know, if it's not at that other level.

People are treating it as a part time job and just a chore.

Yeah, it's just a hat. Yeah, yeah.

It's just one of the many hats.

Yeah, yeah.

Come across that.

I think the other thing I find is it's now recognized that sometimes getting somebody in to help your team, you know, accelerate in terms of their mindset or their patterns that they use is a good thing. But we often bring a product owner in part time with no onboarding, no upskilling, you know, it's just like, oh, you're the product owner, you make the calls. So we put them in this whole new role with no training, understanding, support.

And expect them to thrive in what was pretty. One of the hardest roles.

Oh yeah.

At least a scrum approach that in my view, that product owner one, that's a hard role to fill.

Oh, absolutely.

Do you find that, do you find that people often treat it as just a, you know, a secondary role for people and they don't really need to be helped to adopt that role?

Yeah, well, I think kind of, it's kind of bundled up with your previous point is that.

If, you know, it's quite common that you're brought in to say this team needs help or whatever. But I think straight away that sort of, I think regardless if you're a permanent employee or if you're somebody that's external.

You need to have those sort of consulting skills to be able to not just deal with the team, but to also deal with the people around that team. So leadership, supporting functions and bring them along in the journey. So I think that one of the first questions you can ask is like, okay, well like.

I guess what you want to do is like be kind of getting a picture if, you know, if they're willing to change as well. And it's sort of starting to bring, bring people along for that journey as well.

Because it's never just the team, generally the team things. People are smart, people are mature and people are adults. And if there are things that are specific to the team, those things will get ironed out fairly quickly. And then suddenly if that team wants to go any further, things outside of them need to change. So you need to have built a relationship. Whether you're a scrum master or an agile coach or a consultant that's coming in. Those are relationships. It's all about relationships. Relationships that you need to have built and brought people along in that journey. And Having them to understand that they provide, that they provide a lack of value in that chain as well and that they need to support and possibly change themselves.

I think one of the, one of the things I heard you talk about.

A while ago and it was one of those things I went, damn, that's actually something I don't do and it's something that I should adopt, but I haven't quite got around to it yet, as always. Is this idea of, I think you kind of termed it as do no harm. But the idea of a coaching contract, the idea of when you're starting off with a new group of people being quite clear about what you will and won't do, what you, what's acceptable and not acceptable in terms of helping that organization. Do you want to talk a little bit about that? Because I found that really interesting is that setting that expectation Because I suppose if I, you know, as you said, you become an influencer in the organization to a degree, you're there to unblock and build those relationship and often that can be a little bit fraught when you're in that role. And so that idea of that contract of what you will and won't do from what's acceptable gives you that kind of grounding that, you know where Juneauth is.

Yeah, I try wherever I go to be. I think it's important that we're explicit about what we're doing and what we're doing there to do.

Some people may not know what an agile coach or the scrum master is. So I think it's really important to be, you know, one of the values that we preach is transparency. Well then we should be living that ourselves. We should be open about what we're there to achieve and what we're, you know, kind of where our boundaries are. I think with that, with that coaching contract.

I think that might have been part. I wrote an article a while ago that is basically about like our. Some agile coaches going around doing harm. So like there are a lot of tools that people have as scrum masters and agile coaches that you know about like from even just from a facilitation standpoint like powerful questions and all those.

Which like a lot of those are borrowed from therapy and things like that. So I think we need to be very careful about when we use those and sort of and not go to places that we're not invited and not go to places that we don't have the skills to be able to, to be able to provide good outcomes or support people or if we wander off into a place that's unsafe, that we can help them safely come out of those places.

I think probably coaching is agile coach, like coach is probably the wrong, the wrong term anyway because actual professional one on one coaching is a tiny part of what I do and like coaching as such is a one on one activity. Generally there's team coaching as well. But the, you know, I think that actual side of things is.

Need to be careful with that skill and it needs to be like respected and actually used properly. And contracts are a great way of like setting up that relationship. So that you're explicit that is this is a coaching conversation that you like, that you voluntarily come into, that you want as coaching, that you know what coaching is.

You've got ways of saying no, you've gone too far, let's pull out. This is just being explicit going through and having those discussions with people.

So I think the reason I really like that idea and I think came back to something you said earlier is, you know, if we wanted to understand what the role of a scrum master is, typically there's a large amount of resources out there. You google what does a scrum master do? You know, you've got the scrum guide, you've got. I didn't realize there were other variations that people were logoing up. But anyway, you know, you get good descriptions of what the ceremonies are, you get relatively good descriptions of what the roles are and what they're not. And so you can read and adopt it and learn by using it. But in that scenario, you know, if I googled, because I did do the lazy try, you know, agile coaching contract, you know, nothing comes back really. There's nothing. There's not a lot of stuff readily available out there to, to adopt that practice. And I think that's why it tweaked up my interest was it was a practice that looked like it had high value.

Yeah.

But not one that I'd heard before. If I had a thought about it, I might have got there, but I probably wouldn't have. So. Yeah, that's, that's again why it tweaked my interest as something that was incredibly useful.

Yeah. And we've bounded around. I know there's been a few efforts. So there's a meetup group that I organize and you were there at a session where we tried to come up with a code of conduct.

Yeah. And I was looking forward to that one coming out because I was quite keen to, to sign up and adopt that again just to make sure that, you know, sometimes you, you you are under stress and, and there are shades of gray. You know, you, you get that due north, right? You're saying, well, look, there's this code of conduct that made sense that I'm holding myself accountable to, and I'm starting to feel itchy, which means I'm now getting into a situation where I should really start questioning whether I'm breaching that code. Yeah, it's a tool you can use yourself. So, yeah, that was an interesting process. I think we did some good work, but we haven't come out with an outcome yet of a code of conduct.

No. And it's a tricky thing. There are other coaching disciplines that have a specific code of conduct.

And there's so much, there is so much gray in what an agile coach is that, you know, it is useful to have some sort of black and white. This is what you can expect of me and this is what you can hold me to account for.

But we just didn't quite get there. No.

Well, so was the code of conduct for the Scrum Master specifically or was it a team?

No, no, it was for Scrum Masters.

And Agile coaches because we've done the team. Don't be this guy, be this guy.

Similar to that. And we often do a team charter and so we ask them, we ask our teams to write down what they think is acceptable and unacceptable behavior early. Interesting to have a room full of agile practitioners and ask them to come up for that for their practice. My understanding was it had been tried a couple of times in Auckland with the Auckland meetup and they struggled. So, yeah, it's not an easy one to solve.

And the other thing I think that was really interesting about that meetup was, you know, I'm a great fan of looking at patterns other industries or groups use and go. That makes sense. How do, how do we adopt that for what we do? So there are industries where there is a code of conduct.

Yeah, yeah, it's a standard professional coaching.

So it's kind of a known pattern.

Yeah.

So again, for us to. It was a room of really talented people.

It still should be something because the actual coaching part of what we do is a small subsection of what the role actually entails.

So it does necessarily need to be wider that we can't just copy and paste, but we can definitely learn from that.

And also because Agile is becoming a bit like Big Data was in MySpace or. Yeah, digital transformation. Let me not go there forever. But, you know, it's become a hot word. Right. So when these things become hot and noticeable, everybody Jumps on and it becomes a bit of a wild west.

Oh, it is absolutely in wild west.

And then it comes down, everybody gets bored of, finds it's wild west and jumps off. So, you know, the idea of a code of conduct where at least they read it and it makes sense to them and they hold themselves accountable. People that are renting this for the first time, it's valuable. Right. It's, it's. Should do some good. Yeah. So hopefully you'll kick off another one and we'll have another go.

Yeah, I think there, I think there are hopefully plans to get something to get a wider discussion about it happening. So I'd say watch this space.

Yeah. I mean, how do you find Wellington for that, that publishing and reuse? I've always found Wellington really good at sharing.

Like, I think the Agile community in general is amazing. It's like, it's like, it's relatively unique in that everybody is quite open source.

You know, I was going to say, yeah.

You know, to.

To like a massive extent there are some organizations, some consultancies that aren't like that. But I think as a general, as a general thing, everybody tries to share as much about what they have because I think you're not looking at the world in a, in a limited sort of viewpoint.

If, like, and if the more that you share and the more that people build on top of what you've done or the more that you learn from other people, the better we all are. Right. And I think, and definitely in New Zealand and definitely white or people are following over themselves to share what they've learned or what they've tried or what they've messed up on.

And I think just going back to your nine years ago.

Sorry to bring that up. Twist that nine.

That sort of come to Jesus moment when he thought, hey, it's all about the people. And that's shared across the community, I think, and that's why there's all this collaboration and willingness to share is that people genuinely care about their teams.

And it's hard. Yeah, you can read something or, or listen to somebody or see what somebody else has done, but to apply with a team in their situation, where they are in their maturity model and their organizational state and it's hard. Right. It's not cookie cutter. You can't just go bang, there you go. And it just works. It's actually, you know, it's hard, but.

It'S also a healthy state where if you've nailed a problem, you want to share it. Yeah, yeah. There's, you know, there's ego involved as well as wanting to share.

Oh, yeah.

I guess there always is. Yeah. A bit of ego involved, but somebody good ego.

It's not some bad ones, but, yeah.

It'S worthwhile being aware of it anyway. But somebody referred to, like, those sorts of roles as, like, emotional labor. And I think there's. There's a certain truth to that, you know, that you can't really do our job well. You can't do it well without being empathetic and with understanding. Without understanding what's going on for people and what their motivations and drivers or blockers are.

So.

You know, you need to be in tune with that and to work with people to get things done sustainably. There are definitely. There's definitely history of these things being implemented as a thou shalt, whatever. I don't believe in that myself.

So I think, like, that it, you know, it ultimately does come down to people in relationships. Yeah.

I'm with you with the. The cookie cutter approach as we talked about before we started. Yeah. I'm seeing that becoming more and more prevalent.

Yeah.

And, you know, I. I used to. I learned my lesson early. You know, I learned that what worked with one organization or one team when I've mandated early when I started this journey, that this is the way it works. And they've tried it and tried it. Seriously, it didn't work for them. That was my lesson on, you know, that pattern may or may not work.

Yeah, yeah.

Give it a go. But it's, you know, you can't mandate it because everything's different every time.

Yeah. And like, it's. I get it. Like, it's tempting to have, like, this playbook or this, you know, version five of.

Something that tells you exactly how you should behave and exactly how you should structure things.

The Vision 5 is only because you want to charge a game for Vision 4, right?

Yeah, sure. Well, in. In this imaginary construct that we have. Yeah. But, like, it's really tempting to have all the right answers and have something that you can go to and say, this is what we should be doing in this scenario. I get why that's tempting.

And the. The answer of, like, you know, I'd like. I try my best not to say it. It's always a lazy answer. But, like, the. It's not a lazy answer, but it's a. It depends sort of does. You know, context is really, really important. Sometimes the right answer doesn't actually matter. It's getting people involved so that they can try something and then make it better.

So I Think that, you know, if we had. For me, articulating what the value of an experienced grandmaster or a coach is, is. Yeah, mindset and those kind of things, you know, the ability to help people, you know, be better or accelerate. But often it's experience and, and to me, it's applying that experience when they go, well, how can we deal with this?

It's.

It depends. Here's three or four things I've seen other people try and what happened when they tried it. And so it's. It's kind of. You've got a mental playbook, right? I've seen them try this and this worked for these reasons. I seem to try this, this failed, but it was probably for those reasons and then articulating those as patterns or choices that they may want to try. So it is a form of a playbook, I think, but it's. It's a mental playbook you build up based on doing it for a while. And I think that's part of the value that an experience, scrum master or a coach can bring.

Yeah, and I guess that's where the coaching actually does come in, you know, because what you want to do is get people to think for themselves with, you know, the information of. These are some things that you could potentially try. But if somebody thinks for themselves and comes up with an answer themselves, it's much more likely to be successful because it's theirs and they can see where things have gone wrong. And it's not a binary. It worked. It didn't work. It might not have worked so well. So we might need to change this sort of a discussion.

And then they sometimes come up with stuff that you never think of, Right. They just come up with the coolest shit ever. And it's like, well, that was obvious, but I wouldn't have thought about it.

I've never failed to be surprised by the creativeness of other people.

Yeah, that's kind of cool.

And how much. Almost constantly my idea is not the right idea.

So I was like kind of closing it out. We go back to that planning bias.

I think, you know, I've been kind of mulling it over my head because it is a new concept to me. We've seen. I've seen a little bit happening in the market around this idea of moving a PMO to a Value Office. So from Project Management Office to a Value Office, I've seen some good implementations, some bad ones. You know, I've seen the Value Office become more of a coaching circle. So, you know, experienced scrum and agile coaches Going out and helping new teams grow. I've seen some rebranding. The behavior in the shoes never changed. It was just the word project became value. But one of the other things I kind of read about and never had the luck to try yet is the idea that if you're running a board that goes, you know, backlog up next, what to do, doing done, which means they meet the definition of done. It's tested, it's documented. Done done, which for me means they meet the acceptance criteria from the product owner. And that's typically where we finish off that they're introducing this idea of a value column. And that was once it's in production and it's been.

The product owner stakeholders have to come back and proved that the value they expected to get from that effort was achieved. So we're getting some business benefit. So Back to you. Nine years ago we thought we'd build this feature and 50% of our customers would use it. But actually the number says only 40. If I tie that back with the whole UX kind of user experience up front on what customers really want. And again, not a place that I've played particularly heavily in. But for me, my understanding is you kind go out and do some early engagement about what does a customer really want? If I did this, is that going to meet their need? From your buyer's point of view in this idea that you kind of wanted to force in a retrospective or review, I think, you know, we've built something right, but have we built the right thing and should we carry on building the next thing? Is that what you're thinking? It's kind of a combination of all those things into almost new pattern or ceremony, accept feedback.

That's that feedback loop that exactly that I was talking about and that you've got some external perspective and you're actually saying what have we learned?

So I don't know if you want to call it done or done. Done or done.

Because you know, anybody that's investing, the product manager or the go to market person, when you say to them, I'd like you to come back and prove that the value you expected out of this investment was achieved. It's definitely going to be dun, dun, dun.

It will be if you're a smarter organization. You know that most ideas aren't actually going to in their original form aren't going to satisfy the outcomes that you actually want. You should be accepting that up front and celebrating teams that can find that out as early as possible. That is the point. So I want to see teams as close as possible to those, to those outcomes. And I want to see us constantly challenging how we can learn if we're on the right path as quick as possible. So if that means, I think visualizing that is a great, is a great way of achieving that and asking that question from an external perspective or from an internal perspective, but making sure that we're actually asking that question and getting. And actually doing those course correction changes that we should be doing, but something to actually build that in and to have that as a, as a system, course correction feedback method. Right, Cool. Right.

Well, we look forward to you working out what that is and then we'll get you back. Maybe we can get it sorted and you can talk us through how the hell we do it.

You're going to finish that with me saving the most awful sentence of my life, which is system, force back?

No.

Okay, we'll close it out. So when do you think you'll be finished and you can come back and tell us how to do that? To which you're going to use the other sentence that you don't like? Depends.

I'll never be finished. I haven't figured it out in the last nine years and I'm probably not going to figure out definitively in the next nine. Yes.

Means it's a hard problem to solve. If we're available.

Put it out 80.

20 and let's the community finish it.

We're open source.

Exactly. I'll commit to talking about it publicly soon, so.

Well, that's the false commitment we talked about last week.

Yeah, yeah. Chris Le Grange was on last week and we were talking to him.

About, you know, how do you, you know, you got some stuff you need to do and you know, it's, it's not critical. It's not critical path. It's something that you personally want to do but you know, everything else always becomes more a priority. So how do you do it? And what he said was he creates a force commitment. He creates a date where he's promised to deliver something that this is required for and that forces him to deliver it on that day. So, yeah, force commitment. So there we go. You know, we'll book you in for a podcast sometime later this year to easy. Give you a forced commitment to come back and give us a pattern for no worries. Excellent. Hey look, thanks for your time. Really appreciate it. It's been great show.

Thanks, Tony.

Thanks for your time.

Catch you later.

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 girl Sam.