Join Shane and Blair as they chat with Chris La Grange about leading agile data teams in large organisations.

Read along you will

PODCAST INTRO: Welcome to the “AgileBI” podcast where we chat with guests or sometimes just to ourselves about being Agile with teams who are delivering data, analytics and visualization.

Shane Gibson: Welcome to the AgileBI podcast. I’m Shane Gibson.

Blair Tempero: I’m Blair Tempero.

Chris La Grange: And I’m Chris La Grange.

Shane Gibson: Welcome, Chris. Thanks for coming on the show you and I have known each other in the womb space for quite a while around that big data 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 was ask them to give us a bit of background about where they’ve come from, where they’ve been, how they entered this world of data analytics, and particularly Agile.

Chris La Grange: Thanks, Shane. And thanks Blair for having me on the show. I’m really excited and happy to be here. So as you say, I’ve been working with in the data and analytics space in 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. So I’ve worked in predominantly the private sector, I’ve only just recently stepped into in the public sector and working in the large government agency. But certainly what I have 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.

Shane Gibson: Normally, when I’m working with teams, I find that I brought them into a team that wants to change the way they’re working, or there’s a group people who want to do that. We’re at the coalface, we’re working with the teams in terms of the mindset, the tools and techniques they use. But often we will be working with an organization that has started their Agile journey uses the word Agile at organizational level, but really isn’t adopting their business agility. So an example I use often is the funding models, the teams are still funded on project based funding. And 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, some of the data analytics space, but above the team in your organization. So how were you seeing that difference between Agile within the team and the way they execute versus adoption of Agile as a business and their business agility?

Chris La Grange: That’s a really good question. 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 big milestone bass drops and things that. So that’s quite key, which has brought a lot of those funding questions to the table. I first did Agile in 2007, I was working in a large Telco, and we implemented scrum at that point in time and put together a team of seven 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 other 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 five times higher than any other projects. And of course, it was because the full team was involved, end to end. And the lead organization, we saw that immediate cascade of where we had moved from a classic waterfall model where I had a BA assigned, and 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 so they pulled back on it. And we actually ended up pulling the plug on that test for three months and we actually delivered quite a lot of value over that period, which was 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 ended up essentially happening is we spent the same amount of money and those three months that we probably would have spent in 12, we probably got to the same outcome in three months that we would have got to in 12. We just got there four times faster. But all the organization could see as we were spending four times as much money.

Blair Tempero: Really finance need to be involved in the adoption as well?

Chris La Grange: They do, and they have to really get their heads around it. And this is where a lot of the challenge that we’re unpacking 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 that we haven’t even thought about putting on Agile. So we’ve got our executives, our CFO, our Deputy Chief execs, all of our teams from across the business, now doing Agile training. And actually going through the formal process. One of our associates CFOs, who is normally the CFO stood up at our LSPR planning day and said, ‘Well, I’m now on Agilest’. And I understand that and a few other people in the room are Agilest.

Shane Gibson: Is that standard training those senior people going through have an Agile mindset, the pattern, the manifesto, the principles and those kinds of things? Or, is it tailored for what does this Agile thing mean to you and your type of roles? So as a CFO, we’re going to potentially move to a lot more operational costs versus capital costs. Ideally, we’ve got internal employee teams doing the builds, lease contractors, lease vendors, that kind of thing. So is that the kind of training you did and you take them?

Chris La Grange: So it’s been a bit of a mix. So the training that I just mentioned, most of that was actually led 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, our portfolio executive committee that oversees our full programme 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 you take what you can get so to speak. And it’s great that we’re investing in that. I think that it takes time for people to get their head around the Agile fundamentals and the Agile principles. I think that’ll drop at different speeds for different people as they come to that sort of moment of grokking Agile. As I get that full understanding of it, as they get a full appreciation for that takes time. In terms of getting our finance folks to get their heads around that, it’s a learning process. So we’re not there yet. We are starting to understand that we need to stop funding things based on what I call a one and done business case to deliver a thing. And when that things 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.

Shane Gibson: We talked a lot about technical debt. And one of the things that slightly different than the data and analytics space is, the value of our data degrades over time when we don’t keep working on it. So if we create an analytical model, we score the model, we fit the model, we put them into production. And we know that over time the behavior of our customer, stakeholder’s citizens, or the data we use, and things will change, and the accuracy of that model will degrade. 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 costs to keep refreshing and doing it. And if we take the technical debt idea and actually apply that to data, it is 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 deliver that, we create a physical asset and we depreciate it, and that depreciation cost goes back in those points or something where the team’s allowed to use that value to refresh and recycle to keep it healthy.

Chris La Grange: That’s an interesting idea. 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 through in their court systems as well. And to your point, that ability to actually expose and understand the value and then read 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 Agile gets you a waste on that path. I think that comes back to business culture and an IT culture and investment making. The organization I’m in now has always used as 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 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 then 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 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 go, ‘Well, we know I’m plucking missionary numbers over the year, I’m not using our real ones, we have $20 million a year of capital that we’re going to spend, we’re going to break that into five programs or four 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’.

Shane Gibson: 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. What is the top priority things right now for this increment it needs to be delivered?

Chris La Grange: Exactly. And that 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 five page lightweight business case to get that funding released, and get that work on the way and then we just track the spend PRB API, we’ll get the forecasts, we’ll get 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 we’re generally work managing capital inflow and resource inflow. And actually, what that then teases out is the real organizational constraint which tends to be people’s time and availability to complete the work. 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.

Shane Gibson: So you might find that something is a high priority, but the skill set is tied up with something that’s a higher priority. So therefore, priority number five, is the one that’s achievable with the skill set, or the team that’s available. And that almost sounds you’ve take the gardener, tightwad mode one, mode two theory of Fast lane, Slow lane but changed it. So it’s actually usable to low governance overhead, because of the risk and then the dollar value and that kind of stuff and a lot more visibility.

Chris La Grange: That’s right. 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 without having to know all the answers at the very beginning of the project. And I think it’s fundamental to Agile, if you don’t have that ability to put your trust and confidence in the team and then know that you control the throttle that is where I think a lot of organizations for them, when they tried to move into Agile, they think I still want to know what it’s going to cost upfront. And I want to know what I’m going to get for that. And I’m going to know what I know what my rate of return is, and what my return on investment is at the beginning. And only then will they release the funding instead, you go well, “No, I’m just gonna give you 10% of what you asked for. And then you’re gonna tell me what you deliver off that, and then I’ll decide if I continue to do or if I decide to stop”.

Shane Gibson: Do you find those smaller value projects, so the 100k ones where you’re doing a lot more [inaudible 00:14:06]. So there’s a bigger piece of work you want to do. Some people quietly 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 a small bit of work. And there’s funding model to then come back with the outcome actually is a set of answers to the questions that were unknown, and a slight more surety that the plans got able to be executed.

Chris La Grange: We are absolutely seeing more of that. 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 and that isn’t the rest of the business for 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 because it’s sort of the old Agile metaphor 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. Most people are still trained for I have a need, I’m gonna go in 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 gonna 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, if I say, I need to give you a full customer feedback closed loop solution that tells me what all of my customers experiences to reach my channels. And you go, “Well, can we just do that for one channel?” I’ll go, but I’m going to need it for all channels eventually. So can you just build something that does every single channel? And that’s that challenge you’re going to.

Blair Tempero: Have you notice with more regular demos that sort of mindsets change. So people are seeing something regularly?

Chris La Grange: Once you prove that you can increment and that you prove that they can get something that they can use.

Blair Tempero: So that question on what’s next?

Chris La Grange: 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 three months, and you’ll show me something meaningful that I can actually use. And that’s also where the other challenge is that 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, I can iterate, but I still have to do a massive data integration built 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 normally use the term, you need that data steel threat 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 data sets and assets that come through?

Shane Gibson: I got a thin slice. How do you slice it so that something gets in front of the customer?

Blair Tempero: That’s workable and production.

Shane Gibson: And well should always be production ready. So for me definition of done that, we’ve tested it, we’ve documented that there’s these things as professionals, we should always do our job and that’s our definition of done. How do we get something to somebody else that has at least some value, even if it’s really small, because we knew there? It’s 90 the same back end, though where we’re doing the initial used to be called Sprint Zero. A great friend of Sprint zeros anymore, but I was but not anymore. And then often, we sometimes gets and gets wrong. So an example of God is one of the things I was working with. , we will guess that CDC (Change Data Capture) off a database, the core system was the highest priority. So that’s what if we had to go into a Sprint Zero, we would have built their 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 reported. Because everybody scopes it. And that source was an API, that’s because it was a software as a service, and there was no way of getting the access to the data.

Chris La Grange: So you can’t consume the entire applications and data model, you have to choose that feeling almost think of it more as a stream of one data set. And that’s the mindset shift for a lot of people, that’s where the move to cloud. And the move to software as a services is spinning a lot of data teams, because they want to be able to fully consumer data model, and they want to create a CVC structure against it, and race that and there’s a philosophy I’ve developed, we’re not a philosophy use the term surprise earlier, Blair. I have what I call the classic three surprises of data engineering. And I think our job was a long way towards helping those but those three surprises. So surprise, number one is, it’s always going to be harder to get the data than you think. So when you talk about CVC systems, we talked about moving to cloud, this is actually getting harder. It’s getting the data that you need, and the format that you need, it is going to take longer than you think it’s going to take more time. And so if you’re trying to get all the data you need up front, it’s going to slow your way back 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 sets. A lot of 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.

Shane Gibson: So we call that data lake now.

Chris La Grange: We do. Data Lake was really hard. So what we’ll do is start transforming it. Another thing I can I can sell as a consultant. I’m Sorry, I sounded jaded there for a moment. So that’s surprise number one and that’s the big challenge surprise. Number two, 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. I think data quality and a number of different ways, but obviously the quality and structure. So if I’ve got a field, which is first name, last name, and I’m loading Chris La Grange, oftentimes, I see systems accidentally attached the law as the middle name, rather than as part of my last name. So that structure gets wrong that warehouse teams have gotten pretty practiced at catching those sorts of nominees. But my name is La Grange, not Le Grange, but I’m the only person who knows that. So until an end consumer who actually can look at the data and say, that’s right or wrong? No, that’s wrong, you won’t see that. So the sooner you expose that data, and the more regular you expose real data to real users, you will only then start unpicking all of this 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, and all of these systems. And that gets you into your third surprise, which is that every time we put data in front of the 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 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 now 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 just 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 was say to the business, we’re gonna 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.

Shane Gibson: I think the way I think about it, and we’ve doing a bit of research around using chat-bots as an interface instead of a BI tool, because that’s new hot area anyway, but it looks that’s one that actually might have value to end users. And so the way I think about it, as 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? Now, that’s just the first question. 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 there and then they’re excellent. Actually, I need to know where they’re located. There’s not a change in requirements, it’s just until they understand the answer to the first question, they haven’t really thought about what the next question is. And so that iterative approach to Agile gives us where here’s the answer to that question, what’s your next question. And we tend to have some form of automation or data ops, as it’s called now, we are ending the next bit should be slightly faster than having the first but if possible, we get some speed from that point of view, then then we can behave in a way that meets your needs quicker.

Chris La Grange: And that comes back to, 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 it’s quite key that 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 now 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 an overflows, they’ll think, all I 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 six months before I automate and documents and, and harden that entire solution. And once again, that’s what we fall over. So that ability to break that down, but also to deliver at speed without creating technical debt as you go is essential and that’s not just true for data analytics teams. That’s true for all IT systems teams. 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 that it’s less about Cloud as 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.

Shane Gibson: Did you find though, because every data and analytics team I’m talking about now is moving to the cloud, with the quote marks around it. And for some reason, and citizen testing the data landscape or the Data Domain always seems to be behind our peers and application development, hardware management or compute all those kinds of things in terms of tools and capabilities. In the old days we had the VMware and VM servers and those kinds of things. And I’ve seen the move to cloud Kubernetes. And those kinds of things. And a lot of that rigor has gone with it. If I look at some of the legacy tools, so I apologize to those vendors. But the DataStage has the Informatica as SSTI Studios, the Oracle API’s, those legacy ETL tools in my head, they had a lot of rigor built in 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. Most of the things I’m working with now have moved to the cloud, and they’ve become far more open source centric. And so the benefit, there’s no upfront license fees a lot more flexibility. If you architect it now in terms of automation, and data ops, 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 an example Blair and I were talking about for moving from a relational database to hold data to a no SQL, we lose a whole lot of things in the data world, we got for free of what was in the last. Often because it’s safe, and it was just there. Do you find that in the data network space, the move to the cloud is got heaps of value, but we actually lose some things that made us say for a while that we have to reinvent or re implement.

Chris La Grange: We do. And 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 there, I think they’re good guidance, because there’s a lot of benefit from the cloud. But know what those benefits are, and 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 the cloud is very much where we were the cloud technologies that we’ve gotten the space or 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 was an order of magnitude bigger than it was back then I forget, I’ve lost track of how many data vendors data focus tracking, I think I want to say it’s in the five 6000 range. Now, there’s a huge number of them, what we’re going to see I think, in the next few years as a collapse and 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, synopsis goes to Oracle

Shane Gibson: Salesforce buying Tableau, click buying [inaudible 00:27:50]. And some others, we’re seeing the consolidation of the thought leaders getting bought out by the big incumbents.

Chris La Grange: And that’s kind of the nature of the cycles that we see. And it’s virtual 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 new ideas come from 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 that way hasn’t we have about 1000 problems to solve to build the solution. So we’re now back to the pulling all the pieces together in order to get there. So 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, 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 the business suite, and you’d get all of that get in the box, so to speak. And some of it was good, and some of it wasn’t, but you knew that you have a full set. And now we’ve got to go back to building that set ourselves again. And a lot of teams are struggling with knowing all of the pieces that they need to pull together and how they do that. And what does that mean that complexity back into the equation, and that’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 here. I think that’s actually unfortunately, what keeps coming you and I work.

Shane Gibson: I feel it’s a bit like the stock market. Well, the financial market, there’s a seven year cycle in IT. The bit that makes me really grumpy is I know the seven year cycle and I’ve seen it for three cycles. I still haven’t figured out how to make billions of dollars out of that cycle. I know it happens. I can tell you the kind of the pain that we see, and I still don’t know how to leverage it.

Chris La Grange: I think the secret is to already have billions to spend to buy insurance risks.

Shane Gibson: So if we go back to one of things you see really early was this idea that you’d put your senior people through some of the base training in livers that is, I think what I heard, it was kind of a taster. It’s a bit of effort and some of the stuff won’t be relevant to you might be able to detail but it’s an immersion that gives your 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 as the way I know someone would use but here 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 to help them answer the questions that they have each time.

Chris La Grange: 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, 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 for the projects being charged with 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 were 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 and 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 have those sort of challenges that we’re unpacking 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 the organization to achieve, it’s quite key.

Shane Gibson: And because the organization you work for your weakness is so large, you must have that scaling problem where at a senior level, the vision or intent of the organization strategy or what good looks  over the next five years is probably pretty well known. As you start cascading the message down, as you start scaling to teams, then it like whispers and the message gets.

Chris La Grange: It does. Look, that’s true in our organization, 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 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 of the organization down to which line of business that which unit to measure that’s in somebody’s performance plan, which tells them, 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 when we look at Agile, it gives us that, that ability, to course correct much more rapidly. But it also gives you an opportunity to go the wrong way a heck of a lot faster.

Shane Gibson: We also get some patterns. So we’re talking to a while ago about as  it was Andy Cooper, and then we’re on our way to the Agile group meet-up thing called two day conference, and they made eight ran last year, and there was a whole conversation around OKRs, which was quite interesting. Another one’s value stream mapping. Again, that idea of seeing into and across an organization, what’s happening and where the value was, 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 as an organization and where we’re going.

Chris La Grange: It’s hard and we are doing that as a comprehensive organizational level that 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 joint that fashion, really early days for us in that space. But it’s really exciting as well, to see that actual, that change happening. 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 how to make it work, then it will probably get you where you need to go. There are no bad methodologies, there are just bad fit methodologies, didn’t fit for organizations.

Shane Gibson: Bad implementations. So again, with epic conference, it was a really interesting conversation. But the idea that everybody could throw some topics up on the wall, there were slots for a certain number of topics, and then you created your own little space. And then you could go and be part of that topic. And if you can space it, especially if you got bored, you could go to something else halfway through, you’re allowed to leave halfway through that. And if you will, that kind of stuff. And one of the ones was an interesting conversation about the state of their job market and New Zealand with Scrum Masters coaches and vendors and Big Five and but the one of the interesting things that came out of that was this perception based around the case study of McKinsey and SPARC. And so there was a statement in there around 3000 people were made redundant spot because they weren’t at all. And that’s a really bad thing for the Agile brand and Agile mindset. So a couple of people from Spark actually there and they see it really not true. There’s about 300. So pretty heated conversation, which was interesting to watch. But later in the year, I kind of got some edge on meet-ups, and I met some people on Spark, and I was talking to them. And what they said was as part of their moves to be in an Agile organization, and they took more of a Spotify approach, with tribes and chapters and those kinds of things, they quickly realized that they had somewhere six to seven levels of middle management or team leads. And in the new way of working, some of those people would move into a chapter lead or a trial, they had roles and they had skills. But even after they’re done there, they figured out that there were more people than there were roles or things to do. And so as a result those people left. And so I look at that, and it feels to me that the organization has made a commitment to try and change the way they work. So you talked about pipelining. So I’m assuming that your organization started the safe journey.

Chris La Grange: We’re in PR 13.

Shane Gibson: As I’ve probably seen on the podcast, when we were holding on for a while, but I’ve become far more vocal about, I have lots of concerns around safe as a methodology, because I see it being flagged as a methodology, not a way of working that has value and you could tweak it more as he is a, he’s an out of the box solution. And if you follow all these things, but there’s lots of things in there that have real value from what I could see. So things release planning, if you have more than five squads, and you’re working on the same thing in here same day, the idea of a release train and being on that has value, the PI planning, the idea of getting people to grip 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 valued but I can see some value in that process. But the one that I came back to was, especially in Wellington, at the moment, safe kind of indicates that the senior people in our organization have made a commitment to change. It’s an immersive methodology, it’s the organization should change the way they behave. Is that what you’re finding?

Chris La Grange: For me, safe is an opportunity to cause that change to occur. So many years ago, I was working as an architect, and one of the fundamentals 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 in the process of change, flushes out all the inefficiencies and flushes out the redundancies and 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 the change that spark went through that Agile was the change but it wasn’t the reason that they went through that that structure review and they had redundancies that was the secondary effect of the change happening in the organization, not we’re doing so. So we need less people, it was actually the change triggered a review of the composition of the organization. And that happens, I don’t care what methodology you go to, if you actually embrace it, and you decide that you’re going to change the fundamental structure of your organization be successful, then there’s going to be disruptive change to the organization.

Shane Gibson: They’re in a fast moving environment with new products, new technologies, and it’s been a large organization for years, smart Telecom, and it’s in constant change in terms of structure. So again, it was in Wellington, the some perception that was the Agile badge that caused this, but you could actually go through by restructure it.

Chris La Grange: Telecommunications regulations that were made in the late 90s. And the structural separation caused far more change than that. And then their organization and many organizations, changes unfortunately in any big organization that inevitability to an extent organizations over time, you tend to see organizations contract into a new model of working. And then over time, they expand out again and they scale back up, and then they go through a contraction again, unfortunately, that seems to be the nature of corporations. And I don’t think that that’s an Agile problem, that’s the way that these things work.

Shane Gibson: Let’s look at data world, we had staging areas and the warehouses where we put all the data before we transformed and made available, we treated that as a locked room. So all the analysts would go out and buy OLAP cubes. So then we got to make things a bit more flexible. And that was great but then we started locking it down again. So we’ve already went out and build data lakes, so we go through those cycles.

Chris La Grange: It was that natural cycle and set it seven year cycle again, it’s just how it presents itself. So if you develop any skill as an analyst or as a BI person, the biggest skill you can develop is the ability to, 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 as your ability to survive in an environment. That’s pretty much the core of what we’re touching on there. And for an organization, you cannot 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. 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 that we can’t rest on our laurels there, we have to continuously look at how we get better at what we’re 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 do things at speed. If we’re still doing things now the way we did those 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 I that BI teams are struggling with Agile now, it is an Agile that’s causing problem for them. It’s actually that a lot of their practices are still very old school.

Shane Gibson: Come back to automated testing, we still have to build our own automated testing capability for data and there’s not a lot of reasonable patents out there.

Chris La Grange: No, there aren’t. A lot of data warehouse teams really have a hard time even getting their head around what testing looks in a data warehouse environment. How to automate that and that is one of the challenges. In New Zealand, we struggle with that, that’s a global problem though, 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. It’s also quite key. It’s funny, you’re talking 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  they’re going to be too expensive. So oftentimes what teams will sacrifice is the intangibles, the non-functional ability to do reconciliations, the ability to do replay and reload separate, all the technical debt that gets created from that all those things that are good testing and quality framework would give you

Shane Gibson: If we look at ETL tools where they flow based, so the Informatica is of the world or the new Apache DAGs those things. We start off with each of the nodes and the flow is distinct thing. Now that does one task, it’s all repeatable, replayable and then we get under pressure. So you start seeing code notes, and then a big block of code and then and out so we lose the value.

Chris La Grange: You often lose your replayability there, because developers are optimists tend to build code build to succeed, not code that’s built to cope with failure. So you get into all those situations and that’s it. And unfortunately, what then happens is the system goes into production, we have regular batch problems, ETL problems, other issues, come up and lose returns and says, “Well, you guys are in building this for a while. And that is the constant defensive pressure that I see in data teams. And, and  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 it’s actually delivering value regularly and continuously. And that’s the risk I see in Agile for data as well as 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 for those non-essentials that are ‘X’ feet central continue to do those two?

Shane Gibson: If we’re not going to do them, then it’s a tradeoff decision made by product owner stakeholder and it’s a clear one.

Chris La Grange: It has to be given in writing.

Shane Gibson: An example of one organization, effectively their analytical models are disposable. They have a team of 10 data scientists. And they’re the acceptance criteria as a model was built quickly the model was accurate, their model was run. And then you move on to the next model. So they’ve prioritize speed of model and speed to market over reuse and automation that’s all good, until they carry on with the conversation which it’d be great. If you could run that model for three months repeatably, and it’d be great if the other diners, scientists could pick it up and reuse it. So now it’s not gonna be as fast as disposable because we’re building rigor.

Chris La Grange: 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 the change that comes through? It’s funny, you talked about the release train. Well, one of the biggest things that we have seen is get out of that whole mindset. And that whole shift is in release trains. Finally, it is a place that can truly go to see what changes coming from all their core systems. And the disruptive, , 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 the 11^th hour. And that’s where 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 what story points on our board. But the other is really to walk the room and see what else is going on, and see what’s coming and say, you guys need to come talk to us about that. That’s going to cause us a disruption if you don’t actually mitigate the impact on 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 it change landscape and anticipating it far better than we have in the past.

So think of it as collaboration at scale?

Chris La Grange: It’s kind of collaboration at scale but 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. As I say, it’s safe, so it can be incredibly prescriptive. And it’s kind of treated as almost a turnkey Agile methodology. And for that, that is a limitation. 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. Anything else it is, it is not a one size fits all, even so the Scaled Agile folks would say, it’s not one size fits all the other gives you their four tiers of scale. But certainly even within that how you implement those practices is very organizational and cultural based decision making, you’ve got to make as you go through it.

Shane Gibson: And if you wanted to bring in my views, you want to bring some of the Spotify thing, use them if they fit, if they work. If you want to bring in something or innovate or something or iterate on something, you think you can change it and make it slightly better, that’s great. As long as it doesn’t become an out of the box, it can’t speak and you can’t adapt the way you work because it’s just the way.

Chris La Grange: Well, that’s just an evident, we’re using safe in the organization. I’ve also adapted guilds and squats into my unit. And we’re using those because from the Spotify model, that’s actually a bit of a gap that we saw. And that guild model is fantastic for making sure we maintain cohesion across the different disciplines that we have in the organization.

Shane Gibson: It’s worthy. And then, I’ve used a lot of the patterns out of discipline Agile, and now they’ve moved to the PMI. Are they going to become a safe equivalent, or are they going to retain the beauty of ICF of what they do which is, a bunch of patterns playing particularly well. I can look at the pattern and go, I get it. Let’s have a go.

Chris La Grange: I’m a big fan of that as well. Because what they really allude to what that really focuses on is exactly that being explicit about the reasons why you’re doing things, the way that you’re doing them, know what the options are, and making 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. Because once again, we’re also using discipline Agile. We’ve got both ways of working book, and we go through it, and we look at the oh, we’re gonna do a vision, well, here are the different ways we can create a vision, which of these approaches we’re going to take, how are we going to do this for this particular project? 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.

Shane Gibson: And then again, one of the customers I’m working with, we’ve been using information templates, product templates for a while, worked with them and we kind of iterated on and came up with information product canvas and that’s how missive benefit for a whole lot of really unexpected reasons. And right now we’re just trialing and working through the idea of press releases. So again, if there’s less content than IP Canvas, so all useful information, and we’re just trying to figure out where it fits in the lifecycle. And it’ll come out as having value for the way we work in there or what? But the fact that you can find some information around or for a press release for a normal Amazon product, it looks like this. How do you adapt it for data? Is there much different? Not really, thinking of the words that go into the hurts, the boxes themselves aren’t that much different. So again, it’s that reuse opinions.

Chris La Grange: It’s the inability to actually know, even just it’s a fallacy to assume that everyone already knows the 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 that show you what all different ways of doing it are, is incredibly useful, because I don’t think anyone could actually say handled hard, they know the best way to do this job data warehousing data and analytics BI. There’s actually 100 different ways to do it correctly. 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 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 yet we’ve used the dead practices for that and that’s been really successful.

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

Chris La Grange: Well, if I look at what PMI has done there, that’s about PMI adapting to the new world rather than trying to pull something back into the old world, so to speak.

Shane Gibson: The benefit of that sale actually was I’m seeing a lot more noise in terms of training available. . So one of the problems was, , unless Scott Mark was in your area, there was no way of getting access apart from reading yourself and know that by now, it seems to be a lot more investment and scaling out there. The ability to learn from the people who knows. So that was a good bit of and I’m happy about that one.

Chris La Grange: I hadn’t said this as well. But actually, the other thing that helps is something PMI, which has brand recognition with a lot of leaders and executives having that label on it actually helps a great deal as well.

Shane Gibson: Even TWI runs Agile, things have been around a long time and data space and didn’t move for a while there as well. So it’s good to see.

Chris La Grange: So it’s always good to see that shift. And this is really about what we as practitioners for years have seen coming, finally getting into the limelight and into the leadership headspace has actually been really powerful.

Shane Gibson: Good to see you making that change. One thing we might do is get you back because we’ve had a job Pete on last year, and he was doing some work for treasurer around Agile funding models. So he’s kind of went through that.

Chris La Grange: Well, that’ll be a public servant treasury, getting their heads around that will be really helpful for us.

Shane Gibson: I’m not sure, he hasn’t been with them. But if they leverage back with them, it’d be significant conversation around.

Chris La Grange: Well, that’d be quite good, because that was the other challenge. Talking in Wellington talking in the public sector, there is a whole another 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, I have no idea how.

Shane Gibson: Iteration of three years as a PIP, it’ll be an interesting approach.

Blair Tempero: For many demos.

Chris La Grange: That’s just because I call that a public sector problems, private sector problem as well, because every organization for the private sector, they have shareholders, they have a board. And then they have their leadership team, who were 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, that’s how we achieve those. So to some extent, you don’t need those groups to be to 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 they know the piece of work for us as continuous legislative change. And 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 of what the impacts of those decisions are and how those affect us and what the tradeoffs need to be.

Shane Gibson: 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. And they got me excited because that. If government can actually publish the policies, as the legislation as a business rule is a piece of code that can be tested and executed. If you think about everybody else that wants to do something and they can use an automation test whether that’s going to meet or break a piece of legislation.

Chris La Grange: It’s an interesting concept, because we’ve probably already got that is legislation is code. We haven’t called it the backend we have. We have business rules, which are code, which were written to meet legislative requirements, which effectively execute on that.

Shane Gibson: Well, if you read the open sourced white paper on the findings that came out of the group and DIA that just got shut down the special innovation project or whatever it was. But one of the ones I referenced was and the fact that they’ve put all the legislative rules and the Oracle rules product. So not so much about the product, but the fact that they had.

Chris La Grange: We do have a rules engine with that ability to essentially containerize a rule and make it a reusable effects.

Blair Tempero: So we have 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.

Shane Gibson: 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, I don’t have to take a punt. I can gamify the hell out of it, I can tighten up the rules, but it’s okay.

Blair Tempero: The access to our rules engine.

Chris La Grange: That also is the next step for us. We need better interoperability between agencies as well, there’s a lot of work we do, we’re our agency is dependent on what’s happening on another agency for our 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. It’s almost the idea of an open API across government to be able to ask questions and things 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.

Shane Gibson: If you look at that and then you say, what are the side effects of that? So what we end up doing is actually doing value stream mapping across all of government. So we actually understand where some of the wastages that can be focused on if it needs to be. Innovative companies can check off the call. So you could put 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 back end. There’s so much that could happen if we got to that stage.

Chris La Grange: There is a big caveat on that, which is we need to continue to consider the privacy impacts that they would have and the potential negative impacts that could have we don’t, there is the consideration that we don’t want to be linking all of the government agency data across all agencies on all citizens, that is generally seen as a as a toxic outcome. And we need to be careful about how we do those sorts of things. So as much as there was 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’s considerations.

Shane Gibson: And the introduction of bias based on previous behavior. Especially with AI, fingermarks, AI models, they’re all trained on data. They’re all bias. You’re gonna get a bias model because it’s what it is.

Chris La Grange: And that is something we’re actually conducting joint research with some academic institutions. At the moment, it’s looking at how we look at disparate impact in models and how we also look at the privacy, humans and ethics impacts of the work that we’re doing. And the considerations and, and sovereignty is an interesting one, because sovereignty affects us from a cloud adoption standpoint, but it also has other implications, especially when you look at Maori data sovereignty and you look at the principles of data as a form of identity, and what that means to different individuals into different cultures.

Shane Gibson: Look, I’m still relatively unhappy that a government organization is taking my cell phone usage data off all the Telcos and selling it. Because to me from a sovereignty point of view, I don’t feel comfortable that is happening to my data without my permission. So everybody’s got different views on ethics and bias.

Chris La Grange: And there’s no easy answers, 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. You need to be very careful. And we’re passionate about that. And our urgency that, if we see that this will have a negative impact to people’s lives to people’s well-being or to their privacy or to their human rights. We won’t go ahead, and we’ll pull back.

Shane Gibson: So just close it out, about seven year cycle, I’m seeing lots more of the data governance conversations, that’s coming back around. Again, using old patterns, your 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. So some of the new ways of working which hopefully this time will help us be a little bit better around governing the data.

Chris La Grange: I know what you mean. And we’re actually doing all of it. So we’re deploying an enterprise data catalog, we’re implementing better lineage and profiling capabilities. But we’re also setting up student networks, and our governance committees around data governance are a little bit stalled at the moment, because of 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.

Shane Gibson: I remember one of the largest data governance funded projects in New Zealand or government for a while, years ago was ACC. And, to your point, I remember, there was a data breach in terms of not somebody hacked them 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 governance framework and program of work was formed to solve that problem, especially if it did, but there was a problem to solve.

Chris La Grange: Well, they probably made some progress against that problem and that’s kind of how it works. And to be honest, that’s not just driven data governance. That’s true for all things. If you’ve got governance, and you don’t have a clear reason for it, then you shouldn’t have it.

Shane Gibson: Which means a lot of steering committees should be a lot shorter than. Well, we’ve done a good session there. We’ve definitely bounced around lots of really interesting subjects. So thanks for coming in.

Chris La Grange: No problem.

Shane Gibson: We’ll probably get you back in two months’ time and a bit more of a state of the market.

Chris La Grange: Sounds fantastic.

Shane Gibson: Alright, thank you.

Blair Tempero: Thank you, Shane.

PODCAST OUTRO: You’ve been listening to another podcast from Blair and Shane, where we discuss all things AgileBI.