Agile Unplugged: EP 02 | Mike Cottmeyer and Dennis Stevens

Recorded by Mike Cottmeyer

Welcome to the next installment of an all-new podcast hosted by LeadingAgile’s CEO, Mike Cottmeyer. Agile Unplugged is your chance to 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, out in the field.

In this week’s episode, LeadingAgile Chief Methodologist, Dennis Stevens, sits down with Mike Cottmeyer to discuss Capability-based organizations, Systems of Delivery vs Systems of Transformation, managing dependencies, and more.

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

- So welcome Dennis, thanks for joining me today.

- Hey, Mike, it’s good to see you.

- Yeah. So, a little bit about what we’re getting ready to do. So what I thought, or running common experiment here, Leading Agile and we’re doing this kind of casual format where I want to pick your brain for a little bit right? And so you and I go way back. When did we first meet? Do you remember the story?

- I think it was 12 or 13 years ago.

- It’s been a while.

- I was working in my office down in technology Parkway. David Anderson had been working with an APLN Yeah,

- I was on the board with him at APLN.

- Yeah, and I was doing some methodology work with Microsoft, as a contractor and David had read my stuff, read your stuff, and reached out to both of us and said you guys should get together. You leave like pretty close and you’re thinking about this in very similar ways.

- Yeah, I thought that was kind of funny cause you know, back that was like pre-leading Agile and so you know, when David Anderson sends you an email and says you should meet this guy, it’s like, okay.

- That’s right. Yeah, I’ll go meet this guy.

- That’s right.

- Talk about project management and things like that. So, tell me a little bit about what you were doing before you and I started working together, what’s your background?

- Well, there were a couple of big things I was doing the fundamental foundational thing I’ve been doing for a long time was kind of big project recoveries. Going to organizations that had spent a lot of money, we’re sort of in a difficult position with projects I was doing with Perot, I did it before and turning big transformational projects around. So how do you get an organization to actually, solve the problems you’re paying to solve when they’ve wasted, two thirds of their money and they’re two thirds the way through the schedule and thing is a disaster. How do you like fix it? Now it turns out the way you fix it, is you get to be aligned on value. You get super clear backlogs, you find out what the real cadences you’ve finished work that you start.

- Yeah.

- And you do that like at a project level. So, that was kind of cool, the thing that I was doing like right before we met was I had been brought into Microsoft as a contractor, building out a business architecture practice, I think they called motion. And that was based on some work I’d done, as a consultant several years ago the company was acquiring a bunch of other like power companies, and we were doing capability modeling. We were looking to see how do you bring companies together and merge them together? Again, it was kinda like, which process do you pick? It began as a big transformation of a project, to integrate companies.

- Mm hmm.

- And how do you pull them together quickly? So we’re doing capability modeling. So, I was helping Microsoft build a business architecture practice, on the tail of that.

- Your so Interesting. So I’m gonna ask you a question, I actually don’t know the answer to. And so I’m talking about chance here, but like, how did you get involved in business architecture in business? Well, actually, before I hear that, what is business capability modeling?

- The thing that we were looking at was, how do you look at an organization by what it produces, by the outcomes that it does, instead of by completing projects, or by the processes. And, the way I got involved in that, so its capabilities are looking at the network as a series of what the company does or not how it does it. And then tying that together into a network and then applying Lean principles to designing an organization that can get stuff done. Primarily applying it to projects, cause we we’re like trying to solve specific processes, but it’s generally applicable, at scale as well. The way I got into it was when I was at Perot systems, I was working in Jim champions organization and champion was one of the guys that led business process re-engineering. We had learned that.

- He did it before, Hammer and champion Bill, BPR. Pro-hired those guys in tow. Champion was in there designing, he realized his shortcomings, to business process re engineering. Cause what that was, was, go redesign all the processes, automate them streamline individual processes, but it wasn’t getting the results that it wanted. So we started looking at how do you look at an organization in a bigger sort of slice. Now remember, we were doing contingency type deals, so we’re walking in applying it to like a specific set of processes. But optimizing individual processes didn’t solve the whole. So we started doing capability modeling, to determine what the organization should look like, and then going and fixing the interaction of capabilities, rather than trying to fix individual processes. It was a lens to look at, connecting outcomes together instead of just running projects again,

- Yeah, so I think you you took a stab at this a bit of a level, but tell me like, let’s go just go a little bit deeper into what business architecture business capability modeling is like what is it? Business architecture is looking at the outcomes that an organization produces.

- Hmm. It’s breaking what an organization does to produce those outcomes down into measurable, definable outcomes.

- Mm hmm.

- And then looking at which ones are strategically important, which ones are performing poorly, which ones are too expensive for the value they bring to the company. Doing an analysis of an organization, you can figure out where to focus to apply limited resource. It’s a portfolio management, problem solving technique.

- Yeah.

- One of the problems with six sigma at the time, one of the problems with BPR was you can’t redesign everything. You can’t apply these techniques to a capability to a process that getting better at is useless. Sometimes fixing it isn’t a process problem, it’s a technology problem or sometimes it’s not a technology problem, it’s just an understanding problem. So you’ve got to be able to understand, is it important to get better at that? And what does it mean to get better at it? And it’s not always get better the technology get better the processes, it’s get better producing the outcome.

- Okay, cool. So, also about the time that you and I met you were doing some work with PMI and the OPM three initiative?

- Yeah, that’s right.

- So there’s a reason I’m going to ask you this question, cause I’m gonna set up the next thing I want to ask you, but tell me a little bit about the OPM three thing and what you guys are trying to solve there.

- So, OPM three is looking at an organization at their organizational project management, portfolio management, program management, OPM three. Looking at the capabilities in an organization and trying to determine, based on the problems you’re trying to solve in an organization, which capabilities do you have to get better at. It was a business architecture lens and a business analysis lens on top of organizations, but on top of project management, program management, portfolio management organizations.

- Well so you actually use the word exactly the way I wanted you to use it. cause you and I for part of the first three years we were hanging out and talking about this stuff. We were using the words like capability and competency interchangeably, right?

- Yes that’s right.

- Yeah, and so I thought it was an interesting thing, I thought that like to me and this is stuff I’ve learned from you right? So like a capability is something like its value that the organization produces. And so like in some of the early I think it was maybe it was Merrifield book rework or maybe it came from your HBR article I can’t remember. But it was like the ability to fax something.

- It’s not a capability.

- Oh it isn’t the capability?

- Send a letter, is the capability, to fax something is the process.

- Is the process Got it?

- So that was the distinction.

- Yeah, and so, but then there’s like the OPM three world right? And like the CMMI world, is like around like the, and I’m not gonna get this word right either. But like the skills that you have.

- That’s right.

- Right? So there’s like the value that you produce, and then there’s the organizational competencies that you need to produce them.

- Wherewithal.

- Wherewithal that’s a good way of saying it.

- So it becomes interesting to like, Six sigma is about the process.

- Mm hmm.

- Right? And BPR was about the technology. And a lot of the competency models, a lot of that was about the organization skills and stuff, all three of them are equally important. But if you’re looking at just one, in a vacuum, you might not be using the right problem to solve it. So the capability wraps around the layers.

- Yeah.

- So I can assess the capability and then use the right tool to solve the problem.

- So what was fascinating about some of mine and yours early work together, I remember sitting in front of your whiteboard in your conference room, and we’re like talking about Lean and different things. And trying to figure out where we had common ground and like what we understood and what we don’t understand. And I was working at version one at the time and so like I’m like all in like, not like team level scrum. I was operating in a different space, candidly. Right? And that was about the time that I was starting to develop the teams backlogs, working testing software. kind of, I mean, you would call it meme, something like that, it was like an idea, as a collection of ideas. And one of the things that you and I kind of came up with that I thought was fascinating. This merger of business architecture and the idea of Scrum teams is that a lot of times we think about Scrum teams as a product, or maybe a feature set.

- Right.

- But in a lot of these large organizations, we’re going into, we’re really in effect forming Scrum teams around business capability.

- That’s right.

- Talk to me a little bit about that.

- So, what became really interesting as we were talking was, why organizations aren’t successful doing Scrum, or delivering big projects or making change or trying to make to deliver a product, or a promise they made.

- And it and it turns out that the thing you were talking about, we have to have stable teams, built around solving a problem and in an organization of capabilities are in fact persistent.

- Yeah, cause that’s the thing in the organization that typically doesn’t change.

- That’s right.

- Projects are transient, processes transient. But the capability is introduced.

- Probably pretty persistent. So if you’re going to build Scrum teams, instead of building Scrum teams around projects,

- Mm hmm. You build Scrum teams around capabilities, you can build persistent teams around persistent things. And then those Scrum teams can become much more effective in an organization, then you can start to get a clear backlog to them. The problem of orchestration between capabilities becomes a problem of orchestration of backlogs, between teams.

- Yeah.

- Right? And then you start to measure some of the lean stuff that we’re doing at the time, from some of the con bonds. Some of the learning that we were doing in that area, was then you learn to measure them, so you can orchestrate the dependencies, you can produce clearer throughput. You were looking at it from more of an organizational standpoint and I was applying it like to solving problems. But it became really nice outfit together.

- It was fascinating, because you think about Gosh, 13, 14 years ago, where, like I was going in literally installing version one software and training teams on how to do basic Agile. And I would get asked questions that were like, Well, I’m on six projects that are all doing Scrum. Like how do I go to six daily standup meetings? How do I do six reviews and retrospectives? And that like, put like a earworm in my brain. And I’m like, that’s fascinating, right?

- Yeah, the impossible question.

- Yeah, so the, idea that, in order to do a well formed scrum team, where they can stabilize velocity, it has to be organized around something that’s like a persistent object.

- Right.

- In the organization, right? projects are by their very nature transient, right? And so even like value streams are complicated because value streams tend to traverse, the entire organization.

- That’s right.

- So the business capability modeling language, was pretty powerful.

- Yeah, it connected a lot of questions that we were trying to get answers to at the time. Cause I really wasn’t coming at it from a scrum standpoint.

- Yeah, you weren’t, that wasn’t you. You’re more of a Lean, doing some of the Oh gosh, what was the, critical chain project management?

- Critical chain project management?

- Yeah.

- And so I was trying to create stable capability so I could do buffers. So I was trying to manage dependencies between capabilities and a project that we were delivering, right?

- Yeah.

- And so I would use that stable metaphor, if I can deliver this, and then I can deliver this I can figure out how big the gap is in between. I can, get the gains and not lose when I have the problems, So how do I build a critical chain project plan to deliver? You were talking about doing it organizationally, and using Scrum inside those teams to it? So it was really interesting.

- I think it’s a fascinating intersection as we see how this conversation goes, because, in a way, we’re pretty on record for like dependencies or what gets in the way of almost all this stuff, right? So we want to encapsulate business capability, you want to encapsulate dependencies within a scrum team. But inevitably, the scrum teams have a value stream that goes across them.

- That’s right.

- Right? And so as you’re trying to organize around business capabilities, you end up doing a lot of dependency management.

- That’s right,

- All the way up. So that’s some heat we take some time. So talk to me a little bit about dependency management, in a capability based organization.

- So first off, most organizations that we go into, the dependencies don’t go away, the technical, the process, the funding, the organizational dependencies don’t go away. Regardless what your forms crumb teams around. Regardless what teams are formed, there’s going to be dependencies between them to deliver anything.

- So it’s kind of like you pick your poison. You’re organized around products, you got dependencies between projects, you organize around projects, you got dependencies between business capabilities.

- Yeah and we find out now that we’ve got dependencies between compliance and we’ve got dependencies with distribution and supply chain type stuff. We’ve got dependencies with marketing and how we’re going to communicate things. What’s interesting is, unless you form around capabilities, it’s really hard to get a tight lens to analyze all those together, try to manage it. But one of the things that we talked about is, where do you want your complexity to live? Where can I put the complexity so I can manage it.

- Mm hmm.

- So if I can wrap a container around an outcome and take everything into consideration, compliance, procurement, process, dependencies, technology, competencies, make those manageable? Then I can put my complexity where I want it, to be where I can manage, I can manage inter capability, dependencies, because I’ve aligned everything else.

- So the capability of the scrum team or the scrum based organization that’s around this capability operates with independence and autonomy within itself.

- Within itself, yep.

- But then it has to coordinate, there’s some governance layer, something that coordinates backlogs across multiple teams, is that right?

- Yeah that’s right.

- Okay, awesome.

- So, is that the end state? Do we just want capability based organizations ?

- Well, I do want capable organizations, but I want capability organism based organizations that are completely autonomous. They can actually operate as if there’s no dependencies, as if all the testing and compliance and everything is all software inside that team.

- Yeah.

- That’s the best way to operate. But I can’t, pretend like those things or the teams are autonomous when they’re not.

- So the team don’t just self organize those dependencies away?

- There’s not a scrum master that I’ve met yet at one of our big pharmaceutical clients, that can go change the human factors, compliance rules with the FDA.

- Yeah, got it.

- Right?

- Yeah.

- Now, it’s just a stupid example, but it’s everywhere.

- Well I was trying to be a little funny, right? Cause that’s one of the things that we talk about. It’s like, to move to this kind of organization and to deal with dependencies is often beyond the purview of a scrum team or an organization that goes all the way up to the top right? So there has to be some intentionality around how that’s designed.

- Yeah, it’s in every layer there. I was reading recently Joshua, talking about. Casey?

- Yeah, starting with the with Scrum and not technology, is a failure mode that he sees. And i think he’s probably kind of right? If you really do start with Scrum not caring about technology.

- Yeah.

- If you start with technology, without deciding what you’re going to build your teams around, it’s also a failure.

- Yeah, so there’s the language I think you and I’ve probably centered around is the idea is that you form encapsulated teams around business components, business objects, business capabilities, right?

- Yeah.

- That kind of a thing. And, the people and the process and the technology, should all be encapsulated within that.

- That’s right.

- The problem is, is when we have technology dependencies between different parts of the organization, one managed right?

- That’s right.

- Okay, so that actually kind of begs the next question. So one of the things that you and I have been talking about for a long time, is the difference between a system of delivery and a system of transformation. So talk to me a little bit about what those two things are and how they’re different.

- Okay, there’s this concept of working on the system, versus working in the system. So let’s talk about the system of delivery. I’m working in the system. There’s work I’ve got to get completed, to deliver to a customer, there’s things to get orchestrated. Things have to get signed off on, customers to pay for.

- We’re actually producing the product?

- We’re producing the products. There’s a system of delivery. And there’s orchestration and dependencies and meaning has to be made clear.

- So like a, PMI driven Pim Bock based organization that’s a system of delivery.

- System of delivery.

- Safe?

- Safe defines a reference architecture for a system of delivery.

- System delivery. Last discipline, Agile delivery, also sometimes delivery.

- Absolutely, yeah.

- Okay, cool. So what’s the problem with just saying, Okay, let’s just just do the system of delivery.

- In order for any of the systems of delivery to work, well, there’s two major problems. The first one is in order for any of them to work. The conditions have to exist in the organization that take place. Which means there’s change, you have to do to the organization. I’m going and saying we’re going to train and implement safe, when I have too many dependencies or I don’t have all the right players involved or I have constraints or if the problem is solving is a different problem than the one that saves solves for. Safe and of itself isn’t sufficient, I have to be able to make the change in the organization, so hence the system of transformation. How do I get the buy in from the organization? How do I script the changes that makes the organization to get to that end state to make it work.

- So, you’re saying is that I’m going to try to connect the two concepts together. So a system of delivery, is basically all the processes and rules and frameworks necessary to deliver the work. To work in the product delivery.

- That’s right.

- But to tie back to the business architecture thing, I would suggest that each system of delivery kind of implies, a business architecture. It is implies encapsulated teams that implies minimal dependency orchestration between teams things like that right?

- Set of competencies, I have technical companies, whatever, to all those layers, all have to exist at a certain level for that model, that reference architecture to work.

- So what we’ve seen right over the last 10 years of working together is that people are installing systems of deliveries on top of business architectures that are in congruent with a systems of deliveries. You get that?

- Yep, that’s exactly right.

- Okay, cool. So therefore, system of transformation.

- System of transformations, understanding what the business architecture, needs to be instantiated as, in order for the target system delivery to work. It’s really interesting, it then becomes what can I actually do today? What compensating controls do I need to be managing today until I can shift the organization to where it needs to get to.

- So let’s talk about that idea. That’s a great word. I was actually thinking about that word compensating controls, cause that’s something that I think Chris bill coined for us.

- I’m pretty sure we made it up.

- Yeah we made up most of the really good ideas And so pretty sure we made it up. So now it’s okay, Chris has actually come up with some pretty amazing stuff.

- Yes.

- I think we’re interviewing him next.

- Yeah.

- So talk to me like what’s a compensating control and how does it apply to Agile system of delivers?

- I’ll use safe big room planning as an example.

- Okay.

- Safe big room planning, works when you have a bunch of information sorted out a bunch of dependencies managed, a value stream can operate relatively autonomously, you can get everybody that has an interest in the next release, which is a really good value stream.

- Encapsulated value stream, dependencies are understood.

- Everybody understands the dependencies, that works. When, that isn’t possible, because the technology is too complicated or the compliance and regulatory group hasn’t completely bought in yet or because your funding model is different because you’re using third party vendors and things that you can’t get in the room. You have to add stuff to the planning to get there compensating controls. I can’t make this model work this way. So it’s a bunch of other stuff to make it work.

- So, it’s something that you add to the methodology to compensate for a condition that has yet to be created in the business architecture.

- Yeah, and it’s slippery slope.

- That’s not Agile. That doesn’t sound very Agile.

- Cause to add it, I want to add it with the intent

- Yeah.

- Of getting rid of it.

- Interesting, go a little deeper in that.

- I’m going to add all this dependency management on top of this team, it’s a reality today. But also you need to have a plan in my system of transformation, for I’m going to eliminate those critical dependencies that allow me to operate without the compensating control. Right?

- So let’s take a really simple right? So one of the things in Scrum that we’ve heard about for years is the idea of Scrum of scrums. And so a scrum of scrums is really kind of a compensating control for dependency management.

- Yeah, that’s right. I think mine and yours challenge with it, sometimes it becomes a late dependency, a late risk reduction strategy.

- If the lead time on my dependencies or my risks are longer than the planning cycle for the scrum team.

- Mm hmm. It’s a problem, It’s also difficult sometimes when you’re trying to plan strategy. If you don’t know until you’re done, what’s actually possible?

- Yeah. There’s a little bit of a feed forward that’s a problem too from a strategy standpoint.

- Yeah, my biggest challenge with and again one of the things I think that’s really interesting is that like when you have a chance to sit down with like Jeff Sutherland and Ken Shriver and those guys, I think they’re really smart and really pragmatic. And like I think sometimes as practitioners we lock in Scrum of scrums to be this really dogmatic thing I think they view it, I just want to be on record saying I think they view it as a more broad concept that’s smartly applied in very contextual ways. Right? But so like we’ve kind of implemented the scrum of scrums as like a product owner team concept.

- That’s right.

- Ideally, I would love each team to be operating independently but when there’s cross cutting concerns that have to be resolved across multiple teams and you know doing them late in the sprint cycle in a non planful way kind of creates chaos into the backlogs and creates late delivery and late risk reduction in the process.

- Yeah and late risk reduction, late integration leads to technical problems. There’s a vicious cycle.

- Yeah.

- That comes in with that as well. So one of the things, we just recently had a big client where they’re doing Scrum of scrums, and Scrum of scrums of scrums and the whole model executive meta scrums the whole sort of model, we took our governance model and laid it on top of it just to create some intentionality to the flow of value.

- Yeah.

- So the structure works, and the compensating controls of our model can enhance that.

- Right.

- To make Scrum of scrums work. It’s been interesting, the interesting dynamic has been but in Scrum of scrums, these teams should be able to operate autonomously.

- Well, I think Well, yeah.

- But they can’t yet.

- Well, that’s the interesting thing, right? So it’s almost like two angles that I want to go down. It’s like, like Scrum of scrums, sure, fine, but like I like Scrum of scrums is commonly applied. It just happens too late. Is there anything that prevents us methodologically from saying okay, we’re just gonna do early dependency identification dependency management.

- No.

- But in Scrum, right? Is it frowned upon?

- In Scrum the challenges, this goes on a whole nother interesting conversation.

- Sure. In Scrum, there’s this concept of delegating dependencies really close to the metal. So they can make them fast, really close to the point of contact. The problem is, if that dependency, we talked earlier about the Scrum Master, there’s certain things you can’t actually resolve.

- Yeah. if you delegate the dependency too low or too late in the system, then it actually slows the system down. Because the reality is that dependency can’t get resolved that low and that late.

- Right.

- So, we have to be intentional about where we put what we delegate decisions down to, so that it can be made appropriately.

- So, in a highly dependent system, one of the compensating controls is that we need more upfront planning.

- Yes.

- Than we would in a pure play Scrum environment. So how do you prevent that upfront planning from being waterfall?

- There’s a couple of different things. One of them is to set actual limit on how big any piece of work that’s committed upfront can be.

- So batch sizes?

- Batch sizes, smaller batch sizes. The other one is you have to measure the system, you have to like pay attention to it. And if you start to see batch sizes growing or there’s a balancing. Don Reinertsen talks about this optimal batch size, there’s some sort of thinking you can do about where the optimal batch sizes, and we’re continually through our system of transformation, improving organization going to make batches smaller. And optimal batch size should be getting smaller, I might start out with, six months is the smallest epic I can commit to in my system because it takes that long to get it through some very complex process.

- Okay.

- I want to get down to where in the future that’s three months, I need to put together a plan to do that, and change the rule on how big the batch sizes.

- So we understand that Scrum teams are formed around the business architecture.

- Yep.

- The business architecture initially has dependencies between them, which prevent us from oftentimes doing pure play Scrum or even to play safe.

- Almost inevitably and every place that we go.

- Almost any non trivial size, right? I’m sure there’s some small shops and small departments that is not as Agile.

- Or even like a website in a big company.

- Sure.

- Most of the high value things are there.

- Enterprise level transformation. There are going to be large scales.

- Yeah, that’s right.

- Manufacturing companies, pharmaceutical companies, large financial services companies,

- That’s right.

- Product companies, yeah. Okay, so a compensating control is in place. In order to be able to deal with those dependencies more forward planning, we don’t really want them. It’s not as Agile as we’d like to be. But we’re going to put in a compensating control to deal with those dependencies. Now within that context, right? Talk to me a little bit about what a system of transformation looks like, right? So how are we untangling that? And then also like managing the process of untangling it. Cause I think there’s a lot of fear that if you put in these compensating controls

- Will never get undone.

- They’ll never get undone right and it’ll stop us.

- That is the risk in a lot of organizations that we go into, our first our Basecamp one we talked about Basecamp one let’s create a stable team.

- Okay, so hold that thought right? So you’ve worked, let’s explain everybody what a base camp is.

- So the base camp is an interim step on the to an end goal.

- Okay, so we know where we want to be, we know how Agile we want to be.

- We know how Agile, we want to be based on how that capability has to perform relevant to the market.

- Yeah. So we’re so we can move at the speed of market,

- Okay.

- We can move the speed of our customers our market needs to, so we can be competitive.

- Okay.

- So how fast we need to be, we know what conditions have to exist for us to operate there.

- Okay.

- If those conditions exist, just start doing it. But very few organizations would go into does everything have the actual ability to operate at the speed that it needs to today? As a matter of fact, most people because the stuff is not well managed, through operating as sort of a heroic, chaotic, superhero sort of model of getting work done.

- Mm hmm.

- So what we talk a lot about is, let’s create stability in the organization and let’s balance whip to the organization as it exists today.

- Okay.

- We can do that really, really quickly. And throughput goes up, quality improves, clarity improves, trust improves, a lot of positive things that come from that.

- Stabilized staff or teams.

- Revise the backlog, or manage dependencies

- Manage dependencies where they are.

- Then we start to look at where can we economically improve what’s the next most important capability or type of work that we’re doing, that needs to get done faster. And we’ll start to decompose it into smaller pieces of work. So smaller batches pretty quickly, will start to do the technical things that allow us to get faster feedback, but still at a relatively big chunk, but we’ll start to Basecamp two is smaller batch size. But we’re still operating within organizational constraints, architectural dependencies, some competency limitations right?

- Yeah.

- Basecamp three is where we start to remove those things are not the process that we’re running or the way we break work down, but their architectural or organizational or compliance or contractual types of things that stops. We got to break those dependencies, so we can encapsulate a value stream that value stream move at the pace that it needs to be competitive, right? So there’s like an inevitable ordering of that. The risk is a lot of times when an organization get to Basecamp one, is starting to Basecamp two. And it’s so much better than it used to be.

- Mm hmm. That they forget how fast they have to move to go be successful in the market.

- Yeah.

- There’s so much faster than they were.

- Right.

- So there’s the risk of incremental stuff, it’s reality.

- Well, there’s like two places my brain fork while you’re talking about that. So like, the first one that I kind of wanted to say was, it was fascinating, cause, when we initially rebranded our website, eight, nine years ago or something. We came up with this kind of like hiking, outdoors metaphor, things like that. And so you and I were sitting at my conference table one time, and we were using the word phases, the describe phase of the project, and you’re like, Mike, this word phase is overloaded. We’re confusing our clients. They don’t know if it’s a phase of the engagement or if it was a phase.

- There is a system of delivery phase, the system of transformation?

- Yeah. So as I recall, and I might be, there’s some risks that I might be making the story a little bit more dramatic than it was but like, I remember getting annoyed. Cause I’m like, screw that, right? It is what it is and it’s clear and people need to get over it and stuff. And I think I went and ran 30 minutes.

- Yeah, you excused yourself.

- And I’m pretty sure I came back with a vodka martini. I’m not 100% sure.

- I think that’s also likely.

- But then we came back on base camps, right? Because that kind of implied that you’re going to make it to a like a known state. And you’re going to acclimate for a little bit, and you’re gonna make it to the next state and you’re going to acclimate it for a little bit.

- And then we started going down to language about expedition.

- Yeah, that was the next one. Once we had base camp, I remember the debate being is an expedition, the trip itself, or is it the group of people that make the trip.

- And we understand now that it’s a group of people that make the trip.

- It can actually technically be either, but we decided to say, okay, it’s a group people make the trip and we call it like a trek, right?

- Yeah.

- So we’re like, yeah, we’re being brand consistent across this thing. So it’s actually kind of interesting. When we go into a client, they’re using the expedition Basecamp metaphor. I think that’s fairly powerful. The other place that my brain went that was interesting is, you talk about value stream and organizing around value streams. I think one of the things and I’d love you to comment on this, that we’re seeing in some of the large clients, is that it’s almost impossible to organize around value streams.

- Yes, it’s complicated than that.

- When, they first start,

- Yes.

- Because all of the value streams intersect through the same capabilities.

- That’s right. And so one of the patterns that we’ve been observing is that you organize around business capabilities first, cause that’s actually easier to untangle.

- That’s right.

- Then you orchestrate the value streams across the business capabilities, understand where your constraints are. What’s cool about it, right? This is starting to emerge from our work is that is once you do that, you see where there’s overlap, you see where there’s redundancy, you start to see things that go together.

- That’s right.

- You can actually reorganize and group business capabilities that tend to work most often together, into value streams.

- Yeah.

- So it’s fascinating, right? So the industry staying organized around value streams, but there’s actually intermediate states necessary to get the shared cognition across your organization.

- Yeah.

- And that happened, right? It’s fascinating.

- Yeah, it’s actually correct. We need totally autonomous teams, totally agree.

- We love and be organized in action, love it. Yeah.

- It isn’t that easy yet.

- Yeah.

- So, what is it gonna take for us to get there? But it’s really interesting, coming with an architecture background, we’re gonna refactor the architecture at some point like we know between Basecamp two and Basecamp Four if we get there. They’ll have to re architect the design of the teams that is it the orchestration, we’re gonna obviate the need for some of the managing of dependencies and then the some of the forward planning. Cause it’ll make us able to operate more tightly and then we’ll we need to eliminate those once we’ve made them unnecessary. So we’re going to refactor some part of the organization one of the things we ran into at one of our big financial services clients is getting the mainframe to Basecamp Two. And then selectively moving pieces.

- Yeah.

- Up the curve. Cause whole mainframe doesn’t need to go up the curve, but some of the stuff needed to move really fast to be competitive in market.

- Yeah.

- But how do you get the money and time and trust and everything the organization to make it happen? So I’m gonna fork a little bit here.

- Okay, cool, go for it.

- The way that they operate historically, that decoupling and refactoring of the platform could never be absorbed into the cost of a project. Every individual project had to have the lowest possible cost with the highest initial ROI. But once we formed our own capabilities made somebody own those different sets of capabilities. Now I’m responsible not just for shoving the next project out the door at the lowest possible cost. I’m responsible for making this capability perform right.

- So it’s like a Conway’s Law.

- Conway’s Law. So the organization starts to care about the business people, the people that are funding the projects, start to care about paying for the refactoring, paying for the technical, if they want to.

- They want the performance of their business capability to be better.

- And it’s a business class problem, not what you should have designed it away in the first place. You should be operating that way anyway, why did you build it wrong in the first place?

- So this is what I think is fascinating, right? And this is what I think is part of the power of what we’ve we’ve discovered, right? What we’ve uncovered over these last 10 years is that we always talk about how do you get the business more engaged and like the the collected wisdom is well, you want to make sure every team has a product owner on it right? And that product owner is the voice of the business. I don’t think that is a pattern that works, right? It’s not sufficient. How you do is you make the business responsible, like that business capability, encapsulate the technology and make them jointly responsible for the performance of that business kit.

- That’s right. It’s a p&l around a little business in a general manager sort of concept. It was the technology and the process and the competencies and the rules and regulations that lie in all of it.

- Yeah, it’s fascinating, right? And so which kind of begs the next question, one of the things that you’ve been talking about for at least a year now is the idea that transformation work is is often not being funded out of IT anymore. Talk to me a little bit about what you see changing in the market right now.

- Of the four, we started seeing this probably like a year and a half, maybe two years ago. Where IT feels like they can do Scrum, and they’ve solved the problem for what they’re responsible I can now kind of accurately deliver software. I have enough orchestration that I can be responsible for. They’ve isolated themselves from the problem. The business is going, but I’m not getting what I need out of it. So I need to be able to make sure.

- So we’ve actually, like fixed the engine, we’ve gotten it performing, but it’s kind of taking us to the wrong place.

- Yeah, I’m not able, I don’t have enough influence or control, I don’t know, I think the real answer is, I don’t know how to exploit this new engine.

- Yeah.

- In an effective way, because I’m used to operating this way.

- Yeah.

- They seem to have like, did all the things that they said they were going to do. But we’re not really getting the benefit yet. So on the business side, we start going, Okay, so let’s talk about how you can start to exploit this engine to compete in the market to leverage this way to play that way. Let’s start talking about you can build trust with IT. So you’re not funding technical debt that clogs you up next year, right? How you become responsible for owning that. So the business now and three of my four clients, three of my four clients are all being funded specifically from the business side. Take advantage of the technology delivery.

- Well, this isn’t important topic, because the one of the questions that I get asked out speaking at Agile conferences is how do we get the business to be engaged right?

- So you’ve got several clients, where the business is engaged. Maybe the question I’ll ask is how do you keep them engaged? What do they care about? what’s valuable to the business?

- Yeah, so the challenge has been and probably still continues to be, flipping the conversation from a how good are we at lead timer, scrums or defects as like that to, how many dollars are we getting back into the company? How many customers are we retaining? How cost effectively are we solving? Becomes a capability outcome conversation rather than a technology company but until we got the organization sort of stable, it didn’t matter. You couldn’t you couldn’t deliver on a capability outcome.

- So there’s a chicken in the egg problem. It’s like and this is like a little bit of the debate that we’ve had over the last couple years with Scott Sal Horst and you, it’s like, product people show up and they’re like, well, we have to make sure that we’re we understand our customers. We understand personas, we understand what the market wants and all this different stuff. And then on this on our side, like our historical side is Leading Agile, but you can’t produce anything. So what does it matter right?

- It doesn’t matter.

- So it’s like, on the one hand, you almost have to unlock the system, so it’s capable of producing something.

- Yeah.

- And then you’ve got to figure out how to exploit that system, to be able to advance your product and market in a way the customer will buy.

- Yeah, I have no ability to learn anything and adapt, because my delivery system is so locked in. My 18 months of roadmaps are locked down, there’s no way to learn and pivot. We’ve now fixed that, the business doesn’t really know how to leverage it yet. They’re still trying to shove giant things in or they still have the the collaboration is not there. So we’re fixing that. on the business side of our organizations now. What becomes really interesting about it is that it’s a much healthier conversation. Conversations that used to be really threatening, okay, you’re not going to get everything you asked for in the timeframe you want it. So let’s sit down in the way that we now do this thing and come up with the smallest thing we can possibly deliver in the next 90 days.

- So I’m gonna build an argument here, right? So you’ve got the business architecture, right? Which is basically the business capability, it’s supporting technology it’s people. It has performance characteristics.

- Right.

- The business owns those performance characters.

- That’s right.

- And so the alignment between IT and the business is basically creating shared accountability for the performance of that capability.

- Yes.

- So then, now we’ve got shared alignment at the execution level. And I imagine there’s something you do with the program level, the portfolio level and the strategy level, to make sure that, that kind of zippers all the way up and that the business is connected all the way through the stack.

- There’s some language that started becoming sort of well known in the industry probably five or six years ago, it really goes way back to Intel I managed by objective something, it’s Okr’s objectives and key results. It was a fascinating failure sort of thing when you did it, the organization couldn’t respond. So it’s not the right place to start. But once you get the system working, it’s probably necessary to create clarity up and down the stack, to align everybody to align all those different interests around outcomes. You got to make those be very explicit. So it’s interesting, it’s like the technology problems, just now a step further removed. It’s not that we don’t want to start with technology. It’s until I have stable teams that can build a backlog. I can’t take advantage of good technology, good technology is absolutely critical and key.

- Yeah.

- To be successful, Now I got good process, got some pretty linear around technology. Now I’ve got to be able to point it at the right thing. And in reality, it’s nowhere near that linear it’s like layers, layers.

- Yeah, well I was gonna say because we initially kind of started talking about the base camp model, right? We have base camp one, two, and we talked about the idea of stabilize the system, reduce batch size, break dependencies, invest in capability based teams, right? Innovate, those kinds of things. But what we’ve kind of learned, is that while you’re stabilizing the system, there’s things that you need to be doing to lay to start developing conceptual shared understanding on the product side.

- That’s right.

- There’s technology things that you have to be laying down.

- That’s right.

- Cause as soon as you stabilize the system in order to reduce batch size, you’re gonna have to deal with release management. You’re gonna start having to branch robotic ideas up into smaller pieces, right?

- Yeah, and you can’t do it across an entire enterprise, it makes sense to invest in move, this 10% of your organization cause that’s where you really have to be fast to compete.

- That’s where the expedition idea came.

- Let’s take this slice and here’s this journey, and its journey is gonna be a little bit different than this slice his journey. And this one’s not economically viable to go past Basecamp one or two right now. Yeah, so that’s that, that’s all system of transformation type stuff.

- So talk to me a little bit about like how do you create shared cognition across a client organization to get everybody with their head around? How do you incrementally and iteratively transform this enterprise? What are the things you do?

- That’s a tone of the power of just the language of, if we can get agreement on capabilities or products or the things you want to form the organization around. And then we have our quadrants and we can talk about where does it actually need to live to be competitive in the market. And then we can talk about what are the constraints that exist there. The organization, like in our two day or defined the end state sort of workshops. Six, eight weeks sort of work out there, we can get an organization across the board to kind of go, Oh, you know what, we’re actually operating at zero, we probably need to be at three, here’s the things that block us from getting to three, here’s a path from the scripts to get us there, you can build a pretty clear plan.

- Mmm mmh.

- To help the organization move, and then you can sit there and go and have all hundred things in your organization. These are the 10 next most important ones to move and one of these other 90 to Basecamp, once we’ve kind of done a scripted way, that the understanding of simplification of the metaphor, the whole model. Allows us to get a lot of buy in from the organization.

- So we do something that I think, is fairly controversial in our industry right now, right? So, we’ll take we’ll take a big organization, we’ll break it up into smaller pieces called expeditions, right? We’ll run them through these intermediate states called base camps. The base camps will have intermediate outcomes.

- That’s right. That we can start to measure progress towards What we found is that there’s kind of a standard set of activities and kinds of things that have to be done on every engagement to move an organization forward. It starts to look a whole lot like a Gantt chart. So talk to me a little bit about why isn’t that more emergent in practice?

- Well, I think there’s a couple of parts to why it’s not emergent. The first place, there’s just some physics, how organizations work and how organizational dynamics and where, where people are. There’s another part that’s important. To intuitively figure out how to navigate that very complex script from where you are to where you’re gonna go. It takes a genius with 100 years of experience, they could do like a very tailored path through that.

- So saying 1000 people self organizing are not going to just randomly come up with that approach?

- They’re not going to come up with that approach. So what we do is we go, there may be some inefficiencies for these two teams to go through our scripted sort of path.

- Mm hmm.

- There may be some inefficiency and maybe we can do something for those to make them move a little bit faster. But all the rest of organization, I need management understand where we’re going. I can’t go hire all 20 year experience. Scrum organizational change people coaches.

- I think even if you did, I think they would just all get in the room and fight with each other.

- So even if I could get them, I can’t align them.

- Yeah.

- Right? And the constraints are not within the teams that constraints are in the fabric of the organization.

- Yeah.

- It’s getting the fabric of the organizational and is creating conditions for those teams to even operate that way. And so some of what’s happening while the scrum teams are forming, we’re solving, the program team stuff or the product owner team stuff in a relatively coherent way, because they have to manage dependencies between each other. And we’re forming. We’re solving the portfolio thing more broadly. We’re creating the conditions for those Scrum teams to even be successful.

- Yeah. So talk to me a little bit about in one of the talks that have given over the last couple years, I talked about two different kinds of metrics. I would call transformation metrics and then like business performance metrics. So on an engagement, we will talk about, how do we know that we’re doing the things we said we’re going to do right?

- Yes.

- And getting to the outcomes that we want versus how do we know that’s actually improving the performance characteristics from a business perspective of the organization. Talk a little bit about how you measure those two different things on an engagement.

- So one is measuring the system of delivery, and one’s measuring the results of the system of transformation. So on the system of transformation side, I have observable things I can see a team do. There’s a slippery slope on transformation stuff. I’m not measuring how many people I’ve sent Scrum masters to Scrum training.

- What’s kind of a vanity metric.

- Yeah.

- I’m looking how many people know how to build a backlog? How many people know how to put it in the tool? How many people might have produced their metrics? So they can measure. How many people not making keep a sprint plan? Like we have to actually stabilize velocity, can actually bring their dependencies to a release planning event. Now they’re stable velocity and negotiate to the release plan. There’s a really clear sort of set of measurable, definable observable outcome.

- Things that have to be true no matter what.

- That has to be true to get there. So we’ve laid that out. And some teams can move fast, some teams can move slow, but I can sit there and put up on a board and go, Mr. CEO, in this party of the organization, these eight capability based teams that were critically important to you are now good at these new things. And I can show them because I can observe it, I can observe it, I can look and I can show you their predictability metrics are there, the responsiveness metrics are there, the quality metrics are there. And so we’re getting the result and changing the organization that we said we would.

- Yeah.

- Now it’s one sided thing. On the other side I want to look at and I want to go Okay, so am I able to keep making promises to my customer? How many times have we signed a deal with a customer that we delivered on time? How many times that I shipped something to the customer that broke? How many times how am I improving my actual lead time and delivering to the customer? How am I getting more frequent time to catch them, reducing my time to cash, so there’s a set of business metrics that are very observable. But they’re not lead time by how fast a scrum team spins. They’re measured by how frequently and cleanly we can put product in the customers hands.

- I’m not sure how familiar you are to this but one of our larger clients is a rally ca customer So called rally. It’s like I’m old school.

- They call it rallier.

- They call it Rallier? Oh, fascinating, okay, cool. So being a v one guy, I didn’t grow up in that ecosystem. But apparently they’ve got some performance metrics like industry.

- FBI.

- And you can actually start to see, as a result of some of the things we’re doing, how these teams are performing against, like predictability, batch size, making meeting commitments, it’s gonna need space.

- It’s actually kind of breathtaking.

- Yeah.

- How well it’s working at scale.

- Yeah.

- With this model, it’s like the percentages of teams that are moving up way above the norm.

- Mm hmm.

- Or it’s extraordinary.

- Yeah. So it’s interesting, right? It’s like if we can if we can stop being so myopic and say that, everything has to be emergent, just teach people Scrum, let them self organize. If we can get our head out of that world and recognize that, we’re basically re architecting a system so teams can operate independently. But the performance characteristics the architecture that organization is not emergent right? That can actually be designed very thoughtfully to create a performance enterprise. It’s pretty cool.

- Yeah, it should be.

- Yeah, awesome. Okay, so let’s talk a little bit, we had a fascinating conversation. So this is like, totally, like hot off the presses. I was like, blown away, when we were on the call this morning, talking with Chris about this third leg that we’re starting to deal with in some of our engagements around. I think we’re like, for lack of a better word system of sustainability, right?

- Yeah.

- So we’ve used the system of transformation, to in effect install a system of delivery. But we also know that to some degree, that organization is going to be dynamic and continue to improve. So as strategy changes, different business capabilities are going to light up in different ways. As you’ve reorganized capabilities into value streams, the performance of those, those value streams are going to ebb and flow. As you deal with constraints in different parts of the organization.

- And your understanding of how you’re going to be competitive in the market changes, you’re going to want to light up different capabilities.

- Yeah.

- Performance characteristic image.

- And it’s fascinating, right? So it’s like if you if you think about it, it’s not only insufficient to put in a system of delivery, you have to understand how you’re going to put it in. And then you have to understand how is it going to evolve? Because it’s not going to be static over time. So talk to me a little bit about your thoughts, because I think this is the future of like a truly adaptive Agile enterprise.

- Yeah, there’s some of the language has been very interesting to me, is, if a scrum masters job, is to protect the organization from management, so the scrum team can be effective.

- Yeah, we’ve probably already failed.

- Eventually management’s going to win.

- Yeah, they are right.

- So part of building a sustainable system is getting management to understand how to exploit and leverage the system. Getting business to want to use IT, in this new model to get outcomes they couldn’t get before.

- Sure.

- There’s a tone of first off just teaching, creating awareness and a desire on the part of the people That sometimes fight with a system today, that they want this new system to exist.

- Mm hmm.

- So that’s probably an ongoing part of sustainability, is getting management leadership to want to follow it. There’s an important aspect, in which is how do we then measure our performance of how the system’s working, to identify where it’s slipping or where it’s changing? Where the need is changing? How do we go and look at the performance characteristics and measure it. So I need I need the ability to look at my organization understand where it’s not performing, but not at the individual process level. We had an interesting conversation this morning about BPR versus Six Sigma versus some of the competency based things. They were they were looking at the at a micro lens, because organizations weren’t designed in a way they could look at it in a macro lens. So when you start to get these things pulled together relatively autonomously start to understand the network, start to really leverage the business architecture. All the things those guys were doing, we’re probably useful but because the organization wasn’t up to exploit it.

- So I’m going to go down a rabbit hole for just a moment, give me a minute or two on this. And I’m going to speak something into the universe that I think is like super important. So you know, I do a bunch of university Florida guy, and so just for the record, Dennis is a floor state guy, So there’s a day a year we don’t like each other.

- I’ve learned to respect Michael .

- Yeah, I appreciate that. I mean, it goes both ways. So some University of Florida guy and so I do volunteer work down there and work a lot with the College of Industrial and Systems Engineering. And what I think is fascinating is a lot of these industrial and systems engineers, when they go through their internships and they get their early jobs, they’re looking at like how to process improve something small, and then they process improve something big right? And then they might have an overall process improvement kind of thing. But, I think there’s an interesting frontier around taking the discipline of Industrial and Systems Engineering, and in applying it to software organizations. Like what is the software factory look like? Right?

- How do you re engineer it? How do you optimize the plant floor, when the plant floor are thousands people sitting in cubes looking at computers. And it’s essentially invisible if you don’t understand it.

- Yeah, sure.

- Exactly right. And, so this is why that business architecture lends to me has always been important.

- Yeah.

- In a way to look at it, but you have to teach management. This is about what does good performance look like in a big organization today? And is it the line manager who manages his budget, make sure there’s people shopped around like, like, the things are performant, today, those are probably still important, like we can’t just spend money, but are we really getting the results that we want. If I can go spend that money and deliver the outcomes I’m responsible for in the network thing of I never miss a dependency from my capability that blocks anything of value to another group. If I am achieving, the business outcomes, the business capability outcomes, and reducing my cost and improving my adaptability within my group, but I’m doing it in a way that it releases more value for the whole organization. Then I’m being successful, but I don’t think we look at that we don’t have a lens to understand that. We were just reading an HBR article earlier this week about how most organizations feel like they’re pretty well aligned in silos. But 92% of managers feel like they can’t trust their adjacent silos any more than they can a vendor, they haven’t paid yet.

- Mm hmm.

- So they still can’t get anything out the door.

- Yeah.

- When we start to get the organizational wind through our get our system of delivery in place, and it’s aligned that way. We can teach management how to run it, will start to solve those types of problems.

- Yeah, it’s fine.

- So yes, there’s layers that how do we teach managers to run this new organization? I think it’s a system of sustainability.

- So I have a hypothesis, last theme that I want to hit you with and get your thoughts on it. So um, I think a lot of what we’ve actually built is, less a Agile transformation framework, although it is very much an Agile transformation framework. But it’s more a generalized change management framework. Talk to me a little bit about that. Where do you see what we’re building going?

- The tools and techniques, the ability to get people to change, to be able to get management to buy in and follow a process, the ability to measure what has to happen, break it down, decompose it, create the change. You look at the different change management cycles, the the cotter sort of eight steps and you look to add car, individuals for organizational change, individual change models.

- Mm hmm.

- Those things are probably inherently true, regardless of what you’re putting in the ground.

- Yeah.

- So, applying this model to rolling out some manufacturing, changes in your manufacturing process, or, what we’re doing with our big compliant, with our big pharmaceutical client right now is we’re changing, their compliance organization dramatically. Their human factors, their FDA compliance or regulatory group, work changed that organization dramatically in a way that’s never happened be fore. And it’s not because we’re applying Scrum in sprints. It’s because we’re we’re applying our Let’s focus on getting to value. Let’s look at what the constraints are to the capabilities movements that they need to. How do you guys interface, what do you need to be successful? We’re applying our change model things outside of.

- So when you start to look at it as business capabilities that get orchestrated across, value streams or product areas or things like that, it becomes more generalized. So we’ve historically applied it, into software and IT organizations, but I think it’s fascinating watching it, because now we’ve taken this business architecture view of it, that it’s actually more generally applicable.

- That’s right.

- So one of the books I read probably 15 years ago, then I’m actually rereading right now is that I think it’s Chip and Dan Heath the switch.

- Yeah.

- Where you have the, it’s so it’s fascinating, So you the elephant, the rider in the path. And so the rider is like the cognitive understanding, the elephant is the emotional, like, I just got to get there because it’s super important kind of a thing. And then the path is like the guardrails, right? And so I think about what we do, and like how some of that is, so deeply entwined, right? So, absolutely trying to appeal to the intellect, but to try to create that emotional gloves on the table, like, it’s data, it’s important, it’s moving the industry. But then also, like giving enough guidance and structure, and it’s for how to get there. And it’s safe. Because that’s the thing, I think people underestimate, how scary it is to do this stuff, right? And to tell somebody, you’re smart people, you’re close to the ground, just figure it out. Because that’s going to conflict with each other. They have to fight, they have to put themselves at risk, all that stuff. And so one of the things I think is really interesting about codifying some of this stuff is that, it creates a tremendous amount of safety to get people started. Maybe it’s not ideal, maybe it’s too much of a compensating controls. But I think it’s moving people in the right direction.

- And I think the other thing that’s critical about what we’ve done, it’s applying the whole model. We’re also getting feedback about whether you’re heading in the right direction. So you can adjust if you’re on the right track.

- Like how would you know like, okay, we’re just trying to teach a bunch of people Scrum, like houses.

- Just go figure it out, just go do your best. On all the right things, it could be at odds with each other, right? But if this is what it means to be good at this, and this is what it means to be good at that. And this is what it means to be good at that. And I can measure that. I can turn that into a set of 10 steps. Things I need to have to be true.

- Yeah.

- For me to be good at that.

- One of the things I always ask people, is I go, so let’s say you’re a king for the day, you could change anything you want, like you’d snap your fingers and change anything. What would you go change?

- I get management to support the transformation.

- Well, yeah, right?

- So what everybody wants is, like they want to overcome the cultural resistance. And so what I think’s fascinating is that, once you take that off the table, there’s not a lot of people that know what to go do.

- That’s right.

- What do you specifically go do? Okay, Joshua, you want to go do the technical practices, like, where do you start? How do you start? If it matters, that you’re actually able to move the needle in three to six months, like in a measurable way, like do you do? And most people don’t, have that answer. And so I’m actually really proud of this. So we’ve actually kind of figured some stuff out. It’s pretty cool.

- And while we’re still learning,

- Yeah.

- It’s working pretty well.

- Yeah, for sure. Well, thanks for joining me, Dennis. This is an awesome, time man.

- It’s great to see you.

About Mike Cottmeyer

Mike serves as LeadingAgile’s resident champion of core agile values and principles. He is passionate about solving the challenges associated with adopting agile in larger, more complex enterprises and is passionate about leading large-scale agile transformations. Read More…

Originally published at https://www.leadingagile.com.