Skip to main content

How You Define Success in Agile Matters

Mike Cottmeyer Chief Executive Officer
Reading: How You Define Success in Agile Matters

There’s been a divide in the Agile community for a while now. On one side, you have the camp that’s all about team-based, iterative and incremental delivery. On the other side, you have the camp that sees Agile more of a social movement; this side is all about empowering the teams and building a culture or a mindset of Agility. Meanwhile, as the debate rages on, a lot of the executives and leadership teams we talk to don’t even want to talk about Agile at all. It’s become a dirty word, they tried it and it didn’t work,  and now they just don’t believe in it anymore. So, how do we get these leadership teams back on board with Agile? Watch this video to find out.

Video Transcript

Maybe it’s just the callers, but I notice a frequent occurrence: many individuals avoid mentioning Agile nowadays. I frequently interact with leadership teams. You know, I often engage in sales. Subsequently, my teams inform me, “The leadership wants you to have a conversation with them.”

However, you must avoid using Agile, Expedition, Basecamp, team strategy, and “velocity.” Why? These concepts have suffered misuse. Leadership teams are becoming weary of them. They initially believed in the potential, yet the results were lacking.

As Agile professionals, it’s our responsibility is to bridge the gap between cherished practices, our culture, and the essential business benefits. This bridge is attainable through structural changes, alignment, and harmonizing intellectual property with business objectives. It involves breaking significant tasks into smaller components, eliminating dependencies, and similar actions.

That is what Transformation entails. In essence, Agile isn’t the main concern. The true focus is on agility.

(Musical Interlude)

Companies Don’t Care About Agile

Hello everyone, how’s everyone doing today? Today, I’ll discuss a recent tweet of mine. It highlights the notion that Agile itself isn’t the ultimate goal. What truly matters is agility. The emphasis isn’t on adopting Agile practices, forming Agile teams, or establishing Agile ecosystems.

The key concern is the capacity to introduce products to the market, receive feedback, measure progress, and adapt to the market’s needs. A week ago, my team posted something on LinkedIn that gained substantial attention. We even created a response video.

Perhaps we can include a link to it below this video. Essentially, the image conveyed that agility hinges on alignment. Getting team strategies right, synchronizing backlogs, and efficiently producing working software at scale are crucial. Without this alignment, even the best Agile practices and culture won’t suffice.

Alignment takes precedence. Interestingly, these concepts are closely intertwined. Comments on the post included feedback like, “tell me you know nothing about Agile without telling me you know nothing about Agile.”

It was fairly interesting to observe the various perspectives people held. At one point in the response video, I mentioned that if you aren’t actively pursuing agility through systems, governance, metrics, and the endeavor to introduce measurable products to the market, then you aren’t truly sharing the same context as I am.

There seems to be a divide in the current Agile community. One branch of Agile focuses on team-based, incremental, and iterative processes. This approach centers around optimizing for smaller batches and hastening market entry. Much of this can be accomplished in a planned and predictable manner.

Then there exists another branch, and this isn’t a recent divergence. This distinction has existed for quite some time. This perspective views Agile as a form of social movement, emphasizing the empowerment of teams, enabling teams to make decisions, and fostering an environment for developers to fulfill their responsibilities.

However, the challenge lies in the desire for both perspectives. Drawing from my 13 years of experience in this field and the seven or eight years I dedicated to leading Agile, my belief is that businesses ultimately require the capability to consistently and predictably release software to the market.

Agile introduced a fresh metaphor for conceptualizing how to structure systems and teams, determining the work allocated to these teams, gauging progress, and executing transformation initiatives that facilitate the formation of Agile teams within organizations.

Consider an Agile team, composed of 6 to 8 individuals. They possess some autonomy regarding their technical framework. They collaborate with a product owner, at the very least. Their backlog is well-defined. They deliver functional, incremental software at the conclusion of each sprint, followed by feedback.

Certain conditions must be established within any organization to enable the delivery of such characteristics. Once these conditions are met, methodologies like Scrum or SAFe offer effective approaches to managing tasks, gaining visibility, and tracking progress through burn downs. The presence of teams with minimal interdependencies, operating with a degree of autonomy, is a key factor.

They’re operating clearly with the direction of a product owner, but they have a lot of space to be able to make decisions and decide who and how does the work and all that kind of stuff that is like a byproduct of the ability to get people into the right ecosystems. And so I think to some degree, right as an agile key to this one fork of the Agile community, what they’ve done is they’ve overindexed on the practices of agility like the daily standup review and retrospective, the burn down, the collaboration techniques or if it’s at scale, the big room planning and the different techniques associated with that.

And, you know, a lot of times that side of the world tends to index on culture and how people feel and are they happy or not and everything. And again, like I feel like a broken record to some degree, that stuff is important. But that stuff is a byproduct of being in an ecosystem that can deliver.

And one of the things that I’m really passionate about and the reason why I’m kind of hitting on this in some form or fashion almost every week is because there are a lot of places that we go nowadays where people don’t want to talk about Agile, right? It’s like we’re burning that word out in the industry because what people see it as is, they see it as a social movement, they see it as a way of empowering people.

They see it as a way of trying to change the culture, and culture and everything is great, right? We want it, but only if we can deliver reliably and predictably and get fast feedback. So, what I’m really trying to say with this tweet and with this article is that we have to pay attention to both, or we’re going to continue to marginalize ourselves in many of these organizations.

Enabling Social Movements in Agile

And so, if we want to have empowered people on teams that have local authority to make decisions and to work directly with customers and to get feedback and to collaborate and to do all the cool stuff that we want to do with Agile, we have to create the right ecosystems within those organizations to be able to do that, right?

And so, at the very minimum, at the team level, it’s a complete cross-functional team, few if any dependencies, backlogs that are clearly articulated, they’re broken up into user story-sized increments where you can actually put something in front of a customer at regular intervals and get feedback from it. And the point that I’m trying to make with all of this is that is what enables agility.

The practices that we put on top of it and the culture we create are enablers and byproducts of that. Because, you know, I’ll tell you just candidly, at the end of the day, as a business owner, the CEO of Leading Agile, I care deeply about my people and the work that we’re doing for our client. I want to make sure that our people have a great environment and that they’re supported and that they have the ability to operate somewhat autonomously and to decide.

And, you know, we strive really hard, and we work diligently to be an agile organization. But if we don’t deliver for our customers, if we don’t produce value for our customers, then, you know, our customers can’t pay us, and then we can’t make payroll. And then, you know, you have to lay people off, and there’s just no way to do it unless you’re running the business of it.

And so, this idea that nobody really cares about Agile, all they really care about is agility is is what I’m saying is that if we don’t achieve agility with our agile right as defined by teams that can put things into the market and get fast feedback and inspect and adapt. Right. And to do that in a relatively reliable and predictable way, then we don’t really have a business to run.

And if we don’t have a business to run, we can’t keep people employed. I had an employee one time when we were forming as a company and she said something to me to the effect I guess I was losing my mind or something, you know, Again, early days New CEO. I’ve grown up a lot in the past 13 years, but she said something to me to the effect of, you know, if you keep acting this way, you’re going to damage our culture.

And I was like, well, if we don’t figure out how to run this business profitably, we’re not going to have a culture to dismantle. Right? And I stand behind that, right. And this is what I’m encouraging the Agile community to think about, is think about are we aligning to the goals of the business? Are we able to help the business to be profitable?

Are we able to put things into market on a on a on a regular recurring basis and be able to make money from it? Right. Because at the end of the day, if our Agile isn’t enabling that, if we’re not producing software that our companies can sell, there’s just no amount of practice, no amount of culture is going to overcome that.

We have this kind of notional idea that if we empower people, that if we give them permission to do the right things, that that they’re going to self-organize and they’re going to overcome and they’re going to figure it out. But again, guys, that’s just not the way it works in a lot of situations. There are a lot of things that are going on in some of these large organizations that are beyond the control of an individual team.

So, if you can’t get some of the systems architecture, some of the way that the businesses organized work out, if you can’t get some of the governance to comply and things worked out, you guys are really slugging in an uphill battle.

Adopting Agile is Never About Adopting Agile

So, at the end of the day, right, I think a lot of us want to operate within our sphere of influence, right? We understand the practices and we can teach the practices and we want to encourage the people who do the practices. And we can also encourage people to have better attitudes and to be more adaptive.

And all that stuff is great. But at the end of the day, again, I’m going to keep coming back to it. If the end of the day, if that doesn’t produce working tested increments of software that are tested and validated and able to be shipped and able to be used by a customer and consumed and in actually the company can charge money for it and reduce risk and satisfy its customers and get feedback and all those kinds of things.

It just doesn’t matter. So, when you hear me say things like Systems first are agile is about alignment, that’s what I’m talking about. And and again, if that’s not the problem you’re trying to solve, like we’re living in really different worlds. Okay, So I’m going to just beat this drum, you know, probably week to week and just talk about this a little bit.

So, you know, at the end of the day, what I’m encouraging you guys to think about is that it isn’t about Agile, it isn’t about the practices, it isn’t about the ceremonies, it’s what business benefit that those practices and ceremonies and things were designed to achieve. And if we can’t get the ecosystems right and the companies that we work in, then those practices often kind of fall flat.

And I’m telling you, I see it a lot, and maybe it’s just the people that call us, but I see it a lot as there’s a lot of people that don’t even want to say the words Agile anymore. I go in and talk to leadership teams a lot, have like will go on and we’ll do a sale of something.

And then my teams are like, Hey, the leadership team wants you to come in and talk to them, but you can’t say Agile, you can’t talk about exhibitions, you can’t talk about Basecamp, you can’t talk about team strategy, you can’t talk about velocity. Well, why not? Because those ideas have been so misused. The leadership teams are really getting tired of it, right? They bought into the promise and then they didn’t get the reward on the backside.

So what we have to do as agile professionals is we have to bridge the gap between the practices that we love and the culture that we love and the business benefits that the companies require. And it’s possible to bridge those two, but we bridge them through structural changes in alignment and alignment between IP and the business and breaking big things into small things and breaking dependencies and all those kinds of things.

That’s what transformation is about. So, nobody really cares about Agile. What they care about is agility. So, if your Agile isn’t resulting in actual agility, then we have a disconnect and it’s up to you guys to bridge that disconnect. And as always, let us know if there’s anything we can do to help. So anyway, you guys have a great day, and we’ll talk to you next time.

Next Varying Scope in a Fixed Time, Fixed Cost Environment

Leave a comment

Your email address will not be published. Required fields are marked *