Critique of Agile and Architecture Misconceptions
Many organizations believe they are practicing Agile, but few truly understand its underlying principles.
After reading yet another headline proclaiming “Agile is Out, Architecture is Back!”, it became clear that many critiques fundamentally misunderstand both Agile and architecture.
Articles like this rely on a familiar pattern: “The thing I see today is bad, so we should go back to the thing that came before it.” We’ve seen a wave of these recently, including:
“Kubernetes is too complex - return to simpler infrastructure.”
“Microservices create more problems than they solve - go back to monoliths.”
“Serverless is the future - stop managing clusters altogether.”
In one of the opening paragraphs, the author claims that Agile says “Shipping fast was more important than getting it right the first time”. They attribute this to the manifesto’s value of “working software over comprehensive documentation.” That interpretation is not just a stretch - it’s simply incorrect.
In fact, two of the twelve Agile principles explicitly contradict the author’s claim:
Continuous attention to technical excellence and good design enhances agility.
The best architectures, requirements, and designs emerge from self-organizing teams.
The real problem I’ve seen is that technical managers often don’t - or can’t - create the conditions for good engineering practices to thrive. If strong architectures emerge from self-organizing teams, as the principle says, then the layer above them - the Software Engineering Manager - becomes critical. Without adequate coaching, autonomy, and runway, teams cannot uphold architectural quality.
An SEM’s role is to protect teams and reinforce that technical excellence is a first-class priority aligned with the organization’s vision. When a team member raises a concern like “I’m not sure this architecture will scale,” leadership cannot respond with, “We don’t have time to fix it.” If we claim we don’t have time for technical excellence, it’s usually because we created arbitrary timelines that never should have been committed to in the first place. Yes, Agile encourages preference for shorter timescales - but only when choosing the right change for the right reason.
The path forward is ensuring SEMs have the authority, responsibility, and support to uphold these principles. Senior leaders must make technical excellence and sound architecture part of the organizational vision - not an afterthought. If you want Agile to work, you must follow its tenets before declaring the model broken.