Back to Basics
Agile methodologies have grown increasingly complex—so much so that they often distract from their original purpose: delivering working software early and often as The Cathedral and the Bazaar would tell you. That’s it.
Every few years, the software industry experiences a backlash—a reaction to excessive formalization, just as Agile once was. This isn’t new. It’s simply the pendulum swinging back and forth, as it always does when things go too far in one direction - complex systems tend to dynamic equilibrium. We’ve once again overcomplicated the development process, and another course correction is likely on the horizon. Another rebellion against bloated processes is coming.
At its core, Agile constantly wrestles with a tension between rigid process and simply delivering functional code. Developers often believe they can build great software independently—and sometimes they can. But what’s the point of building amazing software in isolation if no one uses it or it solves no real problem? On the flip side, when project managers operate unchecked, they tend to design elaborate systems that box developers in—leading to even stronger resistance from the people doing the actual coding.
Meanwhile, large enterprises have started turning Agile into a tool for vendor lock-in. These companies adopt heavily customized Agile frameworks as part of consulting packages. The methodology becomes the product, and the teams begin to view their work exclusively through that lens. It keeps evolving, requiring more training and new consulting engagements—much like a life coaching funnel, where each new level brings more complexity and a higher price tag.
The industry constantly swings between extremes: strict structure versus total flexibility, narrow specialization versus generalist skills. The truth is, both approaches can work depending on the context. But in agile software development, we need to return to the fundamentals. Agile should be about lean thinking and trusting your team to deliver. If you don’t trust them, why did you hire them?
Yes, we should standardize where it makes sense - but not at the cost of free collaboration. Over-engineered processes (processes always tend towards over-engineering - it's Parkinson's law) and tools shouldn’t get in the way of people doing their jobs. Like much of engineering, success lies in balance like Aristotle would say.
🤔 Just look at some of these bloated Agile diagrams.
SAFe, LeSS, Nexus, Disciplined Agile Delivery (DAD), Spotify Model, Scrum@Scale, Enterprise Scrum, FAST Agile, OpenAgile, JIRA Align Framework, Agile Portfolio Management (APM), RAGE (Really Agile Group Effort) and others 😊.
Where are the developers in all of this? No one wants to be pushed to the margins of a process — especially in an industry named after what they do.