Agile is dead! Long live Agile!

I don't believe Agile is dead, but I do think it warrants a discussion on what is Agile, the Agile Manifesto, and why after 19 years, it is still misunderstood.

I've seen a few articles recently, the most recent being "Agile software development is dead. Deal with it." by Jason Bloomberg, which you can read at the link below. Note that when I quote from the article, it might be him quoting other people, and not necessarily Jason's views. I do not know Jason, and I'm not trying to discredit him or his article; I am using it as a launching point for discussion and would love to hear back from him, and more importantly, from you, the reader. Thank you in advance for taking the time for this!

I disagree; I still think Agile has plenty of use in this world, just like Waterfall has a place. And for a majority of complex projects, Agile is still the King. Long live the King!

Don't Do Agile. Be Agile!

Unfortunately, I often see companies that want to DO Agile. You can't DO Agile, you have to BE Agile. Agile is a philosophy, a mental model; it is about changing your view of the world. As a consultant, when approached by companies that want "to do Agile", I usually have them step back and rephrase their request without using the word Agile in it. Tell me WHY they want do X, tell me WHAT they want to accomplish, WHAT business value are they expecting to come from this. Then we can come up with ways to reach that goal, in an Agile mindset, possibly using one of the Agile frameworks that are available to us. The HOW is developed by the team, under the guidance of Agile Coaches (including Scrum Masters), and may need to be tailored to your organization.

I live a life of Agile. I coach it, attend Agile meetups, even keep a personal Kanban board. I time box things. I do weekly and monthly personal retrospectives. I even plan my vacations using an Agile approach. Why? Because it works for me, and I get value from it.

Response to Counting Agile's Flaws

My first concern is the sentence "Tools have improved, providing better automation and collaboration." The first key value in Agile is "Individuals and interactions over processes and tools." Be sure that individuals and interactions are occurring organically, and that the tools are only there to help. Many times I see organizations where tools and processes are forced, which goes against the first value of the Agile Manifesto.

The article mentions failure due to "a rigid organizational structure that has been created by introducing Scrum teams." It also states that "I’ve seen creative lights dimmed and inspired spirits dampen because people are forced to work within the confines of their organization’s Agile standards." That's a red flag there, as teams should be fluid, not rigid, and confines implies that change isn't possible. Any good Agile Coach or Scrum Master should be looking for such breaking points, guiding the teams and executives around them. Stifled work due to the organization's Agile standards? Then the coaches need to be diligent in noticing that the standards may need adjustment. One great way of doing this is with Communities of Practice. This fosters improvement and learning from each other on delivering business value.

Another issue mentioned in the flaws section is the belief that Agile is about cranking out working software quickly. That's not what Agile is about.

Agility is about the speed at which we can change.

It is about getting feedback loops and correcting course in complex systems. Faster release of quality software that provides value is an outcome of this. If it isn't providing value, then you're already missing out of the first principle of the Agile Manifesto.

Response to Problems scaling Agile

The next issue listed is with scaling. SAFe seems to be the only mention here, but there are plenty of other frameworks (LeSS, DA, Nexus, Spotify, Scrum at Scale, and more). I am SAFe SM certified but by no means would I say it is the best solution; the answer to this problem is it depends on your organization and where you're at in your Agile journey.

There is a local organization that does tours about their Agile practice, with between 500 and 1000 employees, that doesn't use any of the known scaling frameworks. Why? Because they are still figuring out what works best for them, and they want to get it right, which tells me they are on the right path to scaling Agile.

To say "The problem is found in Scrum", then I would say you're not doing Scrum right, or maybe Scrum isn't the framework that you need to be using. Which means you aren't doing Agile right. I might go as far to say that what you're doing is garbage.

Garbage scaled is exponential garbage.

Start with getting things right. Start with transforming one team, and not necessarily with Scrum -- could be Kanban, Lean, or a hybrid -- a good coach will work with the team to find the right path. When they start having a sustainable pace, quality software with less bugs, trust within the team, etc, then other teams are going to notice. They are going to say "hey, I want that!" At that point, start transforming other teams. Start doing business agility. What works for one department (development) might not work for another department (marketing). Explore. Remember the last two principles of the Manifesto: "The best architectures, requirements, and designs emerge from self-organizing teams. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

Response to Getting to the heart of the problem

The author then talks about the elephant in the room: (lack of) diversity. Here's one thing we definitely agree on -- the need for diversity! However, I don't think this is a problem with Agile or the lack of the Manifesto mentioning it. Inclusiveness and diversity go hand in hand with highly successful teams, Agile or otherwise.

I think it is a problem with corporate culture. Hire people that are exactly the same, and you have a hive mindset. And much like how lack of biodiversity can be taken out by a single virus, a lack of corporate diversity can be taken out by not seeing the world in a different way than competitors, or loosing sight of what the customer needs might be. And you will recall, my definition is:

Agile is about changing the way we view the world.

Perhaps the author is right about there being a problem with the "17 middle-aged white guys [that] put together the Agile Manifesto" being a homogeneous group. However, I know one of those guys personally, and he will tell you that there was a lot of input from women leading up to this, working with them in various teams, gathering input from them. He is all about inclusiveness and diversity. He will also (jokingly?) say, and I am paraphrasing here, "we got together to eat and drink beer, and this is what came out of it." Please read the History: The Agile Manifesto to get further reference.

I notice the author mentions there are "better, more modern philosophies of how teams can best create software are where we find the greatest success overall." And that "The obvious conclusion, therefore, is to realize that Agile has run its course and it’s time to relegate it to the dustbin of history." Yet he doesn't link through or mention any of these. If anyone knows more about these, I'd love to learn more!

In Summary

Agile is long from dead, and has plenty of good uses. It is great for working towards value in any complex system. Is the Agile Manifesto perfect? No. Don't quote it like a bible nor be rigid in the interpretation. Use it to guide you, and be flexible in your journey. Should it be updated? Perhaps. Or we can take it with a grain of salt and do what works for us and our organizations.

Avoid being stuck in tools, processes, or frameworks if they aren't working for you.

Avoid snake oil consultants with the promise that Agile will fix all your problems. If you have an inflexible company culture, a lack of diversity, a closed mindset, Agile will not work for you.

The key to agility lies in feedback.

Whether it is Scrum, Kanban, or other, feedback is critical in complex systems. You need fast feedback. You need to be open to change due to this feedback. Go back to the heart of Agile (Collaborate, Deliver, Reflect, Improve), through short iterations with as much feedback as needed, and you're on the right path.

Agile isn't a goal to be reached. It is a philosophy, it is continuous collaboration, it is delivering value, it is reflecting on the work done, learning from that and improving on it. It is an endless cycle, and I think it is beautiful and worth doing, both professionally and personally.