Building a Culture of Agility

Recorded By Mike Cottmeyer

How do you build a culture of Agility? How do you get hearts and minds to change? How do you get past long-standing behaviors and reinforced patterns of thinking so you can begin to do things a new way? Possibly a better way?

Let’s say you wanted to move from a command-and-control management style toward a more empowering, human-centered leadership style. How would you go about asking those managers to change? Those leaders to change? To risk it all in hopes of finding a better way. In large part, our behaviors are driven by what each of us sees as necessary to get results within the bounds of our organization’s operating model. We play by the accepted rules for how everyone works. Leaders often behave in a command-and-control manner because the company’s operating model is chaotic, impossible to understand, and doesn’t produce results. So, they take control and drive results.

What if they became empowering servant leaders in the presence of a chaotic, impossible-to-understand operating model that doesn’t produce results? They would most likely fail. To get your people to change, your leaders to change, and your organizations to change, you must change the environment each of them operates in. You must change the rules of the game.

This talk will explore the organizational attributes and behaviors that truly support a culture of Agility. We’ll look at the systems necessary to reinforce and guide those behaviors. We will evaluate the things we see in many organizations that get in the way of people being their best selves. Finally, we’ll explore how to systematically introduce changes that make it possible for each of us to think, behave, and deliver in a truly Agile manner.

Watch the Video

Video Transcript

Is the culture a reflection of the organization, or is an organization a reflection of a culture?

I’ve got a strongly held point of view about what actually creates a healthy, agile culture, and I’m going to be transparent about it. I think that when we look at an organization that’s struggling to adopt Agile, we see resistance. We see leadership behavior that resists change, and people who don’t want to participate.

It’s easy to say that we have a command-and-control culture, or that our leaders need to step up or that people need to behave differently. My belief is that most of the resistance we experience in large organizations is because the fundamental operating model — the way we structure teams, do governance, measure and control — is out of alignment with what we’re trying to accomplish with Agile.

So, it feels like a culture problem, like resistance, like not wanting to change. But in practice, my observation is that it’s more like we’re not operating in a system that encourages Agile behavior. So, which comes first? Is culture a reflection of the organization, or is an organization a reflection of a culture?

That’s what I want to unpack. And the reason why this is so important to me is that I run a boutique consultancy based in Atlanta called Leading Agile, and what we exclusively focus on is Agile Transformation. From my point of view, it’s a dicey game to walk into a room full of senior leaders and tell them that they’re too command-and-control and that they need to do something differently.

As leaders, we have a business to run, software to put in the market, customers to serve, and dates to hit. We have financial objectives that we have to adhere to. So, for leaders to relax a little bit, they have to have a trusted system that they can delegate into. They have to be able to put in dollars, resources, and people, and get a reliable, predictable outcome on the backside.

In the presence of that, a healthy Agile ecosystem can emerge. When you’re asking somebody to change, you’re not just asking them to change the way they work, but also to put their career on the line. Everything they’ve known and been successful with over the previous 25 or 30 years is at stake, and it gets visceral. It’s your house, your kids in college, your sense of identity.

So, a lot of times, we come in as enthusiastic Agilists, and we’re trying to cast a vision of what’s possible. But what I think we don’t do a great job all the time of doing is bridging the gap between where we are today and where we want to be in the future.

How are we going to get to this panacea of stuff? There’s again, I can never remember the author, but you guys remember that comic. It was like two scientists standing at a whiteboard as a bunch of math on one side and a bunch of math on the other. And then it was like a it was like a then a miracle happens, right? And he goes, “I think you need to be more explicit in step two.” I think as Agile is, we’re not always great at articulating step two. We have a vision for where we want to go, but we’re not always great at how to get there. So, the end of the story, what I’m going to try to put a bow on this at the end is that I believe that culture behavior change, all of that kind of stuff is a product of a functioning ecosystem.

And so how you form teams, how you govern the work, how you handle dependencies, how you do project intake, how you do investment decisioning, how you tie the organization, OKRs, KPIs, how you manage change, right? All of that kind of stuff is the most fundamental underpinning for how you change culture. And then when you get that operating model using really solid industry standard practices, Scrum, Extreme Programming, SAFe, Large Scale Scrum, all that kind of stuff.

So, we get the systems, the teaming strategies, the governance models working. We enable it with the practices that we’re so passionate about. And then what we’re able to do is we’re able to invite participation, we’re able to invite hearts and minds to change or able to invite people to be less command and control and more empowering, because now they have an alternative to get what they need out of the system without having to resort to the tactics that they used to try.

Okay, so that’s the end of the story. Okay. So, what I want to do to get there. So, by the way, if you’re interested in this stack, you can text “culture” to 33777. Thank you, Tim and my marketing team for setting it up. So, what we’re going to do is we’re going to walk through I want to get your sense about what is an Agile culture that we’re going to talk about, why an Agile culture is important.

I want to talk a little bit about who is responsible for an Agile culture and then how we get there. And then that’s where we’re going to connect some of the dots here a little bit and we’ll see if I can pull this off in the next 30 minutes or so. Okay, so what is an Agile culture? So you think about what Agile is trying to do.

So, when we say a small, complete cross-functional team that basically works with a product owner on that backlog, what we’re saying is that we have a cross-functional team organized around value with a single voice of a customer that is able to produce a working tested increment at the end of every sprint and get feedback from an actual customer on it.

I do a talk that has become integrated into my speaking engagements. I call it “The Three Things”: teams, backlogs, working test software. Whenever someone contacts me saying they’re struggling with Agile, I never ask about training or Scrum. The first thing I inquire about is their teaming strategies.

What are their teams organized around? Can those teams operate off a well-articulated backlog and produce a working tested increment? The first time I gave this talk was at a Scrum gathering in Las Vegas about 12 years ago. There were 500 Scrum practitioners in the room, and I asked who formed teams as Scrum prescribes and had product owners who could produce an authoritative backlog the way Scrum recommends. Only three people in the room raised their hand when I asked who could produce a working test increment at the end of every sprint.

Here’s the deal: a team that’s not well-formed and operates off a random, ill-described backlog and can’t produce a working tested increment is not a reliable system. The organization can’t count on it to produce something.

So now we’re telling our leaders to stop being so command and control. We need them to empower the team, trust the team, and let the team make decisions about what’s the right thing to do. But if the team can’t produce what it’s responsible for producing, it can’t produce the actual thing that Scrum is designed to produce.

So, is that a culture problem or a system delivery problem? As a leader, how would you demonstrate those cultural attributes if it was your organization, and you were responsible for producing that software? I might argue that you wouldn’t be able to achieve the cultural attributes we want. We need to get our team strategies, backlog strategies, and working tested software strategies right.

And when we don’t get those team strategies right and we don’t get the practices right, it’s really difficult to create the culture that we want within the organizations, and we want people to be open. We want people to respond to change. But it’s unsafe to do so.

So why is an Agile culture important? If you had an Agile culture, what would you do with it? How would it contribute to the success of your organization? How does culture map to business results?

So, I want a culture where I can respond to change. Well, what Agile does, which is brilliant, right, is it takes what I call — so I’m kind of in the small team realm. I’m not really thinking scaled organizations at this point, but for a single team, I have analysis, design, build, test, deploy all within the same team. I have a backlog that is written as user stories that describe behaviors, right? So, I go back to like Bill Wake and Mike Cohn’s independent, negotiable, valuable, estimable, small, testable, right?

The way that we write user stories creates the ability to pull something out and to put something new in. The way that we do technical practices with continuous integration, continuous deployment, TDD, pair programming, all those kind of things. It makes it super safe to change the code base. So, there’s something in the structure of that team, the way the requirements are written, the way the technical practices happen that actually enables me to live that cultural value.

So, you know, Dave Priors is actually a CSM who works with us at LeadingAgile. He and I went down this path of, you know, everybody kind of goes to systems nowadays or like recovering project managers, right? And you get these funny questions like, “How do I do Agile if I don’t have product owners? How do I do Agile if I don’t have a complete cross-functional team? How do I do Agile if I’m matrixed across six or seven teams?”

I think what I found is that, in literally every one of our clients, they are in this boat, right? Because they wouldn’t hire us otherwise because this is what we do. You can get an organization to change its team strategies if you create a compelling enough reason. You can measure the change, you can measure the results of the change, and you can get them to change.

So, I’ll shallow away years ago, leader of that objective, so the PM, my inventor, the flex system, and I think as now he’s I know he’s been around in this community for a while, but he wrote a post that I thought was really interesting. He basically said something to the effect of when you take an organization that’s in chaos and can’t produce anything, and you run an agile pilot, you create all of the conditions necessary for that pilot to be successful. Oh, and by the way, we use Scrum, okay?

What happens is when you create all the conditions for that pilot to be successful and you enable it with a set of practices like Scrum, what tends to happen is that Scrum gets the credit, right? So we take the Scrum practices and we transplant them into the chaotic organization. How many people have ever seen Scrum work on top of a functionally siloed organization that can’t produce a working test and incremental every two weeks just doesn’t? But that’s largely what we’re doing, right? And that’s the reason why I think this is such a simple message that I’m exploring with you guys.

But we often see culture as the resistance. Sometimes I run this exercise, which is one of my favorite things to do with user groups. I say to a room full of Agile enthusiasts; Okay. cool. You’re king for a day. You can do anything you want to this organization. You can wave a wand, and people will believe whatever you want them to believe. They’ll be excited about whatever you want them to be excited about. They’ll change their cultural attributes to be different, be better leaders, whatever you want them to be. But now you’ve got to tell me what you would do tomorrow, understanding that we have to produce a release in three months.

So, if you could wave a wand and wipe away all your cultural challenges, what would you go do tomorrow? But you’re on the hook for delivering something in three months. You get the same problem before you continuously get the same problem before different time stops. Interesting. Yeah. Cool. I don’t know that that’s necessarily the way. The way that, to me, where my brain goes is I’ve come up with a team strategy.

I would make sure that all those teams had really solid backlogs. I would make sure that all those teams have the ability to produce a working test and increment at the end of every sprint. I would make sure that they’re consistently running Agile practices across all the different teams and the presence of dependencies. I’d put a lightweight orchestration mechanism on top of it.

I tie it up the strategic content, right, OKRs KPIs, all that kind of stuff, right? And I would have a reasonably good shot in that environment of producing that working tested increment. The reason, what you’re saying is that because I haven’t given that leader a competitive, a compelling alternative to get what they need out of the system, they won’t let me try.

And what I believe is that if you can create the right conditions and make a case that those changes are going to produce the right results, you can create momentum in the organization to make more of those changes. What’s the alternative? Right. And this is where I think like Scrum is by default, right? Generally, when you take a training-first approach, like I’m going to teach you how to do Scrum and then what happens is that we start doing Scrum.

The ScrumMaster identifies the impediments. The ScrumMaster works with the organization to remove the impediments. Right? The team improves over time. That’s kind of the training-first hypothesis. What happens when those impediments are all design? What happens when those impediments are technical dependencies and the tightly coupled mainframe legacy system? Right? What almost always ends up happening is that Scrum gets bent rather than the organization getting improved. Safe gets bent rather than the organization improving.

So, Agile is, I believe, to become a safe and effective Agile delivery ecosystem. We have to get the structure and the governance and the metrics in place. We have to get the dependencies understood. We have to put in the systems. Then we can enable it with Agile practices all day long. And then what will happen, and this is what I think is super cool, and it happens almost every time, is that people will learn how to trust that system and how to engage with it in a more healthy way.

Once they realize that teams have a stable velocity against a known backlog and can produce a working tested increment at the end of every sprint, then they learn that if I mess with that team, if I meddle in its internal workings, I’m actually going to jack it up, right? If I redirect or pull people out of it, if I disrupt the system.

So the behavior changes that we want to see from leaders come from giving those leaders a reliable system of delivery that they can delegate into. I was doing something at Wachovia before the Wells Fargo acquisition in Charlotte, and I was pretty new to the Agile world. I was pretty new to version one and I was doing some basic tooling training, some basic agile training, and a young woman in the background said, “I have to go to six. I’m on six projects, so I have to go to six daily stand-ups, six reviews and retrospectives, six, you know, everything, right?” And I was just like, “How do I protect that person’s time in that world?” And that’s what I think is super hard because it requires an absolute rethink.

One of the big buzzwords that you hear nowadays is the idea of projects versus products. It’s really what we’ve been talking in the Agile community about for the last 20 years, right? How do I organize teams around persistent value and give those teams consistent funding so that they can stay together and produce product over time? That’s like the very definition of agile, right, at the end of the day.

Okay. So, I think this would be the last question I get to ask you guys. Who is responsible for an Agile culture in an organization? There’s this whole thing in the Agile world around trusting the people doing the work, and I agree with that. We have to trust people doing work, but we have to put them in an environment where they can be trustworthy.

So, most of the time, we come in and do transformation work. There is an element of asking the leadership team to suspend disbelief for a minute. Let’s let these teams form. Let’s let them get their backlogs together. Let’s let them start to establish stable velocity, get to a place where they can produce a working tested, validated increment at the end of every sprint.

And then what’s going to happen is you’re going to expose a whole new set of levers to that leadership team. If they keep everything the same, then you should start to be able to, over time, start to understand how long it’s going to take or how much scope that team’s going to be able to get through using Agile.

If they want to change their mind all the time, they should be able to insert new work into that backlog and understand the cascading impacts of inserting that work and what it does to everything else. Okay. But only a team that’s well-formed, stable velocity known backlog, able to produce a working tested increment at the end of every sprint will achieve that.

So, the general rule, when I think about culture, it comes down and so much of it just comes down to trust. And so, what I ask is that the teams have to focus on being trustworthy. They have to be able to do what they say they’re going to do. They have to be able to operate with some degree of predictability.

And then what we ask is the leadership to then respect that capacity, respect that predictability, and not mess with the system and not overload the system. So once the team has stable velocity established, once it has a stable capacity indicator, then the organization has to balance demand against that capacity. And what we find is when we have really healthy teams, or when capacity and demand are in balance, right? All the other things start to snap back.

So, I had one more set of slides, but I think this is enough. The gist, again, is that if you want to change culture, it’s super easy to point at the people and the system and tell them that they need to change. So, what I’m suggesting is, if you get the system of delivery and the organizational design right, get everything in alignment, and enable it with all the Agile practices, you will have an easier roadshow in trying to get people to change their hearts and minds.

That’s the key point. Any thoughts or questions? I’m hanging out here all day, so feel free to come up and ask me questions if you want. Thank you all for coming. I really appreciate it.

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 on April 18, 2023.