Agile Unplugged EP04 | Mike Cottmeyer and Matt Van Vleet

Welcome to our latest episode of the Agile Unplugged podcast with host Mike Cottmeyer, LeadingAgile's CEO. In each episode of Unplugged, Mike and a special guest explore LeadingAgile's freshest ideas, mental models, frameworks, and solutions with the people that are actually doing the work of leading large-scale Agile Transformation in the real world.

We’ll hear about Matt’s background and reveal our roadmap for building the new LeadingAgile Studios, our newest offerings to enable clients to use their capabilities to gain the strength, Agility, and craftsmanship to take on digitally native organizations in the marketplace.

Remember to subscribe and listen to Agile Unplugged on Soundcloud, Apple Podcasts, Spotify, and Podbean—and watch each and every episode on YouTube, IGTV, and Facebook.

Transcript

- Everybody welcome. We are doing a LeadingAgile Unplugged and I have a special guest here, Matt Van Vleet. Welcome Matt, how are you doing?

- Great.

- Yeah. Awesome. So Matt just recently joined us. He is helping us build our technology transformation studio. And we're gonna explore a little bit about what that is going to look like. And, but what I want to talk about a little bit is, let's just talk about your background. Like what have you been up to for the last 10 years since we worked together?

- Yep. Yeah, so I, I spent about 18 years at Pillar and eventually sold the company to Accenture. And in that we grew the company where originally, we did a mixture, as you know, between transformation and building custom software solutions. Over time, we grew to focus more, mainly on customer soft, custom software solutions, and eventually Accenture purchased us. And then I was, helped for a couple of years and in that transformation and getting them up to speed on what we did and I was out exploring what to do next and we reconnected. So---

- We reconnected, yeah. So we first worked together, I guess it was probably back in like late 2009, 2010. I had joined Pillar for a little bit. 'Cause that was when Pillar was thinking, that I guess I wanted to be a transformation company.

- Yeah, one of the challenges we had is we wanted to do, be a transformation company, but a lot of what we did was from the bottom up and we really weren't in position to affect some of the things we needed to, for transformations to be successful. We could affect in our, in our pocket. So we could set the conditions so that we could deliver a great product, but it wouldn't continue to change the overall organization without being engaged at the right level of the organization.

- So let's explore that a little bit because that was actually one of the things that I struggle with a little bit back in that time was trying to figure out because I've been, as everybody probably knows, like super passionate about this space of transformation and trying to figure out how to get companies from A to B and really always kind of took what I called, like a top down, bottom up approach, right? Where you have to have engagement at the lower level, right? But if you're not doing it with like executive support and with an integrated strategy from beginning to end, it's really difficult to sustain momentum. Talk to me about some of the challenges that you had taking it straight from a software development perspective.

- Well, when you're trying to build software and the software we were building was, was very innovative and kind of leading edge for organizations. So sometimes when you were on the proper project, you could get some of the dependencies and constraints or some of the rules, you know, waived for your project, which is great for certain projects. But if the, if you're always breaking the way the organization is designed in order to effectively write software, then it's very hard for it to be sustainable. So things like, you know, dependencies on other departments or groups where we may have been allowed to do that work ourselves and just review it with them, that wasn't standard operating procedure or our project was important enough that it had the funding set up such that it could make decisions around where to move and how to do things in the marketplace without needing to fit into the overall portfolio directly. There were a lot of exceptions that were needed in order to put software out quickly.

- Interesting. So basically if you tie it back to like the talk that I gave, what seven, eight years ago, "Why Agile Fails and What You Can Do About It", one of the things I hypothesized was that one of the reasons why Agile was failing in a lot of transformations was because you would do this thing off to the side and you'd give it all of the conditions that needed to be successful, dedicated teams and a ton of autonomy over what to build and the ability to really massage it's CICD pipeline or get all the different things in place and then wrap it in Scrum or XP or whatever. But then when you took those practices back into the rest of the organization, they would actually fall apart because you didn't have all those exceptions that you were talking about.

- Right. And so, you know, ultimately, there were a lot of needs for those types of projects. So we were very successful and grew and so forth, but that's why we somewhat got out of the transformation business because in the end we were great at building software and we weren't engaged at the right level with the right expectations in order to change the way organizations were structured or the way those processes worked by default.

- So it's interesting. So, on the other side of that, so when I left Pillar and started LeadingAgile, we approached it from a pure play transformation perspective. I wasn't actually trying to help anybody get better at software development per se, or product management per se. That was kind of part of it. But we were trying to help people figure out how to form teams and how to get backlogs and governance aligned and to be able to just even, conceptually get to the place that you could produce a working test and increment of software. So I think where this is kind of interesting is that we kind of hit a wall, right? So in our model, we talk about base camp one, base camp two, three, four, and five. And we got really, really good at getting companies to base camp two. And we could do some of the things that you guys did around base camp four and five, but getting people to bridge through two to three to four, by breaking those technical dependencies actually became quite a bit of a challenge.

- Right, and I think, you know, as you talked about it, there's this, you need to balance the top down and the bottom up and in base camps, one and two, the bottom up are more like, you know, getting predictability and getting, you know, batch sizes down. So they're more the management type practices than they are the technical practices.

- [Mike] Yeah.

- And so now, the technical practices need to come much more into the forefront from the bottom up perspective, as you're going to base camps three, four, and five, because those dependencies aren't just organizational, they're software and some of the tasks around how do you refactor code to break dependencies, or how do you automate build pipelines are pretty complicated things for our clients, but they need some help and support in doing the first time so that we can then help them accelerate their transformation to those higher base camps.

- Yeah, it was actually kind of interesting because, you know, we would hit the market and we would talk about base camp one, two, three, four, and five and then a lot of our focus would be around base camps one and two. And so the kind of, the first aha moment was we actually had worked with a couple of clients long enough to where they're like, "Okay, now base camp three, base camp four." And with base camp three, we realized that there's actually quite a bit of technical runway that had to be established. And then with base camp four, there's quite a bit of product runway that had to be established. And we actually tackled the product side first. And so we started to build a product practice within LeadingAgile and started pulling some of those core skills that we needed for base camp four into base camps, one and two, and started laying the foundation for that. So talk a little bit about the kinds of things in an early stage transformation you might want to lay the foundation for. So you can do some of that technology refactoring once you get past base camp two.

- So when you're thinking about base camp one, and you're wanting predictability, there's a set of practices that give you that predictability. You know, if you're trying to produce work in tested software, first of all, do you have an automated build? Do you have a build pipeline that's getting you things between environments smoothly? Are, you know, are things being done the same way from a technology, just basic standards perspective? Then as you're trying to get to smaller batch sizes and in the base camp two, there's a lot of things where if I do it twice as often, or if I'm doing it five times a year, instead of once a year now I've got to look at that overhead costs and reduce it. So anything that I'm doing manually, that's not value added and getting the value density of the software up, I need to look at it as waste and say, "Well, right now me moving between environments, "I only do it three times a year. "The fact that it's manual is not that big of a deal. "If I'm doing it every day, every week, every month, "now I need that automated."

- Yeah.

- And those are technical practices that are the foundation for some of the higher level technical practices that we need in base camps, three, four, and five. So as we look at applications or products that are needing to move to those higher base camps, we'll engage in some of the fundamental technical practices in the earliest stages of transformations to make sure those teams are prepared to keep moving up the base camps.

- Well, so talk to me a little bit about, because you know better than most that it's much easier to build it right the first time than it is to kind of refactor it and to try to get it into a state where you can do some of these more advanced deployment kinds of things. So what kinds of skills have to be established within the team to get to the point where they can start to break the dependencies and start working on encapsulation?

- Yeah.

- Yeah.

- So, you know, so the basics end up being that we have an automated build and automated scripts to move things between environments. And then we're starting to look at test automation, where I want to make sure that what I'm doing doesn't break something that used to work. So taking an area of the system that I now want to be able to work on independently so that, you know, every team or every need doesn't have to go through the same team. I want different teams to be able to work on different parts of the system. I need to wrap that area of the system with some tests, with some source of truth, to make sure that I know that I didn't break what used to work. One of the things we're going to do in the studio, is do some of that initial work where we can split up the application, we can put those tests in place. And that kind of gives a blueprint for teams to now know how to take that going forward. Because one of the hardest things to do is to take a legacy application, find the seams in it, find the ways to break that architecture and make it more componetized, find a way to get those tests in place because it wasn't designed to be testable.

- Right.

- So we're going to take some of that heavy lifting and take it off of the transformation teams so that they can continue to learn and grow. And our technical coaching, that's in the team room will help define and, get the organization ready to take that now, that new application with reduced dependencies to take that on and continue to move that forward for future development.

- So let's explore that a little bit. So if you think about a LeadingAgile engagement, like one of the things that we start off with is an engagement called Define The End State and really what we're thinking about during that stage is we're looking at the business architecture of the organization. And we're looking for alignment between what I might say, like the business architecture or the technology architecture and the organizational architecture. I want an encapsulated business problem, an encapsulated technology solution and a dedicated team. Right, so you talked about the seams in the organization. So like early on, we're actually looking for the seams in the organization, so we can start grouping people around dedicated business problems. So, so what, you said something that was kind of fascinating. So it's like, while the, while that part of the transformation is happening, then the studio's practice is going to start going in advance and start to do the decoupling work on the backside. Like, explain that to me a little bit, what you had in mind there.

- Yeah, so, what tends to happen right, is your application ends up looking like your organization. So if you have an organization that has a front end team, a middle tier team and a backend team, then your application is going to be focused on that. Instead of if you have your organization focused on business areas where you may have one overall solution that needs to solve, you know, payment issues or, or pricing, or what have you. So a lot of times when we're going into the transformation, we want the payment team and the pricing team to have everything they need to be successful. But the applications weren't designed such that the payment people could be changing their part and the pricing people could change their part. And there's not a whole lot of coordination of those in between that. So what we want to do is first get a foundation in place where the things like builds and deployments and versioning are automated, so that if one side changes their piece, the other side doesn't have to be in lock step, that the application can be deployed and built. And then we'll validate that what used to work on one side still works so that teams can now work independently. So as we reorganize the organization and refactor the organization around these business areas and value areas, we need to make sure that the application infrastructure and the environment is set up to support that. And that starts early on by getting some of the underlying technical craftsmanship, you know, practices in place. And then as we reach those higher base camps, you know, we can help prepare the applications to do that.

- Yeah, very cool. So this isn't a new concept for us. Back in, we've actually had studios on our website since about 2015, right before we did our Collective Soul Concert in Atlanta. Mentioned we ever did a collective soul concert in Atlanta? One of my best moments in my life. So Google might Mike Cottmeyer Collective Soul and you'll get to see me doing some awesome guitar reffing on stage with those guys. That was a lot of fun. But we kind of hypothesized this. So we hypothesized studios, we talked about a training practice. We talked about a talent practice. We've talked about actually a media company, and we've talked about labs. Those are some things we can explore in a little bit, but we've been noodling on this for a long time. And so for the last couple years we've been bringing in technical coaches working on the team room. How do you see these studios offering that you're going to help us build advancing past where LeadingAgile's been over the last couple of years?

- Yeah, I look at the technical coaches that are working directly with the teams and the studio as providing kind of a one-two punch. When you're in the team room, you understand the process, the application, and you're mostly about helping the people transform. The studio can help the environment and the code be transformed. So the output is going to be, you know, more testable code or more, less code with less dependencies, or what have you. And the challenge is, is that, you know, ultimately a lot of what we do at LeadingAgile is we teach people to fish, but you can't teach people to fish if they're starving. So the studio can help get some of the things done, make sure that the business is continuing to get value, that these things are broken up. And, you know, one of the dichotomies you run into is the hardest type of code to work on when learning these new practices is legacy code.

- For sure.

- That it wasn't designed and has these dependencies in it. So if the studio can help break those dependencies, get it in a state that's better, in a better shape than the technical coaches are going to have a more successful time when they're doing things like mobbing and other things with the teams to help the teams get better. The teams are going to not have to learn, they're not gonna have to start with advanced calculus, right? The hardest thing to do while they're trying to learn some basic algebra, right? The teams are gonna be learning algebra, or they're going to be learning how to do these practices and tasks and so forth, but we need them to do it in an environment where they're set up for success.

- Yeah. Cool. So talk to me about why this is so difficult. Why don't teams do code like this naturally?

- It's interesting. I think---

- [Mike] That stump you?

- Yeah. Well, you know, teams are more and more, so a lot of these practices, you know, we've been doing them for years, but a lot of them, they're not as old as the software industry. So it took a while to really figure out, like, you know, the automated unit testing and the refactoring and so forth, to get those into the mainstream of how people built software. I'd say like an automated build pipeline, if you look at, you know, new teams being formed, it's almost like, it's like breathing to have an automated build pipeline.

- Yeah, sure.

- It's like, it used to be that having a compiler that would build your entire application was an optional thing. And now people, like would never think of like building code without a compiler that was real time, or what have you. New teams, would never think to not have a build pipeline anymore. Like and it's, so it's more and more common with green field applications. But now you've got these teams who have really valuable software that's been out there for 30 years and it keeps getting, growing and solving new problems. And it wasn't designed from the ground up with some of these things that you would do today, if you started it. So it's hard, now you've got to go retrofit that while you're trying to add new value to the organization. And it's just a specialized skill to help them get caught up.

- So this might be a little bit of a rabbit hole. I want to see where this goes. One of the things that I think about a lot, and I don't think about it just with code, but I think about with organizations, and in any kind of like systems of people or what have you, but I don't think most people think like architects and I know in Agile, a lot of times we don't necessarily talk about having architects, although a lot of us do, right? Do you think the principles of encapsulation, the solid principles, things like that, do you think those are well understood and like deeply internalized by a lot of developers out there?

- Now you stumped me again. No, I think, you know, one of the interesting things is that if you build software the way we advocate, right? You know, it's test driven. There's a test around it. So ultimately we want is any component you build to be self validating, and, so that if one team changes it, they can know whether they broke something that used to work.

- Yeah.

- Ultimately building software that way naturally forces you into those solid principles.

- Okay.

- Right, so, those principles end up becoming an outcome based on how you build things.

- Ah, fascinating. So what you're basically saying is that when you build using the, like the software craftsmanship kind of things, using TDD and continuous integration deployment and such, that you naturally get an effect encapsulated standalone modules?

- [Matt] Right.

- That's how I'm thinking about, yeah.

- 'Cause you can't test a module if it's dependent on everything else in the organization. So it kind of forces some of those things, but instead of needing to learn all of them and then do that, if you really fundamentally, as a team embrace some of the automated testing, automated builds, like, you know, kind of a microservice architecture or a similar architecture, those things are going to become, you know, you're naturally going to implement some of those things.

- Cool. Interesting. So, you talked about the idea. So, now we're dealing with systems that are not built that way, right? They weren't built from the ground up and now you're looking for seams and ways of breaking them apart, so you can begin to wrap them in tests. Is that an art or is that a science?

- I think it's a little bit of both. So it takes people with experience to do it, at times, but ultimately knowing that, you know, what we tend to teach people is you can't just go look at a million lines of code and say, "Well, let's just spend the next year "writing tests."

- Yeah, sure.

- So if you just take a disciplined process to say, whenever something changes and I need to make a major change to it, I'm going to go in there and make that area more testable. And I'm going to put those automated tests there and I'm going to explore that area of the code, or whenever something breaks. So whenever there's a defect, I'm going to create a test to repeat that defect and then implement it. What happens is that over time, you're going to end up with the most tests in the area that it is that you're changing the most, which means you are investing in them or that break the most, which means you need to get them more solid in the, that investment self prioritizes. Now, so that type of a process and an approach, building that into your organization, I think is a bit of a science, right? We can lock that in. Now, over time, people get more and more experienced of figuring out, right, now that I need to test this because I'm making a major change or because it keeps breaking, what's the best way to do that? And that, you know, some of those things you need experienced people, especially when it's, when it's, you know, legacy code, that could be pretty complicated.

- So why is it hard to do the people side of transformation and the technology side of transformation simultaneously with the same group of people?

- Well, ultimately, you're trying to take a person, you know, it's like teaching someone how to walk on the moon on the moon.

- Okay.

- Right. You know, you're,

- I have no firsthand experience with that one, Matt, so yeah.

- Neither do I, so maybe I, ultimately there's some, fundamentals to go, "Okay, well, let's, "let's help the teams get uplifted "and let's look at the constraints and make sure "that we're not trying to have them solve a problem "beyond where they're at." It may be a problem that only needs to be solved once for the organization, right? So once your application is split up and some of those technical dependencies are removed, you don't have that issue going forward. So sometimes, rather than trying to take my team and teach them all of this heavy lifting of how to split it apart, it may be better to just get someone to split it apart, so my team can focus on creating businesses modules.

- So the group that's being transformed doesn't necessarily need to learn how to split the code, do the legacy refactoring, they just need to know how to maintain it after it's already been split apart. Is that what you're saying?

- I would say maintain it, but then if it's a base camp three or four or five team, it's enhance it and add lots of value to it.

- Continue to extend it using the same principle kind of a thing.

- Right, yes. Extend it using the same principles. So, you know, ultimately this is in a sense, a one time effort that I need to break it apart. Now, a lot of organizations have a lot of these legacy code bases, but for a team or a set of teams that need to work on an application, we can help get it split apart and then let them focus on, how do I build and enhance this code going forward using these practices so that it never ends up again, back in the state it was in.

- Okay, cool. So as you've been hypothesizing this, has been working together to define this offer. So there's four areas I recall that you think that you'll see LeadingAgile evolve into.

- Over time, there's a different set of problems. We've been talking a lot about coming along side of transformation and helping with technology uplift. So we would help, you know, break dependencies, add tests, or what have you. There are times where clients are gonna come to us and say, "I have this base camp three, four or five problem. "I just need a team to build this application "because I have to get it done. "And I don't want it to distract my transformation, "but I want to make sure that whatever's built, "won't have the issues I have in some of my other areas. "So one is I just want value delivery. "The second is that technology uplift. "The third is really a team uplift. "So, we have a team that has a certain level of capability. "There's some of the practices that we're doing "that aren't once a week things "that you need to learn to do, or once a month things, "they're things that change "how you write every line of code." And for those getting into an environment or a dojo where I can then, learn how to do those things, working against real code with a real business problem is an effective way to build up those things. And then the fourth is the technical coaching. Again, providing that one, two punch that says, "Great, you're giving me an application "that now has reduced dependencies, that now has tests, "but I have an existing team "that needs to know how to build on that "and needs to know how to build new features." I don't want to just provide this application into there. And then I could have atrophy where it just gets, like the value goes away because we didn't learn the practices along the way.

- So, basically it's like, it's like everything from, okay, we've got this one offer over here that basically says, you guys are over here transforming. We're going to help you build stuff in the right way. And then we've got another piece that is okay, we're going to help you split this apart so that when your team is ready, that we can, they can continue it forward using these solid practices. And then it's like, we're going to develop the skills within the team so that they can sustain it. And then it's like, we're going to work side by side with you coaching along the way to help you actually do it. Is that a good summary of it?

- Yeah.

- Yeah. Okay. Awesome.

- And I think that's kind of, what I'm actually interested in, so that ultimately it's very hard to move to these higher base camps, especially with an existing set of applications and we need to provide that wealth of things, right? It's actually interesting back in 2015, when you prognosticated the need for studio and these other practices or business units, what was the thinking about how that all would fit together? Is this kind of going down the direction?

- Yeah. Well, so it's kind of fascinating, right? You really have almost have to go back to like my early days. Like when I launched out, so prior to working with you at Pillar, I was at Version One and I had this idea that I wanted to go out and be an independent Agile coach, right? And had no idea, right. 'Cause I'm not, I mean, a degree in computer science, right. I've written code, I understand code, understand architecture and things like that. Like I'm not a guy that can go actually like do this stuff, right? And so in the early days of this, like I was, you know, out solving problems that I was qualified to solve, candidly, which were mainly around organizational design, project management, governance, right. And what I would do is I would spend a lot of time with teams back in the early days when I was on the ground coaching. And I would say like, "Look, you guys have to be able "to do a build every day. "You have to be able to get the testers integrated. "You have to be able to write unit tests. "You have to be able to do these things." And what I found was that for the teams that I was working with is that most of the time they knew what they needed to do. And they knew how to do these things. They just needed permission, just needed time. They needed ground cover and things like that. And so we probably spent the first four or five years building LeadingAgile within that frame, that as long as we create the right conditions for the developers to have permission to do these kinds of things, that they would do them, right? And then as the company grew and the size of the engagements grew, right, and we're trying to do this thing at scale, even sometimes thousands and even tens of thousands of people, what you start to recognize is that not everybody actually has those skills and sometimes permission wasn't sufficient. And so what we started to think about, or what I started to think about is if we were going to become a full service change management transformation company, we had to have the methodology for change, right? So a big part of what LeadingAgile has built over the last 10 years, isn't really a better, deeper understanding of Agile, what we've done is we've built a better, deeper understanding of change management and how to orchestrate change and how to create safety for change and how to measure change. Because one of the big things about our engagements is that we can walk in and we can say, "Here's the kinds of changes we're going to make. "Here's the hypothesis on that return on investment. "Here's the leading indicators that demonstrate "that we're moving in that direction. "Here's what you want to measure "in terms of lagging indicators. "And this is how all that's going to translate "into business results, right?" And so, and so what we started to find is as got better and better at telling that story and doing that kind of work, the barriers to actually getting those measurable results, as you might imagine, are in the technology transformation and uplift side. And then, and actually, and on the product management side, some of the base camp four stuff, because what we were really good at early on was helping organizations unlock their delivery pipeline. So, you know, there's this challenge it's like, when you can't build anything, is the conversation, are you building the right thing or can you build anything at all? And so base camp one and two in practice in the early days ended up being a lot of, "Okay, I'm not trying to tell you what strategy. "I'm not trying to tell you what to build, "I'm not trying to tell you what your customers need, "I just want to unlock your ability to build anything." And we got a lot of companies to where they could build stuff really predictably, but they were building some of the wrong stuff, right? And then, so we moved into the product space and then it was like, well, we know that in order to be able to move faster, they're going to have to unlock some of these technology problems that we had kind of punted down the road a little bit. So that was what was going on in my head at the time. It was this evolution and what the market was showing us was that there was indeed a need to be able to unlock. It was like gridlock in these organizations, right? To get rid of the gridlock. But then once you got rid of the gridlock, you know, the constraint moves and it moved into some strategy conversations, some product conversations, some technology conversations, sometimes it was training and skills transfer conversations, sometimes it was change management communication conversations. It was all over the place. And so the market revealed to us that this is what the next step was. I think we took the right first steps in those early years, but it became really, really clear. And so why the gap between 2015 and 2020? Well, it was like, we just took off. It was like, we started getting large clients and we doubled the size of the company. And it was like, there were so much of the base camp one and two work that really difficult to get the right level of investment and intention in doing some of the technology stuff and the product stuff necessary for four, five, three, four and five. That makes sense?

- Right, yeah. Makes lots of sense.

- Yeah, so it's kind of funny, right? It's like, you know the answer to the question at the beginning, but you have to kind of, we're a very agile company, right? So you have to go to market with what you can do, right? You have to go to market with what the customer is willing to buy from you. And then the market tells you what's next. Right? And it was really kind of a funny thing. It was like, when you were wrapping up your last gig, we were just at the place where we were encountering some of these challenges in a real way. And it was very timely, you know, to be able to take this leap during this COVID shutdown and all these different things. And yeah, it was just very timely, the way it all came together because I think we've gotten so effective at getting companies started and moving and into base camp one, base camp two, and we had danced around the base camp three and four problem enough, that it just got really, really crazy clear that now was the right time to go do all that. So, welcome.

- So no pressure.

- You got a big job ahead of you, man. You got a big job ahead of you.

- Exactly.

- Cool. So let's talk a little bit about the offer, right? You've been thinking about this quite a bit. So one of the things that I've really appreciated is as you've joined us, is that you've really kind of snapped a grid, right? You said you've gone to school on all my talks and presentations and things like that. So you've been walking our team through this, why, what, how, who kind of framework? So talk to me a little bit about why. Why studios, why now from your point of view?

- Well, and when I talk to people about why for an organization, there's always three components of it. So why for LeadingAgile and we just covered a lot of that, right? We understand what we're wanting to do. So why for our clients? You know, again, some of those constraints that are preventing them from getting the higher base camps and some of the unique constraints when you're, when you've got a lot of legacy code that some of the digital native new companies don't have. So that's a big why for our clients. And then there's also a why for our people.

- Well, so why don't they just go build it themselves? I mean, we talked about this a little bit, but let's just put a fine point on it. Why wouldn't they just go build this capability themselves?

- You know, some can, but there's, you know, there's a lot of, of work and know-how to know how to build that. And a lot of what we do is help build that capability for our clients and help them get there. But in the end it will become a capability that they have, and we will be an extension of that capability when they need it.

- Cool.

- And then why for our people. You know, we have technical coaches, who are great on doing that technical coaching, but they also would like to move into building things and creating once in a while. Our great consultants like to do three things. They like to create, they like to learn and they like to teach. And if they're only in a teaching mode, then where do they learn, right? And letting great technical people move between a studio context and a coaching context without even leaving the organization, I think is a great why for our people.

- So let me just see if I can summarize, right? So, we talked about how LeadingAgile needed to fill some gaps in our mission of being able to be a world-class transformation company, right? So we realized that unless we closed this particular niche in the market, that we weren't going to be able to realize our full brand promise, right. And then from the client's perspective, sometimes it makes a lot more sense to have somebody help with this aspect of it, because it's not something that they need to do forever. It's something that they need assistance and kind of a heavy lift. And then once everything's refactored, split apart, you know, test harness continuously integrated and deployed, then they need to have the skills to maintain it and to evolve it. But they don't necessarily need to make the investment in their people for the heavy lifting. And then the last bit, right, is a little bit about us and our people and having the ability to move across these domains and make sure that everybody's skills are fresh and that people are doing what they love. And they're able to engage in a lot of different aspects of the things that make work fun to do.

- Yeah, exactly.

- Yeah, cool. Awesome.

- And then kind of when you go from that why to the what, and we touched on this, so in order to solve those problems for clients, we need to have those four different capabilities, right? We need to be able to help a client, just get something built when they need it. We need that to be able to help them transform their technology environment, to make it a more conducive to these types of base camp three, four, and five team needs. We need to help their teams get to a position where they know how to build on top of these code bases, as well as extend them and maintain them. And then we need that coaching, that gets there on a daily basis to help get those things successful during the expeditions that the teams are going on.

- Cool. So, loaded question. What do you think we can bring to the market that makes us different than anybody else? Like why LeadingAgile?

- The number one thing is to having the things integrated into the model, right? We don't just decide that everyone in the organization needs to get to the same level, right? We talk about base camps and different base camps have different outcomes. And some of those outcomes can be better achieved by having these technical practices in place, and helping solve and affect the metrics or the outcomes. Right, so, so this integrated offer that helps, you know, large organizations look at, where do we need to make change, prioritize the investment in those changes, align both the organizational aspects, like government, governance and funding and so forth. What's the technical aspects that need to change, and being able to do that, you know, within one system of transformation or one system of delivery, I think is a huge advantage.

- So let's talk about that a little bit, 'cause that actually will dovetail probably nicely into the, the how conversation, right? So, one of the things that I think has been a really awesome advancement of the last couple of years is that we've made a clear distinction in market between what we call a system delivery, right? And for everybody listening, that's like what you expect. That's like SAFe, scaled, Agile, right, kind of things, LeSS, what have you. So basically, if you look at the operating model of the organization, the end state organization, we call that a system of delivery. And so we have patterns and we draw from a lot of things. We're not really in bed with say for lesser, disciplined Agile delivery or anything like that specifically. But we draw from the same core patterns in market. And then we coined this thing, we call the system of transformation, which is really around how do you get from point A to B, right? How do you start down the path? And so we have, we have a define the end state where we work out a lot of the business architecture and governance and dependency issues and tooling issues and how we're going to measure and think about during the transformation, how we're going to spin up an Agile transformation office, how we're going to measure progress. One of the key innovations that we made a couple of years ago was something we called outcomes based planning. So every, whether it be a define the end state or whether it be like an expedition to base camp one or two, we have predefined outcomes that have to be achieved really rich activity level guidance. It's amazing how repeatable actually moving an organization through these states is, right. And so what did it gives us the ability to do is to call our shots and to basically say, "Okay, "we're going to take this organization to base camp two. "We're going to take us next organization "to three or to four. "And here's all the intermediate outcomes "that have to be achieved. "And this is the roadmap, and this is the playbook "for how we're going to do those things." And what it gives us the ability is to do is to say, "Okay, there's a coach on the ground "or an organization we're working with. "Here's the activities that are going to lead to an outcome. "And these collections of outcomes "are going to lead to the state we call a base camp, "which is a definable set of organizational "performance criteria." It basically says, okay, this is what you're going to get for your dollars. This is what the organization is going to be able to do when we're done achieving these outcomes. So it's been fun to watch you do, right, is where a lot of our outcomes have been around organizational design and teaming. And how do we do all the alignment things? How do we do the governance things? How do we do the metrics things? What you've kind of come in and done is helped us overlay what are the technical foundations that have to be put into place at the outcome level and at the activity level? So that was a long preamble. Talk to me a little bit about where you see the opportunity around overlying with our outcomes based planning.

- Yeah. So, any of these practices we've talked about so far test driven development, automated builds and so forth, the goal is never we should implement those practices. The goal is the outcome, right? So we've got these outcomes and ultimately, you know, usually they come around, how do we make or save the organization money? And as we're taking those outcomes, then how do we that outcome? So as an example, if we're building a release and we look at it and our define the end state, and we do a technical uplift assessment and find out that on average, each release has about 40% of overhead in it and about 60% of value added work in it, then we can look at that and say, well, how can we use some of these technical practices to reduce that amount of overhead? Maybe by automating builds or moves or reducing rework by having automated testing. So the practices affects some metric like the value density of the work. And that metric is based on one of the outcomes that we're trying to do. So by, by making sure that the practices and the technology changes don't become the goal, but the outcome is the goal, and these are techniques to achieve the goal, now these investment decisions can roll up to people that can prioritize budget and say, "That's very interesting. "I can get, if I could go from 40% overhead "in my release to 10% overhead in my release, "then either I can spend less money or, "and a lot of growing organizations that are in markets "that are being disrupted, or I can get 30% more out, "or I can get releases into production "that much more often." So, you know, tying what we're doing in the define the end state and making sure that the technology investments are tied to the business outcomes, that makes it a much easier decision for the organization to decide where the priority is because it's, how does do these technology decisions help affect our business strategy?

- So interesting. Right. So, basically what you're saying is, whereas maybe in a previous life, you would have come in and help people build software or taught them, you know, software craftsmanship or CACD pipelines or dev ops, or what have you, right, doing them in the context, within doing those same kinds of things, within the context of LeadingAgile's outcomes based plan, business focus, strategy aligned objectives, results focused transformation. That's going to be the key differentiator in terms of how you deploy this.

- I think that's going to be a huge differentiator, for LeadingAgile in how we do these things. In the past, you know, we taught our people to just keep asking why until they could get back to a business objective, but what's great is the way we're doing transformations and the way we're building these plans, the why is right in front of everybody. So now, you know, and it's never, then the technology becomes the goal. We're talking about technology a lot today, but the technology is enablers, is an enabler for the why, for those outcomes.

- So when we talk about a, you know, a base camp outcome, like get predictable, and one of the intermediate outcomes is like form teams and stabilize through put and all these different things, right, then what you're anticipating is overlaying the technology objectives or underpinning all those outcomes with the technology objectives that are really gonna make that a robust ecosystem.

- Exactly.

- Yeah. Okay. Fantastic. Well, so I guess the last thing is who. So talk to me a little bit about that. What does, what's your thought?

- The answer is going to be fairly broad. So on the technical coaching side, right, we need people who, who have been involved in these types of work before that can really help the team.

- So you're really talking about, as you build your team out, what kind of talent are you looking forward to joining LeadingAgile?

- Yep.

- Okay. Got it.

- You know, so I think, and then within the studio, it's people who have that legacy, you know, refactoring experience, people who have the practices. And when we, when we look at the who, we, you know, of course we look at the skill they have today and the experience they have, right? But there's two things that are really more important than that because languages are constantly changing. Technologies are constantly changing. So instead of measuring completely, what do you know today? Have you demonstrated a learning velocity? How good are you at learning the next thing? Because we want people who are continuous learners and really learning new things. And part of that isn't just, because, we can teach people a practice and what have you, but the other piece is we really want to understand their beliefs, right? Are they doing this because it's a flavor of the day, or they fundamentally understand why it's important to build software this way, to map back to the business objectives and so forth. So it's a little harder to measure and understand, but we really want people who understand why these practices exist, can map them back to some of the underpinning theories behind that and then, and then of course they have to have certain skills and experiences in order to thrive.

- Yeah. Cool. Okay. So as we get towards the end of this, what else do you want our community to know about, about what you're thinking or what we're doing, that kind of a thing?

- I think it's important to realize that as you're doing these transformations, as you're building an organization that can do these, that you can take the capabilities of some of our very large clients, free those up to where they're going to have the momentum and strength to compete with some of the digital natives out there that have some more agility and maybe some more craftsmanship than our, a lot of our clients have today, but they don't have all the strengths and other things that our clients have. So as we're unlocking some of these dependencies, as we're building these technical capabilities, what we're really doing is empowering them to succeed in the markets as they're getting disrupted, right? So if our clients can make sure that they're aligning themselves to their clients and markets, and we're enabling that to happen, then I think that's going to be the ultimate success of this integrated offer.

- So helping our clients align better to the needs of their clients. And, and this was an interesting angle and become digital natives themselves, right? Companies that are basically able to, it's just in their DNA, this is the way they work.

- Right.

- That's awesome. Okay. Great. Well, thank you for joining me, Matt. I appreciate it, man. Thanks for flying down to Atlanta to spend some time in our little a recording studio here, so...

- No problem. It's been great.

- Excellent. Yeah. Thank you. Appreciate it.