Join Shane and special guest Lynn Winterboer as they discuss the core differences between teams that leverage an agile way of working while managing data versus creating software.

Read along you will

PODCAST INTRO: Welcome to the “AgileData” podcast where we talk about the merging of Agile and data ways of working in a simply magical way.

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

Lynn Winterboer: And I’m Lynn Winterboer.

Shane Gibson: Hey, Lynn, how’s it going? Thanks for joining me. As you’re over there in sunny Colorado, and I’m here in almost sunny Wellington. It’s been a long time we’ve caught up and talked about all things Agile. One of the things we do when we have new people on the show is probably give a couple minute background about who they are, what they’ve done in the world of Agile, just so that the audience can kind of get a bit of background about yourself. So tell me all about Lynn, and your world of Agile?

Lynn Winterboer: Okay, thank you. I’m an Agile coach, I have been working exclusively with data teams for the past 10 years. My Agile experience goes way back into the 1990s, when I was a software developer for a consulting firm that used an Agile approach called ‘RAD’ “Rapid Application Design”. And that was my first job as a software engineer. And I thought that’s how all software are developed. But then I went into data warehousing in the late 90s, and was very stunned to learn that that’s not how all software or data projects go. And ever since then, I have always been interested in both data and Agile. And for a portion of my career, I had just kind of switch back and forth, be on an Agile web based project that was tons of fun. But I missed the data and then go back into the data side where my heart lies, but missed the Agile. So about 10 years ago, I decided I was only going to do work that intersects Agile and data. And I have been focused on it ever since.

Shane Gibson: Cool. So we first met online. When I attended a TWI training course, remotely from New Zealand, I got up at 1am to attend. And it was all around how to use Agile with data with a whole focus around testing. And the reason I tend to that was an area that I knew in the work that I was doing that I was very light on, and a lot of the teams I worked with was lying on us how the hell do you apply testing techniques when you’re working with data? And what I’ve found over the last couple of years is actually there’s lots of Agile techniques that are applied when we’re doing application development that we struggle to apply in the data space. And for some reason, Agile and data seems to be harder than Agile for other stuff. And I’ve never worked out of it. It’s just us or not. So I thought we’d do today a bit of a chat with all of your experience on why is Agile and data team theme harder than Agile and other teams?

Lynn Winterboer: I have several opinions on why this is different. There are a couple of reasons. One, I do think that people in the data world and people in the software world kind of went our separate ways in the 90s and 2000s because we have different problems to solve. And so a lot of the while data people were solving really interesting and unique problems related to large volumes of data and moving data and Data Cleansing and Data Quality and Data Governance. Software teams were working on how to be more effective and efficient at doing software. And so they were able to come up with a lot of the practices that are now part of a continuous integration practice that really makes sense. I remember being in a web website project in 2003 where we were an Agile team working in an Agile way and the team checked in their work very, very frequently throughout the day into the branch and we did a build at the end of every night and then nobody went home until the build was out. I’m working great. And that was kind of bleeding edge for that time. But it was happening, it was not that hard for the teams to do, they had the technology they needed, they had the knowledge to do it. And they were successful at it. And yet there’s still many, many data teams out there today who aren’t able to do that. Now, there’s a couple of things. One thing might be when cause might be the, if we use some of the data management tools that we use are kind of black boxes, they’re not really meant to be, have little bits of little changes made and then checked into a main branch kind of concept. And so it’s kind of hard to figure out how to do that. We also a lot of our architectures are pretty monolithic and that served a really good purpose for a long time, sort of days they will build it, and they will come data warehouses, were trying to meet all needs at once with these big complicated architectures, but they were very powerful, they provided some power at that time that was needed by our business customers. And we’re often living with some of these architectures were so robust, they’re still around 20 years later, but they are pretty monolithic. So it’s very hard to make a small change to a small piece and not have to regression test the heck out of it. So that’s part of it. Those are two main things, what else comes to mind for you?

Shane Gibson: So there’s really two good ones. I agree on the tooling. So we’ve seen a change in the market over the last couple of years, where the tools that we use to do good and bad things to the data to transform it less black boxy, and more templating. So we’re starting to see some capability for those tools to natively integrate great work repositories like Git, and the idea that as I write a small bit of code, when I go and I check it out, there are still parts of our architecture, our BI reporting and visualization tools that aren’t there yet, the clicks, and the tableaus of the world still aren’t really natively integrated to those types of repositories, there’s no concept of me being able to create a graph on a dashboard and check that graph and then create a second graph on that same dashboard and check them and treat them as two different objects. So we are toggling is behind the Agile techniques we use. Same thing around the moment as architectures and both the technology and platforms we use and things like data modeling techniques we use. We were just served by the Big Data bollocks and happened where we were starting to deal with some of the issues around modeling and those types of things to become more Agile. And then there was a shift in the market as everybody moved to big data as the next big thing. So we spent a lot of time dealing with that before we could get back to our craft.  One of the other things that I was really cognizant of as when we have a team that’s building an application, they’re in charge of the data, they own it, they control it, they control the structures of how it’s created, they control the screen of how to use a manufacturer as if there’s a surprise in the data, it’s a surprise they have introduced. When we work with data, we have absolutely no control. We get surprises on that data that’s manufactured by somebody else every day. And it’s that lack of control of what the data looks like and how it behaves at the beginning that causes us a whole lot of headaches. That makes it hard for us to apply some of the app techniques to the data.

Lynn Winterboer: Yeah, that’s a really good point. And it reminds me too of one of the biggest tactical hurdles we face is that our testing environments, so back to that testing class, that where you and I met, our testing environments aren’t owned and managed by the data people. They’re owned and managed by the application people. And so we need very specific data sets in the testing environment to be able to have to be able to predict what the outcome should be, so that we can test do we actually get the outcome we need? And when we have a bunch of junk data in there, or we don’t control what data is in there. It’s really hard. And in that testing class that where we met, one of the ideas presented is that data teams should have their own testing environment and the data team should be able to control what data is in it. To the point that in between each test if it’s a regression test that the entire schema might be torn down and then rebuilt from scratch, in the next regression test with just the bare minimum number of records loaded for that test case, like that’s an idea that some teams use. And the idea to data teams of tearing down a whole schema is just gives people heart attacks, because we’ve never lived in a world where it’s okay to tear down a schema without bad things happening. So the testing environments, we’re sharing a single testing environment for two different purposes and we seem to always lose.

Shane Gibson: And some of that is the constraints we had around volumes of data. So, in the good old days, we didn’t have the cloud technologies, we have now the cloud infrastructures, the ability to scale on demand and scale back. So we were always constrained. The idea of running test suite over the last 10 years’ worth of data in a warehouse was unheard of, because the rest of our life, when we write, we waited for the database to respond that’s changed slightly now. The ability to do some of the things we couldn’t do before has become available and we’re starting to see teams think differently about that. So some of the principles or practices that we had that have been around for 10, or 20 years are starting to get challenged now because they were based on constraints that are no longer true. But as all things when you have a craft, these often sacred cows, and it’s done that way. And every time you tried it before you failed, so you’re not going to try again. So it’s that idea of teams from a data point of view, being Agile and constantly challenging the assumptions and constraints they had before to see whether they’re still true. The other thing is, apps teams have the ability to have a conversation with a stakeholder slightly easier, can mock up the app. They just do the wireframe. And they use that as a feedback loop. And then somehow they can craft the bits that support, they’re easier than we can, we can craft a wireframe of what a dashboard might look like or a data service. But the amount of effort we’ve got from taking the data as we get it to making it fit that wireframe seems to be a lot more effort than an app team. And that complexity in the middle that we have to deal with means that we try and explain that complexity to our stakeholders, to our users. And that makes it difficult because we’re talking to tech mode data speak to them, and they don’t understand it. So teams trying to figure out, how they can have Agile conversations with their stakeholders where they can articulate the complexity in a way that is understood without actually describing the complexity is a bit of a challenge.

Lynn Winterboer: You’re absolutely right. And I am thinking back through probably close to 60 or 70 clients I’ve worked with in the past 10 years, and maybe 10 or 12 years. But is very rare to have a true product owner, if the team is a scrum team or using the product owner construct. It’s more often that you have what teams will call a technical product owner. Now, I am not a fan of that, I still push them, I still challenge them to say Ah, you’re still insulating yourself from your customer, you’ve got to find a way to get out to your customer. And it’s a really hard leap. And like you said, it’s a habit. It’s something that’s been there for a long time, it didn’t make sense to go to the customer with technical babble. But the team still need to understand the end use of that data, the end benefit of it and it’s quite empowering frankly. Some of the teams that I’ve worked with recently have really embraced behavior driven development and using the Gherkin language to describe the acceptance criteria of a story, or a feature and a feature or a story and it’s been really neat to see them talk about the resulting impact of the effort, like if we do this, then we’ll get this result. And the result is put in some context that has business context. And that’s been really seeing that their eyes light up and seeing the product owners that say okay, I’ve been feeling kind of bad. I’ve been talking in bits and bytes for a while. And now I get to talk in terms of business value. We had a big swing away, a group that I’ve worked with recently, they had done a big Agile transition. And they were using user stories until they weren’t using them. As a data developer need, they weren’t really using them. So then they swung toward just not using User Stories and just going back to their old requirements. And when I started working with them, I just was asking them lots of questions about that. And some of them were willing to try going back to user stories. And we did some work User Story writing workshops, where we really looked at the users. And it was really empowering for those teams to realize here’s who benefits from getting this data and to get it down to like our customers customer. And tell a story of why this is important. And why is this taking up your valuable time as a developer now, when you could be working on something else valuable. So going back to user stories and really working it through to be true end users, not other developers. And then also using this behavior driven development and the Gherkin language for expressing acceptance criteria has really helped them reconnect with the business and the goals of why they’re doing this versus the technical details of it.

Shane Gibson: Look, I’m a massive fan of behavioral driven development and particularly Gherkin. So with some of the teams I’ve worked with, we started off using the Gherkin framework to describe tests. And then we got more thing as a way of just using Gherkin describe rules. So working with product owners to use the given and then framework of what role we need to apply to do something good or bad to the data, like a pseudo language that most of them can understand. I mentioned interested in that technical owner, because it’s one that I’ve struggled with for a long, long time, and I’m still working on, I originally identified this idea that you needed a technical owner or an architecture owner that was outside of the product owner, primarily because, , when we’re doing things, well, our product owners were actually business stakeholders, they knew who to engage them in the organization, how to understand what was important and prioritize it for the team, how to articulate what the definition of done was gonna be and the value that would be actioned of the output that the team created. So they behave three product owners, and typically, they had minimal data background or, or technology background. So when they were given the choice of, do you want us to do continuously deploying CDC changes off the Oracle database, or is overnight snapshot is okay. They looked at you blankly and a technical person would jump in and become the Babel fish. And here’s some to help the product owner understand the consequences of the decision that we’re about to make. So I was a great fan of that for a while because it was the best I had. Lately, I’ve been doing a lot of research and work around this idea of a Product Manager. And so the way I articulate it now is, our product owners should be focused on the data product or the information product we’re delivering. So it’s a piece of data going to an audience in a certain way to achieve some kind of organization outcome. But typically, we’re also building a data platform for a product to use. So we want automated testing, because it makes us faster and safer. And so this idea of having a product manager that’s focused on a platform on a way of working on a capability that effectively if you think about something you would like to sell, and there’s a bunch of features. And then the product owners are focused on the data and the content and the visualizations that have value for the organization, experimenting with that as a concept as does that work by defining those two different roles slightly differently. And then what happens when we get tension? Actually, no, we can’t cheat on this one because the technical debt is going to be too high. That do they have the conversation with the product owner. Everyone answer that one. But for me that concept of our product managers coming out of the Agile apps world, it’s been around for a while and it’s not something that I see as leverage in the data world a lot.

Lynn Winterboer: I agree with you, we don’t leverage get that much. I do really like the idea of product management of our data applications as products. And as you’re talking there, I was sort of imagining that the product manager is the one who’s maybe on the hook to make the whole platform successful. It’s quite a charge, if you think of a product manager and other types of products in the world, they look, they look internally to capabilities, and they look externally to what the market needs, they look at their competitors, a product manager role, take it outside of data, or even an IT role. A product manager is a really intense role. It’s a lot of responsibility. But it’s a lot of ability to make a difference in the world. And so if we pull that in, I do really like that idea. And I could see product owners being responsible for instantiating certain aspects of the overall product, at a more detailed level. But it would be very, very healthy for data teams to have a product management view and to have somebody taking that product management view. And it is a blend of what is internal capability, what is going to create sustainability for a safe future? What does the market need? What are the competitors doing? And when we talk about competitors in our data products, a lot of people in IT shops, if your work for large corporation and you’re working on the data assets of that corporation, you might think well, there are no competitors. And what I laugh about is okay, there are a couple of different kinds of competitors. One, what do your customers in your organization do if they don’t get what they need from you? You have lots of competitors in your organization, and then two what are your organization’s competitors doing with data that makes them better at serving your customers’ needs than you are? So there are there are a couple of different levels of competition that we really want to look at and evaluate them.

Shane Gibson: And you’re actually saying that I was thinking if we think about that product manager in terms of the platform and the capability, there’s often a lot of tension and teams I work with build versus buy. And I’ve seen a big shift in the last couple of years where the majority of the teams I’ve been working with are building your own platforms using open source components, services and kind of putting it together. And often, that’s your natural behavior. So I often see them decide to build something that naturally I would have suggested they bought right is a component and you’re like, actually, that one’s really not competitive advantage within your team. Right. It’s some of the stuff out there that’s available that you could integrate easily looks like it’s cost effective. So I probably question your build everything. And I wonder if that’s something that the product manager is would be looking at not as competitive products within the stack that the team are using? So it’s challenging, what are the options? What are the competitive services, we could deploy within that product? And when should we switch one in the route right windows with changing it, because it’s done, it’s dash. So that would be a key part of that role. The other one is product roadmap. So when organizations start this way of working, when they start the transition, I love the fact that you would use the word Agile transition and not Agile transformation. Thank you very much. We’re not butterflies. We don’t go into our cocoon, and those big shiny suit consulting companies, and then all of a sudden we’re Agile. That’s a generational thing takes time. But we need to, we need to see the vision, we need to give our stakeholders who are taking the risk and funding this change, an idea of what we’re aiming for. So not detailed. We need some kind of roadmap. So splitting out both the platform capability roadmap and how that’s going to make the organization more competitive and more Agile, versus the information products or the data products that we’re going to produce to give the right information to the right person to help them make more Agile and competitive business decisions. So we end up with two roadmaps is a good way of dealing with it.

Lynn Winterboer: I think too. As you’re talking about transition versus transformation that takes time to and recently had a conversation with somebody about this leader really wanted to have a vision for his data teams to transition to a more continuous integration framework. And, and as well as to transition from being a bunch of teams based on assets. This group of humans works on this asset. And this group of humans works on that asset. He’s looking to either figure out if it’s through cross training or reteaming to get a single team have expertise in multiple assets, so they can do an end to end data product. And his comment we were talking about, how might you go there? And then you start to say, “Oh, that’s gonna be so disruptive to our roadmap”. So when you said roadmap, I was thinking about that. And I said, “Yeah, it is”. He’s the guy I don’t know, and I just kept thinking at what point do you decide that the disruption is worth it? And how do you know that and  software teams went through that same challenge, but 15, 20 years ago, and data teams are still stuck in, they’ve got this huge backlog of work. They are projecting this roadmap forward, and at any point, to say, hey, we’re gonna have an intentional slowdown in our roadmap while we refactor some things within the way we work. Sounds politically risky to them. That was the sense I was getting from him, and I get that. I understand why that felt like a scary thing to do. And so they’re doing the slow transition, they’re doing a very slow transition, they could use a little bit more transformation in that little cocoon, just a little bit. But that doesn’t mean that they’re wrong for the way they’re going, they’re doing fine with the way they’re going. They’re just not getting the results as fast as they’d hoped. Because, again, that roadmap that they have is driving a need to keep delivering value in whatever way we’re delivering value right now, and not have a disruption. Which I do think, when software teams were all going through that together, it was maybe like all the rage. It was probably not so unusual to say, we’re gonna have a pause in our delivery roadmap to do this change. But now data teams, I don’t know that we get that upwelling shared experience of doing it all at once.

Shane Gibson: Do you think that’s because there’s such a latent demand to make data more accessible?

Lynn Winterboer: Yeah, because data touches so many things that the backlog is just never ending. You’re kind of never done.

Shane Gibson: But when you’re in Agile team, you never done. If you’re creating a CRM application, you’re always adding new features. So is there a concept of within an application team, there’s always really a minimum viable where it’s good enough that you could, you should never stop, but you could stop and it would work for us in the data world. There’s always more data that we can’t live without.

Lynn Winterboer: I don’t know. I would challenge the idea that a data delivery roadmap shouldn’t be disrupted. I think it should for the right reasons, but I don’t know if we just don’t feel like we have a big enough voice to be able to make that call without political repercussions or what.

Shane Gibson: Yeah, that’s my view of the roadmap is, that’s the road. So also my experience, and I’ve been using yours. Actually, it’s when we have disruption that we reform and iterate and be get better. So we should always be changing the way we work. Sometimes that disruption forces us to accelerate that rate of change. As humans, no matter how much we work in an Agile way, we hate changing things that seemed to be working for us. That’s obviously more on right as an NTP, and we think well that’s been working why would I touch as soon as I bring in a break it. So that’s hard. When the organization’s had a case of where they’re going to be, they want to meet that plan. In terms of scaling, that’s one I’ve really struggled with. And you’ve probably got a lot more experienced scaling out data teams in an Agile way than I have. But right now my thinking is why is moving from one team to two team of humans? By the way, love it the fact that you use the word humans not resources. We have one group of humans working and we want to add another group. Going from one to two seems to be similar okay, going from two to five seems to be a complete nightmare. And I have the perception that in the apps development world, it seems easier. And my hypothesis is because they have more capability to isolate the work each team is doing so they don’t conflict or collide. And with us, we tend to have some core concepts like customer and product and order, and everything’s bound to so we’re constantly colliding, both on the platform and the things we’re using and the data that we’re having to leverage to do our work. But what’s your view, is scaling Agile data team harder than scaling Agile apps teams?

Lynn Winterboer: Yeah, I do think it is for the reason you’re talking about. We’ve got these monolithic architectures, and this touches that touches that touches that touches that and so we it’s hard not to step on each other, if you’re not really tightly controlling who’s working where. There we also have some real specialization of skills. So let’s say you have an organization that has a mix of data assets, and some are homegrown. And so the skills to work on that homegrown are going to be the development skills, the development language, and the database skills and the knowledge about that homegrown thing that’s very specialized. And then you have something that’s out of the box, and you’ve got somebody a product purchased off the shelf that has been customized. So then you have that different specialized skill in that product. I think that I’m seeing that as a challenge to scaling. Because ideally, scaling means you have more teams that have end to end capabilities to work within the sphere of influence of your organization, versus more asset based teams. So there it is a big leap for the longest time, it was a big leap to go instead of having a development team and the testing team to merge them into one to cross train and to cross skill. Well, even just to get them to be in the same organization was a big challenge. And then lots of work done to help teaching developers how to tests and testers how to develop and one organization I know recently, ensure that all their offshore QE resources come with a development background. So they were hiring those team shaped people, and that’s really cool. Like, that’s a really good step forward. But then the next step is okay, now you’ve got everybody on who have skills on one asset, and can test and develop and, you know, do analysis and do all those things that a team needs to do on that asset. Now, we want to go across multiple assets, and they can be very, very different. But all still part of the same ecosystem in the same value chain to get to the end customer. And so it’s a lot of time and cross training, or it could be a lot of disruption. If you have asset, one asset to asset three, and the skill sets on each of those teams is pretty different. The Knowledge Base is pretty different. You can disrupt all three teams, and then create three new teams that each have a third of the old teams, which then those humans have to reteam, which is a not scientific, you can’t force it. It’s not a puzzle you put together and you’re done. It takes time, or you can do cross training across the teams. But that also takes time. So just scaling from that sense is hard. The other thing gets back to the continuous integration capabilities. If you have several teams that have learned how to and have built out their infrastructure so that they can check in little bits of code at a time and rent quick little regression tests and sort of sniff test the code before it gets integrated even further into the next hire environment. Then you you’ve got a lot of safety around lots of people working on it. But if you have a situation where the team is used to really only checking in code, matter of days or even weeks, there’s not much to it, there’s a lot of risk and we see that where teams try to take the cultural change of Agile, but they haven’t they don’t have the technical enablers of it, and then somebody steps on somebody else and it’s just proof that this Agile thing doesn’t work. Because when they were all on one team, they could coordinate easier about who was working on what, and they could have a separation of focus. But they can’t, it’s harder to do that now without the right enabling technologies.

Shane Gibson: So if I’m just thinking through as you’re talking about that, and so if I can’t articulate it back, and the way I think about it, all of a sudden is, we have skills we need in terms of the way we work. So that’s your example of not a separate testing team. There’s a part of the team. They have better skills at testing, but they’re helping the rest of the members test better. And then we have technology skills where we’re trying to use the same techniques and patterns on our technology platform. So we’re checking in code every half an hour over five days. We ideally using the same components. Ideally, we enhancing those. So if we take all those and an Ivana world as a given, we’re still stuck with a problem of that variety of data subject. So I suppose would we take an application team that was building Netflix, and then expect them to build Slack without blinking. It’s a subject matter area, but it’s a whole new area to learn. And when we move from data about customer, or data about product, so doing a forecast to those kinds of things, we’re asking those teams to make that shift. But somehow we forget that, and we just expecting you to pick up that new data to understand, because it’s just data, and that’s one of the challenges we have. I think one of the other ones is in the application world for Agile, there seems to be a lot more content we can leverage. It seems to be a lot more published, a lot more available to find and understand. So if you think about Scrum, there’s so much cool content out there that you can pick up and understand Scrum and reuse it and learn it. And with app development, we talk about React versus Angular, and all that kind of stuff. There’s lots and lots of content and patterns and stuff that you can do to figure that out. When we talk about customer journey mapping. Again, there’s lots of stuff out there on what it is and how you do it. When we look at the data world, it’s a bit dire seems to be nowhere near the content or the quality of content, while the content being as open as our application brethren. So I wonder if that’s part of the reason that it makes it harder for us at the moment.

Lynn Winterboer: I think so, that’s very valid when I do have a good example. And I can use that to explain a concept to a team who is new to Agile or they’ve been trying to do Agile, and it’s been not going well, because they don’t really understand the why behind it. The examples are where their faces light up. And that’s where they start to get it and I have found over and over, you give one data team, an example of a concept, but with using real data, and data geeks are smart people, we can take that one concept and exploded and apply it to our worlds. But without those examples, without those patterns to follow, like you said, there are articles that have been written even when I first got into bringing this together 10 years ago, there were articles that had been written about applying Agile to data, but they were just words. I was looking for something that had a table in it that was going to show me some data stuff, for example, you go from this to that. That is what I really needed to see to help wrap my mind around it, but it’s the examples. I spent a lot of time doing training for a lot of different organizations. And one of the things I found is that if going into before engaging with a group in the training room, if I could get with one of the team members and we could come up with an example to anchor on for the Agile training, it was much better. And so I started investing some time upfront and getting a concept of their world what their businesses and just an example, we could write a couple of user stories around an example we could write some Gherkin around for the tests, that kind of thing. Then people were like I get it, and then they move forward. But if I stood up there and gave them a lot of words, before I got to an example. There’s a lot of skepticism and a lot of people not really listening. So I agree with you, I think there’s a dearth of content really. I tried to do my part and change that when I had my own company, since I joined the company as an employee a couple of years ago, and I have not been doing any blogging since then. And I’m feeling pretty guilty about that, but I’m glad to see you’ve picked it up.

Shane Gibson: A lot less blogging, then I’ve done in the past. But essentially, when you made that change, I was like, “Yes, she’s not gonna be so busy out finding work and doing work, we’re gonna see nothing but blogs coming out with knowledge is such an easy way. That didn’t have very disappointing”.

Lynn Winterboer: I do want to say part of that was, I had some things going on with my family that I needed to take care of. So I just got comfortable, I’ll be honest with you, I’ve just gotten kind of comfortable. I work with 14 data teams, and they’re wonderful humans, and I am thoroughly enjoying being here for the long game, and I just haven’t picked my head up from the cocoon that I’m in.

Shane Gibson: 14 data teams, it’s ridiculous. That’s a lot. The ability for you to scale to that level was just awesome. I think for me, one of the interesting things people always say, and especially when I go and meet other people in an Agile era, the Agile Scrum Masters or coaches, and I say, “Look, I help teams adopt an Agile way of working, but I only work with data and analytics teams”. And they’re like, “Well, why any of the work with any team?” And I say, I probably could. But for me, it’s about those examples that are long enough with enough teams now that I feel when I’m with a new team, and they go, we’re stuck on this problem. I can say, I’ve seen the team do this, and it worked for them. I’ve seen another team do this and this work for them. And I’ve seen a third team do this, and it’s worked for them. Why don’t you just experiment with one of those and see what happens? And you’re talking the language, you’re talking in the language of data, the complexity and it seem to be more open because you’re giving them examples from real experience and that makes it a lot easier to help a team adopt some of those things or experiment with them.

Lynn Winterboer: Absolutely.

Shane Gibson: So to close out here, looking at time, so you’ve been doing a lot longer than I have. Has it gotten easier? Do you believe if you look at applying Agile, we’re an Agile way of working with a data team 10 years ago versus what you’re seeing now? Are we before lot of the application teams, we’re getting over that hump?

Lynn Winterboer: Yeah. I do think so, because that’s a great question. I’m thinking back on my first few clients. It’s easier to convince people to give it a try, because there are more examples in the marketplace. A lot of my career as a consultant was fueled by following Agile coaches who were very good Agile coaches in many cases. But they would go in and work with a client and they’d make great progress and everywhere but the data teams, and then I would get called into, can you just get them over the finish line? And then we’re done with this project? So early in that venture, because I was coming in after the teams were already worn out from dealing with an Agile coach that didn’t understand their data world, the resistance was greater. So I think early in that, in having my company, I was dealing with people who were tired and worn out and a little pissed off. So that was harder. Later in that time of having my own company, I was coming into teams where even maybe one of the last clients I had, the data team wanted to lead the Agile transition for the company. So I think that shifted, our technologies certainly with things like data science and advanced analytics that is really, really well suited for an iterative, incremental approach. So people who are working on older approaches to data management, see the new cool stuff also use being Agile than that was sort of an inspiration but it can also be frustrating, because there’s a difference between him coding something in Python and using Informatica. There’s pros and cons for each but from a from an Agility standpoint, the Python is going to be more Agile by nature. So I do think that. I’m definitely enjoying what I’m doing. There’s still a huge need for this intersection. I’m really glad you’re still out there in the market. And that you’re doing what you’re doing because it’s much needed.

Shane Gibson: Well, I think we’re. I’m still loving it and I just gear so far to so awesome. When I’m working with a team and they’ve just found something that works for them and they just love it. I won’t go there. Later is a new sunshine row. We’re in a hot market. And hopefully it stays like that for a little bit longer. So thanks very much for your time. I really, really appreciate it. It’s been great to catch up.

Lynn Winterboer: It’s been great. So fun to see you again.

Shane Gibson: I think we’ll probably come back in six months or a year with another subject and do it again.

Lynn Winterboer: It’d be lovely. I’d love it. That’d be great.

PODCAST OUTRO: And that data magicians was another AgileData podcast. If you’d like to learn more on applying an Agile way of working to your data and analytics, head over to agiledata.io.