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 found