Avoid Best Effort Mentality AND Get the Agile Culture You Want

“Technical agility is the underlying precondition for process agility, which is the underlying precondition for organizational agility, which is the underlying precondition for business agility. No amount of leadership attitude or mindset will change this.” — Mike Cottmeyer, CEO LeadingAgile

Video Transcript

We want a culture in the organization that is safe and is collaborative and does empower people and does enable the people closest to the technology and to the customers to make the decisions. But we also want to be in a system that makes and meet commitments that we can deliver against the sprint objective. And we can have multiple teams that are integrated in such a way that they produce integrated deliverables on regular cadences and where we have our portfolio items that actually move through our portfolio at a predictable rate. And ultimately that enable us to inspect and adapt and market and achieve our business goals.

(Musical Interlude)

Preconditions for Business Agility

Okay, everybody, how are you guys doing today? I am going to try to unpack a tweet that I put out for my team a couple weeks ago. Can you still say tweet? Is it a tweet anymore? Now that Twitter is x? I don’t know, I guess I’m behind the times. But we put out a tweet and it said something like this. It said that technical agility is a underlying precondition for process agility. Process agility is a precondition for organizational agility and organizational agility is a precondition for business agility. And the follow-up comment was that there’s no amount of attitude and mindset that is going to increase your level of agility if your core underlying infrastructure, your core underlying operating model is not set up for it. So that’s kind of the set up for what I want to try to do today. And so, let’s see if we can explore this a little bit.

When Scrum came out 20 some odd years ago or whatever, I guess it got popular 10, 15 years ago with the advent of the CSM, one of the things, it was a good thing, and it was a bad thing. And the good thing is that it made Agile a lot more mainstream. It kind of got the certification out to the masses and it opened up the doors for the relationship with the PMI and the PMIACP. And it got a lot of people thinking about the attitudes, the mindsets, the principles, and the practices associated with Agile. Now, when we were putting together the PMIACP certification, I was actually on the group of 8, 7, 8 people that did. Of the things that I thought was interesting about it is that if you think about the PMI and the PMBOK, the traditional project management methodologies were very organization, it was very technology agnostic, it was domain agnostic.

These were generally accepted practices that could be applied by most project managers. Most of the time it didn’t really matter what you were doing when you started getting into the agile methodologies. A lot of the things that I talk about really start to begin to matter. What does your organizational structure look like? How are you organized around value? What is your requirements, decomposition practices look like? Are we operating in small batches? Are we able to get fast feedback? Are we able to continuously integrate and continuously deploy? And I think a lot of that is what we’re fundamentally missing in most organizations when we talk about agile. So getting back to the tweet, it’s like if I have a code base that is not continuously tested, continuously able to be integrated, continuously able to be even potentially shipped, it’s like all the process agility in the world doesn’t really matter if I can’t get to a place where I get fast feedback from a real customer if I don’t know that I’ve fundamentally got to a definition of done if I can’t actually ship that product and make it actually work.

So the point being is that without the ability to do the technical stuff, regardless of the domain, whether it be manufacturing, whether it be software, whether it be marketing or collateral or whatever it is that you’re using agile for, if I can’t get to a place where I can produce something that can be validated technically, then all the process agility doesn’t really matter. And how that manifests in a lot of companies is imagine a situation where you’re doing something on some sort of legacy assembly line and there’s a bunch of analysis, there’s a bunch of design, then there’s get the assembly line put together, then then you have the assembly line itself, and then you’re producing something that shows up as value on the back end of that process. You could use Scrum all day long to manage the work that gets done, but you don’t actually achieve agility because at the end of the day, you’re doing large batches, you’re doing long assembly lines, you’re not able to test until you get to the very end of the system.

And so the technical agility, the ability to produce the product in small increments that are testable and validatable is a precondition for all the requirements, decomposition and all the tracking and the managing and the burn down and the velocity and all that kind of stuff. If I can’t get the technical agility and the process agility, it’s really hard to get organizational. It’s really hard to get the parts of the organization to start operating in small batches. How can I do two or three month projects if they get shipped into market on regular intervals? If I don’t have the teams that are able to operate that way, if I don’t have the platforms that are able to operate that way, if I can’t get my organizations within my enterprise to be able to operate with agility, how do I get the overall organization to operate with agility?

The Role of Culture in Agile

And one of the things I’ve been thinking about a lot lately is the role of culture and why so much that we see culture as a first order concern. And I’ve been unpacking culture a little bit. And the angle that I’ve been thinking about it from is this idea of, I think we think about culture in two primary ways. I’ve done a little bit of anecdotal research in some of the talks in rooms I’ve been in over the last couple months. And one of the things that I find is there’s kind of a split. There’s a certain group of people that define culture really as the environment, how people feel, how they interact, do they feel safe, do they feel empowered, things like that. And then there’s another kind of branch of culture, which is a little bit about accountability in making and meeting commitments and do we get things done and what do we do when we’re behind schedule?

What do we do when things are at risk? So, there’s this kind of feelings and more emotional side of agility. And then there’s also kind of culture. And then there’s kind of this idea of culture as the ability to get things done and how do we respond in the face of adversity? And one of my underlying hypotheses is that I think a lot of times in Agile, because we haven’t created the conditions technically for the process agility, and then because we don’t have the technical, don’t have the process agility, we’re not able to produce measurable products every two weeks. We don’t get a lot of the organizational agility and then we don’t get the business agility. And in that kind of an ecosystem, that hard side of culture where it’s about producing things and getting results and making and meeting commitments often falls by the wayside.

And what we end up doing is we end up going more towards a best effort kind of mentality. And it’s like I showed up, I did everything I could. I operated from the Scrum framework. I really loved being there. It was very collaborative. It was very just a good environment to work in. I felt very personally safe. That’s an aspect of culture, but without the ability to actually produce things on regular intervals and to know that we’ve gotten to a definition of done and to actually be able to burn down against the known backlog and be able to make and meet commitments and actually deliver against our business objectives, it’s kind of like, what are we doing? And so, we find ourselves in this conundrum where it’s like we want a culture in the organization that is safe and is collaborative and does empower people and does enable the people closest to the technology and to the customers to make the decisions.

But we also want to be in a system of delivery that makes unique commitments that we can deliver against the sprint objective. And we can have multiple teams that are integrated in such a way that they produce integrated deliverables on regular cadences where we have our portfolio items that actually move through our portfolio at a predictable rate. And ultimately that enable us to inspect and adapt and market and achieve our business goals. And so there’s just a lot of things that work together. I don’t have the technical agility, I don’t get the process agility, I don’t get the organizational agility, I don’t get the business agility. And then I think what that does is that breaks the ability in the culture to say, Hey, we’re going to be accountable. Without that process agility, without the organizational agility, it’s very hard for us to make and meet commitments.

It’s very hard to do what we say we’re going to do. So, we lean pretty heavy as Agilists on the environment that we’re trying to create in the working conditions. And at the end of the day, I think what the goal is, is to have both. I think we want to have great work environments. I think we want to have great cultures that respect people, but we also have to do it within a framework where we can make and meet commitments and we can do what we say we’re going to do and we can deliver against customer promises and we can deliver against market expectations. And so, without the attention to the technical agility, in addition to the process, agility makes it really, really difficult. And so that’s where a lot of the transformation work that we talk about comes in because you can do a lot with the process agility, but if you’re not working to create the underlying conditions for the technical agility to be a thing, everything above it starts to break down the organizational and the business agility and the culture of accountability, the culture of making meeting commitments.

And we kind of devolve into this best effort kind of a thing. And I think that’s a problem. So if you’re in an environment where you’re over-indexing on process and the softer side of culture, maybe look towards the technical agility side and see what can we do to be able to actually deliver this product in small increments so that we can start making immediate commitments and start managing the expectations of our business partners so we can actually run a business and we can actually get a solid return on that investment and we can actually produce things when we say we’re going to do it. So that’s my thought for the day and I hope you guys enjoy and we’ll catch up with you later. See you. Bye.