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 Temperow.

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 Wellington meetups probably last year or the year before and saw you speak. And it was one of those talks that I 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 Alcott.

No.

I think actually—

Cheese will get people there.

Yeah, from memory, I think it was actually partly your slide deck, you know, because it 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 you 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've sort of laid myself down with it and it's just a good way of thinking through something. And it's different, right?

'Cause it's not stock art, it's not, you know, a photo of, you know, the standard now seems to be some kind of pretty photo in the background with a couple of words. So, that uniqueness of visual.

Badly drawn.

I don't remember it being that bad, it was probably better than stick figures. But anyway, what we do for somebody who'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 we're all kind of really, our kind of core interest, our shared interest is agile and helping to make New Zealand organizations 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 9 years, but my background originally was in electronics, so I did electronic engineering and a master's 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 love being a programmer, I don't know, I was probably with questionable quality. I cared more about the people-y side of things than about technical purity. Really cared about 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 9 years ago. So, I had started it when I was working in Ireland. I was working for a large company, and I kind of got involved in the projecty space. I was still working as a programmer, but I was leading a few things. And for about 3 years, we were working on this one major new product. There was probably about 30 of us working on it, for about 3 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 3 times longer and 7 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.

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

Yeah.

However.

It's always a however.

Yeah, so the however is we released it and nobody really cared. Oh. Yeah, so like we were ultimately unsuccessful 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 nights 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, he worked at an incubator and he said, "Hands up who works in product development and software?" So I 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 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 kind of naively introducing a bunch of practices around the stuff that I was working in then, fairly, you know, kind of navigating in the dark. There wasn't a huge amount of Agile awareness or groups around 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 had fairly good scope to be able to make change there, and we kicked off teams and introduced Agile. 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 2-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, 9 years ago, that must have been back where, was Agile Coach actually around then? Was it really, 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 knowledge or experience. So I think the title itself is largely, you know, it's largely wasted conversation. But, you know, it's useful for people who want to search for one of you on LinkedIn.

Yeah, true.

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

And I'm sure, you know, as we do in IT, uh, 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—

I'm sure, yeah, delivery managers or delivery coaches. And I like, ultimately, I don't really care, um, 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 a— 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, you know.

Fighting the good fight.

Yeah, exactly. 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 default anyway. I'd say unless you're a team that's steady forever, 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? Because you can always inspect and adapt what you do.

Yeah.

Right? Nothing's ever perfect. There's always something you could work on to see if you can improve it.

So, yeah, you might be a well-formed 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 may be not things that that team has, I guess, the influence or the control to change. So, 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 into doing great stuff and not wasting 3 years of their life on a project.

At least you delivered on time, right?

This is too soon.

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

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

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

I think Wellington was still, and like New Zealand in general, is still fairly advanced worldwide 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. Cool.

So, before we kicked off, we were kind of talking about what we're going to talk about, and you mentioned a 3-letter 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 a pilot's approaching the runway, even if they think it's marginal, there's a bias to stick to your plan. And you, because you've got a plan set in mind, it makes you, um, 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 sticking to that plan rather than taking into account those external influences.

So I suppose, um, you know, in previous lives for me, we talked about the concept of, you know, well, I've spent $100,000 trying to put this product in, um, you know, I really can't write that off, I can't throw that $100,000 away. So, you know, 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 $100,000 at it. You know, you've got to actually look and say, is that next $100,000 actually worth it? 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 you just have that plan, there's a tendency to, you know, to stick to that plan and to sort of be blinkered. To information that, you know, that plan may not be—

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

Exactly, and you've put time in it, you like, you own that idea, you've probably done loads of things, loads of vision sort of exercises.

Stood up and preached it. Yeah.

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

Yeah, yeah, yeah.

So, um, So one of the things I always struggled with was, you know, when you're talking to somebody senior 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? And it was typically, well, you know, it'll take as long as it takes for the team to build it. They haven't built it before, so we don't know. We can give you a guess, but we're just guessing. And how much is it 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, uh, 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, it's a complete guess based on some science or fact or experience, typically, but it's still Yes. That doesn't go down particularly well, right? 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? 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. Yeah, yeah, yeah. I thought it was like no estimates, no plan, no code, you know, these are the new buzzwords, there's no anything.

No, no. And I don't, I wouldn't say that that's the point of it at all. One of the outcomes in one of the papers I was reading 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 created 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 accidents or those mistakes or those errors aren't human mistakes, or shouldn't be viewed as just that 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— and 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 like no different with those outcomes that we're trying to achieve, or somebody's working on a project or a feature or 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? Like, how to— 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 movable, we have a natural bias to try and follow. Have you worked through in your head yet what some patterns or things we could use to—

So, like, for ages, like, one of the things that I've loved kind of battering is the sprint review. I've seen them kind of just be relatively worthless, and a lot of times, I facilitated worthless ones of them, where it's sort of like story point theater, or you're talking about these Jira things have been done, and we're getting feedback from stakeholders and telling stakeholders about things. Those things are good things, but I think it's like 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. Like, if I think back on that again, I'm going to rant about that project that I worked on.

Only 9 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, like, 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. I think it's 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. I'm going to steal that. One of the things 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 and analytics teams more than apps development teams, well, finally, 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 it, it seems to fit the way they've always worked, and therefore, we don't really introduce produce 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.

Okay.

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 teams self-organizing, changing the way they work, focusing on the things they want to work on next, delivering, you know, things a little bit better and faster and those kind of faster later, but actually delivering into production, all those kind of things. And what I say to them is, look, and I think I got it from the Metacast, is let's do Scrum for a while and then when you're ready, you can move back to Kanban when you think you've got either the way the Metacast guys talk about it 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 going to 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 going to work. And then we'll consciously focus on it until it becomes an unconscious behavior that we've adopted. Does that make sense?

Yeah.

So, yeah.

The thing, Kanban done well takes a lot of discipline. 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, done 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 to pursue change, collaborative change, using the scientific method as a team, right? So, I think it's always worth bringing those back to a team and saying, 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. A really valid approach. And 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. Like everything we say, I'm going to try and not say it today, but the "it depends," like, context is so important. And talking about any team's process without without knowing more about it and 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 think I like the idea that you've 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. So I suppose I give it a little bit of research around no estimates, you know, 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 collaboratively 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.

Them.

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 that I've worked with go on and they use story points forever. 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, it'd be good seeing it just, like, re-termed as, like, No Shitty Companies or something. 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 Structuring that discussion about complexity, and, you know, if the anti-pattern is that they're being taken as commitments, and as for what they're 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 the 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, right? 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 the way you work better or worse is a really important process.

Yeah, yeah. And like Kanban talks about that, it doesn't say use a retrospective. I've worked with a ton of Kanban teams that do retrospectives and it works well. They're 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're not working on how you're going to improve as a team, that's You know, they can be such a great thing, you know, in retrospect.

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

I think it's like storyboarding though, right? They can be used for good 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. 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 that 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, you know, 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 there are, my point is, there are ways of doing these things well, and like you were saying, doing them doing them in a way that can damage a team's 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's 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 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 anti-patterns at an organizational level.

And you struggle to get product ownership as well, I find, 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.

It's just one of their many hats.

Yeah.

Come across that.

I think the other thing I find is, uh, 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, it's 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. Um, 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 It's quite common that you're brought in to say, like, 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 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 of if, you know, if they're willing to change as well. And it's sort of starting to 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 people along in that journey and helping 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 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'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, as you said, you become an influencer in the organization to a degree. You're there to unblock and build those relationships. And often that can be a little bit fraught when you're in that role. And so the idea of that contract of what you will and won't do from them, what's acceptable, gives you that kind of grounding that you know where due north 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 there to do. Some people may not know what an Agile Coach or what a 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 coaching contract I think that might have been part— I wrote an article a while ago that is basically about, like, are 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'll 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 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 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 coaching, 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 you know, I think that actual side of things is— need to be careful with that skill and needs to be like respected and actually used properly. And contracts are a great way of setting up that relationship so that you're explicit that is this a coaching conversation that you voluntarily come into, that you want 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 and 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 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've got the Scrum Guide, you've got— I didn't realize there were other variations that people were logoing up. But anyway, 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 that 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 not a lot of stuff readily available out there 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, but not one that I'd heard before, if I had thought about it, I might've got there, but I probably wouldn't have. So, yeah, that's again why it tweaked my interest as something that was incredibly useful.

Yeah, and we've bandied around, and 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, right?

Yeah, no, I was looking forward to that one coming out, because I was quite keen to sign up adopt that again, uh, just to make sure that, you know, sometimes you, you, you are under stress and, and there are shades of gray, and, 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, uh, I'm now getting into a situation where I should really start questioning whether I'm breaching that code. Yeah, um, 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 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.

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.

So, is it similar to that?

Yeah, and we often do a team charter. 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 with 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 we adopt that? For what we do. So there are industries where there is a code of conduct.

Yeah, yeah, so the Standard Professional Coaching.

So it's kind of a known pattern. So again, for us to, you know, it was a room of really talented people.

Yeah, it still should be something because like 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 it.

And also because, you know, Agile is becoming a bit like big data was in Myspace or digital transformation. Let me not go there, or I'll be ranting 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 Wild West.

Oh, it is absolutely in Wild West, and then it comes down.

Everybody gets bored or finds it's Wild West and jumps off. So, um, you know, the idea of a code of conduct where at least if they read it and it makes sense to them and they hold themselves accountable, people that are renting this for the first time, um, it's valuable, right? It's, it's should do some good.

Um, yeah, so hopefully you'll kick off another one and we'll have another go at Yeah, 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 their publishing and reuse? I've always found Wellington really good at sharing.

I think the Agile community in general is amazing. It's relatively unique in that everybody is quite open source, you know, to like a massive extent. There are some organizations, some consultancies that aren't like that, but I think 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 you would 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 wider, people are falling over themselves to share what they've learned or what they've tried or what they've messed up on.

And I think, um, just going back to your, um, 9 years ago, sorry to bring that up again.

It was that night.

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 listen to somebody or see what somebody else has done, But to apply it with a team in their situation where they are in their maturity model and their organizational state, 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. There's ego involved as well as wanting to share.

Oh yeah. I guess there always is a bit of ego involved, but somebody—

good ego. It's not Lawson Bay ones, but it might be good.

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 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 without understanding what's going on for people and what 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 is definitely a history of these things being implemented as a thou shalt whatever. I don't believe in that myself. So, I think like that, it ultimately does come down to people and relationships.

Yeah, I'm with you with the cookie-cutter approach. As we talked about before we started, I'm seeing that becoming more and more prevalent. And, you know, I used to— I learned my lesson early. 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, yeah.

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

Yeah, and like, I get it, like, it's tempting to have like this playbook or this, you know, version 5 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 again for what you did in Vision 4, right?

Yeah, yeah.

Sure.

Well, in this imaginary construct that we have, yeah. But, like, it's really tempting to have all the right answers and to 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 answer of, like, you know, I try my best not to say it, it's always the lazy answer, but like, it's not a lazy answer, but it's a "it depends." It 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, for me, articulating what the value of an experienced Grandmaster or a coach is, You know, 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 to me, it's applying that experience when they go, well, how can we deal with this? It depends. Here's 3 or 4 things I've seen other people try and what happened when they tried it. And so it's kind of, you've got a mental playbook, right? I've seen them try this and this worked for these reasons. I've seen them 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 a mental playbook you build up based on doing it for a while. And I think that's part of the value that an experienced 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's a, oh, 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 thought about it.

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

Yeah, it's kind of cool, eh?

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 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. I've seen the value office become more of a coaching circle, so experienced Scrum and Agile coaches going out and helping new teams grow. I've seen some rebranding, the behavior and 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 their 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 used, used, uh, the product owner stakeholders have to come back and prove that the value they expected to get from that effort was achieved. So we're getting some business benefit. So back to your 9 years ago, you know, we thought we'd build this feature and 50% of our customers would use it, but actually the numbers 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 then, you know, that for me, my understanding is kind of 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 bias point of view and 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 a new pattern or ceremony.

That's it, 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 done done.

Done done 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 upfront 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 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 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 system course correction feedback method, right?

Cool. All right, well, we look forward to you working out what that is, and then we'll get you back and maybe when you've got it sorted and you can talk us through how the hell we do it.

You're going to finish that and saying the most awful sentence of my life, which is system force back.

No, no, 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, uh, depends.

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

Means it's a hard problem to solve, therefore a valuable one.

So put it out, 80/20, and let the community finish it.

Yeah, we're open source. Exactly. Yeah, I'll commit to talking about it publicly soon.

So that's the false commitment we were talking about last week.

Yeah, yeah. Uh, Chris LaGrange was on last week and we were talking to him, um, about, you know, how do you— you know, you got some stuff you need to do, um, and, you know, it's, it's not critical It's not critical path, it's something that you passionately 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 forced 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 date. So yeah, forced commitment. So there we go. Yeah, you know, we'll book you in for a podcast sometime later this year to 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 chat, guys.

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.guru.