Balancing Company Culture: Why Results Come First

Culture change is largely driven by the values of the person or people who are leading the change. But what happens when those values aren’t aligned with what the business is trying to achieve? Is the business to blame for getting in the way of culture? Or does it start with the people? The reality is that you need to strike a balance between culture and results. But, to understand the balance, you must understand others and yourself. Watch this video to find out how we’re using personality profiling to help us better understand the dynamics of company culture and how we’re applying that knowledge to help our clients get better, more Transformative results.

Video Transcript

Culture seemed like it was something that was really all over the place. I didn’t know how to label it. So the words that I would use are like trust, ownership, empowerment, responding to change, being adaptive, being emergent, safety, teamwork. Those are cultural attributes that the people that I was talking to in the agile community were prioritizing for. The idea again, was that if we could do those things, we could build the right products, we could get faster feedback cycles, we could get better attention to quality, we could get early delivery, we could get predictability, we could get efficiency, we could get lower costs, we could get innovation. And again, I couldn’t make the mental leap as to how those things, those cultural attributes of the organization were going to lead to greater predictability, cost savings, getting things in market faster. The epiphany that I had is that how we view culture is often driven by our personality type.

I’m going to try to make that case here for just a minute. And so we’re all not binary, so we have different preferences and we’re all different blends of different things, so it’s very seldom one or the other. What we’ve got to try to do is we’ve got to try to create organizations that take all of the different aspects of culture into consideration. What’s neat is that we can assess ourselves and we can understand what we value as people, what we can talk about is what we value in the workplace, and then we can explore how the systems that we put together are going to enable people with different personality types to really work together effectively.

Preamble, Introductions, and Text for Deck

What I wanted to talk with you guys about today is a topic that I’ve been noodling around on for about 13, 14, 15 years in the Agile community. I got introduced in Agile back in 2002, was working in some pretty large complicated financial services, software products, and we were doing a lot with Agile, but we were also doing a lot with the rational unified process. We were doing a lot with traditional project management. I kind of grew up in project management, and so my focus was always a little bit around this idea of when are we going to be done with the work? And when I started getting deeper into the Agile community, one of the things that I would hit a lot was the idea that we have to change the culture in order to be agile. Excuse me, a little bit like Lisa was talking about this morning, the idea of being agile versus doing agile.

So, over the last 20 years I’ve been really wrestling with this because as an entrepreneur and an owner of a business, I recognize that culture is a huge part of a company. And if you don’t have a solid culture, you’re not going to do well. But the challenge is, is that I couldn’t quite figure out the bridge between how culture actually produced better results. I just couldn’t get my head around it. And so there’s the Peter Drucker quote that says something like Culture eats strategy for breakfast. And I would wrestle with that and I’d be like, well, I mean what was culture, right? Is it how we felt about going to work or was it how we interacted with the people around us? So I’ve been on this quest a little bit. So what I’m going to do in this talk is I’m going to really start with the end of the story and then I’m going to end with the end of the story.

So, I’m going to tell you the end before I get started. First of all, if you’re interested in getting a copy of the stack, you can text the word culture to that 800 number 8, 4, 4 number, and my team will text it to you. That’s my contact information if anybody would like to have it.

Starting with Systems to Transform Your Culture

So we’re going to start with the idea that a functioning system, a functioning system of delivery, a functioning operating model in an organization is a predictor of the kind of culture that you can actually get. I’m basically saying the fact that if we don’t have an operating model that produces results, it’s very difficult to have a culture. In the early days of my company, this lady that worked for me is my COO, and she said something, apparently, I was having a bad day and she said, if you don’t stop acting this way, you’re going to ruin our culture.

And I said, well, if we don’t start delivering some services, we’re not going to have a culture to dismantle. So there’s a balancing act between these two things. We have to figure out, we have to figure out how to get the performance of the organization straight so that we have a safe place to have the kind of cultures that we want. And so the way that I started unpacking this probably 12, 13 years ago, was this idea of what I call systems first. And what systems first means to me is that if we can get the teaming strategies, we can get the governance models, we get the measurement and control, we create the possibility for Agile to do really, really great things in your company. And what I was somewhat reacting to again was this notion that if we could somehow get the culture fixed, everything would just snap into grid.

Now you remember the kinds of systems that I grew up in were 40, 50-year-old legacy mainframes, monoliths, things that you had to do testing on for months because if you made any change, you could break something else. And so everything in the agile world was really about this idea of teams and collaboration and sticky notes and fun and all this kind of stuff. And I, again, couldn’t see quite how that was going to help me deliver my legacy monolith more quickly to market so I could put software out there. And so I think what the hypothesis around that is, is that if we get the culture right, that the necessary changes will start to emerge and they’ll start to happen. But it reminds me a little bit of that cartoon that was popular, and I keep telling myself, I’m going to add this to the deck.

And it’s like two mathematicians or scientists sitting at a chalkboard and there’s a bunch of math on one side and there’s a bunch of math on the other side, and then it says, then a miracle happens. And then the caption of the comment is, I think you need to be more specific in step two. So this talks a little bit about let’s figure out how to be more specific in step two if we really believe that culture is the thing that’s going to get us there, what is the mechanism by which that happens? And I think that’s a little bit of probably what this talk is. If we truly believe that culture is paramount, how do we create systems that create the kinds of cultures that we want? The other thing that I react to a lot in the marketplace of ideas and the agile world is the idea of practices first.

Now it’s very explicit in the Scrum world that you form a team complete cross-functional team. They work with the product owner, they produce a working test and increment of software at the end of every sprint, and then any impediment that the team comes up with, the scrum master helps them remove it. Well, when we were doing that, the impediments that I was coming up with were again, these legacy architectures, these organizational structures, these governance frameworks, these metrics and controls, the audit and compliance. That was the stuff that was getting in my way. And so what I was finding is that that Scrum was working great at the single team, small project level, but it wasn’t doing great things for us at scale. We weren’t able to remove the impediments. The leaders were saying, fine, go to Scrum training. I don’t care if you do Scrum as long as you deliver the project on time and has all the features and you do it on budget.

So I don’t care if you use Scrum to do that, but it wasn’t giving us the business benefits that we want. So what leading Agile did, what we decided to do was go down this path of taking a business architecture focused approach, the idea of domain driven design, looking for opportunities for encapsulation and the presence of dependencies where dependencies exist. We want to manage those dependencies until we can break them. You kind of have to either manage dependencies or break them. Some of the things with Safe have come along and given us some language around dependency management, which has been positive for the industry. But again, all three are essential. You have to have a solid culture, you have to have solid practices. But if we don’t have the underlying solution architecture, the underlying system of delivery, the underlying operating model in place, very, very difficult to get all the other stuff working.

So that’s the end of the story. So now I’m going to take the long way around a little bit.

What is an Agile Culture?

The first thing that I would encounter a little bit is I would read books on culture, and I would talk to people on culture. And culture seemed like it was something that was really all over the place. I didn’t know how to label it. So the words that I would use are trust, ownership, empowerment, responding to change, being adaptive, being emergent, safety, teamwork. Those were cultural attributes that the people that I was talking to in the agile community were prioritizing for. And the idea again was that if we could do those things, we could build the right products, we could get faster feedback cycles, we could get better attention to quality, we could get early delivery, we could get predictability, we could get efficiency, we could get lower costs, we could get innovation.

And again, I couldn’t make the mental leap as to how those, those cultural attributes of the organization were going to lead to greater predictability, cost savings, getting things in market faster. I couldn’t make that jump. So then I started thinking about, well, who’s responsible for an agile culture in the organizations that we were going into? Was it leadership? I think a lot of culture does come from leadership and what they value and what they prioritize for in an organization. The teams definitely have a culture. The other thing that’s pretty interesting is that our customers have a culture and they interact with us in different ways.

Most non-trivial kinds of companies and applications we work in have external providers. And sometimes the question we’ll get is, well, how do we do Agile if our partners are doing waterfall? So what does their culture look like and how does their culture impact us? And then the last one is the organization who’s responsible for it within the organization?

Four Ways People Think About Agile Culture

So earlier this year, so I’ve gotten to do this talk and it’s evolved each time I’ve done it. I got to do it in Raleigh, North Carolina, did it in Detroit, and then I got to go to Belgium, bruises Belgium and to do the talk out there, did it and did it in Indianapolis. And now I get to come here and do it with you guys. And every single time that I’ve done this talk, I’ve kind of learned something new of how to have an interesting pivot.

But what was interesting and insightful to me, I didn’t even know it was that interesting. I didn’t think it was that interesting when I first thought about it. But at leading Agile, we do a lot with personality profiling. And so it’s part of our hiring process. And so what we need to do is we need a predictive way to help understand how people are going to show up when they join our company. So we have several instruments that we give to people, and one of them that I like, which is kind of interesting, which I’m going to talk about, is something that nobody’s ever heard of. It’s built on the same underlying theory as the disc profile, but it’s called the Color code. And what I like about it is that the language is very accessible, and in my opinion, it’s a way of approaching the people in the room and getting a handle on who they are without actually them having to do personality profile tests.

Most of the time when I do these things, I use my wife and kids as Guinea pigs, and so I get them to do the personality tests, and then if it matches and holds up, then I go like, okay, that’s kind of cool. And then I do my leadership team, and then we do different people in the company. And if it kind of carries water, then it’s something sometimes that we’ll bring in. So we have three or four of ’em that we use. And so the epiphany that I had is that how we view culture is often driven by our personality type. I’m going to try to make that case here for just a minute. And so we’re all not binary, so we have different preferences and we’re all different blends of different things. So it’s very seldom one or the other. But when I started doing this color code on people, it’s basically two axes.

It’s an emotional logical, and it’s controlling non-con controlling. And basically what that means is that if you’re emotionally controlling, that sounds bad, but it’s not bad in this assessment. It’s not like you’re controlling. My wife is emotionally controlling. She wants everybody in our family to be okay and to get along and to have intimate relationships and connections and love each other and stuff like that. She works really hard to do that. And so people that are blue, they prioritize for intimacy, they prioritize for connection. And then the next one was red. And so the last rev of this talk, I just did red and blue, and then as I sat there and noodled around on the red and blue, I’m like, well, maybe I could look at the other colors as well. And this instrument, the logical controlling is red, right? It’s power, it’s control.

I was thinking about Lisa’s talk this morning around the masculine and the feminine. I think there’s probably something there, right? There’s kind of a masculinity and a femininity that we all express differently in our people humanity. And so what I was hypothesizing was that if you are dominant red, then you are going to prioritize for getting things done, hitting dates, having everything under control, making sure that things are going to happen. I’ve been accused through my life of being a bit of a control freak, but it’s like I want our company to be successful. I want our family to be successful. I want to make sure that we have money in the bank and that we can pay our bills and that everybody’s getting an education. And I have plans and I run those things out and I don’t take a lot for granted, and I make sure that everybody’s okay.

So these are not negative expressions. They’re very positive expressions. They can be negative, but more often they’re positive. And so we have this idea of emotionally controlling. We have this idea of logically controlling. Then when we go down to the bottom, we are more on the non-controlling spectrum. And so non-con controlling is kind of fun emotionally, non-con controlling is fun. We want to have lightness people. Creatives tend to be very high on yellow in our company. They’re often unstructured. They don’t necessarily want to play by the rules. They like to exchange ideas and solve problems, but they’re not necessarily trying to get things done on time. And so if you look at my primary split, I’m like 75% red and basically like 20% yellow. And I call myself an invitation to participate. And so at Leading Agile, I go, okay, this is kind of what we’re doing.

I really want you to love it here I do. I care. I want it to be a great environment. We throw rock concerts and do all kinds of different things, but if you don’t like it, go find someplace that you love to work. That’s my general disposition. Whereas maybe somebody who is more on the blue side would be more like, I really care if you love it here because I want you to love it here kind of a thing. It’s just a different tone. And so the yellow is fun and the white is peace. So just an interesting fun fact with this personality assessment. I’m red yellow, my wife is white blue. We’re considered non complimentary opposites. So my wife wants intimacy and peace and wants everybody to get along and follows the rules and everything. And I’m like, let’s just go, just figure out start companies, go on trips, do different things, go skiing, whatever.

So I’m kind of the more out there. And so this epiphany, I didn’t think that there was a whole lot to this. And I was talking with one of my business advisors and I was sharing it, and he said something to me to the effect of, Mike, you thought about this more than most people in the world had thought about it. And what was cool about it for me is that it gave me, it started to give me a language for talking about culture that didn’t seem so esoteric. It didn’t seem so woo woo, it didn’t seem ephemeral. Again, I mentioned to Peter Drucker comment when he said that, when he said that culture eats strategy for breakfast. I don’t think he was necessarily talking about intimacy in blue. I think he might’ve been talking about more red culture. I think he might’ve been saying something to the effect of your ability to get things done and your commitment to getting things done is going to trump your strategy at any time because you can have the best strategies, but if you can’t execute, or maybe if I take it a step farther, your people don’t love to work there.

They’re not going to be engaged. So we’re going to poke into this just a little bit, and then I’m going to make the case that what we’ve got to try to do is we’ve got to try to create organizations that take all of the different aspects of culture into consideration. And so blue culture, this again gives me a neat way of contextualizing some of these words I started with. So when I think of a blue culture, I’m thinking a lot of trust and empowerment and safety and appreciation and connection. We all want to come to work and we want to feel at least most of us do on some level close to the people that we work with. I mean, I think all things equal, we’d probably rather like the people and have good relationships with the people that we work with. And then red, red culture is results, accountability making and meeting commitments.

Ownership performance, you could say if you have a culture of meritocracy that might compete for everybody feeling good and everybody feeling connected, if you had a culture of meritocracy where only the people that were the highest performers or rewarded, something like that. So again, first last rev of this talk was really just focused on red, red and blue. But then you think about a yellow culture. A yellow culture would be about recognition. It would be about creativity, flexibility, collaboration, fun. I mean, think about the people in the agile community that are really into games and stuff like that, and they’re into planning poker and they’re into, I think about guys like Luke Coleman who has all the different ways of collaborating and playing games and things like that. What was the Tasty Cupcakes website that had all the games on it? Something like that. I think it’s neat, and I think that stuff has a place.

And then the idea of a white culture, which is around predictability and consistency and following the rules and clear expectations and harmony and inclusion and autonomy. And so what’s neat is that we can assess ourselves and we can understand what we value as people, what we can talk about is what we value in the workplace, and then we can explore how the systems that we put together are going to enable people with different personality types to really work together effectively. One of the things that we do, and a lot of our corporate communications internally is we’ll make sure that when we send something out, we address all four of the colors. So here’s the red part of the message, the blue part of the message, the yellow part of the message, the white part of the message. We have people all over this color spectrum that work in our company.

So, to me, that was a pretty insightful thing.

How You Can Maximize All Four Views

Now, let’s explore this for a minute. So a successful system is going to maximize all the different views, I think if it’s going to be a healthy system. And so if we index too much on red, we’re going to burn people out. If we index too much on blue and we don’t produce results, then it’s going to be that situation where it’s like, yeah, we have all this great comradery, but our company goes out of business. There’s a lot of us that are very focused on following the rules of Scrum are safe because that’s what we value. We value the rules as a way of reducing conflict in our system. If everybody understands what to do and everybody agrees, then we can all kind of operate in the same way. And then the last one, yellow, right?

Games and fun and things like that. So what I started to think about a little bit from that is this idea that if we were going to engineer systems that were going to take all of those things into consideration, what might those systems look like? What might an operating model that maximized all of the different cultural attributes in a company look like? And so what I did is I kind of walked through some of the different methodologies that are out there, and what’s really kind fascinating is I think if you really look at whether it be large scale Scrum or Scaled Agile Framework or just Scrum or xp, everything kind of comes down to Scrum at its core. I mean, that’s kind of the core. Maybe Scrum xp if you want to say engineering practices and things like that. But really Scrum XP is really at the core of almost everything that we’re talking about.

So I started with this and I stole Mike Kohn’s graphic. I think I’ve been stealing that graphic for about 15 years right now. So it’s a very famous graphic. So think about what Scrum does, okay? It’s three roles. It’s three ceremonies, it’s three artifacts. You have a complete cross-functional team of people that they work with, their product owner. The product owner’s responsible for bringing the backlog. The team is supposed to pull two weeks or three weeks or four weeks, whatever of that backlog off, and they’re supposed to produce a working tested increment at the end of the sprint. And if I, excuse me, if I know the size of my backlog and I know the velocity of my team, then I can start to predict how far then I’m going to get through the backlog when I run out of time, or I can start making different prioritization decisions to bring higher value things up to the top.

So Scrum, when I first heard it, it gave me a very red way of looking at Agile project delivery. Now here’s the relationship with Scrum between the red and the blue. If I have a complete cross-functional team that has ownership over their technology stack that can work with a product owner and produce a working test at increment at the end of every sprint, then what happens inside that team, the team does retrospective, is the team does daily standups, the team goes to lunch together, the team plays games together, the team follows the rules together, they do the ceremonies together and they become a unit. But in my world, everything’s predicated on that outside wrapper because if I can’t get to a place where that team is producing something of value every couple of weeks, and I only index on the other colors within the personality profile, well, it’s like I can have a great connected environment, but if I never produce anything or I can’t tell the product owner, give them any idea when I’m going to be done, well then what do I have?

I don’t have it. And I think I was talking with a gentleman here earlier today in the speaker room about where the industry’s headed, and I was kind of asking about the Canadian market in Quebec and Quebec City and how things were going because there’s a lot of people, a lot of agile coaches that are being laid off, and there’s a lot of agile trainers and scrum trainers that are not making the living that they were making a few years ago doing this kind of work. And you ask yourself why. And my belief is that we’ve indexed on the non-red aspects of Scrum. And I think the reason why I’ve got a slide for it, but I’m going to talk about that slide a little bit, is I think the organizations that we’re trying to apply Scrum into are really complicated and they have to be untangled and they have to be broken down into smaller parts and large technology stacks have to be broken down into smaller technology stacks or we’re never going to get rid of the business benefit out of this.

And so when I went down this next little bit, I started playing with the Spotify model a little bit. Anybody use Spotify here? A thing in Canada? Okay, last time I gave this talk, nobody raised their hand to using any agile methodology whatsoever. So I was kind of wondering what everybody was doing there, but I’ll just assume you guys don’t want to raise your hand. So what’s interesting to me about Spotify is what that model did largely is it basically said that there’s, in the organization, we have our delivery teams, but we also have groups of delivery teams that have to release plan together, and then we have role specialists that need to talk to each other and we have a leadership structure that has to interact. So when I look at Spotify, I don’t see that as inherently different from Scrum at the end of the day.

I don’t have a slide for this one, but what I think is really interesting about large scale Scrum is that I think Boss Vote and Craig Larman, I think they absolutely nailed that. And I do think that large-scale Scrum is probably the most scalable agile methodology out there, but it requires such attention to the technical architecture and the breaking down of dependencies, and the continuous deployment of services and products and things like that. Really, really difficult for people to get there. And so safe gets a lot of heat in the industry right now, and people say it’s not agile, but the problem with a lot of these environments is that yes, it’s not agile in the sense of the manifesto. It’s not agile in the sense of a blue culture or even a yellow culture necessarily, but it can lead to greater agility.

And so sometimes what we’ll talk about in an early-stage transformation is this idea that while you’re decoupling the organization, while you’re breaking the big things into the small things so that the small things can operate with greater independence, you have to put some scaffolding around that. You have to put some scaffolding around it so that the system doesn’t fall apart because the worst thing that you can do is have dependencies in the system that are unmanaged over the belief that the dependencies will break themselves or that the teams will self-organize the dependencies away, and I’ll just tell you, and I know you guys see it in your companies, is that most of the dependencies and organizational challenges, they’re not within the team’s purview. And so the teams get stuck and they’re trying to do something to operate with greater agility. So if safe got an organization to be able to do a three month release where they could only do a 12 month release, that’s greater agility. I mean, it’s not necessarily the blue side of agility, it’s not necessarily the yellow side of agility, but it’s definitely a stab at kind of a red side of agility.

And so that’s what I say a lot in most of these talks. When I go and I do these talks live or I give ’em a client or we’re just talking about ideas, it’s like all of the methodologies work. All of the methodologies have a place everything that was done or that has been documented for somebody in some sort of context. So a big part of the transformation story to pick a methodology that you think will necessarily work in your environment, the story of transformation is about understanding the methodology that has the performance characteristics that you desire for your organization and then doing the work to be able to create the conditions so that you can actually use that methodology and create the culture that you’re trying to get. So it’s a big story and it’s scary. There’s a lot of people that probably are thinking, well, gosh, Mike, that sounds great, but what do I do when I go back to work?

I get it right? It’s a really hard story, but you need to know what you’re up against. We have to have language for this stuff, and we have to be able to talk about it, or we’re just going to be talking past each other all the time.

What Gets in the Way of Culture Change?

So this is a slide that I’ve probably had in almost every deck that I’ve done for the last 15 years or so, and the thing that gets in the way of agility that gets in the way of us creating the kinds of cultures that we want to work in are dependencies, and it’s like there’s this again, belief system somehow in Agile that if we organize teams and we empower teams, the dependencies will go away. And what I find is in practice is that the dependencies don’t go away on their own. The dependencies have to be architected out of the system, especially systems at scale, especially complicated systems at scale.

I’m actually going to go back to that slide a little bit. So you think about what might be considered like a dependency, something that’s kind of killing us, technical bet and defects, shared requirements between teams, access to subject matter expertise, like somebody who you can’t have everybody on every team kind of a deal. Matrixed organizations, non instantly available resources, too much work in process, large products with diverse technology stacks, low cohesion, tight coupling. It’s like, and again, another conversation I was having this morning was around the idea, and I’m not really talking about technical practices per se. I think good technical practices if we are aligning an organization or we’re building a product from scratch is absolutely true. What a lot of times what we’re doing is product extraction and services extraction, and when we move things to the cloud, we’re not moving legacy monoliths, we’re pulling apart these legacy applications and we’re moving smaller things up into the cloud and we’re extracting the key services so that they can scale.

And again, when we start to think about the technology stack and the organizational design as a unit, there’s so many interesting books that starting to come out around domain driven design, been reading some things around the idea of business architecture. There’s words out in the industry like product driven organization. One of my favorite words, I think I picked this up from a Gartner article was the idea of a composable organization. And I think those are the ideas. I think everybody’s hunting around this same thing. If we want to operate with agility, we have to have units of people and technology that can operate independently. So again, just like for any of the technical people in the room, just like we would think about a services oriented architecture, think about a services oriented enterprise organized around deployable scalable business capabilities. I mean, that’s what we’re talking about and getting into this idea of where does agile go in the next three to five years?

I think this is almost like a call to action for me in a way to say if we keep doubling down on the blue side, the yellow side, the white side of culture, and we don’t figure out how to get these incremental and iterative team-based operating models in place, we’re not going to win. We’re not going to win in the industry and all the things that we want to try to achieve with the human condition and people feeling whole and connected at work, you can’t do that. At least I haven’t seen it in an environment that is not performing very well.

The Role of Organizational Structure in Culture Change

So one of the things I think about is how do we organize for collaboration? How do we govern for collaboration? What do we measure and control in a way that increases collaboration? What are the red aspects of a system of delivery that allow us to achieve the blue and the yellow and the white aspects that we tend to index on?

And so I’m going to share some patterns that we use to think this through. The language is mine. I don’t know that it’s universal. Maybe it works for you, maybe it doesn’t, but I think it’s interesting. And so what we generally find in most organizations is that there’s some set of teams that will be organized around shared services, shared technology components, services. Basically I just call ’em services teams, and then there’s a set of teams that consume those services, product teams. Those are typically what we think as agile teams or scrum teams. The next level of team that I think about, we’ll call these all kinds of different things. We’ll call ’em program teams, we’ll call ’em product teams, things like that. But that to me is the key construct that basically enables us to break big requirements down into small requirements, understand the architecture as we go, understand where the dependencies are, what dependencies need to be managed, what user stories or get sequenced when, what is the biggest chance of being able to get work through the system so that we have features rolling out of the system or epics rolling out of the system on some sort of regular basis.

So basically two types of a shared component team, a product team or a feature team supported by a program team or a product team, and then typically governed by a portfolio team. In our world, product teams and services teams tend to be dedicated to the extent that we can get it. The holy grail of those kinds of teams is stable velocity off of a known backlog, and that’s one of the biggest things that I test for. When somebody has me on the phone, I’ll basically ask them, do you know the size of your backlog and do you know the velocity of the team? Because here’s the thing, if you don’t know the size of your backlog and you don’t know the velocity the team and you just believe that if we do scrum that that’s all going to work itself out. I guarantee there is a manager or a product owner that is super frustrated with your team and your organization because if we can’t give them some idea of when we’re going to be done or that it’s going to work or that it’s deployable, we are at a loss.

And so as we move up the stack, the program teams sometimes tend to be part-time. They can be made up of people that have other responsibilities in the organization. They tend not to use a scrum, they tend to use a Kanban system to manage flow. That might be where the middle tier and safe might live. If you wanted to do big room planning and get everybody in, that’s where that would happen. And then you tend to have some sort of portfolio governance that rides on top of that. And so what you end up with is you could draw this a bunch of different ways, is the way I like to draw it. I have another drawing where it looks like almost like eggs, like egg yolks wrapped in eggs and eggs. I kind of lifted this off of Ken Schwaber and something he did about 12 years ago where he was trying to explain this idea of basically where you don’t have encapsulation at the team level, you have to encapsulate with something bigger than it that manages the dependencies between it.

The Role of Governance: Optimizing for Value Creation

So, optimizing for value creation, and this is the thing, right? It’s like it is most teams that we work with are so overwhelmed with the amount of work that they have to do that they’ve just thrown their hands up and they’re just trying to get by. And so what we need is we need some sort of governance model that strategically feeds backlog into the teams so that those teams are producing the highest value things and when there are dependencies that those dependencies are lining up through time and space at least at a release level. And so you can start to think through what does a governance model look like around that? This looks pretty complicated, but at the lowest level that’s just really just a description of Scrum at the program team and portfolio team level. Those are just features and epics moving through a Kanban board.

One of the, that I think is especially in very complicated organizations where there’s lots of dependencies even in safe that has a way of managing dependencies, has a way of doing release planning, I think it’s often insufficient. I think the idea that we can come into a big room planning at a quarter at a time and resolve all of those things in a two or three day meeting is kind of tough. So in those middle tiers, what I tend to think about is a group that works together that’s doing progressive elaboration, rolling wave planning around the backlog that’s thinking ahead five or six sprints or a release or two ahead of the team. They’re understanding the architectural concerns, they’re resolving dependencies, they’re understanding the throughput of the teams and they’re making sure that the teams have the work that they need. Now, does the team get to work with the customer and decide what it is that they’re going to take the product into in an environment like this?

Probably not, but that’s probably not your reality anyway, at the end of the day, you guys I would assume are mostly working in complex systems where lots of teams have to come together with integrated deliverables. And in the presence of that, you have to have some way of orchestrating that. The portfolio team is really responsible for making economic trade-offs in the face of scarce resources. So think about it, one of the big challenges that you see is you have 15 teams and three or four of the teams have nothing to do and one of the teams is totally constrained. It’s a whole theory of constraints problem. And so as leaders in organizations, we have to be able to look at those networks of teams as a system and just like we might on an assembly line and a manufacturing setting, we have to understand where we have constraints on the system and we have to move resources to the constraint.

And I say resources, money could be people, I know that’s provocative, but we have to move delivery capacity into the places where there’s constraints in the system. And then at the top level you do something like an investment here where you’re looking at your OKRs and your KPIs and things like that.

What You Should Measure to Stay Accountable

Okay, well actually let me go to the measurement accountability and then I’ll see if I can drive the point home. So at the scrum team level, backlog, size, velocity, escape defects, things like that more in the middle tiers, you’re looking at cycle time, you’re looking at escape defects, the feature tier, you’re looking at the ability to have you do rework or where features are blocked at the top level of similar kind of flow-based metrics, but that enables us as leaders to manage the system in a way that we not only know what’s coming out of the system and when it’s coming out of the system, we can actually go in and put dollars and people into the system to try to elevate the constraints so that we can get the system to move faster rather than just put pressure on the system and tell everybody to move faster.

We actually have a language or a model for doing that. Now, cool about it to me, if I am a scrum team and I have decided that it’s my responsibility to work directly with a customer and I need to work with those people and decide me and the product owner a hundred percent, what’s going to go into that product? Probably if you’re in a situation like this, you’re probably not in an environment you want to work in. Again, the kinds of environments I’m talking about are very complex systems where there’s lots of dependencies that have yet to be broken. So what are we going to do with those dependencies? What are we going to do to elevate those constraints? And so in the presence of an organization like that, I might have my backlog being fed to me. I might have a product owner, but that product owner might be working in concert with a program team or a portfolio team to understand what the priorities are.

That system above them becomes like the market because the larger ecosystem is the market and within that team, they get to do all the scrum stuff, they get to do daily standups and they get to do retrospectives and they get to play games and they get to have great relationships and they get to self-organize within that team, and they get to decide who does the work and they get to all the benefits, all the humanity that we want in Scrum comes from that team being able to deliver a stable velocity. It’s like the thing that protects the team. It’s like the hard crunchy outside that allows the magic of Scrum to work on the inside. If we can get the red stuff, that’s the biggest thing that we can do to protect the teams. We have to get the red stuff so that the organization understands what it’s going to get for the dollars that are invested.

And I just don’t see any other way. I don’t see any other way in the face of complexity. I mean, I’ve literally worked with teams where we’ve gone in and worked with C-level people and they’re telling me their agile coaches are running a revolution at the ground level trying to basically say tear down management and stuff, and we have to have a healthy relationship with management. But the cool thing is is that one of the things, I’ll talk about this in a minute. One of the things is that you can actually, as you start to break dependencies and as you start to fund the teams locally and give them the resources and the dollars, the whole projects to products kind of ideal, you actually can get to the point where the teams are able to operate more directly with their market and more autonomously. I think that’s possible, but it’s not desirable in every situation, but where it is desirable, there’s a way to get there, and that’s the work of transformation.

Overcoming the Challenges of Enterprise Transformation

So, it’s this idea of incremental and iterative change models.

We’ve had the pleasure, opportunity, honor of working with some really, really large organizations that were moving through some pretty significant scale change. And what’s interesting is if we start to look at the system that needs to be impacted, and so this is maybe another thing of word of encouragement. It’s like we have to lift our eyes up outside of the team, outside of the project or outside of that software product that we’re looking into and we have to see the bigger world around us. And so more often than not what we’re talking about in conferences, this is what to do with the delivery organization, the product delivery organization, and we kind of give a nod to the business and we say, oh, the product owner represents the business. Nine times out of 10, the product owner is like a business analyst that’s basically writing down requirements and the business is way, way bigger than what it is that that product owner is doing.

And so the things that we find that you have to explicitly take into consideration as product management, understanding the customer product, marketing, product strategy, strategy, articulation, how do we craft OKRs and KPIs and delegate intent into the system, and how does the system of delivery that we build for the product teams, how is it rolling up and supporting the organizational strategy? How does the organization know what resources and capacities that it needs to provide budgeting and funding? How does that happen? You might look at shareholder value return on investment in marketplace technology and architecture at scale compliance and controls, talent and culture and leadership. And so this is a funny way of articulating this slide, but what I was thinking about it just got really shorthanded was that blind man in the elephant story and it’s like if anybody’s not familiar with it, we have this idea of it’s an old Indian parable where there’s like three old men that are blind that are touching a part of an elephant and one is touching its leg and says it’s like a tree trunk and another one’s touching its ear and says it’s like a palm fron and the other one’s touching its trunk and saying it’s like a snake.

In reality, it’s all those things. And as agileists, if we’re going to elevate agile and we’re going to be a movement in three to five years, we have to start to think bigger. We have to start thinking about how do we affect change in a way that’s actually going to speak to our C-suite and it’s going to make the kinds of impacts that we might want them to make.

Probably it was probably seven or eight years ago if anybody’s familiar with our website or heard me speak before. I talk about this little four quadrants model, and I talk about this idea of expeditions moving to base camps, and that is a way that we use to articulate and to discuss an incremental and iterative way of moving an organization along. It’s another one of those things that I find challenging because I think a lot of us in the agile world are idealists and we know what it should look like and we want to go straight to what it should look like. But just like anything that you try to change, whether it be your health or your relationships or your family or your kids or anything like that, it takes time and it takes thoughtfulness and it takes intentionality. And so we developed this language of we take slices of the organizations from services teams to feature teams to product teams, to portfolio teams, to investment teams.

We take vertical slices and we move ’em to a place of predictability. So that was always the first thing is get the system predictable first. Because a lot of times if you can get the system predictable using agile techniques, then what you start to do is you start to build trust with the organization that the organization is going to be able to do what it says it’s going to do when it says it’s going to do it. So even if it’s not super agile, it’s incremental and it’s iterative and it’s making a meeting commitments and it’s earning trust with the broader enterprise. So that tends to be the first step is get the system operating in agile and lean practices in a way that it allows us to make and meet commitments. Then the next step is start to break things into smaller batches. Start to take your portfolio items and break ’em into two to three month things and start to get to where you can release more frequently.

Sometimes you have to change your tech practices, sometimes you have to change your testing strategy. Sometimes you have to change release management. Sometimes you have to get CICD pipelines and sometimes you have to get DevOps installed. There’s lots of different permutations of it, but we start with predictability, making meeting commitments. Then we start to go to reduced batch size, and this is the one that’s really interesting. There’s a lot that you can do in an organization where you do not have the purview to break the technical dependencies or even the organizational dependencies with just a really pragmatic, thoughtful way of doing structured governance metrics. You can get a lot of the agile culture, maybe not all of it. You get a lot of the agile ethic. You get incremental and iterative delivery. You get fast feedback, but it’s not as adaptive as you would like.

As you start to break into smaller batches, you have the opportunity to release into market faster, then you can start to get actual real feedback from customers faster. You will hit a limit to your agility if you cannot get dependencies, broken product extraction, services extraction, sometimes that gets called tech modernization tech. Sometimes it gets lumped into the idea of moving to the cloud or digital transformation. All those things kind of live in that family of how do I get big things broken into small things, wrapped in tests, wrapped in services, move to the cloud, scalable, all that kind of stuff. But that is the holy grail. Can I break dependencies at least on the things that have to move the fastest within my organization? If I can get to that, then I can do some really interesting things. The next step for us is now if I have a decoupled team, then I can start to think about team-based funding and persistent teaming strategies.

That gives me the opportunity. That’s the holy grail of the product driven organization, the PDO, right? That’s the holy grail of projects to products because now I’m not funding ments. I’m funding products with teams that stay together over time. And only in the presence of that can you really get into a lean startup kind of mode where you’re inspecting and adapting with the enterprise as you go. Now, you can always, as leaders, you guys always have the option just to go build it on the side and do it on the side of the rest of your organization, and that’s what a lot of companies do. They just have given up on the transformation part. But what I’m really talking about is the transformation side of things. Now, where this gets kind of interesting is at certain levels of scale, it’s certain levels of scale. We have to talk about something.

We’ve been calling summits, and again, I don’t want to index so much on my language, but I want you guys to use the words that I’m talking about as indicative of concepts because at a certain level of scale, you cannot change corporate strategy and corporate governance overnight. You cannot change audit and compliance overnight. You cannot change all these things overnight. But what happens a lot is if you can get it up to a certain level and get the enterprise operating in a more reliable, predictable, small batch size way, you can do some things with funding. A way to think about it often is almost like there’s an abstraction layer where you’re doing all of the agile stuff down here and you’re putting in an abstraction layer that maps the agile stuff up to the more enterprise stuff because you can really out corporate govern a organization using Agile than you can with waterfall or project management.

I mean, you can do a lot of things with incremental and iterative delivery that will blow corporate governance away audit and compliance away. I mean, you can put an interface there. It’s not ideal. But what starts to happen is that over time, if you get enough of the organization at critical mass and the transformation, then you can start to dismantle and start to bring some of those higher order things along. So we started planning with this idea of summits. So once we get enough of the organization in place, we can start to change how we’re thinking about agile planning, how we’re thinking about annual planning, how we’re thinking about batch sizing and market. We can start deploying things in market more frequently and start getting faster feedback at the corporate governance levels. This is an interesting one. One of the things that we’ve done as a tactic in really large complicated organizations is that a lot of the guidance in Agile is really around the idea of around products safe to organize around value streams, scrum to organize around features.

That’s all well and good, but in a lot of organizations, the thing that we organize around to start with, it’s a language that the business understands is business capability. And so I’m a big believer, I think I said this earlier, that business capability modeling domain driven design, this idea of composable enterprises, the idea of a product driven organization, the idea of projects to products, it’s all hunting in the same space. I want encapsulation at the organizational level. And so sometimes what starts to happen is when you put these layers in, you start to realize that the value streams are all tangled up and they require orchestration way too high up and it’s creating bottlenecks in your system. So a lot of times putting in a system like this will give you business intelligence about where to regroup different capabilities actually into value streams. And sometimes, again, in large companies, it’s really, really difficult to go straight to an encapsulated value stream because there’s so many shared services with so many shared components, but you can optimize, and that’s really what I was trying to get at with the product aligned.

And then you get at that level, you start funding products just like we were doing it at the lower levels and then sense and disrupt as an organization, right? Then we can start deploying whole business units into different problems. Think like covid, moving from auto manufacturing into respirators and stuff like that. It’s a lot of really interesting things that you can do there.

Functioning Systems are the Key to Culture Change

And so what I’m making the case for is that, again, tying it back to culture, you’re probably looking at me and going, Mike, this sounds like a bunch of heavy nonsense. Why would you get here at our Agile Canada talk and tell us all this stuff? It’s because getting where we want to go with agility and getting where we want to go, agile cultures and getting where we want to be in terms of connection and humanity and people is going to require us to understand how to create systems that work.

And if we can’t figure out how to create systems that work and we can’t figure out how to move our legacy organizations into those systems, I’m telling you the same problem that people are having with cloud migration right now. This is a place that we’re getting really hit with a lot of our clients that we’re doing transformation work. We’ll have hundreds of millions of dollars of cloud migration that’s happening outside the purview of the transformation, and it’s all the same fundamental stuff. They’re either trying to rewrite everything in the cloud or they’re trying to move everything up in the cloud all at once. And the idea that we break big things into small things and create encapsulation rapid in tests, get it continuously deployable, I think the same pattern is going to hold, right? And so I think that’s going to be an interesting next opportunity for the Agile community to really start having a point of view in the digital transformation space.

And so from our point of view, just to kind of build down on that language, the expeditions are really delivery team stuff, and then summit’s really captures all of the rest of the things around that system. So I’m going to go back to where I started as agile practitioners. I think we have three choices. If we want to increase greater agility in our companies, we can double down on culture as a first order concern and say, if we can get these leaders, we can get these managers, we can get them to trust the teams and empower the teams, then we’re going to win. I don’t believe it. I don’t see it. I don’t see it in action. I don’t see it actually happen that way. I’m not saying that there’s not pockets, but just to me, from what I see, it’s just not sustainable. I think moving down this path of that was the culture first, changing hearts and minds and somehow the world’s going to flip, then going down from a practices perspective and basically saying if we teach everybody how to do safe, or we teach everybody how to do Scrum, or we teach everybody how to do large scale Scrum, or we teach everybody how to do Spotify, or we hire coaches to teach people, I don’t think that’s going to work.

It’s the idea at the end of the day of systems first, right? If we can create the systems where the team strategies actually are real, the governance strategies are actually lightweight and nimble. The governance model at the portfolio and investment tier level are lightweight and nimble. They’re focused on empowering. Then, at the team level, we can create the environments that we want to create, and I think that’s the only way forward. So I think I talked fast because kind of tired, my voice kind of hurts. It’s to talk. It’s hard to talk for an hour when you got a cold. Okay guys, really appreciate you having me. Thank you so much. Appreciate it.