Agile Myths

Introduction

During my career as a software developer I’ve run into a lot of folk who have differing ‘opinions’ on what Agile is. There always seems to be various factions at an organization that view Agile from different perspectives. A lot of them are, at their core, entirely misguided and misunderstand the principles and values of Agile. They’re actually quite simple:

The Four Values

The Twelve Principles

All in all, it’s about sixteen sentences worth of reading. Transitioning organizations (or existing “Agile” organizations) will spend countless millions of dollars in effort to transition their organization, with managers leading the way - yet few people can be bothered to read sixteen sentences in order to make it more successful.

Here’s what Kent Beck, one of the original signers of the Agile Manifesto, had to say about it’s adoption as of late 2020.

It’s a devastated wasteland. The life has been sucked out of it. It’s a few religious rituals carried out by people who don’t understand the purpose that those rituals were intended to serve in the first place.

Ouch… That’s not a good look. So what has happened?

The Theoretical

Organizations have jumped on the Agile bandwagon, viewing the success of the few organizations that have adopted Agile successfully and transformed their organizations but not understanding all the internalized change that happened out of sight in order to get there. These “better-than-not-doing-it” Agile organizations follow Zombie Agile and it’s exactly as it sounds - a lifeless, soulless, shambling corpse of what it truly could be.

Largely, this stems from organizations want for the benefits but its own inelasticity to change to make it happen. I mentioned above people’s inability to read sixteen sentences - yet asking for actual training, coaching, and investment ($$) long-term into change? Short-term pain, introspection, and reduction of output for long-term benefit? Wait, hold up. Pump the breaks - we can’t stop normal work!

And so many organizations and management go into their transitions with what they feel like Agile is. A blindfolded brick layer laying bricks underneath their feet as they walk; entirely unguided and forging a path that might be forward, but can also be sideways or even backward.

Worse case is organizations that do invest in all of the above but still cannot confront their own inability to change. What begins as an organization making a motivated, hopeful dive into the deep-end of change ends up swimming back to the shallow end over the weeks and months ahead. People working there, already likely resistant to change because of existing cultural factors, become tired of the constant switcheroo. Additionally, the organization likely drew lines in the sand that could not be crossed before the transition ever started - lines that Agile demands to be crossed. “Roles have to stay the same”, “We still need to work on multiple things at the same time”, “Agile change is only scoped to the IT department”, “We can’t organize into product teams”, etc..

And so things slip away and backslide to realms more comfortable to management. Where they didn’t have to confront hard empirical truths, have tough conversations with people, nor spearhead and champion experiments that will likely fail. The old ways come singing a sweet song of easier times and its tune is enchanting.

So what are some myths that people in both of these organizations - the blindfolded brick layer and the tired, enchanted swimmer - have in common?

The Practical

My six most common myths of Agile

“Hybrid” Agile

This is my #1 most commonly heard misunderstanding of Agile. It’s not even close. The amount of times I’ve asked about “Agile” only to see manager’s faces contort and sputter off something like “I don’t think anyone is truly Agile” and then go into detail about how their organization is “hybrid Agile” is so common it could be an economic currency. The higher up in management you go the more prevalent this likely is and the more dangerous it is.

It’s one thing to admit that your organization is not perfectly Agile. It’s another to embrace that state of non-perfection.

I’ll put it simply -

Hybrid Agile is bullshit.

Hybrid Agile is bullshit.

Hybrid Agile is bullshit and you are lying to yourself if you think hybrid Agile is real.

The Agile values are foundational to each other, same with the principles. They build and multiply each other and each exist to fill a gap left by another. Picking and choosing causes the entire thing to collapse and we instead get “better than not doing it results”. We don’t build houses without four corners to the foundation, and we cannot build an Agile organization without the four values either.

A common adoption failure is that organizations will bend Agile around what they already do today. Agile is about shaping your organization to be flexible, to have that business agility, to be able to change at the drop of a dime yet instead organizations will shape Agile around how the organization already operate at great adoption cost and little gain. All the same process, all the same tools, all the same roles – maybe a little relabeling but at its core did anything really change? Why adopt Agile at all if, at our core, we don’t want to change?

Scrum Is The Same Thing As Agile

I’ve found this most within teams practicing Scrum inside of Zombie Agile organizations.

Again, I’ll ask you to reflect back on the principles and values. What are any of those really prescribing you to do? Nothing, it’s open-ended.

Scrum on the other hand has the Scrum Guide. Longer than the Manifesto, it’s still only a dozen or so pages and there’s little excuse the entire team hasn’t read it if you’re practicing Scrum.

Scrum has its own set of values:

• Openness
• Courage
• Commitment
• Respect
• Focus

Let me be clear, however -

Agile is not Scrum. But you cannot practice Scrum without being Agile.

Agile is in the eye of the beholder / Agile has many interpretations

This is just flat out wrong. I imagine this mindset coincides very deeply with the myth above (Scrum is the same thing as Agile) and people assume some very conflicting things from it.

I’ve heard this at all levels and roles - management, developers, POs, etc. - believing that the non-prescriptive mindset of Agile means that they’re free to do whatever they want. “Whatever works best for us”, they will say. This is a fallacy and can easily be the most damaging to the entire transition effort and a team’s personal growth.

“Whatever works best for us” is short for “whatever works best for working with the organization today” - which is what organizations and teams don’t want to be conceding. The best thing that works for the organization today is the existing structure because it’s whats already there. Is what already exists truly the best thing though? Almost never.

Most “Agile” organizations are practicing Scrum and Scrum is very prescriptive on how it wants teams to perform its rituals, the roles involved, and how to invoke evolutionary change.

Agile Is A Magic Bullet

Often the people who bring out the pitchforks and torches demanding Agile alignment are those, like myself, doing the work everyday.

However, an easy trap to fall into is thinking that Agile is going to solve everything simply by management saying “Yes”.

It is not going to fix organizational problems. However, it will do a great job at highlighting them. With its focus on empiricism, it will shine light into the dark recesses of processes, culture, roles, etc.. This can be hard for organizations and for people to face data-driven truths about how work is done and the path to change.

Agile Is An End State

As people cycle through, grow in their careers, and as the world changes around them, people will reshape their understanding of how they do their work, what is valuable to them, and how to best tackle the problems faced each day.

People, through internal and external forces, will change every day for the rest of their lives. Lying to ourselves and participating in magical thinking by acting like this isn’t happening is a core anti-pattern to being Agile.

All too often organizations that transition will treat it like they’ve always treated anything else - as a project. One with deliverables, specification sheets, and - most damaging - end dates. Unfortunately, being Agile never has an end date.

If you’re planning on cooking eggs because you’re hungry, but then realize an egg sandwich sounds better – do you still only cook the eggs? No! You adapt, get the toaster out, grab some cheese and slap that bad boy together. Lots of things in real life you are already Agile about and you just don’t think about it in that way.

All organizations are on a journey. Hopefully all of them know where they want to be as an organization in the future. Some organizations have only dirt roads to drive on which are limited in speed and can be awfully dangerous and muddy when the weather is bad. Being Agile is instead driving on a concrete road - more resistant to weather, a heck of a lot more sturdy, and the ability to go very fast.

Agile Is About Managing Projects/People Better

This is untrue but I’ll admit it can seem that way. The original Manifesto was created by sixteen developers who were fed up with the existing status quo. They gathered in Utah and forged a document that, at its roots, is about software craftsmanship.

The key part of being Agile is about developers and their level of professionalism and craftsmanship. As Kent stated above, the Agile movement has been sort of taken over by malevolent forces and so many have appended on a new manifesto called The Software Craftsman Manifesto.

Not only working software, but also well-crafted software

Not only responding to change, but also steadily adding value

Not only individuals and interactions, but also a community of professionals

Not only customer collaboration, but also productive partnerships

If you’re a developer, here’s some questions for you:

• Are you writing tests alongside your production code?
• Are you taking your time to write clean, maintainable code?
• Are you collaborating with other members on your team to craft solutions that are the best for everyone?

If any of these made you wince it might be time to take a look in the mirror and see how you can be the change you want to see.

Honorable Mentions

“The Agile Methodology”

This is largely covered in “Scrum Is The Same Thing As Agile” and ““Hybrid” Agile” but Agile is a mindset. Like “Scrum Is The Same Thing As Agile”, I believe this boils down to people combining all of these into one thing and believing them to be the same.

Some Notes

It’s sixteen sentences. Memorize them, reflect on them, and adhere to them if you believe in them. It’s not hard. Everyone will be better for it.