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

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

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 an interesting and agile way. We're going to do a bit of a Q&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 3 to 4 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 Mae. 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 within 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 fangirl 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 prioritization?

Yeah, basically. Boom, boom, boom. 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 know really what's in it.

That's all 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 2 years ago, it's still sitting there.

Camping gear can stay in the storage cage. Yeah.

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 that 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 brought 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 2 weeks.

You observe.

I've got to watch. I just 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 do 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. Yeah.

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. 'Cause 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 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 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. Cause I took that as a challenge, as in you've never seen it. I don't, I'm not sure that's going to work. I'm like, we'll show you. Did enjoy the way you'd 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 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's 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 them, 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. An 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 DevOps 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 and 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 been 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. Thank you. Yeah.

And the problem with that is now we have handoffs, right? 5 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 3 teams in 3 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 3 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, right? 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 boil 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 you use the retro ceremony, we focus on what 3 things are you going to do next? It's only ever 3, right? Because there's 20 we could deal with, but what 3 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 an 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 macro-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 T, 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. These are 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. Being able to teach your craft is very different than being 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 organization, 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 joke 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, Shagility. 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 patterns 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 brought in by a sponsor or leader, and I get brought 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 have 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 right. This is an example I had with one team I worked with, and I knew one of the people from a previous life. 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's 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, "Oh, 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 supported, 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. You 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 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 of 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 MetaCast guys, Josh and Bob, and they basically came out and said, the answer is, 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 theory of Conway's 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, 9 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 9 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 your job? And halftime 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, Fuck 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 then depending on some personality types, okay, which you're saying before, you get people that are really upfront, they're like, 'No, I don't like it, I'm gonna 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 subtle 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 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'll 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 anti 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 were 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 quiet quit, what I will typically see is the team will then engage with that person to try and help them. They'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's struggling to do the work this way, they just culturally can't. Get it or their skills aren't at the 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. 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 want to use the word fun because there's so many fun retro things to do. I got memes going. We 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 quieter as a 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.

So 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 laptops. 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 timebox it. And then somebody would go, right, next. And then they would go in and dot 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 COVID 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 4, and today we're a team of 13, and only 2— or a team of 5, sorry, and currently there's only 3 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 redid the social contract, but maybe the mistake we made is we didn't start from scratch because there was some predefined ideas, especially in my head of what it should look like because of what I know's worked. 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, yeah, there's 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 just urban legend. But anyway, the story goes, the researcher put 5 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 5 chimpanzees. So, the chimpanzees knew not to touch the banana. Then they took one chimpanzee out, brought a new one in. New chimpanzee comes in and goes, "Ooh, 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, "Ooh, banana," goes to go for it, the other 4 chimpanzees beat the snot out of him. They then introduced new chimpanzees until none of the 5 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 5 and you're going to 13, and by the way, 13 is too big for one team, So you've got 5 and you bring in 1, do you tear it down? And then you bring in a 7th, 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. And that's one of the challenges as a coach. 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 who have done it before aren't bored or just quickly do it without any interaction, right? 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. 'Cause 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'd 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, where you 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, that 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 somebody who's hand-wavy. 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 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 was 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 the 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. It 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 to 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. We don't have to talk in the retros all the time.

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

But everybody has to be engaged. So it's that 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 2 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 to 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. Yeah, 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 2 weeks on it or 3 weeks. So typically one of the things for data I found really successful was 3-week iterations, not 2 weeks. I have some theories about why it works better, but time after time, 3 weeks works, 2 weeks doesn't at the beginning. We should strive to get to 2 weeks. But let's actually deliver something in production from an idea to production in 3 weeks before we chunk it down. And some coaches don't agree with me. I had a podcast the other day and he said, try it with one. Wow. One day. And I'm like, ah.

That's a lot of ceremonies.

Yeah.

They're short ceremonies though, because they'd be, what would it be? 10-minute backlog grooming, 10 minutes from planning, 5-minute standup. 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? Yeah, of course we do, because it's valuable. Yeah, I haven't seen that in the Scrum Guide. It's a pattern from Kanban. It's a valuable pattern. "Ah, 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 standup, 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 whether 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 2-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 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 start it 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 sighed 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 wadjaw. 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, timeboxing, 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 prioritization at the top level to say, what's number 1? You can only have 1 number 1. No, you've got 1 number 1. 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, they're second equal sort of thing. We've got some ways to go, I think, Mei, is what we're hearing, but we're conscious, we know we're cheating.

So you're not cheating, following the pattern to the purity of the pattern. If you're saying to me that there's 5 things that people want delivered and you're able to isolate into 5 different things and you've done your way of working in such a way that 3 got delivered and 2 didn't, then that's great. That's a great pattern because 3 of them are done, 2 of them aren't. But those 2 that weren't done haven't impacted the ability to deliver the first 3. 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 6 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's 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 2 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. Time 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 thread 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's 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 it's going to be my next question.

So it was— we've used Product Canvas for our last 3 or 4 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 versus 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 Agile, it's not going to 100% work for us. We can't really say no to everything for 2 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?

I'd like to say it's HIPO, high, low, pull, organize.

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 prioritization 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 Agile 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.

Yep.

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. 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, you know, 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 been dropped out of the cycle, right out of the supply chain. And so they want both of those. And You 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, ah, 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 a head of data or somebody else form that product manager role. So they have a responsibility to 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 doing 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 of 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, 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 walked 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. That's not, whereas previously, oh, I can't be available 50% of my time or come to your standups. Like, 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 when 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 must feel safe that they attend. So product owners should be at standup, 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%, you know, 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 old 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 3 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 patterns 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 in 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, right? 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 we, 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. And 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 anti-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 one that— last question on, damn, this is biting us in the bum, what do we do?

What do you reckon? Pets in 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 tonkotsu ramen.

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's 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 gotta 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 the 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 5 points. How many hours is 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's a point. A point's as long as you say it is. And that's 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 sensing a lot of Jira hate 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 in Jira. But anyway, to close it off, my question then, so stir fry is one size, what's another size?

So 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 initiados— 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 2-minute noodle job. No, Hamish, it's a 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 2 minutes and then it takes 10 hours, but sometimes it does take 2 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 is there's a bunch of lenses I can use on your sizing.

Yeah.

I can use the time one, 2-minute noodle versus something that takes 12 hours. That's a good sizing for me. I infer value out of that 2-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?

Yeah.

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 hand-cut 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 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 pretty 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.

Thank you.

Excellent.

Cool, we'll catch you all later. And that, 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.