Agile Unplugged EP 03 | Mike Cottmeyer and Chris Beale

Welcome to this week’s Agile Unplugged podcast. It’s our all-new podcast series with host Mike Cottmeyer, LeadingAgile’s CEO. Each week, 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.

This week, we have special guest Chris Beale, LeadingAgile’s Chief Technology Officer. Mike and Chris explore some of the emerging trends they’re seeing in the market and how LeadingAgile is addressing the expanding needs of its customers as new challenges arise.

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

– Well first of all, welcome Chris, thanks for joining me today!

– Good to be here, Mike.

– And what we’re doing is we are just, basically this is a way of helping our audience get to know you a little bit, get to know your ideas, kind of like, what you’ve brought to leading Agile, what your thoughts are, so it’s going to be just kind of freeform, right, so we’re just going to talk a little bit, for the next bit. So where I thought we’d start, is, do you recall when you and I first met?

– I don’t know the first day, but I kind of do know the general time.

– Was it at the Agile 2008 conference? Was it in Chicago?

– Was it at Chicago, on the boat?

– I think it was at Chicago. Version One boat, actually, so you were hanging out at Pillar at the time.

– I was at Pillar.

– I was at Version One.

– Yeah, I was year six at Pillar.

– Year six at Pillar, okay.

– Yeah.

– Now how long were you at Pillar in total?

– Total seven, left right after you joined. I don’t know why, but just kind of coincidence.

– Kind of a funny coincidence. I remember that, that was a pretty cool conversation. What was interesting to me is, you and I have very different backgrounds, like I really came out of project management, and you came out of technology, right? So you’re kind of an early XP guy?

– I am a lifelong, I don’t know how early, but I’m a lifelong, you know developer by training, right, so I came out software developer. Kind of have two chapters that I kind of consider myself, maybe, and maybe one in the middle.

– Yeah.

– I started by solving really cool problems with code, and when that happens, tends to be, you tend to get responsibility for people,

– Yeah.

– So I started to solve problems with people, and lead teams, worked for an organization that, very large organization, about 1000 developers in that organization, and then decided to go do a startup. So about year, July of 2000,

– Okay.

– Great time to go do a dot com.

– Pre-manifesto, yeah.

– Yeah, but great time to go start a dot com, right? So I went and did a startup with some folks, and I went from being a developer who thought way too big, you know, architect, solving problems 10 years out with complexity and things that were never going to happen, and speculating way out into the future, to being the guy who was trying to start a business and needed to have funding three months from now.

– Yeah.

– And so, in order to keep going, and I hired an architect, and his, I would ask him for something, and he would say “Chris, in five years, we’re going to need this.” And I would say, “punkage in three months if we don’t have this, I don’t, you know we don’t have cash, I can’t pay you in three months.” Our investors need to see progress. And so I went from being me to working with me, and I found it to be super frustrating. Just like, probably–

– Yeah, just like working with you now, yeah it’s all good.

– And everybody else, too. So but it was really kind of a seminal, pivotal thing for me, because it was the first time because it was the first time that I really hooked into value, right, and the fact that there’s a reason that people’s paychecks cash and don’t bounce, right, it’s like somebody sold something, and you’ve got to deliver it, and so thinking 10 years out about what might happen, and delaying that, could be not just costly, but deadly to a business. So that lasted for about two years, and then I joined Pillar.

– Yeah.

– And Pillar was what you’d consider to be an early adopter, they started extreme programming, with extreme programming in about 1995.

– Okay.

– So when I joined them in 2002, they had already been doing Agile One XP for about seven years. So kind of, to me it looked like a bunch of weirdos, so I was hired to lead their OnStar account, which about, they were about three million in revenue, and that was about two million of the revenue, so I was responsible for two million of the revenue the day I hit the ground, and I was kind of a developer leader when I was there. And so what I saw though, was these amazing small teams of developers, out-delivering you know, teams three, out-delivering you know, teams three, four times their size, from Ex Center, from–

– So you didn’t have any formal experience with Agile before you started that gig?

– Nothing.

– Okay.

– So I just kind of, maybe talked well, or something, reasonably smart, and so Pillar hired me. And so, really to, I’d had experience running software development organizations.

– Sure.

– So they hired me, and I was just blown away by what these teams of two or three or four developers could put out that the competition couldn’t touch. I was out executing, you know, IBM global services, and at the time, other consultancies, and so, and at the time, other consultancies, and so, but I didn’t know why. I didn’t know what made it work. So I didn’t understand Agility when I took it on. I thought, well it’s got to be these practices, so you know, so Agility has got to be test-driven development, continuous integration, at the time, even in 2002 we were doing those things. Not with all the support and tools that we have today, but we had automated deployments, you know, you run one command and it would go in or out, or whatever. So a lot of things that are kind of cool dev-opsy things that we talk about today, we were doing back in 2002 at OnStar under the covers. OnStar didn’t particularly care about Agile, but as an Agile, as a vendor who owned part of their system, we were able to do a lot of work that our competitors couldn’t do, in a way that they couldn’t do it. And so, so I went on this journey, and I tried to understand what makes this work, and I went through my practices phase, my kind of, mechanics phase, what’s these practices? And all I have to do is teach people these practices, and they’ll be as good as my teams.

– The magic will happen, right?

– And what I found out was, that didn’t happen. So when I tried to, part of my job was then to scale out what we did at OnStar to other clients, to other Pillar clients. And so I tried to hire developers, and I tried to teach them these practices, and in many cases it didn’t work. And so I kind of went through a phase of then thinking about, okay it’s the people. And you know, I tried to get certain types of people, really smart, intellectual, like, you know smartest guy in the room type people. And I put teams of those people together, and it didn’t–

– They didn’t work well together, right?

– So somehow that didn’t happen.

– Yeah.

– And so I’ve been on a journey ever since, but then you and I kind of came together, I, you know, I had synthesized the point of view that I think by the time you and I were together, that was a little bit more team-based, but still very technical in its nature, right? Agile was a very flat, horizontal thing for me.

– Yeah.

– Everything was kind of, you know, continuous delivery or bust, that was–

– So let me connect the dots. So you said at the point that you and I started kind of working together, you had come to believe that the team was really what made it work, not the practices?

– The team proficient with the practices.

– Yeah.

– And you know, I hadn’t quite yet, you know,

– And you know, I hadn’t quite yet, you know, at that point in Pillar, by the time you and I met, I had been probably in 40 different companies.

– Yeah.

– Trying to get them to do what Pillar could do. And what I found was, some of them worked. Some of it held, and it was usually when we had leaders in the company that we were working with who were very transformational in nature.

– Yeah.

– Early adopters.

– Yeah.

– Who really wanted to do this stuff, and were willing to go whatever, through whatever they had to do to do it, and really lean in. And so they were actually change-leading. The transformations where I had those leaders, we were successful.

– Successful, yeah.

– Where I did not, we would fail.

– Right so it was a bit of a cult of personality, I guess. What’s interesting is during that time, at the time that you were having those formative years with Pillar, I was at Version One, I think, because that was what I was doing right before I ended up joining you guys. And one of the things that I got super clear on, was that, you know, we were teaching people a lot of scrum and a lot of the project management kind of practices, not as much of the technical practices, and what I had learned during that time is that if we couldn’t form a complete cross-functional team, we couldn’t stabilize velocity, and if we couldn’t stabilize velocity, we couldn’t be predictable. And so that’s kind of the time when I got anchored on, okay, if we can’t form a complete cross-functional team, it doesn’t matter what we teach them, right? So was that kind of what you had come to the conclusion, or is it something different?

– Yeah, I don’t know that I had that broad base of view, right, it was again, I understood the world through a developer’s eyes.

– Yeah.

– Part of that was moral, this is just how everybody should work.

– Right.

– And people who are, you know, who are clubbing me over the head with finance or whatever, right, other concerns outside of development, kind of didn’t get it. So it was somewhat moral and myopic.

– Okay.

– So the notion of cross-functionality was, give me, you know, we didn’t call them this at the time in Pillar, but a product owner, and then give me four really good XP developers, I can build about anything on the planet.

– Sure, yeah.

– Right. And so, and the problems we were solving tended to be something that would fit within–

– Team.

– You know, a team.

– Yeah.

– And even our OnStar system, the way that that was architected, was very, it was very decoupled and multiple teams could work without really having to affect each other much. So the problems that they had to solve, crash notification, one team could solve it. So, so the classic problem wasn’t scaled, and it was a very technically-centric, like if you didn’t have a CI system, with really tight tests, you know, fast tests, slow tests, all the things that we believe, then you weren’t, you know, you weren’t agile.

– Yeah, yeah.

– In my sense.

– Okay, cool, so I honestly don’t remember the, you actually came and worked with us once, left, back, so you’re one of our boomerangs at leading Agile. What was the context under which we started working together the first time? Did I call you? Did you call me? Like, I really don’t remember, it’s been a while.

– I don’t know, you’ve called me so many times, and–

– I know, I just hunt you down and just don’t take no for an answer, it’s kind of–

– That’s pretty much it.

– It’s kind of a pattern, right?

– That’s pretty much it.

– Yeah.

– It’s the relentlessness that really sold me–

– Just wear you down, yeah.

– Yeah, it’s how I got my wife, so, yeah, same thing. So yeah, the, you and I had, you know, a brief overlap So yeah, the, you and I had, you know, a brief overlap in our Pillar days, and you know, we established a rapport and a mutual respect, and at the point in time that you and I worked together the first time, I had left Pillar–

– And you had been gone for a while at that point, right?

– I had been gone, I took a corporate gig, did my own transformation, which, learned a ton doing that, it was really, as an executive I had to own it. And that had come to its end, it went well, but change happened, and I had gone into consulting again. And at that point I was, you know, I was working in consulting, and I was at ComCast, I think, at the time, and doing some work with, some really good work at ComCast, actually. And then you and I connected, I don’t remember if I called you or you called me, but you and I connected, and you know, we decided we wanted to work together.

– Yeah, very cool. So given the fact that you are, like, a technical guy, at your core, right, more than that obviously now, but you’re a technical guy at your core, with XP, a lot of times the approach to transformation, as you mentioned, is like, is like technical practices based, it’s very moral, that kind of a thing. Like, what prompted you to think that what we were doing with all this expeditions and base camps and four quadrants and all that kind of stuff, like what was the intrigue there that made you say, yeah, one, to suspend disbelief, and go down this path a little bit, you remember?

– Yeah, I do, so I am a, I am someone

– Yeah, I do, so I am a, I am someone who is benefited from people blowing up my brain, for, you know, I have mentors who still do it. And I value them, I treasure them in my network. So there are people I still call, when, you know, when I feel like I know it all, or when I’m done learning. And they’re so smart, they can just, like, completely disassemble me for fun, right? And I seek out those kinds of relationships. How do you, because every time I get blown up, or my brain gets disassembled, I have to put it back together. And these people are really good at giving me new tools and thinking data points and connections, so that my mental models get stronger and stronger. So I don’t ever want to be a person who believes that I know it, because I don’t, right? My mental models are always incomplete, and there was, there was a person in my past who really taught me that, and I think he was just like, screwing with me, you know–

– Just messing with you a little bit?

– Just for fun, like, this guy thinks he knows everything? Okay, boom, right. And so and I you know, and I have to go rethink everything I thought I knew, and so I super enjoy that. So, there were a couple things. You know, there was one that was, it was a mutual respect thing, but two it was just so vastly different, that you know, and having been on, you know, frankly, admittedly, one part, one end of the XP kind of scrum wars, that still rage today, one end of the XP kind of scrum wars, that still rage today, you know, I thought it would be not only beneficial but fun to come join a company that doesn’t think like I do, doesn’t approach the problem like I do, doesn’t do what I do. I knew I would be rendered incompetent from the day I stepped in the door. Which was kind of cool–

– That was, yeah, it was interesting, yeah.

– And what I forced myself to do, was to not dismiss, not assert, to not have a point of view that I was going to impose.

– Yeah.

– So just to learn, just to become a pure learner, and learn how, you know, these scrum people, and you know, project manager folks, and how they thought, and how they came at the problem.

– Well so it’s fascinating for me, it’s funny you say that, because it’s like, I don’t really identify as a scrum person, per se, I actually do kind of identify as a project manager, because I kind of grew up in that world, but the practical reality is, is that in spite of my degree in computer science, I never really did that professionally, right? So when I went off to become a coach, I was like wondering if I could do it, because I didn’t like, have, like I couldn’t sit down to pair program with anybody. Like I couldn’t sit down and teach them anything technical, in that regard. And so, like our whole model was really derived out of, like, I’ve got to figure out how to make a living and do something that I know how to do. And so for me, that was like, organizational design, and it was getting backlogs in the right place, and it was getting teams positioned for success, and getting them the tools that they needed to be successful, right, so like my approach wasn’t born out of principle, it was born out of necessity, right? Absolutely pragmatic, just like what can I do to contribute, kind of a thing. So, so former XP guy, or even current XP guy, in this new world, working with a bunch of people who take this organizational design, project management-centric approach, like, what was the, what were the hurdles conceptually that you felt you needed to get through?

– Well, so maybe, you know, to finish that last point, what leading Agile actually does, did, thinks, what leading Agile actually does, did, thinks, there was no way for me to actually understand that coming in, so we like to put people in boxes, because then we can understand what they’re going to do, what they’re not going to do, and it creates safety, so I can predict. And so, as far as I knew, I was coming into, was–

– Was a scrum guy.

– Was a scrum guy, right. So that was my perception is, a bunch of scrum guys, how do these guys think, right? And so, and what do they do? And so, so that was the process coming in. The hurdle, probably the biggest hurdle I had was, I do have a point of view, I had years of experience, I had years of experience that many people haven’t gotten to accrue, I was running a professional services company, doing agile transformations for seven years, from 2002 to 2009, having lots of failure, from 2002 to 2009, having lots of failure, some success as well, right, so just going through and trying at so many different places when it wasn’t cool yet, and there just weren’t a lot of people around who knew how to do it. And so, so I had all of that experience, and then I went and left and sat in a corporate executive role, and I did it myself, and now I wasn’t the guy advising this guy in the seat, I was the guy in the seat, so I had to deal with a lot of things that I’d never had to deal with before. What do you do with co-employment, when you’re trying to do agile transformation? What do you do with your funding models and capitalization and time tracking and budgets and things that I just, you know, if it wasn’t code, and if it wasn’t, you know, flow of stories or things like that, I just never dealt with it. So I had all of this rich experience, and what I had to do was just kind of, I still had to be valuable leading Agile, which I couldn’t leave it at the door, but what I couldn’t do was to assert point of view. And so, I don’t know if you remember, but there were times where I was very, you know, laid back.

– Yeah, it was like, I want the aggressive Chris that I knew back in the Pillar days, yeah.

– People who know me know that I’m not always laid back. I have a point of view, I will advocate for my point of view, and you were expecting me to jump in and generate contact, and like, be that guy.

– Yeah, because typically, and now you’ve seen this since, right, it’s like the way that I learn is like, I want to go to battle, I want to have like, a harsh exchange of ideas, and you like, just would not engage in that way with me for a long time.

– Because–

– You do now, by the way.

– Yeah, I do, but that’s because I believe that I have a better understanding, still not a full orb understanding of, you know, everything that you and Dennis have been thinking about for so long, right, but there’s still expositional things that, like I get the epiphany and then I realize, okay, that was something that was in the system, you know, six years ago.

– Well, well, so it’s fascinating, just to be really honest about that, it’s like, it’s like a lot of what Dennis and I had in our head, like we had kind of a notional idea about it, and we were talking about it, because we just knew it was true, but we hadn’t, in a lot of ways, gotten far enough with a client to exercise it. So, like a lot of times, what we’re encountering is, like, Dennis and I are very quick to say, “oh yeah, we already knew that, we’ve known that for ten years.” But we actually hadn’t built anything around it yet. We just kind of knew it existed, right, it was almost like the Higgs-Boson, right, we knew it was there in the model, but it’s like we had never experientially seen it, right, that kind of a thing.

– Yeah, so I knew during that time,

– Yeah, so I knew during that time, I knew you wanted the contact, I knew you wanted the engagement, but I also knew that if I engaged, it would be at the cost of my own learning, my own observation. So, until I felt that I had incorporated enough of the foundations into my own thinking, and had blown my brain up enough times and rebuilt it, to have a better systemic understanding of you know, of all of your experience and all of my experience, and all of Dennis’ experience, and all of those things. I just wasn’t going to assert myself.

– Yeah.

– Because I would have robbed myself of the very reason I came to leading Agile.

– Cool, awesome.

– Cool, awesome. So, kind of a weird, loaded question, but like, as you’ve worked with us, right, coming from this rich background that you have, what do you think was the, what’s the secret sauce? What have we brought to the table that maybe you hadn’t experienced before?

– Yeah, so, you know, in my technical past, looking at the world from, really from the developer’s point of view, which is a very valid, those are the people that actually are writing the code to do the thing, right? I didn’t, in my work in Pillar was still very, I would describe it as horizontal. So if I form these XP teams, then I break the problems down, you know, I should be able to do the work. And what I found was, some cases I could, some cases I couldn’t. And I would, I developed a metaphor for it, right, And I would, I developed a metaphor for it, right, which is the statue’s in the marble, all we do is help chisel, and I would go in, in places where they wanted to change, and they had a good, effective executive change leader that I could work with, through gravitas and figuring it out, we could change the organization, and I experienced success with my own transformation doing that. I didn’t have a system for it. I didn’t perceive it as change management, I didn’t really even know what change management was. So, where there was change management So, where there was change management driven by somebody else, I could do it, and I could influence them, as an executive, and so it worked. What leading Agile has really opened up for me, is the notion of change management, that this is a change management problem, and so, I can try to teach as much test-driven as I want, but if the organization doesn’t have any appetite to constrain its demand, and actually not just swamp teams to constrain its demand, and actually not just swamp teams and thrash them with work, there’s not much I can really do to help those teams. And in the past I would just flip the bozo bit on that organization and those leaders, and say, you’re just not ready, or you’re just not capable. But the reality is I didn’t have an offer, to say, a system to say, “here’s what we’ve got to do.” We need to put this in place so that this will work to create, you know, clearings and conditions for this stuff to function, you know, the technical practices, the general kind of existence of Agile teams, you know, to remove the toxins from the organization, and so what leading Agile has helped to grow in me is skill, frankly. I can solve much larger enterprise problems. I can, I can really, so, whereas before I could, you know, I was a pretty good developer, which is why I got more. I could use code and solve very difficult, complex problems. What I’m finding is this is the equivalent of that kind of tool set. But the problems I’m solving are organizational problems.

– Organizational problems.

– So now I can take all of this syntax and all of these tools and frameworks that are at my disposal, and I can use them, I don’t follow them, I don’t check box or anything like that, but I can, you know, do the same thing I did as a developer, which is use them to solve very complex enterprise problems, specifically around, you know, you might not exist if you don’t do this stuff, and you might go out of business, so how do we solve that problem?

– Yeah, a comment and a question: so one of my favorite compliments, and I don’t even know if he ever remembers even saying it, was one time, it was, I think it was Ron Jeffries, on like an Agile project management message board or something like that. He described what we were trying to do, is he goes, Mike is trying to create the kinds of organizations that a developer wants to work in. Right, and I thought that was a really cool comment coming from Ron, right? Because he’s kind of like the uber developer guy, right? And, you know, the fact that he recognized that whether we were good at it or not, the fact that we were trying to create the right ecosystem for developers to be successful, that was kind of a cool recognition, right, so I take that as like a very cool compliment from somebody who probably doesn’t even remember saying that to me, so. The other thing that I kind of wanted to explore with you, right, is I know that over time, people in your networks have pushed back on what leading Agile has done. And so, like maybe, you know, somebody who wants to take a more developer, technical practices approach, but yet is getting exposed technical practices approach, but yet is getting exposed to our base camp model and the quadrants and expeditions and things like that, so what’s your perception of maybe how, some people are maybe misunderstanding what we’re trying to do?

– So first, empathy.

– Yeah.

– I was there, that was my point of view. I would have had the same reaction, had I not actually, you know, what was maybe available to me had I not actually, you know, what was maybe available to me that wasn’t available to these folks is that I had moved beyond the developer ranks. I still write code, still do today, I hobby code, I don’t, no one ever wants to pay me to do it for a living anymore, but I still write code, I pair with my kid, and like, so there’s things that I do that are still technical, but I had made the leap, that two-year leap into a startup, and become a businessman. And so, so I was able to have some experience And so, so I was able to have some experience that maybe they, other folks haven’t, don’t have. But it still happens, and so empathy is the first response. Dialogue is the second, but what I find is Dialogue is the second, but what I find is some people are done learning. They have the answer, and it’s moral. They have the answer, and it’s moral. There’s a right way, there’s a wrong way, and it’s interesting, you know, David Hussman, dear friend and mentor, always talked about Dude’s law and the value of anything we do is the magnitude of the why or the how, but I think sometimes folks lose sight of that, and they need to pronounce themselves as having, they are the expert, I have the answers. I don’t need to learn more, I don’t need to entertain this. And the problem with that point of view, is if you believe that, if you believe you have nothing left to learn, by definition, you are right. And so it will self-fulfill, and so, we have, people that I run into have that initial response as I did, and who will do the same thing I do, which is say, “hey, let me impact this, and let me look at it.” May be skeptic, but I’m willing to have a look, right? We have other folks who are more cynic. “I don’t care how much evidence you give me, right, I’m just not going to believe it, because I believe this,” and so, there’s a, when people get locked into rigidity in morality, and when they’re done exploring and learning, none of us knew this when we were born, right? None of us probably knew it when we were in high school, at some point we had to start learning it. The danger is when you’re done.

– Right. One of the coolest things that, that I think you’ve contributed to leading Agile to date, is you’ve helped Dennis and I make explicit some things that were maybe more implicit, right? That we kind of had a notional idea about it, or we were attempting to do some things, but you’ve made them very explicit for us, and one of the first things that you kind of brought to the table with us, is the explicit decoupling of what we would call now, a system of delivery, versus a system of transformation. And so, help me understand, right, kind of in your words, how do you, what do you see as the distinction between system of delivery and system of transformation?

– Sure. So when we first met, and we were exchanging ideas, I was, it was sometimes difficult to communicate. Because there were elements of just at that point, Because there were elements of just at that point, the system, that we called it, elements of the system that I had to localize to a client, that seemed frame-breaking. But in reality, it’s because they had a different scaled Agile model. Not different change management model, not different way of going about and with outcomes helping teams and teams of teams and with outcomes helping teams and teams of teams to move to higher levels of business agility. So we had a hard time sometimes talking to each other, and learning from each other, because we didn’t have that distinction. And so it was a necessity, I think, that was created along the way, because there is no universal one system of delivery, that, you know, the universe wasn’t created with only a single scaled Agile system of delivery that works, right? But there is some universality to change management, and how people need to go through change and experience change, and what works and what doesn’t. And so, not saying it’s moral, right or wrong, but there are patterns that emerge again and again and again. And so, so by creating that distinction, And so, so by creating that distinction, I thought we were able to have better conversations. If we go into a client and there’s a specific Agile system of delivery, that we believe works, right, that we believe works, right, we’re not going to help to implement something, install something and scale it if we don’t think it scales, or works, you know, that’s not something that necessarily adds a lot of value for us, to go say, “well no, the right one is this one.” This is the only one, this is the right one. But we need to have a way to install that, that’s not just systemic, but you know, it’s wholistic, that’s not just systemic, but you know, it’s wholistic, it’s repeatable, it’s all about, so, so I thought creating that distinction could allow us to anchor onto things that we agreed upon, that need to be done, pretty much every time we do something, as an organization. And then where we could engage with the client, and take care of their local concerns.

– Yeah, so let me see if I can put some of my words around it, and see if you agree with me. So, when we were talking about the system of delivery, right, we were talking about in general, the methodology, right, things like safe, or scrum, or large-scale scrum, or something like that. One of the things I think is cool about our interactions, is we’ve also distinguished within the system of delivery, the difference between like what we might call a reference architecture versus a reference implementation. Right, so team-based delivery, CONBON-based, program and portfolio layers, different metrics, right, those things become reference architecture patterns that are kind of quasi-universal, and then specific implementations of those patterns, safe being a specific implementation, less being a specific implementation. We do custom implementations all the time with clients, that are hybrids of lots of different things. And I think one of the things you were experiencing was that you were working with a client that had a specific reference implementation, right, that wasn’t the leading Agile model, per se. Right, it wasn’t our kind of default place was at the time, right. And so it was driving this conversation around systems of delivery, and how dogmatic are we about the system of delivery. But the distinction for me came, is when we started talking about this idea of breaking organizations into expeditions, then moving them through base camps, and then what turned out to be what we call outcomes-based planning, and all the different activity definition, and how you measure the transformation. That’s when you coined the system of transformation phrase, right, and what was very powerful about it, was the ability to distinguish the operating model that we’re trying to help the client install, versus how we were going to get to that operating model. Right, so what are the patterns for how are we going to form teams and stabilize teams and stabilize through put across the organization and what are we going to measure, and how are we going to start evaluating dependencies, and economically weigh which dependencies we’re going to break, right, those kinds of things. And to the point you just made, what’s super fascinating is that what we found, is that the system of delivery can be almost anything. The system of transformation is almost universal. We find ourselves doing the exact same things at almost every single client at this point.

– And I would say, and we proved that when, for whatever reason we don’t, something doesn’t work.

– Yeah, it’s kind of crazy, right? One of the things that’s really been driven home on your latest engagement is the idea of metrics, and you know, metrics can, you know, a lot of people fight against metrics, because it’s like, they’re used for evil so often, right? Because they’re used to beat the teams up or whatever, but what we found is if we can’t demonstrate the value of the transformation in real economic terms, right, real performance terms, then it’s really difficult to actually keep people’s attention, and to justify the spend.

– So beyond that, our clients have clients. They have CFOs, they have boards of directors, and they’re making investments in this change.

– Yeah.

– So they bought in to doing this Agile thing, and they’ve made strategic decisions that they’re going to change how they work. If we can’t show how that decision is causing, is driving improvement in terms of their ability to deliver to their business, it’s not just us, it’s them. to their business, it’s not just us, it’s them. It’s the sponsors who said, like, we’ve got to do this. And so it’s not just beneficial, I mean, it’s universally beneficial, you know, the mantra that I’ve tried to use in our clients is, if you have a system where Agiles are, metrics are using, are being used for badness, right, they’re being used to beat people up, the metrics aren’t the problem. You know, back to Ron’s point.

– Yeah.

– It’s probably not a place where a developer wants to work, right, so let’s go at the behavior, right, and that’s a change management problem. So let’s eliminate the behavior, not the tool. And I think a lot of times in the Agile community, like, we start to withdraw tools because we are very work surface based, we’re very horizontal, we don’t have the change management in place, and the things we’re creating, they start to be used for badness. Velocity is not necessarily a bad example there, right, so Velocity starts to be used to beat teams, it’s not, Velocity’s not the problem.

– Right.

– Right, it’s the behavior we need to remove.

– Right.

– And so, you know, we focus hard on removing the behavior, not the tool itself.

– Yeah. So, I’m going to take you on a different tangent, just a little bit, and this is going to be pretty exploratory, right, so this is something we were talking about in the previous hour, something we’ve been exploring with leading Agile as a concept, and I want to see if we can riff on this a little bit. So for any body listening to us, we have no idea what you’re going to get here for the next 25 minutes or so.

– Because we do.

– Well yeah, right, so it’s like, just like anything else, like, I think I was telling you when we coined the phrase “field notes,” for our blog, it was because, you know, we don’t report to have all the answers, but the idea is that we’re out figuring things out, right, we’re on the tip of the spear with our customers, trying to solve problems in real time, and one of the things that we’ve seen quite often, is that organizations, as you might imagine, aren’t static, right, not only are the products that we’re building not static, but the organizations themselves are not static. And so what’s interesting is, you go in, and you install, or you help lead an Agile transformation, right, you put in an Agile operating model, and then the business conditions around which that model was designed to deliver for, change, right? And so we’ve kind of coined this, we don’t know what we’re going to call it yet, system of sustainability, system of continuous improvement, system of improvement, we’ve played with some different names, right? But, talk with me a little bit about the things that you’re seeing with the clients you’re working with, that are driving and making that conversation so important for us.

– Yeah, so we have, you know, you can think about that as like, micro disruption and then, you know, macro disruption. So just in the normal course of operating any business, your markets, your customers, the problems you solve, the things that make you viable don’t naturally just flow in in even amounts to all of your teams, and so there’s fluctuations and demand within a normally-operating, stable system, like, here’s these business capabilities over here, for the next three things we want to do for the business are going to be super change, you know, there’s going to be a lot of disruption and a lot of change, but these other ones aren’t going to change much. But then maybe in six months, it could change. So there’s a lot of change in the system, from the flow of demand, meeting capacity in general. So if we can’t, if we don’t have any fluidity, if we can’t actually align our capacity to our demand, then we have constraints. So we might have a team that’s way under subscribed, and a team that’s over subscribed, and the under subscribed team can think of things to do, but they’re not, it might not move the needle. Meanwhile, we’re not going to get as much done for the business because the over subscribed team you know, can’t get any more work done. So there’s this normal fluidity that needs to be established in a system, and then you have the macro disruption. And you can be the disruptor or the disrupted, and you have, you know, some large new wave of change comes through, some S-curve really starts to hit, and now you have to adapt quickly. Things you didn’t do before, you have to do, and you have to do it as fast or faster than your competition, or your entire existence is threatened. And so, it’s positive and great, and a great accomplishment And so, it’s positive and great, and a great accomplishment to set up a stable system, but if that system can’t actually adapt to the kind of problems can’t actually adapt to the kind of problems that you have to solve, with the capacities at which you need to solve them, the time, the speed to market, those kinds of things, eventually itself will become the bottleneck.

– I want to be really clear, right, so a lot of times we’re talking about installing Agile to respond to the change in market, like, so features are changing, right, the needs of the market are changing, but it’s almost like the assumption is that the organization itself, its delivery capability is static. What you’re saying is that sometimes the delivery capability itself, the things that it builds, the way it organizes itself to build them, actually needs to respond to change as well. Is that what I’m hearing you say?

– It does, you’re not, you know, with the types of things you take on in a normal course of business, you know, if I have five teams, each one can do 20 gallons of work, I’m just not guaranteed, and frankly the universe isn’t going to be so nice to me to give me 20 gallons of work all the time for five teams evenly. So I might have fluctuations just day-to-day, between those teams, so I have to establish fluidity between those teams. But there are times where the alignment of that is structural and long term. So it’s not just temporary, we see long-term shifts in demand patterns through the organization, against our business capabilities, and we realize that structurally we’re over subscribed or under subscribed or poorly structured. We don’t have things grouped correctly. And so, or you know, we have big gaps to close, and we just don’t have a lot of bench strength to close it. And so, we want to change the structure and the alignment of our capacity, and basically divide the problems up differently so that we can actually get capacity demand. So there’s ongoing operation, and then there’s just like, things that we have to do, and we get big shifts in the nature of demand, against our business capabilities.

– So it’s almost like there’s a, there’s a, I’m trying to think how to say this, it’s almost like there’s a capability to flex how we’re building features to flex how we’re building features against a known product set, and then a capability to flex the organization to adapt to the need for like, maybe even new product sets or something like that. Like, I don’t know if that’s the way to describe it, but it’s fascinating.

– Yeah, I would suspect–

– It’s like an in the business, on the business, it’s like Agile as we think about it is like the way that we operate in the businesses to build, to do the work of the business. It’s almost like an Agile capability to work on the business.

– I would say it’s core to business agility.

– Yeah.

– So if we take Agile as a thing, you know, as a term off the table, and we think about business agility, we have customers who we believe will give us money or some other thing that we value, in response for some set of problems that we solve. So we’re going to create something for them, and they’re going to give us something, there’s an exchange of value. And so, there’s just, it’s just never going to be that those things are static, and if our Agile implementation, if our structure is static, it’s, the business agility of that structure is not real high.

– So let’s go down this rabbit hole just a little bit, right, so we’re talking previously, white-boarding, so, Chris flew into town to white-board with me for a few hours, and we were going to do this podcast, and we were talking about the kinds of services that a system of sustainability might have to have. So talk to me a little bit, just to anchor everybody, so we know that the business needs to be able to respond to change systematically, like the business structure itself needs to be able to respond to change. What kinds of capabilities need to exist in the organization to sustain the dynamic nature of the organization.

– I would say, at the very core, and this is something that leading Agile really helped me with, right, in my thinking, I didn’t have any context of this, I had been an architect, but I had never really I guess thought about business architecture that much, is you need to have a good solid understanding of your business architecture. And so having a capability model is the basis for understanding how value flows through your organization. How do you take it, what do you do as an organization, to take care of your customers, and how do those things work together? That turns out to be an invaluable kind of foundation for how you want to organize your Agile system of delivery, so you know, how do I define my team, my product teams and my integrating structures, and how do I group things? So it’s an important service to have, and surprisingly, a number of our customers don’t have that function, and they don’t have that knowledge. They don’t actually know what they do, and how it all works together, specifically to satisfy various customer value propositions. specifically to satisfy various customer value propositions. And so, having that function is foundational in setting up that capability, and so that’s part of our system, is to help to instill that, and to install that capability in the company. Beyond that, there are numerous change management kind of services, that we need to have, and so, we certainly need to have coaches, and so, we certainly need to have coaches, so having some sort of coaching service there, it’s, you know, a critical thing. The ability to assess progress, in metrics, so, is an important service, if I don’t know what I’m actually measuring myself against, I don’t know if I’m getting any better. So that turned out to be a very important part of an internal capability the customers need as well. It drives, you know, virtually everything we do.

– Yeah, very cool, we were also talking about exploring the idea, like, I think you guys were calling “improver teams,” like the, like having like a capability within the organization that kind of like, looks at the performance characteristics of the organization, and makes recommendations for like, how to adapt. Like are we going to form teams around something different, do these teams need to perform better, are they underperforming relative to market expectations? Like, do we need to flip the structure of how these teams get formed and aligned? I think it’s fascinating, right, it’s an interesting concept to me.

– Yeah, so, and that’s very, it’s a very pragmatic and, you know, it’s very practical, thing that we need, I mean, our customers spend a lot of money on transformation to get where they need to go, and you know, even from my Pillar days, I, you know, I noticed that we would, we could come in, be very successful, and then when we left, it would tend to unravel.

– Yeah.

– It would backslide, or it would go in multiple directions. And so, great to get them to some And so, great to get them to some target level of agility, but then what? And how do you not just have it go spin out in, you know, numerous directions? And so we have, you know, some large customers in that situation today. They’ve made large investments, they’re seeing a lot of success, but how do they keep going? You know, the core principle is if you’re not improving, you’re not getting better, you’re getting worse. There’s no plateauing.

– Right.

– You’ll get stale in what you do, you’ll lose your focus, meetings that should, conversations that should happen will get canceled. People will become so delivery-focused, that the system of delivery itself, in many cases, will erode, unless there’s individuals who really care about it. Right, so if you’re, you know, Right, so if you’re, you know, an organization that’s made that investment, and you want to keep moving forward, together, right, not as 14 different splinter groups, and, or people going backwards, what system do we put in place to make sure we’re doing that? We’re always getting better.

– Yeah, it’s fascinating, I think it’s awesome. So, maybe the last thread, conversation, I don’t know, I just want to pick your brain on something. So last year we put together a conference called Elevate Agile, and the hypothesis of that conference was that we need to figure out as “agilists,” we need to figure out as “agilists,” for lack of a better word, agile practitioners, how to elevate the conversation to our business centers, and to make sure that we’re not giving the impression we’re just talking about team-based problems. And I don’t know that we actually delivered on the promise of that conference. We’re going to run it again this year, and, and try to elevate our conversation, because like, what we learned is that it’s really difficult. Because to talk about enterprise agility, on some level you have to talk about team-level agility, but then you get mired in the team-level agility conversation, and it’s hard to talk about enterprise agility, right? You talk about enterprise agility, and then people can’t see how that translates to operations on the ground. So it’s just kind of curious, is, in the last few minutes or so that we have, it’s like, what’s your, you’ve worked across the whole stack, right, you’ve been a team-level developer, you’ve been, you know, a CIO, you’ve led Fortune 10 transformations, like, what makes this so difficult from a storytelling perspective?

– So I think in many cases, you know, the enemy is us, right, so even as “agilists,” many of us come from technical backgrounds, and, you know, as technical people, we generally oftentimes don’t get the business. We don’t really, you know, we’re given work to do, we go deal with technology, we talk in code, you know, applications, and servers, and cloud or whatever. And we have a hard time really thinking and talking in the business domains, so I think what we kind of saw in the business domains, so I think what we kind of saw at the conference, is we ourselves draw the conversations.

– Yeah.

– Towards technical topics and technical thinking, and if I’m the CFO or the CHRO, and it’s like, “yeah great, but what about my problem?” I don’t even understand what you’re talking about. So the fact that we haven’t sat in those seats, you know, that we, most of us haven’t been in a business operations role, many of us, it makes it hard to translate. So we use very technical jargon, we don’t even know that we’re using.

– Yeah, like even the examples we use pull the conversation down. Even though we think we’re like, having a big high-level conversation, it just, their mental model goes to the bottom.

– Yeah, we mention the word “velocity” and then we’re done, right, so then they’re just going to gloss over and not know how to care about us. So in some sense, we’re looking up at the conversation and pulling them down. You know, I think that is a big challenge, so, you know, the general kind of recommendation is go understand why your paycheck cashes, like go figure out what makes your business tick, and you know, what makes you win, what makes you lose, and what your domain language is like, even that’s a technical term, right? But how, you know, how people talk to each other, and try to understand the concerns. It’s a little bit like the process that I went through coming into leading Agile. You’re going to have a whole bunch of Agile things you want to say, and it’s kind of the conference a little bit, is there’s all this Agile stuff we want to talk about, but our business does not have an Agile problem. It has a business problem that we believe could be helped or solved with Agile. So suspend disbelief, take on the, So suspend disbelief, take on the, don’t try to be the expert, try to be the learner. Let them coach you.

– So you’ve had some success here recently, with some very high level senior people and some very large companies. What’s the, what’s been the biggest mental shift for you as you’re talking to them, to convince them that you personally, we as a company are able to solve their problems?

– So, you know, first I would say is, exactly what I just said, is empathetic learning and listening, right. So I don’t tend to charge in, saying “I have the answer, I have the answer!” I truly do want to understand, not just what the corporate problem that they may be solving, but their personal, you know, kind of, professional problem as well. Like, what are you trying to do as a VP or a CIO, or whatever. So I want to connect with personal value and business value, together, and personal value is probably the more important of the two. And when, when I understand what they think their problem is, I can help to diagnose, okay that’s a symptom, here’s what you really have to go do, here’s what, here’s where the bleeder really is, and we’ve got to get at it. So I can tie it to, and generally keeping it non-jargonish, So I can tie it to, and generally keeping it non-jargonish, don’t talk to, to be honest with you, I don’t talk to executives about Agile that much.

– Sure.

– Like, I don’t talk about a lot of, any Agile jargon, you know, we just don’t talk about it. We talk about business problems.

– Yeah.

– We talk about, you know, governance, and we talk about how we actually make decisions about what we’re going to do, and how we’re going to fund that stuff, and, you know, how that helps them in market or whatever. So, trying to make sure I’m staying in their world, and solving their problems in a way that they can’t see them, but I can because of all the experience that I have. So, that helps provide, I think, trust with them, So, that helps provide, I think, trust with them, so I start to establish trust.

– So I just want to push at one level a little bit further. So aligning on business problems, aligning on personal problems, caring about what they care about. How do you think executives understand How do you think executives understand the nature of their problem? Like I want to go to alignment, dependencies, things like that, like, so I can have the conversation and avoid Agile all together, but I’d love your take on like, what solutions space words can people hear? Does that make sense?

– Yeah, I think I’m tracking you. You know, at some point you have to, you know, you have to develop language that they can understand, that’s not super technical jargon. But that conveys not just the problem, but how to go about approaching that problem in the organization, and you can crawl into their space to do it. They know what demand is, so if you talk about demand, demand management, those kinds of things, you know, they’ll get it, and if you talk about governance they’ll get it–

– So you don’t say, “we need to prioritize backlog,” you say “we need to have a better demand management process?”

– So, it might not be backlog is the word I’m using.

– Well that would trigger them, the backlog word might trigger a negative, right?

– And beyond that, it’s not just the backlog, it’s the system around it, right? So it’s a little too easy in terms of how it sounds, but, you know, if you have an organization that is not making hard choices about what it wants to do, and everything’s number one, and you’re just thrashing you know, all of the parts of the organization that have critical constraints and capacity, and like, you just, you don’t have the, you’re not going to get more work done than you have the capacity to do, but you’re jamming way more work into that, you know, into that part of the system. They get you.

– Right.

– They’ll track you, and then you can start to slide in a little bit more into some of the structure, not get too jargony, but you can start to get them aligned to some of these scaling concepts that we have.

– Yeah, fascinating. Well good stuff. So what do you think is next? What’s the next big problem to solve?

– I’ve got to build my house.

– You’ve got to build your house . So I’m understanding your personal problems.

– That’s a personal value, right, so I’ve got to–

– So where are you at with that? I heard something about a foundation poured–

– We have a basement, after, you know, after three years.

– Yeah, nice, yeah that was non-trivial, you had to get permits, and a bunch of other things–

– So, we may not want to,

– So, we may not want to, if we’re doing federal work this can be a problem, but the US government had a lot of interest but the US government had a lot of interest in the sand behind my house .

– Interesting, but I imagine you got that totally resolved.

– It took a lot of, actually I had to hire consultants, as it turns out.

– A little bit of irony there.

– And they solved my problem, they cost me some money.

– Well that’s the way it works.

– But they solved my problems, yeah, so I’ve got to do that. No, you know, I think the, it’s such a big question, what’s next for me is continuing to do what I’m doing, which is primarily learning. I just, I don’t ever feel the need to be done, and to feel like I know it all, and that I’m authoritative in some way, like, you know, I just look back at, I have this habit, and I’ve done it every five years of my life, and I look back and I think about how much I thought I knew.

– Yeah.

– And how much I actually didn’t, right? And so, and then I try to ground myself in the present with that, like, everything I think I know now, five years from now I’m going to look back on and realize just how dumb I was. And so, for me, there’s always going to be a focus on learning. I actually did an interview with a guy once, and asked him what he learned on his last, in his last role, and he said “nothing.” I’m just like, how could you learn nothing? It’s impossible! But it’s not, right, experience happens to everybody, learning not so much. So he was getting experience, but he wasn’t learning. I want to learn from my experience,

– Yeah man, cool.

– So you know, I continue to do that. In terms of, you know, the work we’re doing, you know, just continuing to evolve, and to solve customer problems, and what has really been fascinating through this whole journey, is, as I do that, and as we see success, and we run into new types of things we have to, you know, new problems to solve, like the system of improvement. The same patterns emerge–

– Right?

– For me–

– It’s mind-blowing how much the core architecture of this solution is holding, for sure.

– So when I start to pull it apart, you know, what we’re doing is we’re basically breaking big giant changes into smaller changes, and then even smaller changes still, that we can have metrics in place and outcomes-based plans to move, you know, the change, to create the change. So we’re taking big giant change problems, breaking them down, progressively, like we break backlogs down, and–

– Why do you think that’s so controversial? Because I feel like our approach is a bit controversial. It just seems obvious to me.

– I think a lot of people, you know, they, you know how waterfall has become kind of this name we call each other, it’s even worse than the boogeyman, right? Say, you’re a waterfall. What people look at when you start to try to prescribe a pattern of change, like developers, I’m a developer, we use patterns all the time. We have books about them, right? And they evolve, so those patterns evolve with learning and technology, but we use patterns all the time. We don’t start, like, every software project thinking, like, we’re just going to have no patterns and start fresh, right, the languages themselves, the languages, the systems we’re on, frameworks are all patterns. But there’s this, I think, feeling that coming in, and knowing what you’re going to do, in some set of patterns, is way too eager. in some set of patterns, is way too eager. Too speculative, it’s a waterfall. You’re going to do these things, and you’re going to do those things, and they think about it like a gant chart. But they’re really not thinking about change management when they’re thinking that way, and so, and so I think there’s a bias, to emergence when we’re doing transformation. As if patterns don’t exist, and we all use them.

– Yeah.

– Right, whether we think we do or not, whether we’re horizontal in how we use them, like, as an XP guy in Pillar, trying to teach people to do this, if I look back, I used the same patterns. I came in, let’s make you predictable.

– Yeah.

– I’m not going to have a definition of done for you, that has you deploying to production multiple times a day.

– That’s what we tell new people when when they join us. It’s like, find your previous success in the patterns that we bring to the table, because if you were successful, chances are you used these patterns in some form or fashion.

– So even in Pillar, we applied these patterns. We didn’t have a formal framework for it–

– Yeah, sure.

– And it was more gravitas, it was more individual to the work that I did, versus you know, the rest of the organization–

– Probably a lot of reinvention.

– Yeah, and so, you know, I found those patterns, I discovered those patterns over time, because I just couldn’t have a definition of done that was like, continuous delivery, that’s what I’m going to start you out on. So I had to create small changes, get you predictable, reduce batch sizes, you know, start to decouple you, I had to do all that stuff, and I just did it, I just didn’t know why, right? So I think, if people were to examine their histories a little bit, open their minds, I think they might find that they apply some of the same patterns. And then the other part of the problem is, you know, with, especially with larger organizations, like with the Fortune 10 organization you’re referring to, you have a thousand teams, let’s say, and let’s say we’re just going to have coaches show up and coach stuff on the ground, you know, whatever they see is what they’re going to coach. Coaches come from different backgrounds, they have different points of view, they’re going to fight each other, they’re going to disagree, even if they think they’re like minded, like even in the XP community, we had developers, you know, or coaches fighting each other, because whatever particular flavor, you know, of Protestantism or whatever, they would still like, find the opportunity to disagree. And that confuses everybody who’s looking at you and saying hey, can you make me competent, because I need to have a paycheck, and I need to have healthcare.

– Yeah.

– Right, so, it’s not generally confidence engendering to people who are trying to go through this, to see coaches arguing each other over stupid stuff. So, but if we actually have to scale the transformation, we can’t have an ad hoc system to do it.

– Yeah.

– So, to take a thousand teams and how, I mean, how many coaches will I go get? And how long is it going to take, and how do I actually know I’m having an effect? And then how do I know I’m not going to get, like, 48 ways of doing something that I don’t need, that cause a lot of switching cost and impedance mismatch in my organization, and tons of noise? So I don’t want the religious wars, I don’t want any of that stuff that’s going to slow us down, it’s going to make us, you know, look and feel a lot worse when we’re going through this. So, the patterns themselves, the application of those patterns, still tailoring those patterns, like it’s not check the boxes, don’t take your brain out, right, these are tools and frameworks that I just like, as a developer, how do I use it?

– Yeah.

– In this context to solve this problem. You can start to scale, so I can take, you know, rather than telling a CIO, “your transformation, because you have a thousand teams, I figure we can do about 50 teams a year.” So you’ve got a 20 year transformation.

– Right. That wouldn’t be a very popular message for me to go deliver, right? So there’s a way for us in the system that we’ve created, that itself can scale, so we have a scaled system of transformation, beyond just a system of transformation, that we can take a thousand teams, and it can be, you know, a couple, two to three years, to get them to predictability. Super impressive. I couldn’t do that if I didn’t have a system.

– Yeah, awesome. Well thank you very much for making the trip down.

– My pleasure.