AgileData #10 - Prototype to Production

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

I'm Gerard the Beer.

Hey Jarrod, Welcome. Thank you for joining Blair and me to have a little bit of chat today. One of the things we kind of always start off with is asking you to tell us a little story about your background. So how you got into this world of agile, where you came from, where you've been.

Yeah, so I've been working in data warehousing and BI for about seven, eight years now. I used to work in banking and when I came to New Zealand I sort of made a career change and started working in government and sort of naturally progressed into the space of bi. Where I started was cognitive reporting. Then I got involved in a project at one of the government agencies building a new data warehouse. I saw how the project being managed as a waterfall approach. It was actually just a total disaster finding out that, well, that's 90% of the cases when a project in that form is being run. When I change positions at another agency, a similar approach was used to gather requirements and implement change with mixed results, mostly negative. And then we went through a huge change in how we're going to approach this and moving more to an agile ish sort of way of working, which I found to be a lot more positive and had much better outcomes than the traditional approach.

Excellent. Actually I thing to remember that I was part of that waterfall project a long, long time ago before I started my agile journey. And you know, the three of us worked on that new way of working. So I think kind of what we wanted to talk about today was one of the things we experimented with really, really early was this idea of could we prototype and then production.

Yes.

At my current organization we went through a process to acquire a business intelligence tool because previously the organization had a well, mature data warehouse, but the only interface into it was via Excel cubes and SSRS reports. So visualizing data, discovering insights, all of that was very minimal and very hard to do. So we realized that we needed to get a property business intelligence tool, particularly of the new generation of discovery tools. And as part of the RFP process we went through understanding, trying to understand better our requirements. One of the things that we discovered was that there was a need for us to be able to take something from a prototype and productionizing it. So the way that we envisioned doing that was that an analyst or Somebody more from a business type focus needs a tool where they can quickly come up with an insight. So loading a bunch of data.

Very quickly, be able to blend different data sources together, creating some visualizations and discovering something of importance that we want to be able to repeat on a regular basis. So taking that prototype that analysts or business person has then created and then productionizing it in a way that is repeatable, maintainable and easy to use. So we went through understanding a bit of a process of how that would work and capability of the tool was important for us to be able to do that. So with that you'd be able to lift what an analyst has done and hand it over to a developer who can then go and implement the solution in a data warehouse, for instance, by building a fact table, review or something of that sort, and then be able to quickly re pipe the prototype that was created to be from a proper source that then can be productionized and implemented in your production system. And we've done that a few times now and it actually works relatively well. I would say that the type of tool that you're using is important, but also the discipline you have to apply to how you productionize a lot of the new tools that is out there in the market allows people to, well, bypass any kind of formal data warehousing. There seems to be quite a bit of a drive these days to just get things out very quickly without thinking much about the long term repercussions in, well, how is that going to be maintained? How do you have maximum reusability of the artifacts that you are creating? Because it's easy to just employ more people and churning out more stuff. But in the long run, I think it is really detrimental to an organization's data governance.

Yeah. So I agree in terms of where the market's gone.

Right.

And I blame data this time. Right. Last time I blamed OLAP cubes. And I'm not sure in a couple more years what I'm going to blame next. I think data pipelines is the one that's starting to rear its ugly head as the new way of having chaos.

Well, there's always chaos. There's always a new product that does things in a different way that allows you to do things you haven't been able to do before. But for us it's always the principle. So we have a very clear principle in our organization that any rules, any business rules that we apply needs to be in a managed system, which is our data warehouse, and that any kind of transformation or business rules that we want to apply on the business intelligence side? Well.

There has to be very good reason for doing that. And if not, then it has to be pushed back into your managed system.

For me, it's around the principles. I like that word because that's where I've got to with the teams I'm working with at the moment. So what I say to them is we can manage chaos. Give me an example. When you say we need to have visibility of the rules, we can put a pattern in place that says when somebody writes some code, those rules in that code need to be exposed on our data catalog. And that's a minimum that they need to do to manage those rules. So there's the management of it versus the reuse. So if somebody's going to reuse that rule somewhere else or leverage it, then there's actually a whole lot more management or some more conformity of the way we work that's more important. So what I say to people, the teams at the moment is it's okay because we talk about this middle area, this modeling environment. Can we land all the data in the lake, create these data pipelines that are unique bits of code that flow data out to a dashboard? Can we just consistently do that? And I say we can. There's some things we've got to watch out for. We have a scaling problem at some stage, but most of the technologies now can handle that. But what we have to be very clear is that we're never going to reuse components within that pipeline. Because if we want to do that now, we have to bring in some different patterns and principles about reusability. Reusability of the concept, the data concept, customer product, reusability of the business rules, reusability of the way we transform that data, reusability of the way we consume it, and that's the right hand side version, is that we actually want a lot of reuse, which means we have to work differently all the way through. And so we want to make a decision of which one we kind of think we are. What we don't want to be in is in the middle chaos theory, where everything's unique and that makes us fast.

But we're expecting reuse.

And we tried that as well. So we had a semantic layer in our warehouse was used for our cubes and we thought, well, okay, so we can just reuse that for our business intelligence tool that we now purchased. And that didn't work because that semantic layer was designed and built for a very particular presentation layer in mind. And the reusability was Minimal. So we had to recreate a new semantic layer for the BI tool. Although the principle was always, again, well, we want to have something at least that gives you. It has to be layered. So at some level in your warehouse, you need to have the artifacts and the architects created so that from there you can then farm it out your different reporting systems. So whether it's a BI2 or account reporting system, whatever. So there is reuse, there is reusability if you design it well, but it's not probably at the presentation layer.

So if we take that pattern, that layering pattern, where we have some constraints in place which are based on those layers where things can happen. So typically you'd hear the words staging, persistent staging, maybe data lake, but somewhere where you land the raw data in the form, you found it and you keep history over time. And that layer has some principles or patterns that you can't transform the way the data looks. And so we put those things in place to help us kind of reuse. So when you talk about prototype to production, is the analyst allowed to create all the layers in the prototype from source all the way through? Do they have to create the prototype in a semi layered way? Are they allowed to write one big code blob or do they have to actually break it down into a series of code objects?

Okay, so the person who's doing the prototype is not a disciplined developer. We're talking about an analyst who will go and write a paper piece of SQL for instance, and joining a whole bunch of tables that they don't care where it is, they don't care whether it's in your extract layer or your staging area, or whether it's a spreadsheet download from a website or whatever the case might be. They just want to get the data, put it together and do stuff with it. So it is atrocious code, it is not properly developed, it's just hacked together. It is not their role or their interest to do that. And any way that they can just be lifted and shifted into.

So you're saying they're not creating any objects at all at this stage?

Some may, some may do that because it depends on their level of, for instance, SQL skill. But I would not expect them to do that at all. It is then up to. It's called the shared. Yeah, exactly. So some will do it with ding tables, maybe in a database or.

Or just writing very complicated inner joints or left joints, whatever the case might be. But if we do decide that, okay, this thing, this output, it's about the output of what the analyst has created. If we decide we want that output as a productionized, repeatable information product, then it is up to a data analyst to go and analyze what has been done in the code and then structuring it and modeling it appropriately to implement the data warehouse.

So that's always given me a challenge. Right. And the challenge, it's given me many challenges, but the first one I want to talk about is so the analyst that hacks this prototype, right, who does it very, very quickly.

Yes.

They deliver the initial prototype back to the business owner, the product owner, or the key user very, very quickly. Right. And then the second round to automate it, to harden it, to make it managed and reusable and fit your layered architecture takes a lot longer. Right. And so I've always struggled with the business owner, where they go, but I've got what I want. Why do I need to spend all this iteration or these points or however you describe it?

Okay, so there's two aspects to that. One would be if it's a once off, then fine, then the product owner has gotten what they wanted. There's not going to be any energy spent to productionize that. So we'll take that. It's been used, we can archive it and we can keep it somewhere.

If they want to have that updated on a frequent basis with newest data, then that's a different story. Then it has to become part of our data governance. And our data governance is about then, okay, managing how we do this and how we implement it so we keep our people safe. And that's about that. So, yes, an analyst has gone and created something, but we are not putting a stamp of approval on that. We are not saying this is official data that can be used to make decisions, first of all, to provide information to external parties or anything like that. It should not be used for that. And business people understand that because we are very harsh on it.

So, again, Right, So the behavior I've often seen is what I call the manual green button, right? Yes. The analyst goes, okay, I can't schedule it, I can't, you know.

Yes.

But I'm just going to pull it up and every day I'm going to hit a magic green button that I've written that refreshes the data.

They are breaching our policy. Okay.

Yeah.

So you have strong data governance or data principles. Does that say so? Actually, it's quite interesting. So I did a project many, many years ago, back in the waterfall days, and what we did is we actually color coded the reports.

Yeah, I Remember, there was at some stage that people put the bronze, silver, gold type.

Yeah. And actually depending on the logical environment you're working in. So the analyst had access to. I think these days we call it a Sampa.

That's right.

But any content you create in the sandpit actually had a color scheme that was different to the content that was in a managed part of the environment.

Yeah. So actually that's a very good point and something that we should do and we haven't actually, because making it visually different.

The behavior then was. I'd actually. Because we were experimenting at the time and what we found was when a senior executive got given a number, they said, can I have a quick look at where you got it from? And all they were doing was looking at the colour. Right. And they were. It was almost like a spectrum of trust. And they were going, you know, when I talked to some of them, they said they had a conscious decision. They looked at where the data came, that the answer came from. And if it was in the trusted color, they're like, I'm good. Right. I'm going to take that to the board. And I know that the rigor around that number is trustworthy. Then they said. I said, oh, that's good. And so if it was the other color, if it was like bronze, you just. You don't use it.

You don't really trust.

Well, no, they said. No, they said, then what they do is they bring into their trust of the person that gave it to them. Right. Do I have trust of this person? Have I worked with them for a long time? Have they consistently given me numbers that have been correct and validated?

So you're essentially using a prototype to make business decisions.

Are you trusting the person who created the product?

Because often. And what they said was, look, often the value of using that information quickly from that prototype. Right, of course, yes. We don't actually, to get that answer, to make that decision. We don't actually have time yet to make it a trusted piece of information.

That's fair, because that's the risk benefit analysis that you do in your head when you do this sort of thing. Because it depends on exactly that, whether you trust the individual, put it together.

But I think it'll.

But also how important it is to actually make a decision right now.

So you'd have to do it on a case by case basis.

Yes.

If you're looking at trends, less trust is needed. Maybe if you want an exact number.

Yeah, yeah, exactly. What they were saying is, you know, some information to support the Decision I'm about to make is better than no information. If I can trust the. If I have the context of how trustworthy that information is.

Yeah, exactly.

We found the same as well. So, you know, and it also depends on how much exactly the type of problem you're trying to solve and how much. Well, what is the consequence of getting it wrong.

Yeah. Versus not making decisions.

Exactly.

So if we think about that process again, so we, so we go back to that investment by the business owner for the second round. Right. Of work to make it more trusted. How do you do that? Right. Normally we would say that the squad that's going to do development would engage with the product owner and the business owners or subject matter experts. We'd wireframe what they needed, we'd understand the core business events. We go through a repeatable process as a data squad, data analyst squad. That is a way of working to do this with the prototype. Does that shortcut it in some way?

Well, it does because you already have a wireframe, it's of the prototype. So the analysis has already created the dashboard and has a look and feel already that you understand what is the data elements is required to build this thing. So you already know how it needs to be put together to meet that. The only thing that needs some time to work out is to understand how the data was put together in the prototype. And that's where you need a data analysis or that modeler to go in and then just spend time with the person who created it to understand, okay, the logical process they followed in acquiring the data and blending it with other data sources and putting it together. Once that's done, then the data modeler can just decide, okay, how do we then create the structures? Or maybe we already have the appropriate structures in your data warehouse. If not, then okay, then just fill in the blanks of what needs to be developed.

So that prototyping, is that typically done by the core central Agile team, Agile data analytics team, or have you actually devolved it out to.

No, it happens with anybody. So a lot of it comes from our innovation team. But there are other pockets in the organization who does the same thing. There are very capable people who have very technical, who are very technically minded, who does not find it very difficult to do this themselves. But then we just work closely with them and get the right skilled people involved at the right time when they come to us and say, okay, we want this as a production information product and we just work with them to understand, okay, what have they done? And then how would that be Lifted.

Into our managed systems and just following on to that. Given their teams of one potentially decentralized or you know, operating models, they're out doing self service within the business groups. Which is awesome. Would you ever go back and validate that actually what they built was what the business owner and product owner actually wanted?

Absolutely. That's critical. So as part of that we need to then understand what the intent was and also making sure that what they've done is actually matching that because it happens that they would do it in the wrong way, they did a joint wrong or they didn't use the appropriate data source that they should have used or something like that. It always happens because there's multiple things that they are not an expert in. They understand the business side of things, but not so much the data as much as we do because we have people who are experts in that and understanding the data sources. So it's working with their understanding teams and then making sure validating actually what they have done. And it has happened a few times that it's actually. Well actually you should have done it like this and we'll do it properly. And that's why we do it in this way. When we productionizing something is making sure that we're using the right data for.

The right purpose and bringing in those things like peer review, data quality, actual writing test to make sure the data is the rules are matching what we thought they were. All that kind of good management of data versus the wild West. That's awesome. Do you find though that there are a bunch of individuals who prefer to prototype than doing the hard plumbing?

Let's call it Hell yeah.

It's kind of like the cool shit versus the yard shit.

Absolutely. But so using a proper business data engines tool you can find them quite easily just looking at what people are doing and what stuff they are building. And then you can go and have a conversation and say hey, I see you built these things and these people are using it. Tell us more.

What's going on.

Fleshy badge.

Yeah.

What's going on here? We keep to help you out because.

That'S one of the things I think in our industry we've been particularly bad at is BI on bi. Right. Is using our data and analytics and BI techniques to actually see how much of our data is being used that we do present.

What content is being created by our customers to inform us where we probably might want to suggest we invest next.

Absolutely.

We, we typically never have that visibility.

No. And there's still things that you don't know about we don't have full visibility about everything. And yeah, you know, this new generation of business intelligence tools, it's a blessing on one hand, but it is also a bit of a curse on the other because it does, you know, a lot of people talking about democratization of data, but there, there is danger with that as well. People need to also be very responsible with the usage, understanding and sharing of data and how that will be utilized to make serious decisions. And not just the monetary aspect of it, but there are also societal aspects to that that people have to really think hard about. It's not just I gave you a number, there's no consequence. That number could influence a whole raft of other decisions.

People need to realize that there's a huge responsibility in doing that.

And I think that comes back to the idea of data literacy, which is kind of hot in the middle. I think what we missed was when we moved from centralized development and deployment to more of a self service, we kind of started off with self service BI or visualizations and then we kind of moved to self service data data to a degree. And then self service analytics is the new wave coming. We enabled that from a technology point of view, but we didn't really focus on the data literacy.

We didn't build all the capability of people to do this, but not the.

People that create the content that do that self service work, the people they're.

Serving, but both of those people who create the content as well. Because it's very easy to assume that this data can be used for X, Y and Z. And a lot of times it can't because that was never the intended purpose for it. But yeah, absolutely, it's also the people who then are given the information and have to make a decision about it. I am more, I'm concerned about both of those. I think it's important to make sure both parties know and understand and have the capability and the literacy of the data to make the right decisions.

So if I look at it from another lens and the lens of friction. So the thing I've learned over the last few years, working with different teams and trying to say how do we take this agile mindset and create some patterns for data and analytics teams versus app development teams or digital transformation teams, I kind of came to this concept of friction. And the way I explain it is if we look at BIM as a way of modeling, what that gave us was a way of removing the friction from the business analysts getting requirements for data to the modeler and developer that's actually building the Models under the covers. If I think about the information product template and that concept and.

Just working on a canvas for it now, which is taking the document and turning it into an A3, so hopefully that's going to rock. That removes the friction of. How do we very quickly get out of a business owner of SME, or in this case a prototype, you know, something that's been prototyped into something that the rest of the development squad can understand. You know what business questions we're answering? What's the action going to be taken from it? What's in and out of scope for that information product? How do we size and prioritize it? Done some work around defining the rules in a repeatable way. So how do we take ETL and turn it into business language for rules to remove the friction of. When you say we're defining an active wholesale customer, actually, is this the definition of it? Is this what we have to do to the data to get that for you or not? So the removing that friction. So I've got two things I want to talk about in that One is that form of language to remove the friction between prototypes and production and then data catalogs, are they the new cool way of doing this? So let's go back to that. Do you think in terms of information products and Bing being able to take a prototype that somebody's done, have you been able to use those templates and populate them for faster, therefore reducing the friction from prototype to production?

Yes, absolutely. I think.

That makes things a lot easier.

To understand. How to model the data in an appropriate way and how it fits in with the rest of the data that you have.

Is it still the production team filling those out or have you got to a stage where the people doing the prototype understand that they can populate them as they go?

So again, the people who do the prototype don't care about that. So.

That'S not of their interest and I don't think it should be because that is our responsibility to make sure that we do that in a way to manage our own systems, our own data systems.

Yeah, but look, I'm going to challenge you on that one. Yes, I agree that actually the overhead of filling out those templates for a prototype that's not going to be moved to production. I get it right. It's a waste of bunch of effort. You don't care about removing that friction because it's never going to turn up. But there must be a way that we can find that middle ground where it's something they know will be Productionized or they have a feeling, just purely because what I found is once you educate somebody around those templates, they can naturally fill them out. And as long as the effort. And this is why we kind of. I'm doing the IP canvas at the moment, because I have this theory that we can actually fill it out in 10 minutes if we know most of the questions and even if we don't, we've got gaps in there. That's fine, Right?

That's a fair assessment. I haven't actually really thought about doing that or pushing for people to do that, but it's maybe something that we can definitely try and see.

Let's take the beam one. Right. What I'd look to experiment with is not enforcing it, not saying you have to fill out this beam to, but saying when you write your code for your data, if you can think about who does what, because we all know that those words are magic words for some reason, then you're educating with some literacy around light modeling based on business events. It's words they'll understand even if they just gave you a document with five stickies, which is customer orders. Product is the thing on modeling.

That's actually. Peter, I'm just now thinking, because when we do training and training people how to build their own apps and information products, it's actually something that we can incorporate in the training. It's like, well, when you develop.

Your app and you are going through the process of acquiring the data and stitching it together as part of that, you can actually incorporate the who does what and so on, because that will actually also help you crystallize the output that you need for this particular exercise that you're embarking on.

Yeah. And actually Lawrence was over here this year, last year, and what he's done is he's taken the beam canvas, which is the kind of a three where it's got. I don't know if you've seen it where it's got. And he's now actually starting off the workshops of his customers with the beam canvas first and then go down to the beam table. So what I'm wondering is actually, again, it's about friction, Right. You don't want to have the bean table is probably a lot of detail for them to fill out. But if they had the canvas in like a PowerPoint and all they had to do was draw on some colored stickies, so they've got the who's, the what's, the where's, and that's an artifact that they always produce. It's it should be a.

That's a great idea and I, I think, I think we should, we should try that and I, I'll let you know.

Give it a go.

We'll go and do it.

Give it a go and see.

Very good idea.

Yeah. Will it work or will it not? And so the next one is data catalogs, right? So in the new hot call.

Yes, they are. It's all over the place.

All over the place and they're really useful. Again, like, you know, again if I talk about our domain it's one we should have always documented, described what we do with data and we typically never do. But from a prototype to production, if they're prototyping in your tool and your tool's integrated with a catalog, shouldn't that give us some insight on what they're doing in a way that reduces friction of redevelopment?

I think there's a lot of value in that, yes. However, at the moment I can't see.

I can't justify the cost involved in doing that right now but I could certainly see in a few years time our organization at least will have to do that and that there will certainly be value in doing that. We're still on our path to maturity, so we're not quite there yet. We don't quite have that need yet. But these data cataloging tools is really going to be very important in a few years time for us at least and I think for a lot of organizations already important because there's such a wealth of data out there and getting your head around what can be used for what is getting harder and harder. People talk about big data or whatever.

Not the depth of the data, it's the breadth of the data that we have to really try to get our heads around in New Zealand particularly because there's so much information available from all kinds of sources from different government organisations, departments with stats, New Zealand's integrated data infrastructure, which is also a wealth of information but it is so wide and so vast that it's really hard to get your head around it. Yeah, Yep.

Yeah, I agree. Yeah, I think we'll see.

Dating.

I think they're almost a new black. Yes. So right now they're kind of. You have to buy a dedicated one and they're not cheap. No, we'll start seeing that capability becoming more and more into the end to end products again as we go through that, that cycle of consolidation. So you know, I'm still working with a bunch of squads where we're still going for that nirvana which, which is in a three Week iteration, we can go from.

An idea to acquire the data, transform the data, load the data and visualize it in a three week cycle. So one of the squads I'm working with at the moment, it was interesting. We're starting the journey and it was interesting.

The data they're pulling out is all API based. They have two API calls to the system and they'd written the calls to that system for the API and for one of the other products, information products, that was all good. So we came into another information product that was going to leverage some new data from that system. But we had an acquisition way of working that we knew worked. But unfortunately for the data they went to hit, the API worked completely differently. So they had to write another bunch of code to make that API work effectively. The squad's sitting there and it's like, okay, that's going to be two to three days for the engineers to write that new API call data in. But the rest of the squad are sitting there going, well we need to understand the data, model it, all that kind of good stuff. So what the engineer did is said, well that's fine, all I'll do is I'll do quick manual, I'll run the API manually, download the data, dump it into an area for you to play with and then I'll harden up the acquisition code while you carry on. So for your Agile, your core Agile team, not the prototypers, are you applying a prototyping technique in the way they.

Work where we need to? Yes, we create some, we call it like dummy data or whatever the case might be, just to have it in a structure that you can then use to develop further with the intent need to harden it up exactly like that. So we've done that a few times where either it was a new thing that we haven't created yet, so we had to come up with new things to collect it, or it was something that we are going to change quite substantially. These new attributes we don't have. So we just made some attributes up just to not have people sitting around and wasting time. Well, actually all you need is just something and you can go ahead and do the rest of it. It's just making sure that you. Resource management.

Yeah, well, optimization of the team, the squad, so that it's not half of them sitting around waiting when they could be. Makes sense more risk because sometimes you.

Can'T do that unfortunately. But I think we've had a few times that we could do that because.

People find, find BAU to do, don't they?

And they fill that void bau which still has value but it's not focused on the main thing.

Well, we'll always have a backlog.

There's always something to do apart from what the tech videos. So kind of just closing out then. So let's talk about anti patterns. Right. So you know, what are the top things? So this concept of self service prototyping outside inside the kind of managed data team and then moving it back into reinvesting and hardening and reuse and all those good things, what are some of the end patterns? What are some of the things you would suggest people watch out for as not so good ways of working if they try and adopt this practice or pattern?

Well, so one of the things would be not to just copy and paste the code code back into your warehouse, but actually taking the time to understand what has been done and properly structure it. Because it's easy to just take a bunch of code and just create a view for it which is highly inefficient. It does a whole bunch of things that should not be in the view for instance, but you should actually have created additional fact tables for that particular purpose, properly layering it. So you need a well disciplined data modeler to go through that and understand what the intent is.

So on that. So we create some form of definition of done that when you're grabbing a prototype and you're re plumbing it.

Here's the but it has to be reviewed by you know, say your data architect as well, the data warehouse architect. There needs to be peer review of these things so you know, that's really important. It's easy to to do something in a quick and dirty way and not have to worry much about it until next year when for some reason something breaks and then you have to spend three weeks trying to fix it. That's the main thing for me is to make sure that we do things the right way. So there's the right time and there's the right way as well.

So definition of done to make sure we haven't cheated when we've spent the time trying to harden and make it usable. What, what I'd also suggest though is actually definition of ready having something where we say actually for a prototype to be accepted for that rebuild. Here's the things we need almost back to that friction, right?

There are things like that as well. It's the maturity of the data sources that's being used. If it's just something that somebody put together in a spreadsheet, well then there's a lot of questions whether that's appropriate for using something that is, that should be a production information product. If somebody just came up with a bunch of a list of something, so we have to put a proper government process around that as well, then if it's master data, newly created master data or something like that, there's a lot of data governance issues that need to be addressed. Making sure you do again, you can take a lot of shortcuts, you can do things in a quick and dirty way, but making sure you do it the right way.

Okay, excellent. All right, well, thank you very much for your time. Thank you. It's pretty awesome.

Yeah, thanks.

Yeah. And we might get you back on to pick another subject and in a few months time and be happy to go around again. Excellent. All right, we'll catch you all later.

All right, see you later.

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.