TD:LR

Aldo Rall: Hi, and welcome to today’s episode of “The Focus”. I’m Aldo.

Horia Slusanschi: And I’m Horia. And today we’re welcoming Shane Gibson.

Aldo Rall: Welcome Shane. And as part of an intro, we usually explaine why we have you people as a guest on here. And the reason why we’ve invited Shane on to today’s episode is that he works in Wellington, just down the road from us. And a few years ago, a mutual friend that I was working with, introduced me to Shane. And Shane, and I went up for a coffee in Wellington. And it was a really interesting chat. And ever since then, we’ve been touching base here and there. And we thought that Shane has got enough battle scars in the space that we’re talking about, in order to come share his story and come share his experience with us as well. Shane’s also quite handy in the data space. And that’s also a very interesting avenue of oversight that we’ve explored a little bit in the past with the likes of Scott Ambler. But it would be good to actually hear your thoughts about things here on oversight as well. So Shane, with that, I’m not going to lay out everything because I don’t know everything about your background and your experience, why don’t you share us a little bit or as much as you want about your river of life?

Shane Gibson: Yes, I’d love to, thanks for having me on the show. So as you see data and analytics, that’s what I’ve done for most of my life. So probably the tool looking over 30 years now. I started out working in government, when I came out of school, and accounts. And I was lucky enough as part of that to fall into a role where we replaced our financial system. And they got me into the world of IT. And I very quickly learned after that, that the whole area of ERP and financial systems, brought me to tears. But I lucked onto this thing, where our CFO wanted some reports, she wanted to understand how much we’d spent with those things. And so back then, it was the early days of data. We had tools like forests and trees, so I was playing around with that. And from there, I went on and worked for a couple of big US vendors for 10 years, and what was called over in New Zealand pre sales. But now it’s called sales engineering, customer engineering. So I was between the salespeople that wanted to close the deal, and the customer that wants the problem solved. And then from there, went out and started my own consulting company. So typical data and analytics consulting company, bunch of people that worked with us, would go and help a customer out, ideally, for a couple of years was always our goal, because that was the business model. And as part of that a couple of customers were really kind enough to let me experiment with their teams around this thing called Agile. Sometimes we had to call it iterative, because they’ve done Agile before. But really, it was this idea of adopting an agile way of working, but within the data and analytics domain. And that always had a few interesting challenges. So when I compared it to software engineering, a lot of the patterns we could adopt, but we had to adopt them slightly differently, or they sometimes wouldn’t work given a particular context. So I’ve been lucky enough to coach those teams for the last eight or nine years now. Every time I work with a new team, I learned something new. And then three years ago, I co-founded a Software as a Service startup called AgileData. So I’ll be spending my time between building out that company and their product, and still side hustling with customers, to help them when they need help, because we’re bootstrapping the startup. So we’ve got to pay the bills somehow until, after seven years, we’re an overnight success and highly profitable. So anything to do with data analytics, and agile and combining those two, that’s my passion still.

Aldo Rall: Thank you for that. And on combining those two, you must have had some really interesting adventures, and how all of the data and the Agile or new ways of working adventures and then obviously, the strong connection into oversight and governance, into that space. What are some of the adventures that you can share with us from that link between the three things?

Shane Gibson: I think that one of the challenges with data and analytics and agile is there’s a couple of them that I’ve distilled over time. So one of the first ones is we typically adopt this new ways (inaudible 00:05:03), we were undergoing a massive change. So we might be Greenfield things a data analytics platform. So building from scratch. And so that gives us this pattern, which I love to call building the airplane, while flying it. So we don’t want a big iteration zero, where it’s six to 12 months of navel gazing and building the wrong thing, we want to rip into it. But there’s a whole lot of foundational work the team has to do in terms of their practices, their processes and their technology stack. And that’s always one of the challenges. I think in the software engineering world, it’s a little bit easier to build out your technology platform relatively quickly. Whereas in the data world, we haven’t quite caught up. I think the second thing is for some reason, the data work or the analytics work often gets bound to a big ugly program of work. And so what we get with that, as we get those legacy oversight, ways of working, we get those big committees, we get steering committee, communities of data governance, we get a whole lot of talkie talkie and no Dewey. And so that’s one of the other challenges I see a lot is how do we break those patterns? How do we make sure that those oversight functions, fit for purpose? They’re doing just enough at the right time? How do we get those groups to focus on prioritization in the future, and solving those problems and bottlenecks, not micromanaging the work that the teams are doing. So usual oversight problem with anybody that’s moving from, program or non iterative ways of working to the Agile way.

Aldo Rall: So what have you found that other than those things, you talk about micromanage? It’s quite a strong theme. We’ve picked up with a lot of people we’ve interviewed. What are some of the things that you’ve tried to do in order to try and not fall into a micromanagement trap from an oversight function?

Shane Gibson: So, it’s really focusing on when a group of people are going to do something, why are they doing it? What does it look like? What does good look like, almost like a definition of re do, definition of done for those groups? So one of the first things I tend to do is move away from a steering committee structure, to a prioritization forum. So what we find is, ideally, prioritization is done by one person. And we all know one person doing a job as long as they’re not overloaded, is the most effective way getting that work done. But often in a large organization, especially the data in our workspace, we have so much latent demand, we have so many stakeholders or business units, or supply chains or customer journeys, that each one of those wants some work done, and we have to prioritize those and one person, typically one. So I would typically not see the chief executive prioritizing that work, who actually is the only person that sits at the level where they can make that call. Sometimes, it might get delegated down to a chief data officer, but not often. So one of the first things we look to do is set up prioritization committee where those people have a way of prioritizing the next piece of work to be done. When we do that, the natural pattern everybody wants is a scoring mechanism. They come up with a spreadsheet, and they go, well, why we don’t give it complexity, value to the business, time to deliver, cost risk, and we end up with all these numbers. And, we do a spreadsheet and we prioritize, and we say this is the next most valuable piece of work. And then what typically happens is somebody goes, Not really, and they change the numbers. So I look at that, and I go, Okay, well, that’s a waste of effort. So typically, the way I talk about it is the role of a prioritization group is to horse trade, to actually agree what’s next and then set a plan of what might not be next. The order it might be done. And then as soon as the team is ready to do another piece of work, we Horse trade again. And what I tend to see, especially when you have senior people in the room, they are very good at horse trading, they will have conversations like Okay, love to get my work done now. But I can see from an organizational strategy or whatever point of view, this one is the next most valuable. But you’ve only got these many iterations. And then I’m going to expect my one to be done next. So don’t go and take the team for six months or a year. Because I’m not going to let that happen. But you can have the next couple of iterations. And those conversations are really interesting to watch. Now, one of the tricks that I found, one of the patterns or anti patterns is when these proxies in the room. When the people in the room aren’t actually enabled to make the decisions and the proxies are either running off to ask the boss what can be done, or they’re making calls that then get overturned when the person in power, person with the manner to make the decisions find out. So the people in the room have to be enabled to make those decisions. Because we’re committing for the work, that team are going to do and changes, okay. But change comes as a cost.

Aldo Rall: So I this prioritization forum, what has been the typical ways that you found work to establish that forum?

Shane Gibson: So typically, there is somebody who’s kicked off the team’s journey into this new agile way of working. And that person might be called a product owner, it might be called a team leader, might be called manager, but they’re effectively a leader. They showed leadership behavior. They’re normally the person that goes and knows who in the organization should be on the committee, on the prioritization group. Of course, stop using that word committee, on the prioritization group. They know that people who have the ability to make decisions or the people who don’t. And they go and get that work done. They go and invite them. Now, what often happens is, there’s a bit of an adoption curve and everything we do, so when we started off with a new data and analytics team and a new way of working, not a lot of people want to work with the team, because they’ve heard all this before. They’ve had programs and projects, and they’ve asked for stuff. And it’s never been delivered, or it’s not what they wanted. So we talk about, nobody really wants to work with them. But after they start seeing success for a while, they all jump on. And we get this massive wave of latent demand. Same with the prioritization group, normally, everybody’s busy in meetings, everybody’s busy trying to get the work done, and everybody’s got fires to fight. So again, the first stakeholders in that group are normally, the early adopters. And then once it shows success, everybody else wants to bail in. And again, there has to be a role in the team at a relatively senior level, or a person with trust, to manage that change of people coming into the room to agree the prioritization of what’s next.

Aldo Rall: What would you say are the best ways of working for these forums or these groups?

Shane Gibson: So there’s a couple of things that are really important that I’ve seen over time. So often, people can’t articulate what data and analytics is. It’s difficult. So because it’s big, and we use lots of three and four letter words and lots of technology. And we’re like, Do you want acd 2 or not? It’s like, really. So that group find it really hard to prioritize, what work should be done next, because they don’t understand the work. So we need a way of articulating to them. And so I have a framework or a patent that I use to called information products that I’ve worked with a bunch of different customers over the last eight years to refine. And so it’s a way of describing what that work is. So we describe what the outcome of that works likely to be. What’s the action, that’s going to be taken if this work was delivered? It describes the business questions that are going to be answered. So if you say to somebody, how many customers we got, we’re going to answer that question, they can understand that, it describes the personas, they’re actually going to get the value out of this, who’s our target as a senior manager, as an external parties and an analyst, who’s going to get the value out of this work? It describes the core business processes. So who does work from (inaudible 00:13:45)? So what core business process are we going to deal with this information product describes the way we’re going to deliver it, we’ll see output look, like is it a dashboard? Is it a report? Is it an API’s and a data services? What is it? What are they getting for the money? And so effectively, this information goes into a canvas into I3. And that when filled out well means that a senior leader connection read it and go, Okay, I understand what you’re talking about now to a level that I need to. And then they have something to prioritize. And so then what we do is we get them to prioritize those information products, just wreck them. So that comes on to the second part, once they know what the choices they have are. How do they make that? And what I found is there’s actually quite few number of really good agile games, for prioritization. So one of my favorite is 500, they given 500 virtual dollars. All the information products get put on the table, and they vote with their virtual money. The one with the most money wins, that’s the one that has the most value. So I find those types of ones depending on the culture of the organization and the culture of the people in the room. Those different Ways of prioritizing, you need to fit to the organization and the culture of those people to get a good fit but there’s always one that works for them.

Aldo Rall: I’ve heard about a story where there was also this prioritization by committee. And it always turned into a big bunfight. And a whole lot of to and fro. So really getting decisions out and the senior agile consultant at that stage, this was probably about 12 or 15 years ago, that he was asked to come and sort this out. And as people walked into the room, he handed them each $100 Monopoly money bulb, and he set the new rules and said, you can only spend $100, and you decide on what you want to spend it on. But that’s all you can spend. And he said, he noticed some really interesting behaviors is that people started bartering. And this is this horse trading you talked about. And then they formed a little cartel in order to go and actually figure out what did they want to spend their money on and supporting one another. And the beauty of that is, it takes the drama away from the team that needs to do the work, all they want is just get something and do the work and get something else and do the work. They are not pulled into the drama and the pump and the fear and what all of that is, just they can get on with the work. That’s quite a powerful tool. I like that.

Shane Gibson: And often will see a hippo behavior. The highest person in the room. So that’s okay, I have no problem if there’s one person in the room making the prioritization decisions, great. They’ve made, I don’t care who makes them, and they’re made. So there needs to be almost a definition of ready for that session, they have to think we have to be well informed and ready to be able to prioritize. So if there’s pre work, they need information before, they need to have it and they need to have done the homework before they walk in. You want to create a time box, you want to create an iteration an hour or two there, at the end of that, there will be something that’s next, you want that to be committed too. So changes is okay, but change just before you give it to the team, that’s the highest cost change. So ideally, get a bit of a roadmap about what you think might be next and two, and horizon two and three, and then worry about changing those. And then the other thing I always say is, if there are two priorities that come out at the top, we’ll flip a coin. Because what you’re saying is actually both are important, and it doesn’t really matter. So then the team will effectively pick the one they liked the most. Because you’re telling them that, there’s two priority ones, which they can’t be, so it doesn’t matter what. And that’s okay. It doesn’t matter. The work will always get done. It’s just win.

Aldo Rall: I was bringing back to you talking about the scoring mechanism. And what are you finding? How value is usually determined if they score their value? How that usually determined?

Shane Gibson: Normally is anecdotal. So, we find it hard to quantify the value of data and analytics, I think we find that hard as humans to quantify the value of anything really. I talked about three levels of done now. I talk about the definition of done, which I now treat as the internal metrics for criteria for the team that they’ve done the job properly, set of professional standards. So, definition of done will be the team saying, Yes, I’ve tested my code, i have validated the data, I’ve reconciled it. I’ve checked it into a repository, I’ve had a peer review, and I’ve written the documentation. And the reason I described that as product owners and people who aren’t doing the work, just expect those things to be done. Or they expect you to do your job, and they expect you to be a professional. So why should a stakeholder or a product owner, if we’re using Scrum terminology, why should they say and you’re going to write tests for your code? Because everybody expects to test the code? Well, they should do. And then I talk about definition of done. Which actually, is the acceptance criteria, if we’re using Scrum again. So that’s what the product owner or the person, the stakeholder is saying that the tests are right, how they’re going to validate that the work that’s been done, was to the standard or to meet their expectations. And then the third one is the one that I’ve never actually been able to experiment with a customer yet properly, is the definition of DONE. And so what that is, if we think about those information products, if the stakeholder who wants the work done, could actually define the value they’re going to get out of it, not just the action they’re going to take but the actual value in terms of revenue increase or cost savings or risk reduction, it’s normally one of those three.

Aldo Rall: Or making the right decision based on the data that they see in front of them.

Shane Gibson: That’s an action. But what’s the value of that decision? Am I increasing my revenue and am I decreasing my costs, or am I reducing my risk? Those are normally the only three outcomes we ever get. So, if I could say that, this analytical scoring model that determines the next customer to churn, right is what I want. And the action I’m going to take is, I’m going to do a Save offer to them. And based on the data we have, we think the value let’s save off of that is retention of revenue of $100,000 in three months, that definition if we could define that upfront, and that’s the definition of value. And then if we could prove it after the fact, after we’ve delivered that information product, if we could prove that $100,000 was delivered, then we get a better feedback loop. Because what happens is, especially in data and analytics, we see a lot in software as well, we build useless features that nobody wanted. But in data analytics, we’re often getting data and answering questions that actually don’t, and the stakeholder is asked for it, doesn’t deliver the value they promised for that effort. And data analytics, things are expensive. So for me, if we could put a value, quantify a value on it, it should help us with our prioritization. But we shouldn’t treat it as theater. We shouldn’t just pull numbers out of our backside, and write it down pretend, actually a value number, and then try and prioritize on it. Because just you’re making stuff up. So pick one.

Aldo Rall: Horia, you’ve been doing a lot of work in value, or understanding value, etc. What have you got to share in the stuff that Shane has shared with us? Any thoughts?

Horia Slusanschi: I like the idea of $500 worth of virtual pot. It’s like playing Monopoly, if you will, that gives you an intention of out of these initiatives, which ones are closer to your heart, and you do so in a manner that simplifies a lot of intuitions, if you will. Now, one technique that I found useful with some customers, is to actually work with them to identify a handful of key dimensions of value. What are the main contributions of value and then score on those dimensions? So it’s, similar in some respects with the idea that you’re describing, but it uses a per topic budget, if you will. And then based on that, you can actually then rank those dimensions and end up with a with a value score. What have you seen in this way of alternative value scoring?

Shane Gibson: So we’ve experimented a bit with the Keno model. So that’s, the idea of what is it? What is something that people just expect? What is something that’s going to absolutely delight them? And I can’t hear what the other two quadrants. So data was a way of putting the work to be done in different quadrants, and then the one that was near the top. It doesn’t give us a priority, though. We have to agree up front that, if we want, or we going to focus on things that delight, versus things that are expected, we have to make that call first, because we want to know at the end of that process, into that prioritization iteration, what is the next piece of work to be done. Another one I use a lot is five lane. So being a good Agile coach, I take out my my bag of sticky notes and duct tape. So you put five lanes or a five rows on a big table. And you basically say to them, this row ones are top row, that’s the highest priority. The information product that set the left in slot number one, is the first one that we do, and then we run. When you run out of room, there’s a constraint there, it goes down to row two, keep going. Row four and five, probably never going to get done because you’re going to reprioritize new work in the future before we ever get there. Rows three, depending on how much you got and how fast you go, how complex it is, probably not going to get, the row one and two probably will get over 6 or 12 months. Some customers I’ve worked with they wanted to put a little bit more context around it. So they’ll say row ones regulatory, so giving you an example, if you’re working for a bank and the Reserve Bank demand something that goes in row one, doesn’t matter what’s in row two, row one wins. So row two becomes strategic, row three is programmed, we’ll take the call row four or five as wishlist. And that’s okay. I don’t mind. So that gives you context of what goes where. But remember we are going to prioritize from the top left. I’m trying to think the other ones, there was another one, which was dot game. So you basically get to dot a whole lot of them. And then the ones that aren’t dotted get removed, and we read dot, and so we’re constantly re dotting, until we get down to top three. So again, it’s a way of removing and re voting time and time again. And I’m sure there was no one like that with poker. But somebody like tasty cupcakes always has some good games that you can use from a prioritization point of view. As I see it, the key thing is do it, so it fits the culture of the organization and the culture of the stakeholders and get them to experiment. So here’s some choices. This one works this way, this one works this way, which one’s going to fit for you? And when it stops working, get them to reiterate. Director say, that process isn’t working for us anymore. What can we change? To get better prioritization?

Horia Slusanschi: One of the things that we find is very much like you were saying about flip a coin, if you have two things of equal importance, I prefer to talk about sequencing, rather than prioritization. Because in sequencing, I actually have to pick this is first, this is second, this is third. And one technique that we fill in handy there is, we have the story of the beer and the whiskey barrel challenge. So let’s say that they’re dripping. And I’m losing $10 worth of beer and $50 worth of whiskey. And usually, when you ask people, so which one do you want to tackle? They’ll say, I’m losing more whiskey. So let’s, fix the whiskey. And then if you say, Hold on, but if I’m getting closer to the fix, and I’m noticing that the beer barrel is a simple fix only takes a minute to fix, but the whiskey one takes about 10 minutes to fix. How comfortable are you that we still fix the the whiskey one, and then they think, it kind of scratch their heads a little and they go, okay, hold on. Because the thing is, in the 10 minutes, that you’re fixing the whiskey barrel, you’re losing 100 bucks worth of beer. Whereas in the one minute that you’d fix the beer, one, you’d only lose 50 bucks worth of whiskey. So understanding how to balance the amount of time to achieve a value, the speed to value, and divided by the duration get an acceleration to value, really makes a difference in terms of how you should sequence things.

Shane Gibson: I struggle with that one. Because as humans, we suck at estimation. And we don’t want to do the work before we estimate how much it’s going to cost or how long it’s going to take. So we do really like estimation, and that is one area that gets gamified all the time, people change the estimate, because they wanted to make it look smaller. Now ideally, like estimation, and Scrum, we really want to get to a stage where we’re not doing it, we want to get to a stage where every information product is of the same size. And then we take the idea of time out of it, because we know that unit of work, is a unit of work, and they’re all equal from a unit of work point of view. But that’s hard. If we talk about lifetime value, we can decompose it down to, what’s the value, what’s the value by product, what’s the tune of the customer, we can break those models down, but that is difficult. So I tend to use decenticising at the information products at a prioritization level. I say yes, small, medium, large, extra large, and we’d love them to go in as all smalls, but they don’t and then that’s the only hint, I tend to give the stakeholder around sizing. The second one is you still see a lot of Moslow behavior, must is straightaway it has no value because the must never musts. We must do this. But what if we don’t? And the number of times I’ve seen must, they don’t get done, so they’re not musts. The assurance of codes or words. Sometimes there’s these delay tactics, I must do it, but not right now.

Aldo Rall: Very good. So we’ve described over the last few minutes of describe a lot of techniques and so on, but I want to step a little bit back and ask you, what benefits do you see that an oversight practitioner will gain when we practice these types of techniques in value scoring?

Shane Gibson: So it gives us that time horizon. So there’s a couple of areas where oversight brings immense value. So one is planning the future lightly. So what does work potentially look like? So, you ideally, again, if we’re using Scrum, it would be great if the team could start on day one, from a standing start, get the work done in two or three weeks iteration and be done. But that’s hard. So giving them a heads up of what possibly might be next, allowing them to lightly working here, there’s a common pattern. And so without that roadmap, without their understanding of an oversight of what the future might look like, it’s impossible for them to work ahead lightly. So there’s value in that. And then the second value is when we scale. So again, I say the most effective team was a team of one. Finding those unicorns that could do all the work on their own is incredibly hard. And the data and now look space. So we have a team of 49. And they would really want to give over time, you add three more squads, pods teams to that, you get five teams of nine, we started having massive problems as we scale. And so that’s where oversight comes in. And I tend to now have quite an opinionated view on that. And I like the term. I’m not sure I like the term federated, but it’s based off got. And a lot of it does come from Scott amblers, early in the writing. So I was trying to remember the reason we caught up, was because I was exploring discipline Agile of it, and that’s why I was talking to you. That’s what remember that now. And so in the podcast I do, one of our guests gave me this great team that I love. And they talked about exoskeleton and internal skeleton. And so the way it works in my head is when we’re in an oversight role, and we’ve got a scaling problem. We’ve got a bunch of people that we want to corral and work in a certain way. We’ve got to decide which rules are immutable, which is our exoskeleton, which is the frameworks they can’t go outside without a really big discussion with us. Those are the rules of the game. And so as an oversight role, we should set those exoskeletons very clearly. We should be able to articulate exactly what fits inside and what we deem has been outside. And if you want to go outside at what’s the process to have a conversation with us, to be very few rules? Because those are those hard things that people are going to hit. It’s going to hurt them when they head up.

Horia Slusanschi: So just pause there very few rules. Would you say that having it more of a principle driven than a rule driven pattern or carabus, or exoskeleton? Is that a better way?

Shane Gibson: Principles are a good starter, but I do a lot of work with principles, but I find them a good starting point, but then relatively valueless. Because there are a bunch of words. And they can be interpreted in many different ways, data itterate data as an asset. What does that mean? That’s mean that I’m going to actually get a table and I’m going to put it on my balance sheet, with a value and I’m going to depreciate it and that depreciation value is going to go back to the team to maintain it, or is it just are we going to think of it as NC, which of those 2 am I dealing with? I can interpret a whole lot of stuff. So I tend to think now about rules. Which are immutable. They’re very clearly defined. So a rule we have in New Zealand is you can’t drive your car without a seatbelt. I know wear my seatbelt on. I know what happens if I get pulled over by the police, when I don’t ever seatbelt. It is a rule that I should comply with. It also has massive value to me, I can see why I’m doing it. So that’s the exoskeletons. Those are the things that are immutable. That actually is a really big conversation. It’s almost a fireable offense to break those rules. And then the internal skeleton of things we build on top of their guidance. So the principles, practices and patents is the way i think about them. Because I think each one of those is a different way we describe them. So a pattern is something that can be used in a certain context and has proven value. So if I can describe a pattern, the most people will use it because it makes their life easy. As humans, I wouldn’t say we’re lazy, but we like to leverage things that make complex things easy. So if we can have a bunch of patterns and terminal skeletons that they build on, most people will follow them right. They will adopt them because it makes sense. And so that’s how I think about governance now, very clearly, what’s the rule that you can’t break and what’s the consequence of not breaking it? And how do you describe it to me? So I understand, well, I’m going to break it. And what’s a principle, a pattern or a practice that has value? And I should adopt it. But you’re not telling me I have to. You’re leaving me to self organize as you should to do the right. And the context or the term and the applicability. Now, those prints, those patterns are hard to describe, it’s hard to describe the pattern, it’s even harder to describe the context of where it could work and where it doesn’t. Where principles, we have a whole lot of frameworks like TOGAF that give us a really nice template to fill a principle out, but it’s an intent. So I still start off with principles, because they give me an intent. They give me a favor. So I still find them useful. But they’re only the beginning of the work.

Aldo Rall: This is fascinating. So I like the idea about the exoskeleton and the internal skeleton, that’s a really beautiful way of describing it. I’ve never heard it being described that way. So Horia looks like you want to say something?

Horia Slusanschi: Well, I’m fascinated by data quality. And I think there could be a lot of opportunity in this space to get a lot of benefit, without necessarily a whole lot of pain in improving data quality, what thoughts do you have in this space?

Shane Gibson: So the standing joke in the data and analytics world work, probably not so much nowadays, because it has moved on a little bit in the last two years. But the way we get data quality is we put something into production, and we wait for a user to identify that it was wrong. And what we’ve seen, and there’s been a whole change of technology in the data and analytics world over the last couple of years, and we have no what’s called a modern data stack. So we’ve had a massive uncoupling, or decoupling of our technology stacks. And so we’ve seen a whole lot of new technologies come out in the data profiling space, the data quality space, the data observability space, and each one of those brings some capabilities in one area, but only a part of it. And so when we look at that data quality, everybody has a different version of what that term means. So does that mean that the data looks the same as it’s always looked, the profile of the data is what we expect? So for example, there’s a field called phone number, and only has phone numbers, and it doesn’t have any text? Well, it doesn’t mean that it’s got phone numbers in there. And the phone numbers comply with the phone number masking standard for New Zealand, if it’s in New Zealand phone number, the 021 the 027 or it complies with the US, one of us US phone number or doesn’t mean actually the phone number works? I can bring a personal answer, that phone number is valid. They’re all data quality problems. And then we get the mutation problem. This data is coming in. We know what it looks like, we’ve tested it, we’ve made sure it’s fit for purpose, and then it changes. So the obvious one is, somebody changes the column in the source system from a character to a numeric prior, and that causes us massive problems. But what happens if the context of the data changes? What happens if that phone number, instead of being the home number that becomes the mobile number because nobody really has a home phone anymore? What happens if it’s a shared family phone number? I did some work in an agency for would have been 15, 20 years ago. And when we were profiling their phone numbers, there were a whole lot of phone numbers that said do not ring. And what it was, was a family member who wasn’t allowed to know where this person was. And so here’s a text setting in a phone number field. What do we do with that? Now, why wasn’t there? Well, because there was nowhere else in the system for the product. And that was what came up on the screen. So it was flashing in the person’s face not to ring it. But there’s a whole lot of context around about where we store it. So data quality is one of the least serve practices in the data and analytics space still. I think it’s a hard problem to solve. We’ve got better at it. But we don’t treat it as part of our profession to make sure the data is right typically. We move the data, we get it ready to be consumed, and then we think we’ve done our job. So I struggle with that as a practice in the data and analytic space.

Horia Slusanschi: Would it be wonderful to figure out a way of paying closer attention to cleaning data. Because too often we have something that’s almost good enough and for one, have a little bit of care and attention, things are getting worse. Because the beauty of practicing a little bit of attention to data profiling is, we can identify bugs, structural ways in which data deteriorates. And by noticing it, you can then actually fix all sorts of problems and extinguish whole categories of defects early on.

Shane Gibson: And, I think the practices that we still seem to adopt, especially in corporates and enterprise company has been around for a while, is based on a whole lot of practices and patents that have been around for years, but no longer fit for purpose. And it’s almost the library kind of concept, as an information management behavior, not a data of behavior. And that is, for some reason, we think we can have a team of people who are responsible for data quality, the data quality stewards or the data quality analyst, and somehow we think they’re going to clean the data, they’re going to fix this problem, or we think they’re going to profile and then somebody’s going to care. But they lost voice in the wilderness. Its look at this data. It’s wrong. No one cares. So I think we have to fundamentally change our way of working on data quality. I’ve seen some people experiment with it. There’s some good practices and patents coming out now. But they’re early. But we pretty much have to throw away everything we’ve done in the past. And that’s, scary. Because what do we do about (Inaudible 00:42:15)? We’ve got this massive way of working that everybody tries to subscribe to? Is it fit for purpose anymore in an agile world? Or is it based on a hierarchical organization? I’m not sure, I know the answer to that one. But I think we need to change what we do in the data quality space.

Aldo Rall: Thank you for that Shane. We’re going to change a little bit of talk here. And we talked about the data space. Let’s talk a little bit about it from the other side and look at what you’ve noticed around agility, and oversight. But before we get there, you run your own podcast, you’ve mentioned that before? Can you tell us a little bit more about it?

Shane Gibson: So I run two, so I’ve done the AgileData podcast for quite a few years, used to be called AgileBI called podcasts before we moved away from BI to data in the world. And I followed the trend. And so that one for me, it’s just been a personal hobby, I wanted to get into podcasting. I know a little bit about data and analytics, and I knew some people who did it. And so I talked to guests that right back in those days, we were just telling stories, they had an interesting story of what they did. And I wanted to share that story. These days, what I focus that one on is patterns. When I find somebody who has patterns on how you apply agile in the data space, I try and get them on the show to talk about those patterns. So that one’s a little bit ad hoc. And then the other one is the no nonsense agile podcast. So that was a funny story. So I do that with a gentleman by the name of Murray out of Australia. And we had made up once, Murray was at room during COVID. The lockdown the first one, he was great at reaching out to lots of people and having virtual coffee. So I had a chat to him. And then on LinkedIn, he posts who’s got the best agile podcast out there. And which one should you listen to? And I see it, here’s a list of them. But a lot of them. Don’t do it for me. And so I said, but I really would love to experiment with one. So if you’re keen on doing this, let’s do, so we did. What we found as the first 10 or 20 episodes, as Murray and I argued with each other. We, agree a lot, but we disagree on semantics. So we have a constant argument about skills versus roles, which I’m still willing. Thank you, Murray He doesn’t agree. And then Murray a great connector. So what if I started doing was finding people in the Agile world had been doing it for a while and had something valuable to say and now we bring them on as a guest. So, that’s been exciting. We do one a week effectively, one guest a week. And have a lovely chat to them or for me, it’s a lovely chat. Lots of more intelligent questions. I learned so much out of them. And I had meet some of my heroes. I’ve met Scott Ambler. I’ve met some other people that have always been on my list of people I’ve loved to meet. And I’ve met them virtually now. So that’s pretty cool.

Aldo Rall: That’s excellent. So looking back at the last year, from those two podcasts, what were the top three ideas you’ve encountered?

Shane Gibson:  So if I look at the no nonsense, one, because we talk to basically a bunch of leaders, which is interesting. So leaders in the Agile space, but also leaders in the product space. So those things that you wouldn’t typically call agile, because it’s not Scrum. It’s not flow. It’s not safe. It’s not using those terms. But they found it in agility. One of the takeaways I have is companies that are formed in the 70s, and the 80s, or Huracan. That’s their DNI. And actually, they can try and be agile, but they probably never will be. Now, it doesn’t mean that agility doesn’t have value to them. Changing the way they work and bring in some of the agile practices have value to them. But they’re never going to be agile organizations. Unless something fundamentally changes. And anybody 2000s onwards, typically is founded in agility, those organizational hierarchies don’t exist. They operate in a different way. So that’s the first thing. The second thing is, there’s a lot of companies out there that were founded after the 2000s that don’t do Agile, agile in the ways that most of us talk about, they don’t use Scrum, they don’t use Kanban. They don’t use Lean. They don’t use the terms we use. But they behave in the same way. They adopt those patterns. And I found that really interesting. Another thing is, a large number of the Agile leaders in the world started this in the 70s, the 80s, and the 90s. XP, although these are like new agile things that are new, I thought we are agile and where it came from. You listen to them, and they’ve been doing it for 20 years. So I thought that was quite good. We have yet to find somebody that will defend safe. But we’ve had lots of feedback that we should stop begging. Actually, it’s a fair call out what people have said is, if you have an agile mindset, then stop bagging something. And actually, see where it has value. So I’ve been a little bit better at not bagging it as often, I still don’t believe it has as much value as every other practice. So those are probably the key things that come off top my head.

Aldo Rall: Thank you. That’s quite interesting. So let’s talk a little bit about oversight and governance, and not necessarily where it plays out in data. But in general, what you’re noticing in organization, so what your journey taught you or in any experience taught you about oversight.

Shane Gibson: So one of the definitions of ready for a team that wants to adopt this new way of working should be what I’ve now termed the heat shield, there needs to be a person in the organization that sponsoring that change, that’s looking for the change in the organization to happen. And they’re willing to entertain this idea of agile ways of working as hoping that change. And they need to have the power or the monitor in the organization to be able to create this heat shield, this umbrella for the team, for a period of time to make them safe. So normally, I’d say three to six months. Because we’re changing everything on them. We’re changing their team structure, we’re changing the things they do, the way they work, the terms they use, we’re changing everything about how they operate, and they need time to break and reform. And so that heat shield is probably the number one government’s thing we need. I’m still strongly opinionated on anything that involves a committee has no value. Although I’ve talked for a bit of the podcast about how you can have a group of people prioritize, I probably need to look at the other areas of oversight or governance and say, okay, apart from prioritization, what else has value, what else needs to be a team sport outside of the group? That’s doing the work? I still see non agile behaviors, whenever we use the word governance that seems to come with it. It’s command and control seems to be founded in that term for some reason.

Aldo Rall: And that’s precisely why we’re doing this podcast, is to look at that chasm, is to look at what’s the tensions that play, that prevents the one from moving over, or blending or, finding a win win on both sides of that equation. So a lot of our first episodes have been just sharing the research we’ve done in the initial two years of this journey that we’ve been on. And it’s quite fascinating to see how those tensions play out in organizations. We can, take you through this at another stage, if you want to. You mentioned something about frameworks earlier about bashing a specific framework. And now one thing I’m noticing, and I want to propose that this is potentially a final of oversight, and here is what I’ve noticed, is that frameworks are selected. But the reasons for those selections are never clear. It’s either because it’s a golf course deal. You took the decision maker out on a golf day, or it is very good sales and marketing about it, or these this other neighbors have done it. So we should also do it. But though, the reasons, the why of adopting a specific framework is really clear. So for me, that’s a failure of oversight. Not asking, why are you choosing framework X and not Y, or Z, whatever the case might be? What are you noticing in your circles around that?

Shane Gibson: Like this is where I become very opinionated. Frameworks have value, but the value is not the framework, I treat it as pick and mix. There are patterns in every framework. And every agile approach, they have value give and take context, we should experiment with all of them. Somebody once said to me that they’re really good value of ciphers, there is a three diagram that gives them a menu of all the other things they can look at. Well, there’s some value we had, you’ll get an epilogue on the podcast, and he’s got unfix. And that’s the one that probably resonates the most with me, because it almost looks like Spotify, and what they published, in terms of the idea of rows of lines of people that are working on a value stream, or working together, and then an intersection of columns, so a bit of a matrix, and then dots for specialty areas. And so that resonated with me the way he described. He told the story, because that’s the patterns that I’ve had the most success work with teams. I was fixated with lists for a while. Because I like the idea that it does, it only focused on the things that you needed as agile scaled, while some minimum viable scaling. But what I found is, it’s really hard to understand what was for me, that I couldn’t understand enough to self learn or do those kinds of things. So I did that. I love (Inaudible 00:53:38) when it first came out. That was because it was a toolkit. And I still really subscribed to the idea of a pattern toolkit. But like all things, when you do that, it’s hard to find the pattern you want, it’s hard to go through the toolkit. You’ve got to figure out the journey. And that’s difficult to find the thing you need when you need it. So I don’t personally believe in frameworks, I think every team should build their own way of working, they should adopt patterns from all the approaches and all the frameworks, and they should build their own. One of the things I found I did as a coach early on, was, I would always bring in what I did at the last customer because it worked. And it took me a while to smack myself in the face and go, No, hold on. First step is go into observe, observe what’s happening. Get some ideas. And then once you’ve observed and speak a little bit, maybe have a chat to them, see what they think is important. And then agree with the team what they want to adapt. What do they want to focus on and experiment with? Versus going in and going, this is the way you do it. Let’s start off with Scrum because we all do it. And you’re walking in with rolling out your framework, bring it out The PowerPoint slides first, I think some of the frameworks are based on a pyramid scheme of money. Their certification. It’d be fair to say in New Zealand government, there is narrow barrier that if you’re not safe certified, you probably won’t get a lot of work in the Agile space. Is that a good thing? No, I don’t think it is. I think there’s put a paywall up where a bunch of people have to go and spend money on certifications to be able to help teams. And so very opinionated on this idea of frameworks. They have value. But they’re not the answer. You can’t just plop a framework. And that’s not my view of agility.

Horia Slusanschi: So how would you say that influences the work of oversight? If, that’s the issues you find identified, an oversight person looking from the outside in? How is that going to influence that way?

Shane Gibson: No idea. My answer is I work with teams. And then it’s okay. I don’t have to care. But even then, that’s not true. I do have to care. Because then funny things happen, so often, the data and analytics team for some reason, especially in corporates, one of the first things to experiment. And actually, I think one of the reasons for thinking about it now is they don’t have software development teams. They bring it off the shelf, and assess products, so they don’t have a core set of teams, they might have a digital team may be the first ones to experiment with agility. But then data analytics teams often start off next. And so what happens is sale adoption curve, everybody goes, yes, that’s agile thing. And then when they start seeing success, they go, this agile thing. And flabbergast being a big corporates, that what happens often next is, somebody they’re bringing an external party to define their agile framework. And that person doesn’t actually talk to the team, just doing it. So this team over here is doing it. And you see the practices and processes and patterns may not be fit for purpose for the rescue organization, they probably need to be iterated, but that’s okay. But then you bring in some expert, or sometimes not even an expert to write an agile Guide, which you’ve always got to follow. And it’s like, well, how does that work? Like, that’s just to pick up a framework. And so for me, I struggle with that one. Why the rule is, iterate, experiment, create the ACE, give it a go, got the practices, distinct doing and apply it to another team and watch it fail, and then say, what do you need to change? How do we articulate what they’re doing that’s hard? Do they come in observe? What’s your process that you’re going to experiment with for scaling out these practices or a set of practices? I struggle with that one. And so I pretty much don’t work in that space, because I don’t have an answer and I can’t help.

Aldo Rall: But again, these are key questions that any oversight capability need to ask is like, you want to adopt agile, or you want to go on a digital transformation. These are key questions that oversight need to ask? Why don’t do this or that?

Shane Gibson: And so there’s a bunch, like I said, roles versus skills. Project managers there, a term there’s a bunch of trigger words that Murray my co-host. And so one of them I have is transformation. So we think about transformation. So, a caterpillar creates a chrysalis. It grows inside and covers itself. And then after a period of time, it comes out of the chrysalis, and it’s a beautiful butterfly, is transformed. And then it flies off and it dies. That what we want, sounds like a project to me, sounds like a program. It doesn’t sound like an iterative way of working. So we should be constantly changing and transitioning. We shouldn’t be transforming, because that term has a whole lot of beginning and ending behavior in it. Another joke I used to have is, how do you get an agile management office in organization really quickly, where you take the PMO and call them VMO? They’re no longer a program management officer, you are value management office. Well, we’ve just put different slippers on the same people. How do we expect change to happen when we do that? So I think when you’re talking about bigger organizations, and when you’re talking about their oversight, outside of the team and the heat shield for that team, I think it’s a scaling problem. We’ve got a whole lot of problems that need to be solved. And I don’t have patents yet for how to solve them.

Horia Slusanschi: It’s a really interesting challenge. So what we’re trying to do, because on the one hand, we want to be safe. I don’t want to try stuff that is scary, that may fail. I don’t want to be looking bad. I want to do things that are proven in other places, and therefore they’re safe, I want to have certainty that whatever decision I make is going to be a good decision. I don’t want to be seen as being irresponsible. I don’t want to take risks that are undue. So as a result of those desires, therefore, I will look around and see what can make things safe for me, what can be sure and certain? What can be reassuring, in terms of course of action?

Shane Gibson: Yes, there is no certainty. If I go ahead, I get a sinti of estimating work to be done, or do the work. I know the hold on, that won’t work. Because once I’ve done the work, and I knew how long it took, next time I do it, I do in a different way, or the context of the organization has changed. So there is no certainty. There needs to be safety in the way that it is okay to fail, but people don’t get hurt. We need to make sure that everybody is okay. And we lose a lot of that, especially in Scrum. We’re sprinting all the time. There’s no, safety of the team often. They get into this rat race, this hamster wheel of constant delivery. They lose the fun and the joy of the work they’re doing, often it’s a burden. So we need to bring some patterns and give them a break and let them do that. But every time somebody says I want certainty, he was like, you have no certainty in how you’re doing it now. Again, another trigger word, risk spreadsheet, where we write the worst down and color code them, to make the governance group go away. We don’t use them often. We don’t use it to manage the risk. We don’t talk about the mitigation, but then we don’t actually mitigate it. So there’s a lot of theater in the way we work in large organizations. That causes problems. But the in small organizations, they have a whole lot of different problems. It’s not just large organizations. Small organizations have a whole lot of different risks and uncertainty and their ability to fail is different for whole roster reasons. One of the other things that came out on the podcast, theme that stuck in my head is, there is a difference between a manager and a leader. I can’t articulate exactly what are those kind of quantify it, but it is different. There is very much leadership behavior, and managers. And the other one that was really interesting for me, is a good leader can become a manager for a short period of time, when it’s necessary. But they will then go back to being a leader, they will let go. That’s hard. Because once you get your hands on the right, once you’ve got that you’re managing the work to be done. Letting go again, it’s hard. So that’s what good leaders do. And I think, again, good leaders in organizations help with the adoption of agility. But I don’t agree the certainty and any of the practices agile or not.

Horia Slusanschi: I wasn’t suggesting that there is, as you might imagine, expressing a point of view. So I was attempting to put myself in the shoes of decision makers that operate in an organizational context in which risk taking is not rewarded. Mistake making is actually severely punished. If I operate in the social sector, be it New Zealand or Australia or other countries that have, democracy as a foundation. You don’t look good by making mistakes. You don’t want to end up on some form, in the past, there was talk of I don’t want to appear on the front page of the newspaper, these days it would be some form of social media scandal or or shaming.

Shane Gibson: I agree if you’re in the public service in New Zealand, because that’s where I work. You’re in a horrible situation right now. Because you need to change the way you work, the whole worlds changed and those practices need to change. But you’re in an organization that perceives that can’t afford the risk of that change, and society won’t let them fail. So we only ever tend to report on the failures, not the successes. And so that’s a hard job to do. And also, your shareholder changes every 3, 6, 9 years. And the intent of what you do as an organization supposedly doesn’t change. But the team does, the core, values get changed. And, that’s one of the things I struggle with. So one of the teams I worked with. And I actually just had a person I work with, there was change agent on the AgileData podcast. And she gave me a term that I love, and it’s called permaculture. She’s weirdly interested in mushrooms and fungi and trees and a whole lot of ecosystem stuff. But this idea of permaculture and so I’ve been thinking about it for a long time. And one of the things I struggle with is, when the chief executive of an organization changes off, and the previous chief executive was quite agile, focused, that worked in organizations that adopted agility, and they bought that change into the organization, then they leave. Often the new person comes in and throws it away. Just wipes it out. Agile stuff, didn’t work for me last time. And that’s brutal. How can we say we’re successful in our domain? If a senior person come in and the organization gives up. And it just lets that happen. So I don’t know. I think that’s hard.

Horia Slusanschi: It’s very interesting how, as you say, the organization lets it happen. So we could argue that it’s not the the people reporting to the new chief executive could do anything about it. It’s actually the person that the Chief Executive Reports to, it’s usually not a person, but some form of appointment committee or a board of oversight in some ways. In the social sector, there will be some form of ministerial oversight possibility.

Shane Gibson: We’ve seen that pattern, the new chief executive comes out and first thing they do is organizational change, and the tier twos that report to them get wiped out. And then utilities come in, and they restructure at tier three, and tier four. And portal people at the front line doing the job. It’s like, why are they doing this, I just want to get on and serve the person that needs my help, I need to achieve that. So one of the things that has come out a lot is this idea of setting a shared goal. As a leader, understanding that setting the goal and the vision and telling people where you want to go, and then leaving them get on with going there, is one of the things that a good leader does but that’s hard. How to articulate your goal. And if your goal is to make money, how many people were aligned with it? Somehow, but I think we’re going to see organizations that have a greater good goal, a goal that’s greater than just making profit.

Aldo Rall: And that goes back to how we express value, how we score that value, is that just on a monetary basis, or are we looking at, the triple bottom line? Are we looking at what’s the impact on people? What’s the impact on customers? What’s the impact on nature or environment? And that’s why I think it’s important that when we do that value scoring, that we understand those dimensions, the dimensions or the area discussed.

Shane Gibson: And also, we have to be okay that some people don’t have the same goals or morals or ethics or view on the world as us. So when I start off with a new team, early on, I will have a conversation with each of the team members about this is going to be a massive change. And you’ve effectively been voted on to an island and 9 times out of 10. You didn’t get a choice about whether you got put on their island or not. And it’s okay to vote yourself off the island. It’s okay to say you don’t actually want to work this way. It’s not for you, give it a go. You should at least give it a go and experiment with it because often a lot of people that I think would vote themselves off, become the biggest proponents of it, they love it that takes some time. But it should be okay for somebody to say this isn’t right for me. And then the organization should be very clear about what that means. Does that mean you can go work in another team that doesn’t work this way? Or does that mean actually, you’re not aligned with the organization and the organization would do the right thing and help you find a role somewhere else. And it’s the same when we get organizations that are driven by personal goals, that whole idea of personal worth. When you make the changes in organization, you got to be clear that, some people just want to work, get their money and go home and have the lives, they don’t want to work for an organization that’s focused on something other than that, and that’s okay. If they don’t align, then don’t align. But we need to treat people with respect when we do these changes. Otherwise, we can do a lot of harm. And I think we we had an experiment with it in New Zealand, and it didn’t really go anywhere. And I picked up a coaching ethics from Bob Galan, he gave me his one, will share it with me and I iterated on it for what i may feel right. I think we need each Agile coach, should actually say, here’s the things I subscribe to, here’s the things I believe in, here’s what I will do, here’s what I won’t do. And then we should hold ourselves accountable to it. Because, we’re dealing in people’s lives here. And it is a massive change. And if we do things wrong, we can do damage, or we can hurt people and we shouldn’t, not intentionally, we should be very clear on what we believe.

Aldo Rall: So that’s very thoughtful. So, in closing, what haven’t we asked you that we should have?

Shane Gibson: I think he’s 101 questions around governance that you probably got better guests than needs to talk about where’s the Agile community going? So if we think about an adoption curve, a lot of people have now said that we’re in the late majority for Agile. I have a joke with Murray, he was a co author of a book called Agile 2.0 and I’m not a great fan of 2.0 and 3.0, and that kind of thing. But it was a good question. It was the manifesto was written many years ago, had the context of the time. We’ve experimented a lot, we’ve learned a lot. I still think it’s valid. Because it’s a set of principles, it’s a set of words that still ring true to me. But what’s next, what is the next iteration of this way we work? Because something’s going to come out. We know, history tells us, when we get to that late majority, something new pops up at the early adopter mode. So what is it?

Horia Slusanschi: I’ve got it, it’s called digital transformation.

Shane Gibson: I think we’ve done that one as well. So what new buzzword from what are those big animals firms that have lots of young graduate people in shiny suits that need to get put on site. What’s the next buzzword for them? I don’t know. We see lots of buzzwords. And that’s dangerous. There’s lots of agile practices that have got lost. I think a lot of the lean and flow practices are more fit for purpose. But scrums easier to understand what it was for me, easier to coach, easier to adopt. So we might see moving back a bit more towards those flow patterns, maybe or maybe somebody else will iterate and come out with something else that’s better than what we do now. Which would be great. As long as it doesn’t get wrapped up into a whole bunch of certification or money making as the core goal. We have, agile Alliance and Scrum Alliance and those things, but there seem to be for me, looking from the outside and now more training organizations than professional bodies. But don’t know.

Horia Slusanschi: I have a few hypotheses about why don’t we already have something meaningful in the Agile oversight, Agile Governance, kind of space, first and foremost, people that it would be aimed at, have a habit of being extremely busy, and having calendars chock full of stuff. Therefore, most of the time, they won’t take the time to actually invest in some form of educational approach, that’s systematic. Another difficulty is, I went on a two day agile oversight or Agile Governance course. And now I’m certified Agile Governance or, that is unlikely to work all that flash, very much like, I took the IC agile coaching course. Now I’m an Agile coach, look at me six years ago, I was flipping burgers, which you might laugh, but I’ve literally come across people like that. So the difficulty is, most of us want instant benefit. I don’t want to do much effort, I just want to know, I just want to be good. I want to be a master of my craft. But please don’t make me think, don’t make me spend a lot of time and effort at it. Can I just, like in The Matrix, take the blue pill, and boom, I know kung fu or something like that. Therefore, it’s going to be really tough, it’s going to be really challenging. Because you want to get better at oversight, you want to get better at governance, it requires dialogue. It requires conflict navigation, it requires the determination to say some things that are painful, that are uncomfortable, that sometimes people particularly the higher up in the echelons of organizational authority go, the more ego comes into the picture, more often than not, and therefore, if you dare to challenge the orthodoxy, the current way that we’re doing things right now, or I’m calling the shots right now, then it’s off with your head, very much like an Alice in Wonderland and the Queen of Hearts. So again, other difficulties in getting agile and adaptable, going, which, by the way, is the reason why we’re making this as a podcast. So we can hopefully, explore some of these uncomfortable topics, and make it so that people don’t take it personally. Because they hopefully will realize that we’re not interested in bagging people and saying, you idiots, you’re doing this on that, how dare you not do a good job? No, we’re not at all interested in that. We’re very much interested in redemption, in helping people to become amazing leaders, amazing practitioners, wise and inspired oversight, courageous practitioners of dialogue, that actively go and look at what is actually going on, and invite people into the conversation into dialogue. But it’s not just about making things safe. It’s also about practicing courage. So the challenge we have, fundamentally as a community, in terms of where do we go next with agility is, how do we cultivate the courage to keep each other more engaged, more in tune, with one another and less Despairing or despondent. Because you’ve also heard Agile is dead. There’s no more of validity. It’s 20 years old, who cares? Well, actually, until such time that you can show me something way better. And we can do that. Agile ideas are still particularly valid. The problem then is mislabeling of things. Because when you see a lot of friction and action, that’s ineffective, and you say, it’s agile because they have daily standup, it’s agile, because they have retrospectives. Well, no, it’s mislabeled. It’s fake, agile.

Shane Gibson: And I still think go a team that do daily stand ups and nothing else is better the team than a team who don’t, team they don’t talk to each other once a week, is not as good often as a team that talk to each other each day. But I’m with you. I remember when I first started this journey, I first heard the word agile and I started exploring or reading up on it, I saw a bunch of hippies doing Kumbaya. But as I used it more and learned the value of it. I was like, “Yes, the other thing is we’ve got to understand that this senior leaders at organizations, this is all new to them”. Their literacy is low. I look at somebody who’s laughing me the other day when I was texting on my phone, because I was using my fingers to type the words and young digital natives will use their thumbs. And so my literacy on using that as low compared to theirs. If you’re a senior person in an organization, you got taught through your business schools, and through your experience, that command and control is the way an organization works. And we use lots of cool agile words. We’re almost as bad as the data industry. We use words that don’t make sense. And so, again, who’s teaching them? Who’s making them more literate on the value of these things? Who’s making it so that they don’t need to be scared when all these weird words get used really quickly? And they don’t understand what everybody’s talking about? Because that’s a massive amount of uncertainty for them. And why would they let somebody do something in the organization where they don’t understand what it is? And it can’t be articulated to them in a way that they do understand? I don’t understand what you’re saying. So why would I take that risk? So there’s a cool role there. And helping leaders become literate in what we do, and why there is value in what we do. So still a lot to do, even though we are agile age. So like, the data warehouses did, I keep hearing the core principles of a data warehouse to where value? So it’s still an exciting time to be. And, for me, still working with a team and watching them grow and change the way they work and start enjoying their work again, and getting success. That still gives me a buzz every day, I see that happen. So that’s a cool place to be.

Horia Slusanschi: And that’s the hope for the future, really small, highly engaged teams that achieve great results for their stakeholder communities. That’s the way to go. Because if you have teams that actually achieve great results for their customers, and their customers go, this is great. Give me more. How are you going to mess with that? And why? Who’s going to let you when you’re delivering value, like that, so we need more of that? Wonderful. And with that, I would like to thank Shane for a wonderful series with us. I’m Horia.

Aldo Rall: And I’m Aldo. Thank you, Shane for your time and thanks for sharing your ideas and thoughts with us.

Shane Gibson: Great chat. So thank you too.

Keep making data simply magical