AgileData #35 - AgileData WoW Q&A - Hamish Gray and May-Lyn Hu

Foreign.

Welcome to the Agile Data Podcast where we talk about the merging of agile and data ways of working in a simply magical way.

Welcome to the Agile Data Podcast. I'm Shane Gibson.

And I'm Hamish Gray.

And I'm May.

Hey, welcome team. Good to have you on the show. So today we've got a new format that we're going to experiment with in a interesting and agile way. We're going to do a bit of a Q and A. We're going to talk through some of the experiences you've had in your organization, applying Agile and data together in a new way of working and where I think I've seen some patterns before that may help with some of the problems you've got. I'm going to jump in with some, hey, I've seen this in another customer or another team and this is what they did. Before we rip into that, why don't we get you both to give a little bit of background about your journey combining this agile and data stuff together.

I'm going first. I'm Hamish. As I've said, I've got a reasonably long history in data, 20 odd years, but probably only three to four years in agile. I've been coached directly by Shane before, so if that's a good or a bad thing, I'm not quite sure yet. Currently work in a different organization where I first met Shane and we've been trying to channel Shane as best we can. Really excited about today and what we can learn.

I'm May. So originally I was an accountant before moving into the data space. Realized that I really liked numbers and then switched into doing data science financial institutions. I currently now work with Hamish, which is an amazing thing. But ever since I've moved into tech, I've basically embraced the Agile lifestyle so much that when I moved houses, my partner and I both work in tech. We sprint boarded our actual house move. So this is how much of a fan girl I am with it.

So how much of the backlog did you not deliver?

All of it, because I'm crazy about it. Nothing got culled.

Did you put your boxes in the garage in a backlog order of prioritisation?

Yeah, basically. Which was like meant to be unpacked first. What was most used? Yeah, yeah.

I have to admit some of the boxes are still sitting in the garage and that's how we were able to adapt really quickly because it was. We're going to abandon unpacking this box because we actually don't really care what's in it.

That's right.

We do that in prioritization all the time. Right. You go back to your backlog and you go, hey, that really good idea that we had two years ago, it's still sitting there.

The camping gear can stay in the storage case yet.

Excellent. All right, so first question, first area you want to focus on because we've done a little bit of pre work, a little bit of backlog, sprint grooming and we've got a bunch of questions here. So which one do you want to hit first?

Well, let's maybe we'll start at the beginning. Shane, when you first bring agile to a team, like what's the number one thing you're trying to get across? I remember when you came and met us at that place, I know stuff happened, I wasn't really aware of what was happening, but it all worked out. Did you have a plan or was there a flavor you're trying to get across? What's the number one or number two thing that you really need to get across first to get people into it?

The first thing as a coach is observe. So I made, I've made in terms of true agile behavior. I've made so many mistakes over the years of working with teams and so one of the first mistakes I made was after I worked with my first team I jumped to another organization with a new team and they were starting from scratch again and I naturally started them off from where the last team ended up and that was a massive mistake because in my head I was like, we're here. But that team wasn't right. So first rule I learned was go back to the beginning. Yeah, because you don't know where that team's at and so treat them as if they're starting from scratch. The next thing I learned was a team had some success with some patterns and so when I went to the next team I was like, hey, here's the patterns are going to work. But the context was different, the organization was different, the team was different, the level of maturity, their ability to adopt was completely different. So again I learned that basically to begin with you've got to observe and that's a really difficult conversation with somebody. So sometimes you'll get bored in and it's let's get the team delivering. And you say cool. So the first thing I'm going to do is I'm going to rock up and I'm going to observe for two weeks.

You observe, gotta watch.

I just, I watch, I watch whatever you're doing, I watch your stand ups, I watch your retros. If that's what you're doing. I watch the way you work. I ask some questions which typically start with why? And then as a result of that, I get an idea of where the problems might be. Now, the interesting thing is everybody else already knows where the problems are. Just I don't. And so I'm just trying to understand and elicit that. And after that, then the way I think about it is I have a set of patterns that I've seen other teams being successful with, and so I just suggest them. I go, hey, I think you have a problem around this. Do you agree? And then I say, I've seen other teams this or this and had some success. I think with your context, it might work. Do you want to experiment with it?

I noticed that a lot with you. As in, what I think I hear you're saying is this. Have you thought about this? You wouldn't actually tell us what to do. You'd more make suggestions about how we could perhaps make it better. Or what I hear I'm saying is that's obviously a deliberate thing you're doing there.

So there's two parts to that. One is something I learned in the old days around my sales background is by articulating back what I think you're telling me, we get clarity that actually, I've heard you and I've understood. I've listened. One of the problems I have is I like to talk and not listen, so I have to be very conscious about. Okay, I think this is what you're saying. And the key thing about that is it agrees the context. Because if we're both working with different words or different contexts, then we get miscommunication, and then it's just a suggestion. It's your way of working. And the thing that amazes me is, and you know, we probably did this in the old one as well, is I'll go, you can try that. I've never seen it work. These are the ways I've seen it fail. But give it a go. Because actually, I've worked with teams that managed to rock it or do something that I go, I wouldn't do it that way, but. But it works for them. And that's the key. It's about experimentation. It's about inspecting what you're doing, adapting it, and then getting a feedback loop to say, it worked, keep doing it. It didn't work. Stop doing it.

I used to enjoy it when you'd say, give it a go. I've never seen it work before because I took that as a challenge, as in You've never seen. I don't. I'm not sure that's going to work. I'm like, we'll show you things. Did enjoy the way you challenge us like that. And at least it was good to be understood or to check our understanding. Do you think then just second question in my head here. Is the data context helpful as well? Because as in, is data different in Agile than, I don't know, delivering a website, perhaps?

Yes. So I think that the patterns we apply in software engineering from an agile point of view, are applicable in the data domain, but the data domain has a whole lot of complexity that just makes them harder. And I still don't have a clear articulation of what those are. I'm writing an article for my way of working right now about it, which is making me think about it. The best I've got at the moment is when you're doing software engineering, you're in control as a team. You control the database, you control the application, you control the way the data is entered, you control the way the feedback loops happen and so that you're in complete control. In the data world, we're dealing with exhaust, we don't control the way the data is created, we don't control the way the data is managed, and we don't control the quality of the data. And so if we think about the problems we have, it's all around fixing those problems. We also don't have good tools for taking the data work and chunking it down into an hour to get something to production. For some reason, the way we work and the tools we have means it's always weeks before we get something in production, and that's when we're doing well. If you look at the software engineers, they can deploy a button in an app quickly. And in the data world, it seems like there's so much we have to do to get value to our consumer, to our customers, that we can't get it down to that level yet.

Do you think we'll ever be able to get it down to that level, or is it just because you're using data to make decisions and there's too much complexity within it that it'll never end up being like a deployment of a button?

No, I think we can get to a deployment of button, but I think it's a hard problem. There's a whole lot of work in the market at the moment around data contracts, and that's the idea of pushing between software engineering teams and the data engineering teams. A contract that is held Programmatically, that says the data has to look like this. It's an API. This is what the data looks like. If that contract gets broken, then the software engineering team fix it. It's not our problem. I think that'll solve a lot of the problems for us. The next one is how do we break our requirements for our stakeholders down to small chunks? We have a tendency to go, we want to solve big problems, whereas actually we can deliver just that. First question. If the first question is, how many customers do we have? If we can get that in front of them tomorrow, then that's a good thing. We know the next question is going to come, which is, where are they based? What are they buying? How much are they buying? What are they not buying? How do we make them buy more? We have all those other questions coming, but let's just answer that one question first. But as data people, we seem to want to boil the ocean. We're not particularly good in our skills and our careers at the moment of refining it down to really small chunks of work.

And do you think that's a personality thing? Because I think in this new team, we've been trying to push that quite a lot, as in, let's just get something. Something's better than nothing, get feedback. Because I've seen what I think you're saying that we have the temptation to deploy the entire fact table rather than just the first two columns, which is customer count. How do we break that? Is it automation? Making deployments easy test? What are the things you're seeing successful teams doing to reduce their time to production? Because in my eyes, it's. We want to do multiple per day deploys. I know that's a little bit out there. Most data teams are maybe once a week, but that's where we're aiming at the minute.

For me, the North Star is reducing the cost of change. We do automation because we reduce the cost and the time to deploy. If we think about that, that if we could make changes really quickly at low cost, then we're going to be more open to chunking down and experimenting. We tend to bundle things together because the cost of change is high. For example, if you're not in control of your own releases, if you have to hand your releases off to another team, who then move it to production, a traditional way of working, then that cost of change is massive. They can change it if it goes wrong. And so again, in the data world, we've been taught to bundle things together into big bunches of work, which is the anti pattern For Agile, right. Agile is break it down to smallest chunk, get it into production, into the hands of the customer first as quickly as possible and then ask for feedback. So we want to bundle those changes together so we get better value for money. If you think about the software engineering land and their agile approaches and their devop approaches, they've got good at being able to deploy themselves safely so their cost to deploy is much lower so they can do it more frequently. That's what we want, we want feedback.

Do you think, speaking about how data, we're used to doing things in really big chunks and do you maybe think that it's an evolution of where data has come from where a lot of teams potentially work in silos and it's this is my bit of work, this is the project that I've been working on by myself. And then when we begin to look at Agile things can be a little bit interchangeable because you have things planned out, you've got tickets and everybody should be able to jump in and help within each other having to deal with that mental shift. How have you had to manage that before? Do you think that's part of the issue or it's a bit something else?

A lot to unpack in there. I think one of the anti patterns is roles, not skills. In the data world we focus on roles and actually right now we've gone into this in the modern data world we've gone to this hyper specialization where everybody's hyper specialized, everybody's doing one small chunk of that data value. Yeah, one tiny thing.

Yeah, yeah.

And the problem with that is now we have handoffs, right? Five people in the value chain to get the data out the door and they're all hyper specialized and so now they have to hand off to everybody else and that causes friction, that causes a problem with our language. There's a whole lot of dependencies. So ideally what we want is cross skilled teams that can get the work done amongst themselves and we focus on the skills in the team, not the roles in the team and then once we do that we see a change of behavior.

Right.

Once the team focuses on skills, not roles for some weird reason, it's because we're humans, we see a massive change in behavior in the team. For me that's one of the first patterns I will always apply is getting the team to understand their skills matrix their T skills.

I remember that actually the T skills and then I related it to what we've got going on in the current environment and we are, if anything we are roles, not Skills. We've got effectively three teams in three separate roles with a range of skills across those sort of things. So what would you suggest did a T skills analysis to figure out where people think they are, what are the chunks?

If you had to define the teams and then the boundary between the teams, there's going to be requirements. Gathering, engineering and visualization are the three chunks that we typically see.

Almost. It's engineering analysis, data analysis and data science are our three divisions.

Yep. So I'd combine those first two together to start with. The data scientists are always a challenge because they're research and experimentation rather than a more production value chain. So again, one of the things we say from an agile point of view is don't bore the ocean. Don't try and take on a massive amount of uncertainty at once because it's hard. Break it down to small chunks of uncertainty, remove them, make things better and then go and deal with the next one. Right. And that's why if you're using Scrum and use the Retro ceremony, we focus on what three things you're going to do next. It's only ever three, right. Because there's 20 we could deal with. But what three are you going to try and execute? I'd take your requirements and engineering and I'd merge those teams and I'd focus on how they can work together. And then once you got that rocking, then I'd look at the data scientists and say, okay, how do they come into the team? Now that's a challenge. Because their value chain, the way they work, moving that data through, is typically different to what engineering and more dashboardy county and amounty type teams will do.

We touched a little bit on T skills before internally for us, how do you bring in and have people have the same or similar sets of T skills, but also embrace and encourage diversity for diverse thinking? Because sometimes I feel like you could end up with everyone kind of being the same. If you're looking for a certain skill set, how do you break things up a little bit to have different ideas, especially when it comes to analysis.

If we break it down to acro level skills, which is what I do, there is a skill around stakeholder management, there's a skill around facilitation, there's a skill around eliciting or gathering requirements, there's a skill around engineering, there's a skill around testing, there's a skill around documentation, and there's a skill around release management. For me, those are the big macro skills that I constantly see. We map the team at that Level, we don't care if they do Python or Scala or SQL. And then what we find is people have a strong team and then they have a bunch of secondary skills that they are good at. I use a framework around novice, practitioner, expert and coach. So novice is somebody who's learning, right? They're doing it, they're starting out in those skills. They've got a little bit of skills, but they don't do it every day. Practitioner is, hey, that's my job. This is the skills I do. This is what I love doing. I do it every day. And an expert is, hey, I am. I rock this skill. I can show other people and help them out when they're stuck. And then the jump to coach is a really interesting one for me because that says I can coach and mentor somebody else to be an expert like me. And that's actually, again, a different set of skills. Be able to teach your craft is very different than be able to do your craft. But that's okay. Not everybody wants to be a coach. Some people just want to be an expert and just keep rocking what they do. They love it and that's okay. So we get the team to map out those macro skills with that sense of depth and then we look for gaps and overlaps. We want both. And so we tend to find. If I categorize them because I've just finished doing this. If you come from a BIE role, you tend to be on the left of that T skills, right? You're around that stakeholder management, facilitation, requirements gathering. You're really good at that. And actually you tend to be really good at documentation for some weird reason and maybe a little bit of testing. Actually, if I'm an engineer, I'm in the middle of that T. I'm in the engineering. Ideally, I'm pretty good at testing. Ideally, I've got some good documentation. I might actually be quite good at requirements gathering, but I tend not to want to do stakeholder management. I'll probably go down to the release management side. And then if you look at a tester, depending on where they come from, they're either going to be what I call the inverse mohawk. They're either going to be good at facilitation, requirements gathering and good at testing and documentation because they came from a BA role, or they're going to be actually strong in the middle. So they're good at testing and good at development and engineering because they came from a development role. Get ready to map them out and then you overlay them and Then what you're looking for is you're looking first of all for double ups, because that's what you want. You want it where you've got multiple people that have practitioner or expert level in that skill. Because when somebody's on leave or somebody's busy doing a task, somebody else can pick up the next task to be done. So that's the first thing you want double ups and then the second thing is you want to identify big gaps. And normally you look at a data team, they will have a massive gap in testing because it's a QA team that typically does it as a separate team. And we want to bring that skill into the team, but we don't want to hand that work off. So that's one I normally see. Sometimes the bas are held outside into a separate part of the organisation and that's a problem. So we want to bring those skills or those people into the team. The goal is the team can do the work without relying on anybody else. That's our goal.

Just swinging back to agile a bit more. So then, do you think it works for all types of cultures and teams? We're finding perhaps a little bit more technical people, a little bit more robot like. So enjoy the segmenting, work down and then it's harder to sell into non.

Tech people and drink the Kool Aid. That's been my trick with it. How do we indoctrinate them in the cult?

So don't treat it as a cult. So, yes, I think it can be applied everywhere.

Definitely a cult. Definitely a cult.

I thought that right when I first started, I came from a more traditional background and I was like, what's this hippie Kumbaya? So we experimented with it for a while before I drank the Kool Aid. I think it's the best we've got. I'm hoping that a new set of practices and ways of working and patents comes out in the world that are better. But I still think compared to anything else, this is the best way of working. Now, what's interesting is, and I probably did it with you in the old gig, when I come into an organization, I typically get bought in by a sponsor or leader. And I get bought in for one of two reasons. The team is starting their journey and the leader goes, cool. We want them to have some help and support, so bring a coach in. The second one is they've started the journey and they've hit a wall. They're stuck, they're not accelerating, they're not growing and they're not enjoying it. And so I get to come in to help fix that problem. I have this concept of a heat shield. So the first thing a team needs to be safe is this idea of a senior leader who's going to take the heat when things go wrong and not the team. And then as part of that conversation I had with them is I say, okay, so what will typically happen? At some stage, a person will vote themselves off the island or the team will vote them off the island. So we will get to a stage where somebody says, this isn't for me, I don't like working this way, I don't want to work this way, I'm not going to work this way. And that's okay. I don't agree with them, I'm disappointed. But they have that choice. So what I say to the heat shield is, when that happens, what are we going to do? You need a plan, because these are valuable people to the organization. They just aren't going to work with the team that way. And so that's the first thing we need to do, is we know it's going to happen and we need to set up a safe environment. That person can make that call and be safe. The second thing then is I used to try and guess who it was and I never got it wrong. There's an example I had with one team I worked with and I knew one of the people from a previous life, and you tag them as a traditional waterfall developer. This is my job. Give me a document, I'm going to code to that document. If there's words in that document, that's what my code's going to do. If you tell me that my code's wrong, I'm going to point to the word in the document that says it's right. It's your document that's wrong. That traditional waterfall behavior. And so when I went in, I was like to myself, yeah, you know, this person is going to need some support because I don't think they're going to adopt this way of working. They were the one that loved it the most. There was actually a stage where there was a change of leadership and the heat shield disappeared and a new person came in and was like, I don't believe in this agile stuff. It doesn't work. And that person actually said, if we change the way we're working back to the old way, I'm leaving. People have to be supportive, they have to be safe. They have to adopt this way of working as a choice and they should have the right to not adopt it. And still be okay, but they can't be part of the team anymore.

You're saying heat shield there. Shane used to call it shit umbrella is what I remember. It definitely wasn't heat shield.

It's PG rated, Hamish. It's PG rated.

So I have had some feedback that in New Zealand the shit umbrella term is okay, in some other countries it is unacceptable. I've now tempered my terminology to be more open and inclusive.

So if we think about the reverse, right? So in an ideal world you have a senior leader that wants to bring it in, that can be your heat shield and beep umbrella. What happens if it's. There's like a guerrilla revolt from under. So. So you have people that have worked in Agile and they're just like, I love it. I really think this is a great way of working. We can see the current ways that are working that are not doing. Do you think one, it's feasible to do it from bottom up rather than top down and two, what do you do when you don't have this heat shield if you're going to go from bottom up?

So I've only ever done it from the bottom up. I've never worked with an organization that was top down. And I see a whole lot of anti patterns around things like SAFE and Scaled Agile, where there's Agile Theater, which is top down. But we actually aren't adopting a new way of working. So I have a very strong opinion on why SAFE is not agile. There's a great podcast by the Medicast guys, Josh and Bob, and they basically came out and said the answer should you ever use SAFE is no. And if you work for an organization that's starting to adopt it, leave if you like Agile, if you don't like Agile, stay. So for me, I've never managed to work for an organization that's top down. It's always been bottom up and that's good in some ways and bad in others. Right? There's a whole lot of anti patterns that come out. If you're going bottom up, the heat shield has to be there because what you're saying is the organization's not adopting this Agile way of working and you're going to go and completely change everything. You're going to change the way you're funded, you're going to change the way you deliver, you're going to change the way you communicate. Everything is going to change. That's an anti pattern to the organization. The organization's based on a hierarchy. There's a serious Conway law that doesn't matter what you do, you're always going to bounce back to the organizational structure. And so you need that heat shield to break it and actually allow you to form your own organization. What happens next is really interesting. So nine times out of 10, when the team's rocking it, the other parts of the organization see that the team are getting success, enjoying their work, having fun and delivering good shit and they want to adopt it. Then we see some really interesting behavior. So one organization, the PMO Project Management Office, brought in an external BA to write up their Agile way of working. And that BA did not talk to the team that was doing it. And so they brought out this handbook of this is the organization's way of doing agile. That was done in complete isolation of the team that were actually doing it. And to me that was an anti pattern. The other one is we often see somebody will go and stand next to the standups and just listen if we're using Scrum and then think they have enough knowledge to try and adopt it with their team. And again they make the same mistake I did at the beginning. They say, oh, this is how you do it. These are the rules. Rather than we're going to change. When you start to scale and when you move from one team of nine or less to more, either in your organization or outside your organizational hierarchy, you have a whole lot of new problems. Scaling is hard.

How do you keep up the enthusiasm with the scale then? Because you're always going to hit hiccups and bumps along the way. And especially if you've got people, we'll say adjusting, I want to say slowly drinking the Kool Aid with it. How do you maintain momentum?

That's a damn good question, which I don't have a good answer. Humans maintain momentum when they're getting success and having fun. And actually sometimes the challenge causes momentum. So this is a really interesting one actually. If I think about this so often, you'll see when you start off with a team, they're not on board. They're like, it's been done to them. So one of the first questions I'll ask when I'm observing is why are you doing agile? And half time you'll hear, oh, I'm not. We got told to do it. You've got a bit of a challenge. What you find is sometimes when adversity comes in, the team will then get stronger to repel that adversity. There's scenarios where the team is starting to work this way and somebody comes in outside and goes, agile doesn't Work, it's crap. You're never going to get this done. And then the team are like, if you it's working for us, we can make this work. And then they solve some of their own problems because now they've got this enemy to fight. One of the rules of being an agile coach is do no damage, right? Do no harm. And it's really tempting to architect that adversity because it's going to help the team form. But that's a harmful practice. As a coach, we should never do that. But when we see it happen, I often see the team kind of reform against that. So I find that an interesting behavior.

So that type of adversity if you're, it can be really verbal and depending on some personality types of pain as you're saying before you get people that are really upfront, they're like, I don't like it, I'm going to verbalize it. What happens if you have the, maybe not the opposite or the different this concept of like silent quitting but that, that very subtleness towards it where you can't really see the agitation but you can feel maybe the environment change because people just check out with it. They're like, I'm giving you bare minimum, not dealing with it. Have you had something like that before?

Yep, multiple times. So that's the vote. Vote themselves off the island behavior. Okay. And so what would typically happen? And these are all generalizations. So let's go back to one of the first patterns that I recommend a team does is this person that person. And it's an exercise where it's a bit kumbaya but it's very valuable, I've learned over time. So we get the team virtually or on a piece of paper to have two columns and on the right hand side is this person. And these are the behaviors that we like as a team. So we'll see things like turn up to a meeting on time, don't talk over the top of somebody else. Allow somebody to speak and have their view, provide creative feedback, don't ridicule the person. And then that person is the ante of those. You turn up late, you talk over the top, all those kind of behaviors. And we do that early because we want a safe way for somebody to call out behaviors, not people. So the conversation when it goes is I think you're being that person. In the old days when we're co located they'd point to the line and it's a really safe ish way of calling out that. But when you see that it's got to a stage that we need some intervention because somebody's now calling it out. When we see the quiet quitters, what we would typically see is the team know they're not engaging. If we're using Scrum, we have a bunch of ceremonies that are quite interactive. We've got Sprint planning, we have the retros, we have the demos. There is a bunch of ceremonies where everybody is involved and when people quite quit, what I will typically see is the team will then engage with that person to try and help them. I'll try and bring them into the team again. Most people are fair, most people are reasonable and most people are kind. So they will try and help that person out and they will either see something like that person struggling to do the work. This way they just culturally can't get it, or their skills aren't at a level and they're getting tasks that aren't fitting their skills and the team will help them out for a while. Interesting enough, after a while, if that person doesn't make it, the team will then go unconsciously. We're spending too much time propping up and helping that person. And then they will quiet quit them for them, they will isolate them, they will just stop involving them. And at that stage, that's when the heat shield needs to come in and say, what are we going to do about that? And have a conversation with that person. So the humans are pretty good at noticing these things and helping eventually. Sometimes people just don't like that way of working and that's okay, but they can't stay on the team just to.

Sidetrack for fun, speaking about the ceremonies, keeping it interesting while remote, and allowing if you have different personalities again, and you've got a lot of people that are, I'll say, quieter or a bit more reserved when you're in person. It's a lot easier to have their focus when you're doing all of these ceremonies. When we're working remote, it is very easy to get distracted. Do you have tips or tricks on how to make all the ceremonies, especially providing feedback during retros, engaging for them? And basically, I don't use the word fun because there's some fun retro things to do. I got memes going. We've got a lot of memes, and that's good for the guys, but, yeah, just thinking different ways for other people out there that have quite a reserve team.

The best pattern I've got is tastycupcakes.org, i think, which is a website of interactive things to do from an agile point of view. And they actually updated a lot of these from being on prem co located to remote, which is awesome. If you're following scrum and your scrum coach is involved, typically, I suggest they go and find ways of changing the retros to be something slightly different. So I have a set of them, boats and anchors and those kind of ones. They're all based around this idea of good, keep doing bad, stop doing middle. Have a think about it.

I think.

I can't remember, was it your team, Hamish, or another where we did La Vista baby with the Terminator.

Yeah, and I'll be back.

You can't change it every time though, right? Because then it gets a bit trite. But mixing it up again now and again is interesting.

How about getting people to converse? And obviously you want to try and make it a safe space, but sometimes some people just.

Don'T speak.

We tend to start off with a team charter as well. It's one of the foundational documents I'd get everybody to do, which sets some of the rules of engagement. So when we have a virtual meeting, does everybody have to have their camera on or not? It needs to be the culture of the team. One of the really interesting ones I use as an example is we were co located, this is before COVID with a team. And they were quite introverted. We were doing retros, which were stickies on the wall, quite interactive. And the team didn't like it, it wasn't them. So they decided that they were going to do silent retros. And I was like, what are my famous words? That's not going to work.

Shane's famous last words.

Nah, that's not going to work. That's not how you do them. But let's have a go. So what they did was they're using Microsoft Azure, DevOps or whatever. They went. One of the reasons I love this team was they didn't use Jira, so they were using Microsoft Teams version, which actually is more useful. And there were some interesting features in there. So what they did was they would come and sit in a room with their laptop, so they were in the same room. They would then go into those boards and fill out the cards silently for their retro and they'd time box it and then somebody would go right next and then they would go in and.it'in the product and then they go right next and then they would use the chat feature and type in the chat to give feedback and then they would create the cards and what they work next. And pretty Much did it without talking and I was like, that's not me. I did not enjoy those retros. But remember, it's not about me, it's about them. And they did it. Yeah. And I believe they still did it after co, because they could do it remotely, actually probably rocked it better than the team that couldn't do it that way. So your team culture is important. The other thing is as soon as a new person comes into your team culture will change and you have to adapt because of that.

So for us in our current team, 12 months ago or a little bit more, we were a team of four and today we're a team of 13 and only two or a team of five, sorry. And currently there's only three of those members left and we've got a whole. We've got 10 new people basically. And we went and did that. We didn't do this person, that person. We did what we call a social contract. And then everybody really enjoyed it, it actually worked and it got us over a few little humps and stuff because I have done that before and I thought this would be good. We did a different way, which was fine. And then I guess we, we redid the social contract. But maybe the mistake we made is we didn't start from scratch because there were some predefined ideas, especially in my head, of what it should look like because of what I knows, work and actually reflecting potentially a mistake. I know it, it works for the guys in my direct team, but we know it doesn't work everywhere or that's our assumption. So is it in that regard, Shane, do we rip it up? Go back? We did do it together but the problem was I think Moses had already written on the. Already written on the board and therefore do what you're told sort of thing. And maybe that's the other thing, I'm not sure, but it's.

It biased it by, I guess in the induction, right, you see what was previously done, so you assume that was it. But as you say, when someone new gets added, the culture changes.

So people.

Yeah, there's a really great research out of a university study from many years ago and I need to actually go and find out whether it's true or disturbing legend. But anyway, the story goes, the researcher put five chimpanzees in a cage and at the top of the cage they put up a banana and every time a chimpanzee went to go grab the banana, they used a fire hose and caned all the five chimpanzees. So the chimpanzees knew not to touch the banana. Then they took one chimpanzee out, bought a new one in, new chimpanzee comes in and goes, oh, banana, Right. Goes up, they all get wet. Yeah. So that's cool. He knows not to do it. Then they take one out and bring a new one in. A new one goes. All banana goes to go for it. The other four chimpanzees beat the snot out of them. They then introduced new chimpanzees until none of the five chimpanzees in the cage had ever been wet. But every time a new chimpanzee came in to get to the banana, it got beaten. And so, as humans, once there's a set of rules, especially when we're starting off or we're coming into a new team, we feel uncomfortable breaking the rules. I'd say tear it down. Ideally, you're going to end up with a similar set because some of the same people in the room. The challenge is, though, if you start with five and you're going to 13, and by the way, 13 is too big for one team. So you've got five and you bring in one, do you tear it down? And then you bring in a seventh, do you tear it down? So it's that cost of change. You can't sit there constantly just doing social contract ceremonies. And so that's the challenge is that balance of when do you redo it? When do you not? Where's the value in it?

It was hard enough reintroducing ourselves every time there was a new person, let alone redoing the social contract.

Yeah, but that's important. That's one of the challenges as a coach is we have techniques or games that we can play to introduce each other. But when a new person comes in, you really need to mash it up so that people have done it before, aren't bored, or just quickly do it without any interaction. That's one of the fun things is going, okay, what can we do this time that gets us the same outcome, the same pattern, but it's different. So as a coach, you're constantly learning. You should be. You've got your playbook, and then you need to add to it every time or tell the team to do it. This is an interesting thing for me. The patterns I have, most of them aren't ones I've found. It's ones teams I've worked with, have found. And I've just gone, that's useful because people find cool stuff.

I was thinking about your Silent retros. And I'm sure some of my team would like a silent retro. And I obviously hate it when you've got big personalities in teams or people who like to talk a lot and then people who don't like to talk a lot. How do we make it fair? So how do you then ensure everybody. And I guess in our smaller team we're all. It works pretty well, but when we go a bit bigger, we struggle to.

To get everybody engaged at the level. Perhaps that I think would be productive, but I know it's not what I think, it's what everybody thinks.

I'm a big fan of safe psychological profiling. You know, the whole disc methodology. There's a Simpsons one, which I love. We can get the team to profile themselves using a website and they tell them which Simpsons character. The goal of that is for the team to understand that everybody's different. There are people that are detailed and people that are big hand wavy. And as a team we need all that diversity and it's okay. But the way we converse with somebody who's detailed is different to the way we converse with somebody who's hand waving. The one way we engage with people that are extroverts is different to the way we deal with people that are introverts. So one of the things I would always look for is are the quiet people happy? Some people just don't want to talk. Now we need to engage them to make sure they're not isolated. But if they're happy not talking up all the time, that's okay. As long as they're a proactive member of the team, they'll do it in different ways. So another example, right, and it comes back to pre Covid was one of my litmus tests about how we were going as a team and how I was going as a coach was the volume of noise in the room. So when I walked in and we did that waterfall handoff thing, everybody was isolated and it was very quiet. And then with the early teams I worked with, I could see this buzz. There's lots of conversations. People get up and go to a whiteboard and troubleshoot. There was constant movement of team members. And one of the teams I started working with, we didn't get that they were still stuck at their desks. And I was like, ah, this isn't working. But again, I'd learned to observe. So I observed what they were doing and what it was. Even though they were co located, they communicated via chat. That was a team culture. So they were communicating constantly. They just weren't doing it by moving desks and doing it face to face, they were doing it through their desktops and that was okay. But that sense of engagement that everybody reaching out to somebody else to get help, peer review, all that stuff was actually happening, was just happening in a way I didn't expect. So go back to your point. Get people to understand that everybody's different and it's okay that we do need those broad set of personalities that introverts like to be talked in a certain way and extroverts in a different way. So if we can change the way we talk to people that are different to us in a way that they like to be talked to or talked with, then that's helpful. And then is the team healthy? Is everybody enjoying their work? Are we getting work done? Are we engaging with our stakeholders and getting feedback? That's success. Don't have to talk in the retros all the time.

We wouldn't be there if we weren't talking in the retros though.

But everybody has to be engaged. So watch for the quiet quitting, watch for the voting off the island and make sure it's a conscious decision by that person in the team that they don't fit. And that's okay. Not excluded without actually wanting to be excluded.

So then, just a bit of a meta question. Can you introduce agile in an agile way? Because what I think we've been doing is piecemeal introducing parts of Agile and trying to choose what we do next and maybe we've picked some, made some wrong decisions here and there or is it big bang, everybody stop, start. And at the same time we've been doing a lot of work, doing a lot of things. Hence couldn't really take two weeks to train everybody to have you seen Agile.

Agile or I believe I only do Agile. Okay, so our goal is not to be agile, we're not doing an agile transformation, we're not adopting agile. Our goal is not to use this a word, it's not what we're doing. We're changing the way we work. So have more fun, do better work, get value to our customers earlier, get feedback and there are agile patterns we can use to do that. Craft your own way of working. One of the interesting ones for me is I will typically, after observing for a while, I will typically recommend the team start with Scrum. Even though the data value chain is very flow based, it's a much better fit. But the reason I get teams to start with Scrum is it's a forcing function, it breaks a Whole lot of stuff which makes people reform. So by putting iterations in, we're actually breaking that flow and giving them something that constrains them. You can only spend two weeks on it or three weeks. So typically one of the things for data I found really successful is three week iterations, not two weeks. I have some theories about why it works better, but time after time, three weeks works, two weeks doesn't. @ the beginning, we should strive to get to two weeks, but let's actually deliver something in production, from an idea to production in three weeks before we. We chunk it down. And some coaches don't agree with me. I had podcasts the other day and he said, try it with one, one day. And I'm like, that's a lot of ceremonies. Yeah. The short ceremonies though, because that'd be. What would it be? 10 minute backlog, grooming, 10 minutes from planning, 5 minute stand up. Yeah. So I find that moving to an iteration based model. So Scrum patterns help the team change the way they work. It just seems to happen. The other thing is SCRUM has very well defined ceremonies. And so I'm not a great fan of following the Scrum book, but there are a bunch of patterns. And so everybody says to me, oh, but we do. We're doing pure Scrum. And I'm like, do you use a Kanban board? Of course we do. Because it's valuable. Yeah, I haven't seen that in the Scrum guide. It's a pen from Kanban. It's a valuable pen. Oh, we do peer programming. Awesome. But that came from xp. What I find though is sometimes forcing functions help. So if we think about the daily stand up, it's a ceremony to force the team to have a conversation for 15 minutes every day about where they're at. It's a checkpoint. Our goal should be to remove that as a ceremony. Our goal should be everybody's checking in on such a regular basis that we don't need to spend that 15 minutes forcing ourselves to talk. However, when we get a new team member in, typically I'd suggest you go back to stand ups because that team member doesn't know how to communicate on a regular basis with the team. It doesn't understand how you work. So going back to enforcing function has value retros. Right. If we are constantly adapting our way of working and actually doing it, if we're constantly saying that part of the process doesn't work, here's what we're going to do to fix it and we fix it, then we don't need retros so they're forcing functions that have value and then once we're mature enough, we don't need them, then lose them because we're doing it anyway. But when something changes, have a think about when we need to bring it back. So I'm still on the fence about whether my tendency to move data teams to scrum first is a good thing or a bad thing. It works, but I'm not sure whether I'm maybe doing a little bit more harm than I should. I'm still beating myself up on that.

One. Currently doing scrum and two week iterations, but it's arbitrary because of the amount of change we get into our iterations anyway just due to the nature of things. So we're actually trying to set ourselves up in a way so that if and when the change comes, which invariably does and has, then we are ready to check in what we've done, deploy that, or at least be able to step away and move. I think that's helped in the last couple as well, where rather than complaining about the pivot, we know it's coming and it's just the way it works at the minute with the business we're in and we're finding that's working for us. But what is a little bit disappointing when we get when we set up the sprint and it's 90 points and that's what we're asked to do, we know we're not going to make it, but we started anyway and sure enough come the end we've done 60, but 20 of that's new and this sort of.

Stuff. Why do you commit to 90 points.

Then? That's a good question. I just side because I don't have a good answer for.

It. So this is one of the key things for Agile is the team are empowered to say no. They have to be empowered to say no. If they can't say no, then you're at real risk of doing Wagyu. They can be told to change what they're going to deliver, but then we reset. It's a reset. Right. And so the clear thing we have to say to our stakeholders is we will change whenever you want us to change, but there is a cost and consequence of that change and we'll tell you what it is and you get the right to say yes, I'm going to wear that cost and then we do that change. You can't have your cake and eat it too. You can't say here's 90 points, you've committed to doing that. Okay. Oh Halfway through, can you do these extra things? But I still. No. Yep, you're changing it to a degree that the agreement we had at the beginning no longer exists. So let's stop, let's check everything in and let's start again. And that's what we should do. Unless you're using flow. If you're using flow, then we take a lean approach, which is all around. How do we make that change with minimal waste? And so the patterns we use are different. I tend to really think about those macro patterns of iterations, time boxing and the patterns that support that, and flow, where change is constant and the patterns that support that. Sometimes you can do a hybrid, but hybrids are dangerous, especially when you're starting.

Out. It's interesting because I think where we came from, at least, which was flow in a reasonably agile organization, then this has just been the best of getting a little bit more clarity around when we can get stuff done. And I think that's what we've done and we've at least forced the prioritization at the top level to say, what's number one? You can only have one number one. No, you've got one number one. Okay, put them in order. And then that's happened and it's worked. And then we always tend to deliver 1, 2, 3. It's then the 4, 5 get bumped out, but they're also needed because really they're not 4 and 5, that second equal sort of thing. We've got some ways to go. I think may is what we're hearing, but we're conscious, we know we're.

Cheating. So you're not cheating, you're just following the pattern to the purity of the pattern. If you're saying to me that these five things that people want delivered and you're able to isolate into five different things and you've done your way of working in such a way that three got delivered and two didn't, then that's great. That's a great pattern because three of them are done, two of them aren't. But those two that weren't done haven't impacted the ability to deliver the first three. If you've got constant change, I can almost guarantee that your way of working now is very focused on how to get the work you've done before the change happens and put it somewhere where it's semi safe and be reusable when you go back to it. And again, that's great pattern. You lose some of it because we time switch. And when we go back six months later, we're not quite sure what the hell we did, but at least that work's not completely lost. Some of that value has been retained. So that's good behavior as well. I can infer that maybe your team are checking things in on a more regular basis than every two weeks, just in case things change. They're like, okay, it's checked in, I'm done, I can move on to the next thing, times switch out thing and that thing's already there. I don't have to say, give me a day to finish this off and check it in. So you probably observe some good behavior that comes from that constant threat of.

Change. I think so. I think we're getting there from where we used to be and having some clarity at least knowing with the retros. For us it's like the check in going, okay, we know that the pivot's probably going to come, so how do we, like you said, mitigate the process and how do we help each other and get to a checkpoint out.

Of interest on that so often? 9 times out of 10 we will see the pivot being telegraphed early. We see the conversations, we sniff the, oh, that priority is no longer the priority. This is going to change on.

Us. So we've had things dropped as well, which is great, as in we're no longer doing this, stop doing this, because it's no longer priority because obviously it's just the type of business which is good. But I think a lot of our pivots come out of, I'm going to say poor planning and that was.

Going to be my next.

Question. So it was. We've used Product Canvas for our last three or four products and got amazing feedback on it, as I've shared with you. And then some of these other legacy bits of work, they'll come out of nowhere and they wouldn't be unknown, they're just undiscovered. Yeah, undiscovered, undocumented. So I think that's a bit of a frustration too because we're in this place where we've got some super well thought out product canvases and it's that's got legs of its own now verse legacy things that come up and they always pop up and oh, we need this. And of course it's operational, therefore has to happen 2 hours ago Sort of thing, so that's fine. But that's the conflict we get. Hence why Strict Agiles is not going to 100% work for us. We can't really say no to everything for two weeks. Like maybe we could in the old gig you could stop, but here we probably need to be available. It's almost 24 7, right iteration.

With a black and white beginning and an end and the committed tasks at the beginning. And nothing can change. That's not going to work for you. So you need to bring in some of that flow behavior. But now you're working in a hybrid model and you have to figure out how to do that, find the patterns that work. Out of interest, how does prioritization happen for you at the.

Moment? Like to say it's Hippo highest, very.

Common. And then when is that conversation had? When are things prioritized for.

You? So I guess our head of data, she'll be off. Speaking of stakeholders, it's a reasonably flat structure, right? So an ELT discussion. We need to look at inventory and then therefore these are doable. We're pretty close to that level really. So it does come in fairly strongly by us setting ourselves up in this way. We've forced the prioritisation as you can't have more than one, we've got to choose one. That is pretty much if CEO says go, then pedal to the metal is pretty much how it.

Works. One of the things I'm experimenting with at the moment is this idea around product management versus product ownership and what happens in the software engineering world, the product world, the other disciplines or domains which adopt actual ways of working. And how do we adopt those that product owner, product manager seems like a really interesting conversation normally. So I could almost infer that your head of data is your product manager involved with stakeholder discussions, the prioritization of what's next. Is there somebody between that head of data and yourself when you start doing an information product, is there somebody adopting that product owner role?

No.

No. Do you tend to bring a subject matter expert in to the team for the period that information product needs to be delivered? So if you're talking inventory, do you bring in an expert from outside your team on.

Inventory? The head of inventory would come in and do the work with us, sit with us, we do the product canvas with him, and then we'll talk to him fairly extensively. So he effectively takes on the product ownership role of the products we're currently doing. There's ops, there's other business functions as well that also have stuff to do too. But I guess our head of data, she can prioritize it in terms of our team's.

Resources. And then if I give you an example for inventory. So if you're doing an information product around inventory and they want delivery Time between each of the inventory steps from out of warehouse to delivery to customer, that's one thing they want. And then the second one they want is lost deliveries where something's being dropped out of the cycle, right out of the supply chain. And so they want both of those and got to the stage where you're like in this iteration you can have one. So it's not the big prioritization of the work to be done, but now we're down at almost a feature level, a metric or something smaller. Who makes a trade off call? Would it be the head of.

Data or that subject matter expert, the SME. And we've literally done that in a lot of the planning as is, as was. What do you want for this particular piece? I need it now. Okay. Not what it was. So they'll make the call there and then and we'll using the canvas we can draw that out pretty quickly. And then even day to day issue with data in X we've got a 2% error rate, push on, find the answer and they'll make the call pretty much on the wire. So no operational system's perfect. Hence we'll find problems and things got to operate. And as we drill in we find these issues. But yeah, they'll 100% make the call. But head of data will be aware of it. But we're enabling his job to do stuff. So he just needs to be aware of the pitfalls or the choices, which is I think correct because he knows what he wants. They know what they want pretty.

Well. Yeah. And that's a common pattern. So if I go back to one of the problems around applying agile in the data domain, this is one of them we will typically see ahead of data or somebody else form that product manager role. So they have responsibility, find the funding to deal with the stakeholders, to prioritize what's next at a big level, have that roadmap, have that vision that they typically form that product manager role. And then when we're doing some work, when we're delivering some information products because we're jumping across business domains, often we bring in a subject matter expert or a product owner, people that are making a trade off for a period of time for the information product or set of product information products and then that person will leave and somebody else will come in and that gives us some challenges because we have to train them up. Now if you're not in an organization that is agile across the organization, then that idea of a supporting role, product owner doesn't exist. That behavior doesn't exist. We have to train them how to do it, we have to train them on how we work, what's our value chain, how do we work, how do we do the things we do in the data space to a level that they understand it enough to help make trade off decisions. If we look at software engineering, the product managers and the product owners are typically static. They're typically there for a long time. They're not swapping in and out, especially not the product owners. They have a domain, they're doing the E commerce site and they stay doing the E commerce site with their team for a long time. So that swapping in and out of a product owner gives us a whole lot of uncertainty that other agile teams don't have. And so therefore we need to look at ways of doing.

That. And to be honest, we have product managers in the other parts of the business who do exactly that. They'll manage certain areas. But in data people do have to jump in and out and we haven't like we did at the old gig, we train product owners. Not directly done any official training for these people we're bringing in, we've just shown them and walk them through and it's been less cumbersome because it's not like you need to read this, you need to understand all this. So I actually think that's worked and maybe we over egged it before, whereas this time it's maybe it's different sort of people, different business. There's no official, you're a product owner, you need to be available this sort of time. They just, you just need to be available for me to talk to you during the day. Yep, no dramas. It's not. Whereas previously, oh, I can't be available 50 of my time or come to your stand ups like. And there's none of that. Which is, it's an interesting difference.

I've noticed obviously when you have the software you're saying people are available most of the time and they're maybe a little bit more embedded in with the team. How do you see then the ceremonies go? In data, you have these pseudo product owners but they're separate. So for us our ceremonies and whatnot are definitely just within our data team. We don't include anyone.

External. I would invite the product owner to every ceremony that the team feels safe that they attend. So product owners should be at stand up, product owners should be at backlog grooming for the products that they own. They should be at Sprint Planning and the team might want to invite them to the retros. But may decide not to because that's your internal laundry. That tends to be the one the team wants to protect. Quite rightly because they're discussing what didn't go well and they need a safe space to do that. But the product owner should be involved everywhere else. If we have proxy product owners, we have a problem. I encourage teams to say if there's no product owner, we're not going to do the work. The product owner should be available at least 50% of the time. When we were co locating what we used to say was come and sit with us for the whole day and do your work or come and sit with us for 50% morning or afternoon and do your work. And then the team know you're available and will interrupt you because it's their time to get answers. That's what we're asking for. Often they go, oh, I'm too busy. Because the poor product owner gets given it as a second job. Do your job and do this. And it's interesting. You go, I've got 13 people working on this for three weeks. Here's the cost. Are you telling me that you don't want anybody to manage the trade off decisions and where the value gets created? Seriously, is that a good business decision? Sometimes that works, sometimes it doesn't. The other thing is I'm doing a whole lot of writing at the moment around skills versus roles. And so there are supporting roles. Some teams, when I think about the patents that have been successful is they bring a supporting role of product coach into their team as a member of their team, especially at the beginning. And that person onboards the product owners early before they come into the iteration. So they pre work the product with the product owner. They go, this is how it works. And by doing it early they're able to do it when it fits the product owner because they haven't been committed to the information product or the iteration yet. The other thing is it also gives them a support network where there's somebody else they can go and ask a dumb question. One organization I worked with when you were a product owner, you got a little bit more tax and that you had to be the product owner mentor for the next product owner. The next product owner was able to call a coffee with you and just ask you those dumb questions and you had to help them and that was good because you had that done to you. Somebody helped you when you started. So just think about how you put that supporting role in place. Whether it's product owners helping product owners or a product coach inside your Team as a supporting role. We often find the product owner role becomes a real bottleneck for us and there's a whole lot of anti patterns. Why? It's not a role or skill we teach. They're doing it as a second job. Nobody told them the value of it. They didn't want it, they just got given it. We need to solve that. It's a problem in the data space or data domain because we switch them in and out on a more regular basis than other domains do. It's kind of where I got to on that one because I'm still ruminating and trying to see where's the patterns and where's the Andy patterns, because it's been annoying me for a while. Just before we close out any last one, top of mind that you're thinking you're rocking and everybody should do it the way you do it or. Last question on. Damn, this is biting us in the bum. What do we.

Do? What do you reckon? Pets and meetings is a winner, mate, like.

Always. Oh, absolutely. I was going to be like, I'm very proud of our sizing just because it's funny and it's around food more than anything.

Else. Stir fry and gourmet burger and tonkatsu ramen.

Yeah. Noodles. Yeah. But the diversity all the.

Way. I don't know if we did it last time, Hamish, but when we experiment with sizing as a team exercise to understand what sizing is about, the fact that it is about relativity. It's about the team having a conversation of why some think it's a large and some think it's a small. We've got to be really careful that points aren't used as weapons. If we start seeing an organization behaving badly and starting using points as a weapon against a team, I encourage the team to stop pointing. Just don't do it anymore because it's hurting you more than it's helping you. But when I do the exercise where we kind of training, I use.

Fruit.

Yeah. I go grapes versus watermelon. What's the size.

Difference? In our original team, it was. So it's five points. How many hours does that need? An hour conversion. I pushed back pretty hard on that and I think I lost that war. But in the new team, at least, there's no question around how long is a point. A point's as long as you say it is. And hence why. I think actually the change to food helped break that a little bit. We still use points because Jira wants points. For some reason, we.

Can'T. That's because Jira is.

Evil. Yeah.

Yeah. I'm sending a lot of Jira heat.

Here. Two things. I don't like Jira because I don't find it a useful, usable interface and because it came from a ticketing system, not an agile system. So I find it hard to use. Complex and awful. The second thing is Jira takes us down an anti pattern of ticket prism. We focus on the tickets. All that works around those tickets, not around getting the value out to our customer. And so we get stuck in prison just moving the bloody tickets and Jira anyway, to close it off. My question then. So stir fry is one size. What's another.

Size? So it's. It goes instant noodles and something is instant noodles because the directions are on the packet and all you need to do is add water. We have a stir fry because most people really understand what the end product will really look like. And you have one cooking methodology, but it's just what you're adding to it. Then we've got gourmet burgers, which can either be on the high end or low end. You either make. You're making your own aioli and your own hand cut fries with it. But then in terms of the burger, when you think about it, it could be chicken, beef, whatever you want in the patty. And then we have something that's called a Tonkotsu ramen, which those food initiatives, it's 12 hours to make if you do it properly. But a lot of people think they can do it really quickly and they can't. So basically that's something that's like. It's Hamish. It's a two. It's a two minute noodle job. No, Hamish is the Tonkotsu ramen. It's not the same. You have to make the broth and have cooking skills that you. Sorry, Hamish, but cooking skills that you don't.

Have. Well, it's not like I say that's two minutes and then it takes 10 hours, but sometimes it does take two minutes. It's just. It's not always.

Me. I love that. And if you're okay, I'm going to steal that when I write up the articles and patterns around things. So what I love about that is there's a bunch of lenses I can use on your sizing. Yeah, I can use the time 12 minute noodle versus something that takes 12 hours. That's a good sizing for me. I infer value out of that two minute noodle versus value out of a gourmet burger. It's like it's quick, it's dirty. Is it enough or do I need the gourmet burger? And therefore I know I have to invest. There's that value thing, there's that level of expertise. It's written on the packet. It's almost like novice, practitioner, expert, right? So some people just can't do those big ones. But it's a skills thing. Skills and practice and experience. So how do we get somebody that they can actually craft that gourmet meal? And we have more people that do that.

Also. It's a stakeholder management that comes with it. So each version of it, you either have a very clear idea together and you don't really need to talk about it, but some of them like a gourmet burger, you're just like, does it come with handcuffed fries? Is it coming with onion rings? Like you don't know what it's meant to be, but you have a rough.

Idea. And then the other thing is, it's a shared language that I still don't understand what that last one is. So I'm going to have to go Google it and then go buy one. Because I'm like, yeah, I'm a foodie, I want to go try that. But again, it's a shared language. As data people, we constantly don't understand how the language we use with our stakeholders, our business people, they don't understand that language. As agile people, we often don't understand how the agile words we use, the data people don't understand and the business people don't understand. So again, we want to get to a shared language as closely as we can across all those different things. Hey, look, that's been great for me. Anyway, I found that really, really interesting. And hey, anytime I can walk away with a nice pattern like that food grading, I'm happy because I've got another thing for my toolkit for the next team I work with. So hopefully went away with some stuff that will be useful for you to keep accelerating the way you're.

Going. Totally. Thank.

You. Excellent. Cool. I'll catch you all later.

Data Magicians was another agile data podcast. If you'd like to learn more on applying an agile way of working to your data and analytics, head over to agiledata IO.