Let’s begin with an odd sounding question: when is Agile not actually Agile?
If you've ever been in an Agile business that seems to be following all of the rules, but is still missing something, you know this question isn't really all that odd. When teams struggle to get the results they want, they can often get stuck wondering whether the problem is with Agile itself or how they're implementing it.
That’s why you need to go beyond a simple focus on following Agile practices, and also consider the outcomes you're hoping to achieve by becoming an Agile business in the first place.
This moment of introspection will help you avoid getting stuck in “fake Agile” (more on that later), and generally get the most out of your transition to Agile ways of working. Review your business alongside these five traits and see if you're actually Agile.
It’s no secret that, driven in part by technology, business is moving faster than ever. Globalization is making even long-stagnant fields more competitive, and businesses are being forced to adapt and change at an ever-increasing pace.
As events like the Covid-19 pandemic have further strained businesses, the benefits of Agile have become clearer than ever. From its origins in the early 2000s, Agile has always been focused on addressing the real problems businesses face.
It’s no wonder that even areas outside of IT, like marketing, are seeing a huge uptake in Agile use.
But right alongside the growing popularity of Agile has been the danger of half-measures, misunderstandings, and other problems leading to businesses failing to get the benefits of agility.
That’s why it’s critical to look at these five traits. They’re what sets truly Agile businesses apart from those that are just going through the motions.
Far too often, managers assume that just because everyone is ostensibly working towards the same goal that they must also share a purpose and vision.
However, that’s far from the case.
That’s why the first value of the original Agile manifesto calls out a shared focus on creating value for stakeholders. Despite being a core tenet of Agile, this shared value too often gets overlooked as teams fall into the trap of using Agile practices for their own sake (or simply to please managers).
In other words, you can have a shared purpose, but if it’s the wrong one, then you’re still going to run into trouble.
So what does a lack of shared purpose look like in practice?
Often, it’s when some team members are interested in pleasing the customer while others are focused on appealing to their manager, that lack of alignment is going to create conflict, inefficiencies, and a bad internal culture. These members might say they’re aligned and working towards a common goal, but closer inspection frequently shows otherwise.
Ultimately, this shared purpose and vision is the foundation of team alignment. So, if you’re having trouble getting your teams aligned, consider whether the real issue is either a lack of this shared purpose, or that the purpose itself is wrong.
Agile isn't just about what people do, it’s also about why they do it.
Even the best Agile process in the world can’t bring benefits if the final output doesn’t produce value for the stakeholder. That’s why truly Agile businesses map the value stream before beginning a project.
Are you noticing that team members get stuck in their work or don’t feel they have clear direction? Throwing your work onto something like a Kanban board isn’t going to necessarily give you the individual empowerment your team members need to self-manage.
In fact, that shiny new board might just function as a fancy way to show you that things aren’t actually progressing as planned.
An effective Agile business will have a people-centered culture which eschews hierarchy and emphasizes accountability.
Consider what happened the last time something went wrong on your team.
Was there any accountability (not the same as punishment)?
Were any changes made in response to the pitfall?
If you answered "no" to either of this questions, you may be falling short of this Agile trademark.
The big picture here is that implementing Agile isn’t always easy. Doing so without flat structure, explicit policies, and accountability robs your teams of the incentive to get Agile right.
After all, why bother if things don’t change in response to challenges and learnings? Just remember that the purpose of these elements is ultimately empowerment. Flat teams with clear structures and ground rules developed by the team members are more empowered to try new things, fail fast, and learn.
Empowerment is great, but you still need to ensure people are empowered to do things that will bring the stakeholder the value they need.
That’s where experimentation and feedback loops come into play.
If your teams aren’t growing and evolving based on real experiments, you’re missing out on a critical Agile business fundamental. Remember, you’re empowering team members so they won’t be afraid to try things and learn from them.
What you’re aiming for is to nurture teams that see experimentation as just a regular part of their work, not an exceptional thing they are forced to do from time to time.
You should be able to check in and ask about ongoing experiments and recent learnings. If you ask and get a blank stare, that’s a big red flag that there’s a gap in the Agile mindset of your team.
But you also shouldn’t be fooled into thinking that this kind of speed comes at the expense of stability, quite the opposite. The key is to combine agility with the stability you get from that shared vision, greater visibility, and improved culture.
So those experiments don’t mean constant change, but constant development instead.
Infighting, tribalism, and a focus on blame when something goes wrong are all clues that you might be lacking in this Agile fundamental.
Or, as the Agile Manifesto puts it, “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” All of that work building stable, flat, and empowered teams is deeply connected to the ultimate goal of building a trusting culture.
Try asking team members what they think about their team and projects.
Do you hear language that indicates trust in the team and its individual members? If not, then this should be a major area of focus. A lack of trust can easily undermine progress made in other areas of Agile, so it’s not something you can ignore.
In fact, it’s the basis for any high-performing team with or without Agile
What exactly should you do if you find a lack of trust on your teams? Frankly, this most often points to other problems, as increased trust should be an outcome of getting the other things on this list right. So look for trust as a part of a larger check for everything on this list. If you find something that’s lacking, focus there and see if addressing it improves trust.
You should also consider improving your own leadership capabilities to help improve trust within your teams. Leading by example is always one of the best ways to change an internal culture.
Too often, businesses implementing Agile focus too much on technology. But it’s still critical and therefore on the list.
Without nailing the other four trademarks, all the amazing Agile tech in the world just isn’t going to help you. That’s why, instead of starting with a focus on tech, it should come later.
But what is the Agile business approach to technology compared to any other business?
The shift is from seeing technology as a series of support tools built around specific tasks to something seamlessly integrated into a team’s work. So whether you’re talking about tools for visibility or communication, the functioning of the team without them should be unimaginable.
Often this means digitizing traditional products or switching to more modular technologies capable of evolving alongside your team. But regardless of the specifics, the technology you use needs to be adaptable enough to handle the experimentation and evolution that’s so critical for Agile businesses to function.
Taking all of this together, you can see the danger of thinking that you’re an Agile business while actually missing critical fundamentals.
This is what’s commonly referred to as “fake Agile,” and it’s a worst-case scenario you want to avoid.
The problem is that falling into the fake Agile trap can easily poison the well, convincing team members and stakeholders that Agile doesn’t work for them. To quote Steve Denning from the article linked above:
“Some instances of supposedly agile management have as much relation to real Agile as someone wearing flamenco costumes and talking about flamenco, without having mastered flamenco dance steps or displaying a feel or flair for flamenco music.”
The result of this is businesses going through all of the trouble to implement Agile without reaping the benefits.
In other words, you spent a lot of money on that flamenco costume without ever learning to dance in it.
That’s why it’s so critical to use the five trademarks listed here to identify areas where you might be falling into the fake Agile trap.
Of course, all of this brings us to the final question, what should you do if you find yourself lacking in one of these areas? Start by going back to the Agile fundamentals, focusing on ensuring you're developing the mindset and not simply going through the motions.
It’s also worth noting that you should be communicating that Agile is a process, not a switch.
If you’d like to learn more about business Agility, we’ve got a self-paced intro course for non-technical teams to get you started.