How Agile, Really? Five Key Elements

There’s a lot of talk about agility, agility at scale, and DevOps. We’re in a new era — the era of the hippie agilist. No different from what happens in modern global politics, where selling hate is easier and more effective than doing things right. To some of these new hippies, any amount of order and governance seems to be evil. Some false prophets even associate the word “project” with the devil, or “the wicked one.” Every kind of fanaticism runs short on knowledge and experience — radical words only ever demonstrate fear and ignorance.

And yet, this radicalism points to something real: being agile isn’t easy, and the bureaucratic structures of the past are being called to renew themselves into collaborative, open structures that make room for more motivated, effective, and efficient teams. This post lays out five elements to evaluate how agile your team or organization really is.

Agile Transformation

“Agile transformation” is easy to write, especially in a blog post — but how easy is it, really, to start one? Well, like any good consultant, the answer is “it depends.” And the truth is, it depends on the current state of the organization or team taking it on. That’s why I’m sharing these elements: to evaluate how agile you are today and what you need to consider. It’s a good starting instrument to gauge the size of the effort ahead of you.

1. Continuous Delivery Capability

How skilled is your team at delivering? Is the delivery process for the product or service in development simple and smooth? Is every release still a headache? How fast, and how often, can you deliver?

Delivery capability isn’t the same as production capability. Many companies already have good production processes in place — predictive, agile, or hybrid — but are unable to put what they’ve produced into the operation’s hands, ready to use. That’s a bigger problem than it looks, because it shows that agility in production teams won’t make much of a difference to the organization’s operation and business. What’s the point of producing fast if we can’t “capture value fast”?

This covers processes, technology, verification capability, and recovery capability — the last one tied to the potential need to roll back a release that’s already in operation. In software terms, we’re talking about the well-known steps into pre-production and production environments.

2. Built-In Quality

The verification process for products and/or services in development should be a natural part of the production process, integrated into it, with a proven track record of effectiveness. If you’re not sure how to gauge your maturity level here, ask yourself: does delivering products and services to the operation still scare you? Do you distrust the results? If you get “butterflies in your stomach” — that gut feeling — and it’s not the good kind, that’s something you’ll need to address.

3. Team Spirit

There isn’t much to say here. A spirit of camaraderie and collaborative work either exists or it doesn’t — there’s no such thing as a halfway good team. This is something you need to evaluate across all your teams, or some of them. Some teams will surely do better than others — learn from them, and assess the objective conditions of each team: how much and how heavy their workload is, team size, total duration of the effort.

Team dynamics are fundamental to agile production. Motivated people are a magnet for good ideas — they’re willing to work through problems and give their best for the outcome. If a team is lacking “psychological safety,” you’ll likely need to work on its pillars — I’d invite you to look into Amy C. Edmondson’s work and the articles published under Google’s re:Work initiative on high performance.

4. Product and Backlog Management

This one’s a delicate subject, because it involves the operation itself, and the people who best understand the business, in some way. In Scrum, the Product Owner role is the cornerstone of methodological success. Are you able to assign knowledgeable people, empowered to make decisions about the expected outcome? This is a breaking point — a deal breaker. It’s a fairly common problem: not having the right people — with the knowledge, experience, and authority — to make decisions about the product or service. Existing structures almost always resist bringing that business knowledge into production or development teams, and that’s where a lot of today’s agility failures come from.

5. Technical Excellence

Another delicate subject. We often depend on technology from external vendors who care little or nothing about agility in their clients’ internal processes. Today’s agility is only possible thanks to recent technological advances. In software development, there’s an undeniable dependency between “doing agile” and having cutting-edge technology — containers, automation, and distributed systems like microservices or even serverless.

But technical excellence is also tied to existing infrastructure, or our ability to make the most of it. That may seem trivial today, with all the technology and cloud services available to us, but it isn’t always the case — legacy systems will often be a bottleneck.

For matters beyond technology, agility will surely require areas like talent management, hiring and recruiting, marketing, and sales to move at the pace of production and go-live teams. There, simplified processes and automatic controls become a necessity.

In short, “being agile” and “doing agile” both take a lot of effort — fortunately, team effort. It’s important to first understand where you stand today, and to grasp, at least at a high level, what an agile transformation will mean. Remember, it’s not the same for everyone, and it doesn’t happen at every level at once. How agile is your team, really? Are you ready for a transformation?