AgileData #15 - Leading agile data at scale

Welcome to the Agile BI Podcast, where we chat with guests or sometimes just to ourselves about being agile with teams who are delivering data analytics and visualizations. Welcome to the Agile Bi Podcast. I'm Shane Gibson.

I'm Blair Tampero.

And I'm Chris LaGrange.

Welcome, Chris. Thanks for coming on the show. You and I have known each other in the Wellington space for quite a while around that BI data and analytics space, but not so much in the land of Agile. So what we tend to do when we have somebody new on the show is ask him to give us a bit of background about, you know, where they've come from, where they've been, how they entered this world of data analytics and particularly agile.

Great, thanks Shane, and thanks Blair for having me on the show. I'm really excited and happy to be here. Yeah, so as you say, I've been working in the data and analytics space in Wellington and around the world for the last couple of decades and have worked both at the deep technical level as a developer and as an architect and also worked in leadership roles and management roles for a number of different organizations and also worked in professional services and consulting in that space. I've worked in predominantly the private sector. I've only just recently stepped into the public sector and working in a large government agency. But certainly what I've found over the years is that agile has become very much a key enabler for success in the data and analytics domain. And I think that a lot of the challenges we've struggled with over the years with successful data delivery and data warehouse delivery has come back to a lot of the key disciplines that agile brings to the table.

Normally when I'm working with teams, I'm working with teams. So I find that I get brought into a team that wants to change the way they're working, or there's a group of people that want to do that. We're at the coalface, right? We're working with the teams in terms of their mindset, the tools and techniques they use. But often we'll be working with an organization that has started their Agile journey, uses the word Agile at an organizational level, but really isn't adopting that business agility. So an example I use often is the funding models, right? The teams are still funded on project-based funding rather than a pipeline of people that do what's the highest priority next. So for me, you're probably one of those more interesting people that are sitting above the team, right? Still in the data analytics space, but above the team in your organization. So how are you seeing that difference between agile within a team and the way they execute versus adoption of agile as a business and their business agility?

Yeah, that's a really good question because I would say where I am now, I'm very fortunate that the leadership of the organization has embraced the idea of Agile adoption and an Agile approach, not just in the delivery of our technology projects, but across all initiatives across the organization and really looking at organizing the whole organization around the concept of value streams, the concept of delivery in ongoing increments and ongoing delivery rather than, you know, big milestone-based drops and things like that. So that's quite key, which has brought a lot of those funding questions to the table. And really, you know, I first did Agile in 2007, I was working at Allaraq Telco, and we implemented Scrum at that point in time and put together a team of 7 and kicked off our ceremonies, kicked off our stand-ups, got underway. And about a month in, things were actually going pretty good. We even brought some of the key business stakeholders into the sprint team and actually had them on-site co-located with us, and it was all going great. And then I got a call from our finance accountant who said the burn rate for our project was was 5 times higher than any other project. And of course, it was because the full team was involved end-to-end. And in that organization, we saw that immediate cascade of where we had moved from a classic waterfall model where I had a BA assigned, then I had the architect assigned, then the developer, then the tester, then the operations team. Suddenly, all those folks were involved at once, and the burn rate was so high that the organization became terrified that they couldn't sustain that. And, and so they pulled back on it, and we actually ended up pulling the plug on that test, uh, 3 months in. And we actually delivered quite a lot of value over that period, which is the disappointing side of it, which was actually the team delivered a phenomenal amount of value and a really functional solution, and the business stakeholders were ecstatic over what they received. And yet we couldn't get support again to take that approach, because what, what ended up essentially happening is we spent the same amount of money in those 3 months that we probably would have spent in 12 We probably got to the same outcome in 3 months that we would have got to in 12. We just got there 4 times faster. But all the organization could see is we were spending 4 times as much money.

Really, finance need to be involved in the adoption as well?

They do, and they have to really get their heads around it. And this is where a lot of the challenge that we're unpicking in the organization I'm in now is that training and education of what Agile is, what the Agile principles are, what the sort of fundamentals are. In Agile for people that historically organizations haven't even thought about putting on Agile. So we've got our executives, our CFO, our deputy chief execs, a lot of our GMs from across the business now doing Agile training and actually going through the formal process. One of our associate DFOs, who's normally the CFO, stood up at our last PI planning day and said, "Well, I'm now an Agilist and I understand it." And a few other people in the room said, "You're not an Agilist yet, mate." But—

So out of interest for that, is Is the training that those senior people going through the standard training of agile mindset, the pattern, the manifesto, the principles, and those kinds of things, or is it tailored for, okay, so what does this agile thing mean to you and your type of role? So as a CFO, we're going to potentially move to a lot more operational costs versus capital costs.

That's right.

Because ideally we've got internal employee teams doing the builds, less contractors, less vendors, that kind of thing, right? So, yeah, is, is that the kind of training you did? You tailored it?

So it's been a bit of a mix. So the training that I just mentioned, most of that was actually the Leading SAFe formal courses. And from that, we've then established a Lean Agile Center of Excellence inside the organization, and that group is working as an advisory to some of our key governance groups like our Portfolio Executive Committee that oversees our full program of work. And so they are providing that advice on a day-to-day basis to some of those key leaders in addition to the formal training that we've done. I didn't have control over how we approached that training with them. I probably would have put them on the Agile Fundamentals type training before I put them on the methodology type training. So, yeah, so, you know, you kind of, you take what you can get, so to speak, and it's great that we're investing in that. Yeah, I think that it takes time for people to get their head around the Agile Fundamentals and the Agile Principles, and I think that'll drop at different speeds. For different people as they come to that sort of moment of, what's the old IT term, grokking Agile. Sorry, but yeah, as they get that full understanding of it, as they get a full appreciation for it, that takes time. In terms of getting our finance folks to get their heads around that, yeah, it's a learning process still. We're not there yet. We are starting to understand that we need to stop funding things based on a, what I call a one and done business case to deliver a thing. And when that thing's done, we capitalize the asset and we're done. We are starting to look at funding value streams, where we assemble a squad, that squad continues to develop against a roadmap, and then as that squad implements, we capitalize assets along the way.

That's actually an interesting one because, you know, we're talking a lot about technical debt, and one of the things that I think is slightly different in the data and analytics space is the value of our data degrades over time when we don't keep working on it. So, you know, if we create an analytical model, we score that model, we fit that model, we put that model into production, and we know that over over time, the behavior of our customers, stakeholders, citizens, or the data we're using, right? Things will change and the accuracy of that model will degrade.

Yes.

And so in the old days of analytics, before we had the data science and AI buzzword, we always talked about monitoring those models and figuring out when they need to be rescored, retested, retrained. With data, if we think about the old data warehousing days, we always had a team that maintained the warehouse and kept it up, but they also then were the ones dealing with the issues that came through when things changed. And so when we're in this land of agile and we're still using block funding models, we don't really bake in that time and cost to keep refreshing and doing it. And if we take the technical debt idea and actually apply that to data, there's a really interesting idea about making data actually an asset. So as we've developed the data and moved it into somewhere that's useful, we take the operational costs of the team that delivered that, we create a physical asset out of it.

Yes.

And we depreciate it, and that depreciation cost goes back in as points or something where the team's allowed to use that value to refresh and recycle to keep it healthy.

That's right.

And yeah, interesting idea.

Yeah, there's a great quote that I love that it's not mine, that came from a colleague I spoke to recently who said that data is a liability until you make it an asset. And that is very, very true in the data warehousing world, and most organizations will find this true in their core systems as well. And to your I mean, you know, that ability to actually expose and understand the value and then realize the value is where a lot of organizations struggle. I think the job is done when the data is collected and made available, and it's not. And that's where I think agile, agile gets you a ways down that path. I think that comes back to business culture and IT culture and investment making. You know, the organization I'm in now has always used its capital depreciation to fund the reinvestment into its assets. For lifecycle maintenance, but not really from the concept of continuous enhancement of those assets. And, and so what we actually ended up doing organizationally is centralizing all of those capital depreciation funds back to a central body and then allocating those out to our program. And, and we've moved from individual capital funds and individual capital allocation to funding capital as a stream across the work program. So instead of looking at, you know, this business case allocates this much capital and you get this much money and then you're done, we are starting to look at instead going, well, we know we have— I'm plucking imaginary numbers out of the air, I'm not using our real ones— um, we have $20 million a year of capital that we're going to spend. We're going to break that into 5 program or 4 program increments. Each one of those is going to be $5 million, and then we're going to decide what we're going to do inside that program increment. That's going to add up to $5 million.

So bringing a prioritization framework at that level to say, here's your scope, which is effectively this many people for this amount of time.

Yes.

What is the top priority things right now for this increment that needs to be delivered?

Yeah, that's right.

That's the trade-offs.

Exactly. And it also means for us, we've actually stripped away a huge amount of the front-end work that goes into conventional project funding and capitalization planning. So we have a principle where if the work is under $2 million in total cost, we only require about a 5-page lightweight business case to get that funding released and get that work underway. And then we just track the spend, PRB, PI, look at their forecast, look at the tracking, and then we manage variations as we go. And generally speaking, that doesn't mean we've got a whole bunch of $1.9 million programs. It actually means we have a whole bunch of $100,000 projects, and, and we're generally managing capital inflow and resource inflow. And actually what that then teases out is the real organizational constraint, which tends to be our people's time and availability. Availability to complete the work. And, and that then drives a much more tangible and realistic prioritization discussion at the organization level, because typically it's not prioritization based on what has the most capital benefit, it's what's achievable based on the resources that we have.

Right, so you might find that something is a high priority but the skill set's tied up with something that's a higher priority.

That's right.

So therefore priority number 5, you know, is the one that's achievable with the skill set or the team that's available.

Exactly.

Cool. And that almost sounds like you've kind of taken the Gartner, you know, Type 1, Mode 1, Mode 2 theory of fast lane, slow lane, but changed it so it's actually usable. Yeah, to a level. To, you know, low governance overhead because of the risk and the dollar value and that kind of stuff and a lot more visibility. That's right.

Yeah. And culturally, it's also meant we can give our teams the confidence to try something, see how it goes, and then come back if they need to do more, right, without having to know all the answers at the very beginning of the project. And that, I think, is fundamental to Agile. If you don't have that ability to put your trust and confidence in the team and then know that you can control the throttle, that is where I think a lot of organizations fall down when they try to move into Agile. They think, I still want to know what it's all going to cost, up front and I want to know what I'm going to get for that and I'm going to know what my rate of return is and what my return on investment is at the beginning and only then will I release the funding. Instead you go, well, no, I'm just going to give you 10% of what you asked for and then you're going to tell me what you deliver off that and then I'll decide if I continue or if I decide to stop.

Do you find that those smaller value projects, you know, so the $100K ones, where you're doing a lot more MVP or Ration Spikes, so you know, you know there's a bigger piece of work you want to do.

Yes.

Some people quite rightly are asking some questions that you can't answer because you haven't done the work or the research or thought about it. So you go away and do, you know, a small bit of work in the funding model to then come back where the outcome actually is a set of answers to the questions that were unknown.

That's right.

And a slight more surety that the plan's able to be executed.

Yeah, we are absolutely seeing more of that. That's where we're actually, I think, now at the next stage of the challenge we're going through, which is how do we get more MVP thinking into the organization. So that to me, as much as your Agile teams and your program group need to understand that perspective, the real change you need to see to succeed in that is in the rest of the business, the rest of the organization. They need to think about their problems differently. They need to think about their problems as what's the next thing I can do in this space to get me further to the solution. Rather than I need the complete solution. And I need to, because, you know, it's sort of like the old Agile metaphor, you know, build a scooter, then build a skateboard, then build a scooter, then build a bicycle, then build a motorcycle, then build a car. Well, if you go into a car dealership, they're not going to try and sell you a scooter. And so most people are still trained for the, I have a need, I'm going to go and ask for a solution. And I've already conceived in my mind of what that solution is. So if you tell me that I should get a scooter first, and then you give me a car later, they're going to go, "No, no, no, no, no, I know I'm eventually going to need a car, so I'll just buy the car." And that's breaking down that mindset. So in our world, that means, you know, if I say, "I need to give you a full customer feedback closed-loop solution that tells me what all of my customers' experiences through each of my channels," and you go, "Well, can we just do that for one channel?" I go, "But I'm going to need it for all channels eventually, so can't you just build something that does every single channel?" And that's that challenge you get into.

Have you noticed with more regular demos that sort of mindsets change?

It does. Yeah.

People are seeing something regularly.

Yeah, once you prove that you can increment and that you prove that they can get something that they can use. Yeah.

So that question of what's next is—

That's right. Yeah, but that's a leap of faith for a lot of people to sort of step back and say, I'll let you go, you'll come back to me in 3 months and you'll show me something meaningful that I can actually use. And that's also where the other challenge is that, you know, you still have to get your own technical teams thinking that way as well. And then data warehousing in particular, there is still this mindset that we have to have all the data first before we can do anything with it. So there's this concept of, well, yeah, I can iterate, but I still have to do a massive data integration build before I can actually deliver anything off the top of it. And the challenge with that is it still adds oftentimes months or years to the cycle before you can get to a prototype. So you've got to change that thinking back to what I almost use the term, you know, you need that data steel thread of what is the key thing I want to answer, how do I integrate in a way that gives that answer without worrying about all the other dependent datasets and assets that come through.

And I call it thin slice, right?

Yeah.

How do you thin slice it so that something gets in front of the customer?

That's right.

And it's workable in production.

And well, it should always be production ready, right? So yes, I mean, for me, definition of done, you know, we've tested it, you know, we've documented it. There's these things as as professionals, we should always do our job and that's our definition of done. That's right. But yeah, how do we get something to somebody else that has at least some value, even if it's really small? Because we knew that it's 90% backend build, right? We're doing the initial, you know, used to be called Sprint Zero, right? And I'm not a great fan of Sprint Zeros anymore, but I was, but not anymore. And often, you know, we sometimes guess and guess wrong. So an example I've got is with one of the teams I was working with, we all guessed that CDC, change data capture off a database of the core system, was the highest priority.

That's right.

Right? So that's what, if we were, if we had gone into a sprint zero, we would've built that capability. The first information product we got delivered, given as the highest priority for the organization, became a deliverable that was an emergency because a project had just gone live and delivered no data reporting. 'Cause you know, everybody de-scopes it.

Yes.

What a surprise.

Yep.

That source was an API.

That's right.

Because it was a software as a service app and there was no way of getting access to the database.

So you can't consume the entire application's data model. You have to choose that field and almost think of it more as a stream of one dataset. Yeah, exactly. And that's a mindset shift for a lot of people. And that's where, you know, the move to cloud and the move to software as a service is spinning a lot of data teams because they want to be able to fully consume a data model and they want to create a CDC structure against it. And raise that. There's a philosophy I've developed, well, not a philosophy, you used the term surprise earlier, Blair. I have what I call the classic 3 surprises of data engineering. I think Agile goes a long way towards helping those. But those 3 surprises, so surprise number 1 is it's always going to be harder to get the data than you think. When you talk about CDC systems, when you talk about moving to cloud, this is actually getting harder. Getting the data that you need in the format that you need it is going to take longer than you think, it's going to take more time. If you're trying to get all the data you need up up front, it's going to slow you way the heck down. So you really need to think about what is the data I really need to do the first MVP? I'll just focus on that and then I'll go back for the other data assets. A lot of practitioners have a tendency to focus on, well, I know it's going to be hard to get the data, so I'm going to try to get all of it so that I don't have to go back again. And you end up with these data warehouses that are almost a complete replica of all of the IT systems in an organization.

I think we call that data lake now, don't we?

We do.

Yeah.

Yes.

Yes.

Yes. You know, data lake is You know what? That was really hard. So what we'll do is stop transforming it. So that it's easy for people to copy. Bing Data Lake. That's another thing I can sell as a consultant. No, sorry, I sounded jaded there for a moment. So that's surprise number 1, and that's the big challenge. Surprise number 2, the quality of the data will always be worse than you expect. So once again, that means the earlier you expose the data to the end user, the sooner you're going to see some of those problems surface. And I think of data quality in a number of different ways, but obviously, you know, this, the, the, is quality and structure. So if I've got a field which is first name, last name, and I'm loading Chris Lagrange, well, oftentimes I see systems accidentally attach the La as a middle name rather than as part of my last name. So that structure gets wrong. Data warehouse teams have gotten pretty practiced at catching those sorts of anomalies. But my name is L-A-G-R-A-N-G-E, not L-E-G-R-A-N-G-E, but I'm the only person who knows that. So until an end consumer who actually can look at the data and say, yeah, that's right or wrong, knows that's wrong, you won't see that. So the sooner you expose that data, and the more regularly you expose real data to real users, you will only then start unpicking a lot of those data quality problems. Because once you get over the access problem, the next thing that slows you down is your quality problems, your data quality issues that you expose in all of these systems. And that gets you into your third surprise, which is that every time you put data in front of business or in front of an end user, the requirements will change. And we treat that as a surprise when it happens. But it's actually a benefit of good delivery because in our world, people need data because they don't understand what's happening. So when you give data to them and they suddenly can see it, they learn from it and they build a deeper understanding of it, and their understanding matures and evolves, and they start asking more questions. Those are positive. Oftentimes, we're trained in conventional IT systems engineering thinking to think, no, we have to have all the requirements at the beginning, and then we're delivering to those. And what Agile gives us is the ability to say, we know we don't know everything at the beginning. We know we want to iterate. We know we want to flex. And one of the big powerful things Agile lets you do is say to the business, we're going to put the data in front of you. You're going to change all your requirements. We're going to embrace that change because that actually improves the solution longer term.

Yeah, I think the way, the way I think about it, and we're doing a bit of research around using chatbots as an interface instead of a BI tool, because that's a new hot area anyway, but it looks like it won that's one that actually might have value to end users.

Yes.

And so the way I think about it is I think about it as my next question. So if we think about the requirements change, in my view, a lot because somebody will say the question I have is how many customers.

Yes.

Right now, that's just the first question, right? It's the first question they have in their head that they can't answer, and they can't make any decisions without understanding that question and the next question. So you give them that, and then they're Excellent. Actually, I need to know where they're located. It's not a change of requirements, it's just until they understand the answer to the first question, they haven't really thought about what the next question is.

That's right.

And so that iterative approach that Agile gives us, where it's, here's the answer to that question, what's your next question? And, you know, if we team it with some form of automation, or DataOps as it's called now, where adding the next bit should be slightly faster than adding the first bit, if possible.

Yes.

Right, we get some speed from that point of view, then we can behave in a way that meets their needs quicker.

That's right, and that comes back to, you know, we've got to get better at the things that inhibit the ability to iterate rapidly, and your definition of done that you talked about earlier, I think, is quite key to that. Done means documented, tested, productionized, rigorous, auditable, traceable, full lineage. All of those things need to come with the solution out of the box. And, you know, we have tools available these days that automate a great deal of that and can speed that up. But that is also where teams often get bogged down, is in all of those. They'll think, oh, you know, I'll give the business a spreadsheet with the data, or I'll give the business a table I've populated manually with the data, and then they'll have to wait another 6 months before I automate and document and harden that entire solution. And once again, that's where we fall over. So, you know, that ability to break that down, but also to deliver at speed without creating technical debt as you go essential. And, uh, you know, and that's not just true for data and analytics teams, that's true for all IT systems teams these days. Yeah. And I actually think that's where most of the drive towards cloud is coming from. It's less about the cloud costing model, which has some benefits, and it's less about cloud as a, um, a somewhat turnkey solution. I think it's because actually in practice people are finding that that hardening and that ongoing application management and that evergreen maintenance is really challenging for most organizations to do. So they're looking to cloud to provide all of those things so they can get back to focusing on the value.

Do you find though, because you know, every data analytics team I'm talking about now is moving to the cloud with the quote marks around it, and for some reason, and I see this in testing, the data landscape or the data domain always seems to be behind our peers on application development, hardware management, or compute, all those kind of things in terms of tools and capabilities with rigor. So I'll give you an example, you know, when in the old days we had, you know, VMware and VM servers and those kind of things, and I've seen a move to cloud with Kubernetes and those kind of things, and a lot of that rigor is gone with it. If I look at some of the, what I would call legacy tools, so I apologize to those vendors, but you know, the DataStages, the Informaticas, the SAS DI Studios, the Oracle ODIs, those legacy ETL tools in my head, they had a lot of rigor built into them because they've been around for so long and they just had added features that made everybody safe. It made life easier, automated some things. Lineage, classic one.

Yes.

Most of the teams I'm working with now have moved to the cloud and they've become far more open-source-centric. And so the benefit of that is no upfront license fees, a lot more flexibility. If you architect it right, you know, in terms of automation and DataOps, you can swap pieces in and out when you find something slightly better. You get access to the source code so you can add features that you need without going into a 12-year release cycle. But the downside is those tools don't have the capabilities that made us safe.

That's right.

Like an example Blair and I were talking about before you arrived, moving from a relational database to hold data to a NoSQL, you know, name-peer-key data store.

Yes.

We lose a whole lot of things that in the data world we got for free of what was in the license.

Referential integrity.

We relied on it often because it made us safe and it was just there. Do you find that in the data analytics space, The move to the cloud has got heaps of value, but we actually lose some things that made us safe for a while that we have to reinvent or reimplement.

Yeah, we do. Yeah. And that, I'd say that's an absolute key challenge that we're seeing as well. As you move to the cloud, I think it really comes back to the fundamentals. Know why you're doing it. Don't go to the cloud because CIO Magazine said you should be in the cloud or because there's a blanket policy for your organization that we're going to be cloud-first. And everything. Those things are, are there. I think they're good guidance because there's a lot of benefit from the cloud, but know what those benefits are, know what you're trying to achieve with them, and don't just do it blindly thinking it's just going to be better. Because you're right, I think the cloud is very much where we were— the cloud technologies that we've got in the space are where we were in data and analytics probably around the early 2000s, where there was an explosion of vendors and capability in the marketplace. And I think that explosion now is an order of magnitude bigger than it was back then. I forget, I've lost track of how many data Data vendors, Dataflock is tracking, I think I want to say it's in the 5,000 to 6,000 range now. There's a huge number of them. What we're going to see, I think, in the next few years is a collapse and a consolidation again, much as we saw in the late 2000s with a lot of the big vendors swallowing up a lot of those smaller integrators. Synopsys goes to Oracle.

Cognos goes to Softy. Yeah, and we've already seen that with Salesforce buying Tableau. That's right. Qlik buying, you know, Unity and some others. We're seeing the consolidation of the thought leaders Yeah. Getting bought out by the big incumbents.

And that's kind of the nature of the cycles that we see. And it's very true in the open source space because in the open source communities, that's where a lot of the innovation is coming from. It's where a lot of the new ideas come from. But most of the open source products out there are a very smart and very capable group of people working on solving one problem. And in data warehousing, we have about 1,000 problems to solve to build the solution. So we're now back to the putting all the pieces together in order to get there. So, you know, oh, I've got a streaming solution that gives me my feed, but that doesn't give me my auditability and my lineage. So now I need a metadata solution that can catalog and track that alongside it. And I've got to put all those pieces together again. You know, what we saw a decade ago was most of the big vendors were starting to bundle big application suites together to actually solve that problem. So you'd buy e-business suite and you'd get all of that in the box, so to speak. And some of it was good and some of it wasn't, you knew that you kind of had a full set. And now we've got to go back to building that set ourselves again. And you're right, I think a lot of teams are struggling with knowing all of the pieces that they need to pull together and how they do that. And it is adding that complexity back into the equation. And there's a big learning curve for a lot of these technologies as well. And we're back into the old challenges of interoperability and compatibility and standards. So all of that comes back through again. I think that's actually, unfortunately, what keeps guys like you and I in work.

I always say, I feel it's a bit like the stock market. Market, well, the financial market, there's a 7-year cycle. Yes. In IT. The bit that makes me really grumpy is I know there's a 7-year cycle and I've seen it for 3 cycles.

Yeah.

I still haven't figured out how to make billions of dollars out of that cycle. So I get quite grumpy with myself because I know it happens.

Yes.

And I can tell you kind of the pattern that we see and I still don't know how to leverage it.

I think the secret is to already have billions to spend and not have companies to buy.

Yeah, true.

Take some risks.

Yeah, yeah, yeah. So if we go back to one of the things you said really early was this idea that you'd put your senior people through some of the base training and leverage that as— and I think what I heard was it was kind of like a taster, right? It was a— yeah, it's a bit of an effort and some of that stuff won't be relevant to you, might be a bit too detailed, but it's an immersion that gives you insight that will then have you asking more questions that are relevant to you and your role and what it means to you. And then you created almost a coaching office, is the word I know it's not the word you use, but that's what it is.

Who is this effectively?

A bunch of experienced coaches who could then engage with those people and have a conversation at the right level, at the right time, about the right thing.

That's right.

To help them, you know, answer the questions that they have each time.

That's right. And alongside that, we are adapting our governance structure and our governance principles and practices as well to identify those challenges. And we haven't solved for all of them. One of the big ones we're working through at the moment is We, like many organizations, have some teams that are purely project-funded, and those are actually the easiest ones to move to an Agile funding model because, largely speaking, they're all being charged to the projects, being charged to the capital. That's fine. We have a group of other teams who work in oftentimes more operational roles that occasionally do project work, or part of the team is generally doing some project work and part of the team is doing ops work, and we're struggling a little bit in that space. To get those teams into the full sort of agile model once again, because a lot of their work is much more reactive. And there's also those lines of business that have their own sort of dedicated teams delivering services to them as well, but those teams also provide some services to the rest of the organization. So that's where a lot of BI teams sit. Oftentimes you'll find a BI team has some key business groups, oftentimes marketing or finance, who are sort of those most important stakeholders that always get what they want. And then they deliver stuff to everyone else as well. And we, we have those sort of challenges that we're unpicking and trying to understand how we continue to enable some of those key value streams to occur, but at the same time make sure we're still prioritizing across the organization and make sure we're still looking at the whole organization comprehensively and not letting someone's— to coin a phrase— someone's little private force achieve their goals, which may or may not be more the most important thing for what is the organization to achieve is quite key.

And because the organization you work for, you're working with, is so large, you know, you must have that scaling problem where at a senior level, the vision or intent of the organization, the strategy or what good looks like over the next 5 years is probably pretty well known. At a certain level, I would hope. But as you start cascading that message down, you know, as you start scaling to teams, then that it's like whispers, right? The message gets really muddled.

Oh, it does, it does. Yeah. And I think that's, I mean, look, I think that's true in our organization. I think that's true in every large organization I've ever worked in. The more layers you have separating your leadership from your execution, the more it becomes, the more structured you have to be in how you message what your strategy, your vision, and your goals are and how that works. In a perfect world, everyone would have a strategy map, which would go from the high-level key objective for the organization down to each line of business, down to each unit, to a measure that's in somebody's performance plan, which tells them and if you crank out 15 widgets a month, then we'll achieve our KPI for the year. And I've never seen that in reality. It doesn't work that way in reality. In reality, it's kind of setting a direction and then everyone else finding out how to get there. And I think that's, you know, when we look at agile, it gives us that ability to course correct much more rapidly, I think. But it also gives you an opportunity to go the wrong way a heck of a lot faster.

Yeah, but I think we also get some patterns, right? So we, you know, I don't know who we were talking to a while ago about OKRs. I think it was Andy Cooper. And then Blair and I went to the JAFIC conference, Agile kind of group meetup thing, 2-day conference that Nomad 8 ran last year, and there was a whole conversation around OKRs there, which was quite interesting. Another one's value stream mapping, you know, again, that idea of seeing end-to-end across an organization what's happening and where the value is and where you can tweak it. So there are some patterns that we can leverage that help with that that shared understanding of what good looks like as an organization and where we're going.

That's right.

But it is hard.

Yeah, it is hard. And we are doing that at a comprehensive organizational level now. We are moving to value streams that go all the way from frontline to backroom IT. And we're bringing those teams together to work side by side on solutions in a joined-up fashion. Really early days for us in that space, but it's really exciting as well to see that actual, that change happening. And, you know, as I say with Agile, there's the methodologies, the frameworks, and the practices, and those are fantastic. Those are good. But I actually look at those and sort of say, whatever your methodology is, get good at your methodology. Just be good at what you do and solve for that. Because even if your methodology isn't perfect, if you're good at it and you know how to make it work, then it'll probably get you where you need to go. There are no bad methodologies, there are just bad fit methodologies for different organizations.

Bad implementations.

Bad implementations.

So again, with that JFIC conference, there was a really interesting conversation. And what it was, was, so they worked on the, I can't remember what it was called, but the idea that everybody could throw some topics up on the wall. There were slots, you have a certain number of topics, and then you created your own little space, and then you could go and be part of that topic.

Open space.

Open space, yeah. If you got bored, you could go to something else halfway through. You're allowed to leave halfway through, that's okay, right? And if you're, all that kind of stuff. And one of the ones was, an interesting conversation about the state of the Agile market in New Zealand with Scrum Masters, coaches, and vendors and Big Five, and it got a bit heated. But one of the interesting things that came out of that was this perception based around the case study of McKinsey and Spark. And so there was a statement in there around, you know, 3,000 people were made redundant at Spark because they went Agile, and that's a really bad bad thing for the Agile brand, the Agile mindset. So there were a couple of people from Spark actually there, and they said, "Really, actually, it's not true. There's about 300," right? So, you know, pretty heated conversation, which was interesting to watch. But later in the year, I'd kind of gone to some Agile meetups, and I met some people from Spark, and I was talking to them. And what they said was, as part of their move to being an Agile organization, and they took more of a Spotify approach, right? With, you know, tribes and chapters and those kind of things, they quickly realized that they had somewhere like 6 to 7 levels of middle management of team leads, right? And in the new way of working, some of those people would move into a chapter lead or a tribe, you know, they had roles and they had skills. But even after they'd done that, they figured out that there were more people than there were roles or things to do. Yes. And so as a result, those people left. And so I look at that and I go, okay, that feels to me that the organization has made a commitment to try and change the way they work. So you talked about PI Planning, right? So I'm assuming that your organization started the SAFe journey.

Oh yeah, we're in PI 13.

Okay. As I've probably said on the podcast, we haven't recorded one for a while, but I've become far more vocal about, I have lots of concerns around SAFe safe as a methodology because I see it being flagged as a methodology, not a way of working that has value and you can tweak it, more as a, here's an out-of-the-box solution and if you follow all these things. But there's lots of things in there that I think have real value from what I could see. So things like release planning, if you have more than 5 squads and you're working on the same thing and near the same date, the idea of a release train and being on that has value. The PI planning, the idea of getting people together and seeing from a shared vision point of view how you're going to go over a period of time. Still struggle with 500 people being in a room as value, but I can see some value in that process. But the other one that I came back to was, especially in Wellington at the moment, SAFe kind of indicates that the senior people in an organization have made a commitment to change. Because it's an immersive methodology, it's the organization should change the way they behave. Is that what you're finding? Is that— I am finding that.

I think to me SAFe is an opportunity to cause that change to occur. And sort of, many years ago, I was working as an architect, and one of the fundamentals in enterprise architecture was almost the, if an organization is centralized, decentralize it, if an organization is decentralized, centralize it. Not because either of those frameworks is better than the other, but because the change brings the value. And the process of change flushes out all the inefficiencies, and it flushes out the redundancies, and it flushes out the other things that the organization has probably accumulated over time. It's a horrible thing to say in a lot of ways, but looking at like the change that Spark went through, I think that Agile was the change, but it wasn't the reason that they went through that, that structure review and they had redundancies. I think that that was a secondary effect of the change happening in the organization, not, oh, we're doing SAFe, so we need less people. I think it was actually the change triggered a review of the composition of the organization, and that happens. I don't care methodology you go to, if you actually embrace it and you decide that you're going to change the fundamental structure of your organization to be successful, then yeah, there's going to be disruptive change to the organization.

With that organization, they're in a fast-moving environment with new products, new technologies, and it's been a large organization for years, Spark Telecom, and it's had constant change in terms of structure and that. So again, it was interesting that it was, in Wellington, there's some perception that it was the Agile badge that caused caused this.

Yeah, but you could actually go through 5 restructures, you know, the telecommunications, um, regulations that were made in the, in the, you know, late '90s, and the, you know, the, the structural separation caused far more change than that did. And, you know, um, so yeah, and then, and, and then that organization and many organizations, you know, changes unfortunately in any big organization is an inevitability to an extent. All organizations over time, you know, you tend you see organizations contract into a new model of working, and then over time, they expand out again.

They scale.

Yeah, they scale back up, and then they go through a contraction again. Unfortunately, that seems to be the nature of corporations. I don't think that that's an agile problem. I think that's just the way that these things work.

Let's look at DataWorld, right? We had staging areas in the old warehouses where we put all the data before we transformed it and made it available. We treated that as a locked room. So all the analysts would go out and buy OLAP cubes. So then we kind of made things a bit more flexible and that was great, but then we started locking it down again. So everybody went out and built data lakes. Exactly. So we go through those cycles even though we've updated them.

It is that natural cycle. It's that IT 7-year cycle again and it's just how it presents itself. To me, if you develop any skill as an agilist or as a BI person, the biggest skill you can develop is the ability to adapt and change and to anticipate not just the little changes that happen day to day in your job, but the big changes that are going to come along and how you deal with that. That's Darwin's theory of evolution in a nutshell, is your ability to adapt to change, is your ability to survive in that environment. That's pretty much the core of what we're touching on there, I think. And I think for an organization, you can't not do something because it might affect and cause change. You have to think about what you're trying to achieve and you have to pragmatically look at what you need to do differently and how you need to work. If I look at the IT sector in New Zealand, if I look at the BI sector in New Zealand, I don't think anyone who's in BI today needs to worry too much about their job. I think there's a continuous growth in the space. We're in one of the most high-demand professions in the world, and that's not a bad place to be. But I think that we can't rest on our laurels there. I think we have to continuously look at how we get better at what we're doing. Doing because over time what I have seen is that the old way of doing things has given way to new methodologies and new practices and new tools and technologies which make it much faster, much leaner, much more ability to— we have much more ability to do things at speed. If we're still doing things now the way we did them 20 years ago, we will become obsolete. And that's where I'm seeing a lot of the challenge in a lot of BI teams as well. Agile is kind of causing them to change, but if I look at most of the things that that BI teams are struggling with Agile now. It isn't Agile that's causing the problem for them. It's actually that a lot of their practices are still very old school.

Come back to automated testing, right? We still have to build our own automated testing capability for data. And there's not a lot of reasonable patterns out there.

No, there aren't. And a lot of data warehouse teams really have a hard time even getting their head around what testing looks like in a data warehouse environment, never mind how to automate it. And that is one of the challenges, I think in New Zealand we struggle with that. I think that's a global problem though. I think, you know, good practitioners in the different domains with those key disciplines that understand what needs to be done and how to execute it successfully. And also then how to convince the folks that are managing them, leading them and funding them that these things need investment in order to be successful is also quite key. You know, it's funny you talk about testing and one of the things that I've seen many, many times in my career is that management first pushes back on project costs because the projects look like they're going to be too expensive. So oftentimes what teams will sacrifice is the intangibles, the non-functionals, the ability to do reconciliations, the ability to do replay and reloads that create all the technical debt that gets created from that, all those things that a good testing and quality framework would give you.

Or if we look at ETL tools where they're flow-based, so the Informatica of the world or the new Apache tags, you know, airflow tags and those things. We start off with each of the nodes in the flow is a distinct thing. You know, it has an in and an out, it does one task, it's all repeatable, replayable. And then we get under pressure. So you start seeing code nodes, right? You start seeing an in and then a big block of code and then an out. And so we lose the value of any linear, we lose all the value of our automation.

And you often lose your replayability there because developers are optimists and they tend to build code built to succeed, not code that's built to cope with failure. So, yeah, you get into all those situations and that's it. And so, unfortunately, what then happens is the system goes into production, we have regular batch problems, ETL problems, other issues come up, and leadership turns and says, "Well, you guys aren't building this very well, are you?" And that is the constant defensive pressure that I see in data teams. And I think that's where As practitioners, we've got to find ways to, in an agile world, but in a cloud world as well, continue to maintain that focus on a good quality robust solution that runs well, but that is actually delivering value regularly and continuously. And that's the risk I see in agile for data as well, is that we get into this mindset of just give them the data as quickly as you can, as often as you can, and strip away all of the non-essentials. Well, those non-essentials are actually essential. To continue to do those too.

Or if we're not going to do them, then it's a trade-off decision made by the product owner stakeholder, and it's a clear one.

Yeah, it has to be, they get it in writing.

But yeah, acceptance criteria. I mean, I've got an example of one organization that effectively their analytical models are disposable. They have a team of 10 data scientists, and their acceptance criteria is the model was built quickly, the model was accurate, it, the model is run, uh, and then you move on to the next model. So they've prioritized speed of model, speed to market, over reuse and automation. Yeah, uh, and that's all good, right, until they carry on with the conversation, and or but, right, which is, oh, and it would be great if you could run that model for 3 months repeatedly. Oh, and it'd be great if the other dinosaur scientist could pick it up and reuse it. And so then it's like, okay, so now it's not going to be as fast as a disposable model, because we're building all that rigor in, right?

That's right. And then you have a change management exercise as well. And so you've suddenly got the need to understand who all of your users are, who are impacted by each change that comes through. It's funny you talked about, you know, release train. Well, one of the biggest things I think data warehouse teams get out of that whole mindset and that whole shift is in release trains, finally there's a place they can generally go to see what change is coming from all their core systems that's going to disrupt them. You know, so many data teams I've worked with have struggled with the constant disruption of their source systems, making changes that they don't know about, they find out at the 11th hour. And that's where I think, you know, we talked a bit about PR planning, those PR planning days, when I take my teams to those days, they're kind of on two missions. One is to receive the work that our team needs to do and to work with the other teams that are asking us to put story points on our board. But the other is actually to walk the room and see what else is going on and see what's coming and say, hey, you guys need to come talk to us about that. That's going to cause us some a disruption if you don't actually mitigate the impact to us along the way. And that's been quite a powerful tool in our toolbox to ensure that we're actually getting better at seeing what's coming, seeing the lay of the land, seeing the IT change landscape and anticipating it far better than we have in the past.

So effectively it's collaboration at scale.

It's collaboration at scale, yeah. But it's collaboration that is actually, it's transparent and it's open. It's an opportunity to literally walk around and have a look and ask questions and find out what's going on, which is a lot harder when everyone's at their desks working at different speeds and different cadences and stuff. So, as you say, I think SAFe can be incredibly prescriptive and is kind of treated as almost a turnkey agile methodology. And I think for that, I think that is a limitation. I think organizations should take from it what value they get from it and leave on the table the things that they don't think they'll get value from, like anything else. It is not a one-size-fits-all, even the Scaled Agile folks would say it's not one-size-fits-all. Yeah, they give you their 4 tiers of scale, but certainly even within that, how you implement those practices is very, very organizational and cultural-based decision-making that you've got to make as you go through it.

And if you wanted to bring in, you know, my view is you want to bring some of the Spotify patterns. Yeah, yeah, then use them if they fit, if they work, you know. If you want to, you know, if you want to bring in something or innovate on something or iterate on something because you think you can change that and make it slightly better, that's great. As long as it doesn't become, like you said, out-of-the-box things. You can't inspect and you can't adapt the way you work because it's just the way.

Well, that's just that. And even, you know, we're We're using SAFe in the organization, but I've also adapted guilds and squads into my unit. And we're using those because, you know, from the Spotify model, that's actually a bit of a gap that we saw. And I think, you know, that guild model is fantastic for making sure we maintain cohesion across the different disciplines that we have in the organization.

Yeah, it's useful, right? It's worth the effort. And then, you know, I've used a lot of the patterns out of Discipline Agile, you know, the dad, and then Now they've moved to the PMI.

Yes.

You know, it's like, okay, are they going to become a safe equivalent, you know, or are they going to retain the beauty of what I see of what they do, which is, you know, a bunch of patterns that they explain particularly well.

Yeah.

That means I can look at the pattern and go, oh, I get it, I think, let's have a go, right?

Yeah, I'm a big fan of that as well, because I think what they really allude to, what that really focuses on is exactly that. Be explicit about the reasons why you're doing things the way that you're doing them, know what the options are, and make an informed decision about how you do it, rather than just arbitrarily deciding that you're just going to follow this thing because a consultant told you that's the one you should buy. And I think that's— yeah, because once again, we're also using Discipline Agile inside the unit, and we've got the Ways of Working book, and we go through it, and we look at the, oh, we're going to do a vision. Well, here are the different ways we can create a vision. Which of these approaches are we going to take? How are we going to do this? For this particular program and how do we construct it. And I find that's actually an incredibly useful tool for even just knowing which questions you need to be asking as you go.

Oh, and then, you know, again, one of the customers I'm working with, you know, we've been using information templates, product templates for a while, worked with them and we kind of iterated on and came up with the Information Product Canvas. And that's had a massive benefit actually for a whole lot of really unexpected reasons. And right now we're just, you know, we're trialing and working through the idea of press releases.

Yep.

So again, right, there's less content than an IP Canvas.

Yeah.

Um, but you know, it's all useful information and we're just trying to figure out where it fits in the lifecycle and it'll either come out as having value for the way we're working there or it won't.

Yeah.

Um, but the fact that you can find some information around, well, you know, for a press release for a, you know, for a normal Amazon product, you know, it looks like this. How do you adapt that for data? Is it that much different? Not really.

Yeah, that's right.

Thinking of the words that go into it that hurts. The boxes themselves aren't that much different. So again, it's that reuse of patterns.

It is, and it's that ability to actually know, even just, you know, it's a fallacy to assume that everyone already knows the right way to get there. And knowing what the options are, knowing what the approaches are, knowing what other organizations have done, having resources you can go and look at to show you what all the different ways of doing it are is incredibly useful because I don't think anyone could actually say hand on heart they know the best way to do this job, data warehousing, data analytics, BI. There's actually 100 different ways to do it correctly and or more. And it is important that you're explicit about each step that you take and how you do it. We're using the Canvas approach for our continuous improvement framework that we run. So alongside our program increment schedule and our agenda, we also run a CI Canvas and board and we are running running a number of continuous improvement initiatives at a business unit level and at a team level and at a squad level and at a management team level. So we're looking at the big things that we need to make shifts on from a continuous improvement standpoint, and we're looking at small incremental changes as well through that framework. And yeah, we've used the data practices for that and it's been really successful. Yeah.

Yeah. So let's hope that it carries on living and being open and doesn't get locked away in a safe and prescriptive. Because I'd hate for that to happen.

Well, I think actually if I look at what PMI has done there, I think that's about PMI adapting to the new world rather than trying to pull something back into the old world, so to speak.

And the benefit of that sale actually was I'm seeing a lot more noise in terms of training available.

Yes.

So one of the problems was, you know, unless Scott or Mark was in your area, there was no way of getting access apart from reading it yourself.

No, exactly.

And now it seems to be a lot more investment and scaling out that, you know, the ability to learn from the people who know. So that was a good benefit. I'm happy about that one.

I hate to say this as well, but actually the other thing that helps is something like PMI, which has brand recognition with a lot of leaders and executives. Having that label on it actually helps a great deal as well.

Even TWI runs agile courses now.

Yeah, exactly.

So, you know, things have been around a long time in data space. Stays in place and didn't move for a while, they've changed as well.

No, exactly. It's good to see. So it is good to see that shift. And this is really about what we as practitioners for years have seen coming, finally getting it into the limelight and into the leadership headspace has actually been really powerful.

Okay, good to see you making that change. One thing we might do is get you back because we had Agile Pete on last year and he was doing some work for Treasury, I think, around Agile funding models. So he said, you know, once he's kind of worked through that, he'll come back.

Well, that'll be interesting. As a public servant, Treasury getting their heads around that will be really helpful for us.

Well, so I'm not sure he has or he hasn't, or whether he's got to, because there's help in them, but if he's got some leverage, might get you back with him. Yes. And then it'd be interesting to have a conversation around—

Well, that'd be quite good, because that is the other challenge, you know, talking in Wellington, talking in the public sector, there is a whole other dimension which we need to work through, which is how the government interfaces into the public sector and how they approach it and how we get that agile thinking into the government level and what that looks like. I have no idea how to approach that yet.

Treat every election iteration of 3 years as a PI planning. That would be an interesting approach.

With many demos.

With many demos, yeah.

That's just it, because I mean, I call that a public sector problem, but it's a private sector problem as well, because every organization is, you know, for, for the private sector, they have shareholders, they have a board, and then they have their leadership team who are beholden to the objectives that those groups set. We have, in the public sector, we have all of our citizens, and then we have our elected government, which is our equivalent to the board, and they're the ones setting the strategic direction and setting the goals for the organization. And then from there, we adapt how we achieve those. So to some extent, You don't need those groups to be too cognizant of agile, but you do need them to ideally understand how we're going to try and get there and how we're going to give them what they want. Because the big piece of work for us is continuous legislative change. Those legislative changes tend to come with an end date before we've ever even conceived of how we're going to execute on them. So, it's important for us to be in constant communication with government around what the impacts of those decisions are. And how those affect us and what the trade-offs need to be.

I was doing some reading the other day around legislation as code and some of the stuff that had been happening in New Zealand with researching and experimenting around that. Yeah. And that got me excited because that's— if government can actually publish their policies, their legislation as a business rule, as a piece of code that could be tested and executed, if you think about everybody else that wants to do something.

Yeah.

And they can using automation, test whether that's going to meet or break a piece of legislation.

That's, yeah, it's an interesting concept because I would actually say we've probably already got code that is legislation as code, which is having called it that. What we have is we have business rules, which are code, which were written to meet legislative requirements, which effectively execute on that.

Yeah, well, if you read there's a, they open-sourced a white paper on their findings that came out of the group in DIA that just got shut down. Down the special innovation project or whatever it was. But one of the ones I referenced was Inland Revenue and the fact that they've put all their rules, their legislative rules in the Oracle Rules product. So not so much about the product, but the fact that they have—

No, the idea of a rules engine with that ability to essentially containerize the rule and make it a reusable artifact across the organization.

So we had one bit of legislation that basically governs our government department, and that contains funding conditions which can easily be put into code. If you follow these, you get funded. If not, blah, blah, blah. So if you scale that up—

Yeah, and make it open source and put an API on it so that I can call it with some inputs and I'll get an answer. I don't have to ring you up anymore, right? I don't have to take a punt. I can gamify the hell out of it. You have to tighten up your rules, but that's okay.

Well, that's the next part of access to our rules engine.

Yeah, but that also is the next step for us. We need better interoperability between agencies as well. There's a lot of work we do where our agency is dependent on what's happening in another agency for a key decision that needs to be made for a client or citizen. And at the moment, those processes are not always well streamlined or well orchestrated, and they often add long time delays into processes. And, you know, it's almost the idea of an open API across government to be able to ask questions and things like that. And the ability to do that would empower a lot more proactive service to the country and a lot more ability to execute successfully.

I think if you look at that and then you say, what are the side effects of that? So what we end up doing is actually do value stream mapping across all of government.

Yes.

Right? So we actually understand where some of the wastage is and that can be focused on if it needs to be.

Yep.

Innovative companies can, you know, chatbots are cool, right? So you could put, you know, some form of chatbot technology on there where I can ask a question and get an answer relatively easily because it's now a known backend, right?

That's right.

Yeah, there's just so much that could happen if we got to that stage.

Yeah, there is a big caveat on that, which is we need to continue to consider the privacy impacts that that would have and the potential negative impacts that could have. We don't, you know, there is a consideration that we don't want to be linking all of the government agency data across all agencies on all citizens. Is generally seen as a toxic outcome, and we need to be careful about how we do those sorts of things. So as much as I think that there is huge benefit in doing that, that's the other dimension we haven't really touched on today, is the privacy, the ethics, and the human rights considerations. And the sovereignty as well.

And the introduction of bias based on previous behavior.

That's right.

Especially with the AI, you know, again, fingermarks, you know, AI models, right? Yeah, they're all trained on data that's biased. Yeah, um, therefore you're going to get a biased model because that's what it's learned.

That's right. And that, that, that is something we're actually— we're conducting joint research with some academic institutions on at the moment, is looking at how we look at disparate impact in models and how we also look at, uh, the privacy, human rights, and ethics impacts of the work that we're doing and the, the considerations. And, you know, and sovereignty is, is, is, is an interesting one because sovereignty affects us from a, um, a, a cloud adoption standpoint, but it also has other implications, especially when you look you look at Māori data sovereignty and you look at the principles of data as a form of identity and what that means to different individuals and to different cultures.

Look, I'm still relatively unhappy that a government organization is taking my cell phone usage data off all the telcos and selling it, right? Because for me, from a sovereignty point of view, I don't feel comfortable that that is happening to my data without my permission.

That's right. And that's, you know, so everybody's got a different view, right?

Ethics and bias, right?

It does. And, and, you know, and there's no easy answers, but there is a— but you have to go through a consultation and a discussion process, and you need to be open and transparent about what you're doing, and you need to be very careful. And then, you know, we're, we're passionate about that in, in our agency, but, you know, if we, if we see that this will have a negative impact to, to people's lives, to people's well-being, or to their privacy, or to their human rights, we won't go ahead, we'll pull back.

And also, just to close it out, I suppose, talking about 7-year cycle, I'm seeing lots more of the data governance conversations.

Yes, that's coming back around again.

And sometimes again using old patterns, like conversations of data stewards, data custodians, data governance committees and that, but hearing a lot more of catalogs and automated profiling and data fit for purpose based on persona. And so some of the new ways of working, which hopefully this time will help us be a little bit better around governing the data.

Yeah, no, I know what you mean. And we're actually doing all of that. So we're deploying an enterprise data catalog, we're implementing better lineage and profiling capabilities, but we're also setting up steward networks. And our governance committees around data governance are a little bit stalled at the moment because my experience with governance in this space is it's the same challenge we've always had, which is if you want effective data governance, have a problem to solve and then apply the governance to that problem rather than doing governance for the sake of governance.

Yeah, I remember one of the largest data governance funded projects in New Zealand, the government for a while years ago was ACCC. And taking your point, I remember there was a data breach in terms of not somebody hacked in, but information was publicly sent out when it shouldn't be. And the chief executive said, that's a problem that needs to be solved now. And therefore the, the data governance framework and program of work was formed to solve that problem.

Yes.

Not sure they ever did, but there was a problem to solve, right?

Well, they probably made some progress against that problem.

Yeah.

And that, that's kind of how it works. And to be honest, that's not just true for data governance, that's true for all governance. If you've got governance and you don't have a clear reason for it, then you shouldn't have it. Yeah. Yeah.

Yeah. Which means a lot of steering committees should be a lot shorter than they are.

Yes, they should be.

We'll get on to that next time.

All right.

Look, I think we've done a good session there. We've definitely bounced around lots of really interesting subjects. So thanks for coming in.

No problem.

Appreciate your efforts. And we'll probably get you back in 12 months' time and do a bit more of a state of the market.

Sounds fantastic.

Excellent.

All right. All right. Thank you, James.

Thank you. You've been listening to another podcast from Blair and Shane, where we discuss all things Agile BI. For more podcasts and resources, please go to agilebi.guru.