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:
Anti-pattern: Our team is agile because it does grooming sessions, sprint reviews, sprint planning, and sprint retro.
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.
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.
Anti-pattern: The performance issue we face is because the design team did not go through SAFe for Architects.
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.
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.
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: