intuitem
articles

7 reasons why "Agile" is dying (and why it's a good thing)

Abderrahmane Smimite •
#agile#scaling#methodology

Based on personal experience, research, and a lot of intense discussions with fellow agilists and people involved in Software Development, here is a summary of what I believe is broken about the current state of Agile (yes, the marketing noun with the capital A) that I have tried to illustrate through real-life examples.

I promise that this is not just a microwaved version of Dave Thomas’s 2015 talk, which you should definitely check 😊 Let’s dive in:

  1. It’s becoming more about methodologies rather than common sense core values: most likely, when you’ve read Agile, you were thinking about Scrum, kanban, SAFe, etc., rather than the Manifesto for Agile Software Development, the X over Y pattern, and why it was created.

Anti-pattern: Our team is agile because it does grooming sessions, sprint reviews, sprint planning, and sprint retro.

  1. It’s becoming more about tools rather than why we use them. It must be more than just filling some exotic Jira fields that someone who’s not even on the project anymore copied from somewhere on the internet.

Anti-pattern: The issue is that we need an extra field to track this on Jira, add more steps to the workflow and buy this plugin to create an adaptive view. Scratch that; what’s blocking our agility is that we don’t have the right to create a new Jira project.

  1. It’s becoming more about packaging software delivery into something controllable and understandable by the exec level: how much does it cost for 5 kilos of Story points? We have been twisting concepts such as commitment and ownership for a while now.

Anti-pattern: The transformation office has noticed that on the last PI, predictability has dramatically decreased, which means that the Teams are not Agile enough.

  1. It has become a well-established industry that has drifted toward collecting (and renewing!) certifications and badges on LinkedIn rather than going through the actual practical iterations. Don’t get me started on McKinsey and other big consulting companies. It’s ok to make a living out of Agile, I am a consultant myself, but this mayhem and noble concepts distortion have to stop.

Anti-pattern: The performance issue we face is because the design team did not go through SAFe for Architects.

  1. It has become chiefly this weird trend about branding projects and organizations as modern and state-of-the-art without being willing to go all the way to apply the principles across the whole organization, especially with “Agile @Scale.”

Anti-pattern: We hired Agile coaches. They are the new managers; accordingly, you must obey them from now on. The company will use sprint metrics to monitor productivity and team efficiency. Also, the project managers are now the scrum masters for department A and the Product Owners for department B.

  1. Agile becomes mostly about speedy, broken MVPs rather than actual working software. Yes, we need to experiment fast but let’s call it just that, an experiment, proof of concept, proof of value, or whatever you are comfortable with instead of shipping non-quality in the name of agility.

Anti-pattern: sure, this microservice could break with ten users. We’re not sure, it was not tested, but it should be enough for v1 (yes, usually in the passive voice). We need to be Agile to meet Time To Market requirements.

  1. Some teams refuse to adapt to new factors and adjustments in priorities in the name of Agile. Some typical sentences are within the lines of “it doesn’t fit with this sprint or this PI, it has to go through sprint grooming and planning sessions, we cannot work on unscored topics, etc.” I get the motivation behind that, but the narrative is often wrong and associated with a poor choice of wording.

Anti-pattern: Sorry, security team, we cannot handle the findings of the pentest. We need to ship these almost-done features in the next 4 to 6 months, and we’ll have time then to recover this technical debt.

The TL;DR version is that I believe that what companies and teams are perceiving today as “Agile” has drifted away from its core values toward tools, ceremonies, metrics, and prepackaged concepts, which contradict the initial intent. In the grand scheme of things, I believe it is a good thing as all of this is just a big iteration: kanban, scrum, scrumban, SAFe, etc., all are experiments that just happened to last a bit longer than expected. What matters now is where we can take it from this point and shamelessly learn from what didn’t work. Here are some random thoughts on how you can “denoise” your workflows: Start by unlearning “Agile” and review the agility values. These values are pretty straightforward, so don’t over-engineer it: identify value, build through small incremental steps, make sure that your design choices can evolve in an optimal way, learn from previous attempts, and repeat (aka the late 50’s PDCA principle) Context matters: Agility is not a one-size-fits-all recipe, and you need to adapt it to your project/product/organization. There are good things to cheery-pick from the existing frameworks, methodologies, and tools. Agility is the most efficient when understood and adopted across the whole organization. Always keep an open mind for uncertainty and unexpected events to adapt and possibly even thrive.

Bonus: if you hear a big company promoting a “packaged” Agile transformation Office or Program, just Run!

Some good references:

← Back to Blog