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

Join Shane Gibson, Hamish Gray and May-Lyn Hu as they talk through some of the experiences they have had in their organisation applying agile and data together in a new way of working.

Read along you will

Shane Gibson: Welcome to the “AgileData” podcast. I’m Shane Gibson.

Hamish Gray: And I’m Hamish Gray.

May-Lyn Hu: And I May-Lyn Hu.

Shane Gibson: Welcome team. Good to have you on the show. So today we’ve got a new format that we’re going to experiment with 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’ve seen some patterns before that may help with some of the problems you’ve got, I’m going to jump in with some. I’ve seen this in another customer or another team and this is what they did. Before we jump 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?

Hamish Gray: I’m going first. I am 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, have 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 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.

May-Lyn Hu: I am 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 within financial institutions. I currently now work with Hamish which is an amazing thing. But ever since I’ve been 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 split boarded, our actual house move. So this is how much of a fan girl I am with it.

Shane Gibson: So how much of the backlog did you not deliver?

May-Lyn Hu: All of it. Because I’m crazy about it. Nothing got cold?

Shane Gibson: Did you put your boxes in the garage and get backlog or whatever prioritization?

May-Lyn Hu: I meant to be unpacked first, what was most used. 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 we’re going to abandon unpacking this box, because we actually don’t know really.

Shane Gibson: That’s right. We do that in prioritization all the time. You go back to your backlog, and you go, Hey, that really good idea that we had two years ago, it still certainly.

May-Lyn Hu: It can stay at the storage.

Shane Gibson: 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 ones you want to at first?

Hamish Gray: Well, 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 favor you’re trying to get across plus the number one or number two thing that you really need to get across first to get people into it.

Shane Gibson: Just first thing as a coach is observe. So 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 on 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 of all I learned was go back to the beginning. Because you don’t know where that team’s at. And so they treat them as if they’re starting from scratch. The next thing I learned was, a team had some success with some patents. And so when I went to the next team. I was like, here’s the patents 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, and it’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’re going to watch, I just watch you, whatever you’re doing, I watch you stand up. So watch your retros, if that’s what you’re doing. I watched the way you work. I asked 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 know. And so I’m just trying to understand that 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, I think you have a problem around this, do you agree? And then I say, I’ve seen other teams listed with us and had some success. I think of your context that might work. Do you want to experiment with it?

Hamish Gray: 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 had more make suggestions about how we could perhaps make it better. Or what I hear saying is that’s obviously a deliberate thing you’re doing in.

Shane Gibson: 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. But 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 to context. Because if we’re both working with different words or different context, and we get miscommunication, and then it’s just a suggestion, it’s your way of working. And the thing that amazes me is, we probably did this in the old one as well, as all go, you can try that, I’ve never seen it work. These are the ways I’ve seen it fail, like give it a go. Because actually I’ve worked with teams that managed to rock it, or do something, there 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.

Hamish Gray: 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. You’ve never seen, I’m not sure that’s going to work, i am like we’ll show you thing, did enjoy the way you could challenge us like that. And at least there was good to be understood or to check our understanding. Do you think, just seeking question in my head here. Is the data context helpful as well, because as there’s data different in agile than delivering a website, perhaps?

Shane Gibson: Yes. So 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 into production. For some reason, the way we work in the tools we have, means it’s always 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 and an app, quickly. And in the data world. 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.

May-Lyn Hu: 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. But it’ll never end up being like a deployment of a button?

Shane Gibson: No, I think we can get to deployment of the button. But 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. That’s an API. This is what the data looks like. If their contract is 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 out requirements for our stakeholders down to small chunks. We have a tendency to go, we want to solve big problems. Whereas actually, we can’t deliver just that first question. If the first question is how many customers we have? If we can get them 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 this does answer that one question first. But as data people we seem to want to boil the ocean, we’re not particularly good at our skills, at our careers at the moment of refining it down to really small chunks of work.

Hamish Gray: And do you think that’s a personality thing? Because in this new team, we’ve been trying to push that quite a lot as in this just get something, something’s better than nothing. Get them get feedback, because I’ve seen what 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, we want to do multiple per day, deploys know that’s a little bit out there, most data teams maybe once a week, but that’s where we’re aiming at the minute.

Shane Gibson: For me, the North Star is reducing the cost of change, we do automation, because we reduce the cost, then 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 handle releases off to another team who then move it to production in 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. And to big bunches of work, which is the anti-pattern for agile, Agile is break it down to smallest chunk, get into production into the hands of the customer first, as quickly as possible, and then asked 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, or their agile approaches, or 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.

May-Lyn Hu: Do you think speaking about how data ware used to doing things are 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 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 thing, can be a little bit interchangeable, because you have things planned out, and you’ve got tickets, and everybody should get to jump in and help with 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 something else?

Shane Gibson: A lot to unpack in there. 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 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. One tiny thing. And the problem with that is, now we have handoffs and 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. Once the team focus on skills, not roles, for some weird reason, it’s because we’re humans, we see a massive change in behavior of the team. For me, that’s one of the first patterns I will always apply, is getting the team to understand these skills, matrix, and the key skills.

Hamish Gray:  I remember that actually, the team skills, and then I related it to what we’ve got going on in the current environment. And if anything, we have 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 team skills analysis to figure out where people think they are?

Shane Gibson: 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.

Hamish Gray: Almost, it’s engineering analysis, or data analysis and data science, are our three divisions.

Shane Gibson: Yes, so I combined 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 boil the ocean. Don’t try and take on a massive amount of uncertainty at once, because it’s hard, break it down into small chunks of uncertainty, remove them, make things better, and then go and deal with the next one. And that’s why if using Scrum, and use the retro ceremony, we focus on what three things you’re going to do next. It’s only ever three. Because there’s 20 we could deal with but what three are you going to try and execute, I’ll 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’ve got that rocking then I’d look at the data scientists and say, Okay, how do you like them 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 dashboard, county and amount type teams will do.

May-Lyn Hu: We’ve touched a little on testers 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 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?

Shane Gibson: 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 T, there’s a skill around documentation. And these are skill around release management. For me, those are the big macro skills, I constantly see, we met 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 starting out in those skills, they got a little bit of skills, but they don’t do it every day. Practitioner, that’s my job. These are the skills I do, this is what I love doing, I do it every day. As an expert, I rock the skill, I can show other people and help them out when they’re stuck. And then the jump to coaches are an interesting one for me. Because that says, I can coach and mentor somebody else to be as 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 micro skills with that sense of depth. And then we look for gaps and overlaps. We want both. And so we tend to find by categorizing first, before doing this, if you come from a big role, you tend to be on the left of that T skills. 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 it facilitation requirements gathering and good at testing and documentation because they came from a BI’s role, or they 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, getting 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 on that skill. Because when somebody is on leave, or somebody is 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’re looking 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 why I normally see, sometimes the BI’s 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. But the goal is the team can do the work without relying on anybody else. That’s our goal.

Hamish Gray: Just swinging back to Agile a bit more, so then do you think it works for all types of cultures in 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.

May-Lyn Hu: I think that’s the Kool-Aid. How do we indoctrinate them in the cult?

Shane Gibson: So don’t treat it as a cult. So yes, it can be applied everywhere. Definitely, I’m still there. 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’ve probably done it with you on the old gig. When I come into an organization, I typically get board in by a sponsor, a leader. And I bought in for one or two reasons. The team was starting their journey and the leader goes cool. We want them to have some help and support. So bring a coach in. And the second one is they started the journey and they’ve had a wall 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 a 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 the 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 what’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. This is an example I have one team I work 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 is going to do. If you told me that my codes wrong, I’m going to point to the Word and 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, 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, we just changed 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.

Hamish Gray: The thing you’re saying the heat shield, Shane you used to call it shit umbrella, is what I remember a diff. It definitely wasn’t heat shield.

May-Lyn Hu: It PG related.

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

May-Lyn Hu: 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 heat umbrella. What happens if it’s there’s like a gorilla 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.

Shane Gibson: 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 medical scholars, 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 good in some ways and bad in others. There’s a whole lot of anti-patterns that come out. If you’re going bottom up, that heat shield has to be there. Because what you’re saying is the organization is 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’s going to change. That’s an anti-pattern to the organization. With organizations 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 nine times out of 10. When the team is rocking it, the other parts of the organization see that the team are getting success, enjoying their work, having fun and delivering good ship, and they want to adopt it, then we see some really interesting behavior. So one organization, the PMO, project management, office, board on an external BA to write up their agile way of working, and that BI did not talk to the team that was doing it. And so they bought out this handbook of this is the organization’s way of doing agile that was done in complete isolation to 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 stand ups. 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, 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.

May-Lyn Hu: How do you keep up the enthusiasm scale then, because you’re always going to hit hiccups and bumps along the way. And especially if you’ve got people who say, I want to slowly drinking the Kool Aid with it. How do you maintain momentum?

Shane Gibson: That’s a damn good question which I don’t have a good answer. To humans maintain momentum when they’re getting success and having fun. And actually, sometimes the challenge causes momentum. 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, that 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, I’m not, we’re not 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 from outside and goes agile doesn’t work, it’s crap, you’re never going to get this done. And then the team are like, 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. And one of the rules of being an agile coach is do no damage. Do no harm. And it’s really tempting to architect that adversity, because that’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 reform against that. So I find that an interesting behavior.

May-Lyn Hu: Say, that type of adversity, it can be really verbal. And in depending on some personality types as you’re saying before paying it, people that are really upfront, they’re like, I don’t like it, I’m going to verbalize it. What happens then, many of the officer are the different, this concept of like Silent quitting, but that’s very subtle is 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 done something like that before?

Shane Gibson: Yes, multiple times. So that’s the vote themselves off the island behavior. And so what will typically happen, and these are generalizations, so let’s go back to one of the first patents that I recommend a team does is, this person, that person. And it’s an exercise where it’s big Kumbaya, but it’s very valuable. I’ve learned over time. So we get the team visually 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 the 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 kinds 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 that point to the line. And it’s a really safe fish way of cooling out there. 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, and 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, try and bring them into the team again. Most people will have fear, most people are reasonable. And most people are kind. So they will try and help their person out. And they will either see something like that person struggling to do the work this way, if they just culturally can’t get it or their skills aren’t at the level, when they’re getting tasks that aren’t fitting the 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 quite 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 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 stand the team.

May-Lyn Hu: And 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 obviously 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 it’s something fun, which I think to do. I got memes going, we got a lot of and it’s good for the guys. But just thinking different ways for other people out there that have quieter resulting.

Shane Gibson: The best patent I’ve got as tasty cupcakes.org, which is a website of interactive things to do from an agile point of view. And they actually update a lot of these from the 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 ones they’re all based around this idea of good keep doing, bad stop doing, middle have a think about it. I think I come in or was it your team Hamish or another where we did Bella Vista baby with the Terminator?

Hamish Gray: Yes.

Shane Gibson: Can’t change it every time they write because it gets a bit trite. But mixing it up again. Now again it’s interesting.

May-Lyn Hu: How about getting people to converse in? Obviously, you want to try and make it a safe space. But sometimes some people just don’t speak.

Shane Gibson: We tend to start off with a team charter as well. That’s one of the foundational documents I’d get everybody to do, which set some of the rules of engagement. So when we have a virtual meeting, does he really have to have the camera or not? It needs to be the culture of the team. And one of the really interesting ones I use as an example was, we were co-located. So this is before COVID with a team. And they were quite introverted. We were doing retros, which were stickies on the wall, that were 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 am I famous words? 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 using Microsoft as your DevOps or whatever they went. One of the reasons I love this team was they didn’t use JIRA. So they were using mark for soft things version, which actually is more useful. And there were some interesting features in there. So what they did was they would come and sit on a room with a laptop, so they were in the same room. They were then go into those boards, and fill out the cards silently for the retro and that time box up. And then somebody would go right next, and then they would go in and dot it in the product, and they’ll 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, we want the weakness 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. 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 you team culture is important. The other thing is, as soon as a new person comes in, your team culture will change. And you have to adapt because of that.

Hamish Gray: Though, 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 five and currently, there’s only us, three of those members left, and 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 were some pre-defined 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 in that regard Shane, do we rip it up, Go back. We didn’t do it together. But the problem was, I think most of it was already written on the board and therefore do what you’re told sort of thing. And maybe that sounds like I’m not sure, but.

May-Lyn Hu: It biased it by I guess in the induction, you see what was previously done. So you assume that was it. But as you say, when someone who gets out of, the culture changes.

Shane Gibson: There’s a really great research out of a university study for many years ago. And I need to actually go and find out whether it’s true or deceiving, 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 with a new one and new chimpanzee comes in and goes or banana. Right goes up, they will get that. 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 banana and it goes to go for the other four chimpanzee beat the snot out of them. They then introduce new chimpanzees until none of the five chimpanzees in the cage had ever been with but every time 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 challenges, 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 on one, do you tear it down, and then you bring in a semblance to tear it down. So it’s a cost to change. You can’t sit there constantly just doing a social contract with ceremonies. And so that’s the challenge, is that balance of when you redo it, when do you not? Where’s the value in it.

May-Lyn Hu: It was hard enough, we’re introducing ourselves every time there was a new person within the group and the social contract.

Shane Gibson: Yes, 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 the people who 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 till the time to do it. This is interesting thing for me the pens I have, most of them or ones I’ve found, as ones teams I’ve worked with have found and I’ve just gone that’s useful. Because people find cool stuff.

Hamish Gray: I was thinking about your silent retros. And I’m sure some of my team would like Asana retro, and obviously hate it, when you’ve got big personalities and 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 fear? So how do you then ensure everybody and I guess, in our smaller team, we’re all works pretty well. But we may go a bit bigger, we’d struggle 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.

Shane Gibson: I’m a big fan of safe psychological profiling. The whole disk methodology, there’s simpsons one which I love, we can get the team to profile themselves using a website, and they tell them which Simpsons character but the goal of that is for the team to understand that everybody’s different, that there are people that are detailed, and people that have 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 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, i think quiet people are happy, some people just don’t want to talk. No, 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 productive member of the team. They’ll do it in different ways. So another example, and it comes back to pre COVID, was one of my litmus tests about how we were going as a team and how we are going as a coach, was the volume of noise in the room. So we walked in, and we did that waterfall handoff thing, everybody was isolated, and it was very quiet. And then with the only teams I worked with, I could see this buzzers, 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 there, they were still stuck at their desks. And I was like, this isn’t working. But again, I’d need to observe. So I observed what they were doing. And what it was, even though they were co-located. They communicated via chat, there was a team culture. So they were communicating constantly. They just weren’t doing it by moving discs and doing it face to face, they were doing it through the desktop. So 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 get 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. And 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 as the team healthy as everybody enjoying the work, we getting work done. Are we engaging with our stakeholders and getting feedback, that success. We don’t have to talk in the retros all the time.

Hamish Gray: We wouldn’t be there, if we weren’t talking in the retros, though.

Shane Gibson: If 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 while that person on the team, they don’t fit. And that’s okay. Not an excluded without actually wanting to be excluded.

Hamish Gray: So then just a bit of a Meta question. Can you introduce agile and 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.

Shane Gibson: I believe I only do Agile. 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 I word, it’s not what we’re doing. We’re changing the way we work. So have more fun, do better work, give value to our customers earlier, and 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 after observing for a while, I would 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 that 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. And typically, one of the things for data I found really successful was 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, at 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 chunk it down. And some coaches don’t agree with my podcast the other day, and he said try it with one day and I was like. The short ceremonies though, because I’d be what it would be, Team backlog grooming, 10 minutes from planning. Five minutes standup. So I find the move into 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. There are a bunch of patents and somebody says to me but we’re doing pure Scrum. And I’d like do you use a Kanban board. They, of course we do. Because it’s valuable. I haven’t seen that in the scrum guide. That’s a patent from Kanban, is a valuable patent. Or we do peer programming, awesome, but they 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, that’s a cheap point. 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 suggest you go back to stand ups because that team member doesn’t know how to communicate on a regular basis for the team, it doesn’t understand how you work. So going back to a forcing function has value, retros, 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 fix it and we fix it, then we don’t need retros. So they’re forcing functions that have value. And then once we mature enough, we don’t need them then loose them, because we’re doing it anyway. But when something changes, have to 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.

Hamish Gray: I’m 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 doesn’t 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. We have 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 working for us. But what is a little bit disappointing 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 in, we’ve done 60, but 20 of that’s new and the sort of stuff.

Shane Gibson: Then how you do 90 points?

Hamish Gray:  That’s a good question. I just side because I don’t have a good answer for it.

Shane Gibson: 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 are at real risk of doing Agile, they can be told to change what they’re going to deliver. But then we reset. It’s a reset. And so the clear thing we have to say to our stakeholders as 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 bear 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, or halfway through, can you do these extra things, but I still No, you’re changing it to a degree that the agreement we had at the beginning no longer exists. So let’s stop it. Let’s check everything in and 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 patents we use a different, I tend to really think about those macro patents of iterations, time boxing, the patents that support that, and flow, where change is constant and the patents support that, sometimes you can do a hybrid, but hybrids are dangerous, especially when you’re starting out.

Hamish Gray: It’s interesting, because where we came from, at least, which was flow and a reasonably agile organization, then this has just been the best of getting a little bit more clarity around where we can get stuff done. And 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 one, two, three, then the four, five get bummed out. But they’re also needed, because really, they’re not four and five that second equal. So we’ve got some ways to go, I think May is what we’re hearing, but we’re conscious, we know we’re cheating.

Shane Gibson: You’re not cheating, you are just following the patent to the purity of the patent, 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. And that’s great patent, because three of them are done, two of them aren’t done. 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 have done before the change happens and put it somewhere where it’s semi safe, and maybe reusable when you go back to it. And again, that’s great patent, 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 works not completely lost, some of that value has been retained. So that’s good behavior as well. I can infer that maybe your team checking things in on a more regular basis than every two weeks, just in case things change the like, let’s check done, 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 out. So you’ve probably observed some good behavior that comes from the constant threat of change.

May-Lyn Hu: I think we’re getting there from where we used to be, and having some clarity, at least knowing what the retros for us, it’s like the check in going okay, we know that the pivots probably going to come. So how do we, mitigate the process? And how do we help each other and get to a checkpoint.

Shane Gibson: Out of interest on that. So often, nine times out of 10, we will see the pivot being telegraphed earlier, we see the conversations, we sniff the, that priority is no longer the priority, this is going to change on us.

Hamish Gray: So we’ve had things dropped as well, which is great as we’re no longer doing this, stop doing this because it’s no longer priority, because obviously, that’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. 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 in some of these other legacy bits of work, they’ll come out of nowhere, and they wouldn’t be unknown. They’re just undiscovered, undocumented. So 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 that’s got legacy things that come up, and they always pop up at it, we need this. And of course, it’s operational, therefore has to happen two hours ago, sort of thing. So that’s fine. But that’s the conflict we get, hence why strict Agile is not going to 100% work for us, we can’t really say no to everything for two weeks, like maybe in the old gig, you could stop. But here we probably need to be available. It’s almost 24/7.

Shane Gibson: 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?

May-Lyn Hu: Let’s say, its hippo.

Shane Gibson: Very common. And then when that conversation head, we know things prioritize for you.

Hamish Gray: So I guess I’ll hit up data. She’ll be off speaking of stakeholders, it’s a breeze me flat structure. 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, you’ve got to choose one, there’s pretty much I guess, if CEO says go, then peel to the middle is pretty much how it works.

Shane Gibson: 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 as your product manager volger, the stakeholder discussions, the prioritization of what’s next.  As somebody between that head of data and yourself, when you start doing information products. Is there somebody adopting that product owner role?

Hamish Gray: No.

Shane Gibson: Do you tend to bring a subject matter expert in to the periods, that information product needs to be delivered. So if you’re talking to a mentor, you bring in an expert from outside your team on inventory?

Hamish Gray: 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, they also have stuff to do too, but I guess I’ll hit a date. And she can prioritize it in terms of our team’s resources.

Shane Gibson: And then if I give you an example, for inventory, so if you’re doing an information product round on the tree, and they want delivery time, between each of the inventory steps from our warehouse to delivery to customer, there’s one thing they want. And then the second one they want is lost deliveries, where something’s been dropped out of the cycle route or supply chain. So they want both of those. And you got to the stage where 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 or metric or something smaller. Who makes a trade-off cool? Would it be the head of data, or that subject matter experts.

Hamish Gray: The SME, and we’ve literally done that in a lot of planning as well as 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, our issue with data and 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 systems, perfect hints will find problems and things got operate. And as we drill in, and we find these issues, but that low 100% make the call but hit a data or 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.

Shane Gibson: Yes, and that’s a common patent. So if I go back to one of the problems around applying agile and data domain, this is one of them, we will typically see a hitter data or somebody else form that product manager role. So they have a responsibility, find the funding, deal the stakeholders to prioritize what’s next and 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 that information product, we’ll see the 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, and there is idea of a supporting role product, and it doesn’t exist, their behavior doesn’t exist, we have to train them how to do it, and 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.

Hamish Gray: 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 a data with people, do have to jump in and out. And we haven’t, like we did at the old gate, 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 is this time, it’s maybe different people, different business, there’s no official, you’re a product owner, you need to be available this sort of time, they just need to be available to talk to you during the day. No dramas, it’s not. Whereas previously, I can’t be available 50% of my time or come to your stand ups. Like there’s none of that, which is an interesting difference I’ve noticed.

May-Lyn Hu: Obviously, when you have the software, you’re saying people are available most of the time and the maybe a little bit more embedded in with the team. How do you see them the ceremonies go, when in data you have these sort of product owners but they’re separate. So for ourselves ceremonies and whatnot are definitely just within our data team. We don’t include anyone external.

Shane Gibson: I would invite the product owner to every ceremony that the team feel safe that they attend, so product owners should be a stand up. Product owners should be backlog grooming for the products that they own. They should be at Sprint Planning and the team might want invite them to the retros but may decide not to, because that’s your internal that tends to be the one that team wants to predict, 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 they’ll interrupt you. Because it’s their time to get answers. That’s what we’re asking for. Often they go, I’m too busy, because the poor product owner gets given it as a second job, your job and do this. And it’s interesting. 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 tradeoff decisions and where the value gets created? Seriously, is that a good business decision? Sometimes it 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 as they bring a supporting role of product coach into the team, as a member of their team, especially at the beginning. And that person on-boards the product owners early before they come into the iteration, so they pre work the product with the product owner, the guy, 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 with somebody else they can go and ask a dumb question. One organization I worked with, when you are 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 does 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 product coach, untied 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 wired, 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, it’s a problem in the data space or data domain because we switch them in and out on a more regular basis in 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 patents and where’s the end of it and it’s because there’s been annoying me for a while. Just before we close out any last one top of mind that you thinking you’re rocking and everybody should do it the way you do it or when the last question on Dan’s was biting us in the bum. What do we do?

Hamish Gray: What are you reckon Pitzer meetings as a winner, May, like always.

May-Lyn Hu: Absolutely. It was going to be like, I’m very proud of our sizing just because it’s funny. It’s around food more than anything else.

Hamish Gray: Stir fry and gourmet burger.

Shane Gibson: 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’s about relativity, it’s about the team having a conversation of why something gets large and something is too 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 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 are training, I use fruit. I go grapes versus watermelon. What’s the size difference?

Hamish Gray: In our original team. It was so it’s five points, how many hours is there, needed our conversion, I pushed back pretty hard on that. And I lost that war. But in the new team at least, there’s no question around. How long the point is, the points as long as you say it is and hence that I think actually the change to food helps break that a little bit. We still use points because JIRA wants points for some reason, we can’t pass.

Shane Gibson: Because JIRA is evil.

Hamish Gray: Yes.

May-Lyn Hu: Same thing a lot of Jira hates you.

Shane Gibson: I don’t like Jira, because I don’t find it a useful usable interface. And it 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 prison. We focus on the tickets, whatever 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. Anyway, to close it off my question then. So stir fries one size, what’s another size.

May-Lyn Hu: 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, during the meat 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 some it’s called a Tonkotsu Ramen. Which of those food initiators, it’s 12 hours to make if you do it properly, but a lot of people think they can do it really quickly when they can’t. So that basically that’s something. It’s Hamish, it’s a two minute noodle job. Not, Hamish has the Tonkotsu Ramen. It’s not the same, you have to make the broth and have cooking skills that you don’t have.

Hamish Gray: That like I say that’s two minutes, and then it takes 10 hours. But sometimes it does take two minutes. It’s just not always me.

Shane Gibson: I love them. And if you’re okay, I’m going to steal that when I write up the articles and patents around things. So what I love about that is, there’s a bunch of lenses I can use on your sizing, often use a timer and two minute noodle versus something it 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. As high as quick and steady, isn’t enough? Or, do I need the gourmet burger? And therefore I know I have to invest, is that value thing? Does that level of expertise? It’s written on the packet that’s almost like novice practitioner expert writes. So some people just can’t do those big ones. Well, it’s a skill set of 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.

May-Lyn Hu: Also, as 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 talk about it, but some of them like a gourmet burger you decide, does it come with hand cut fries? Is it coming with onion ring? Like you don’t know what it’s meant to be, but you have a rough idea.

Shane Gibson: And then the other thing is, it’s a shared language that I still don’t understand what their last one is, I’m going to have to go and buy one because I’m like, I’m going to 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 worth we use, the data people don’t understand or 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. That’s been pretty great for me. Anyway, I found that really interesting. And anytime I can walk away with a nice patent like that food grading, I’m happy because I’ve got another thing for my toolkit for the next time I work with, so hopefully, went away with some stuff that will be useful for you to keep accelerating the way you’re going.

Hamish Gray: Totally. Thank you.

May-Lyn Hu: Excellent.

Shane Gibson: Cool, catch you all later.