The Agile Altar: Why Software Engineering is a Discipline, Not a Belief System
In 2001, seventeen software developers gathered at a ski resort in Utah and drafted a lightweight, pragmatic manifesto. Its core message was simple: favour individuals and interactions over processes and tools, prioritise working software over comprehensive documentation, and embrace change rather than rigidly following a plan.
It was a necessary rebellion against the heavy, bureaucratic waterfall processes of the era. Yet, in a stroke of profound irony, this philosophy of liberation has been gradually twisted into a rigid corporate dogma. Today, in boardrooms, and development floors across the globe, Agile is no longer a mindset; it has become a religion.
Having spent more than three decades navigating the shifting paradigms of software engineering, from writing raw x86 assembly in the early days to the now task of architecting modern, agentic-first platforms, I have witnessed this transformation firsthand. We have replaced one set of heavy processes with another, wrapping it in a new lexicon and treating deviations from the framework as a heresy. From my perspective, it is time to step back, examine the rituals we have adopted; and return to practical engineering.
The Rise of the Agile Clergy
The shift from being agile to doing Agile has spawned a massive, lucrative industry. We now have certifications, framework matrices, and scaling models like SAFe that rival the complexity of the very systems they were designed to replace.
In many organisations, the Scrum Master has morphed from a team facilitator into a sort of project priest, ensuring that ceremonies are strictly observed regardless of whether they add actual value. When an R&D department is struggling to deliver an overhaul of its development workflows, the dogmatic response is rarely to examine the technical architecture or the specific team dynamics. Instead, the prescribed solution is almost always "more Agile." We are told to strictly enforce timeboxes, adhere to the textbook definition of a sprint, and ensure every ticket is perfectly groomed. We treat the framework as infallible, placing the blame on the engineers for failing to follow the rituals correctly.
Rituals Over Results
When a methodology becomes a religion, ceremonies matter more than outcomes. The daily stand-up is perhaps the most glaring example. Originally intended as a quick, tactical alignment for the development team, it frequently devolves into a daily micro-management status report where developers justify their existence to Technical Leads. Or worse, nothing is actually understood, or meaningfully gleaned.
Sprint planning, and retrospectives, can easily become performative exercises too. Teams spend hours debating the Fibonacci sequence of story points for a minor bug fix, engaging in a bizarre theological debate over the true meaning of an "8" versus a "13". What a waste of valuable time, pure theatre that I've never fully agreed with.
When we prioritise the adherence to these rituals over the actual delivery of value, we lose sight of what we are actually trying to achieve. Software development is not about moving Jira tickets across a board with perfect cadence; it is about solving complex, often ambiguous, problems with elegant code, robust systems, and clear thinking. It's never, ever, as linear as Agile thinks it is.
Velocity as a Moral Virtue
Perhaps the most damaging aspect of corporate Agile is the weaponisation of metrics. Velocity, originally a rough capacity-planning metric meant only for the team's internal use, is routinely extracted by the business, charted on executive dashboards, and used as a measure of productivity.
When velocity becomes a target, it ceases to be a useful measure. Teams will naturally inflate estimates, avoid refactoring, and shy away from necessary technical debt reduction; all to ensure the burn-down chart looks aesthetically pleasing to stakeholders. This fundamental misunderstanding of empirical process control can lead to a culture of gaming the system, rather than engineering resilient software.
Returning to Pragmatic Engineering
If we are to break away from this dogma, we must stop treating software development frameworks as one-size-fits-all linear solutions. The SDLC required to build an experimental, AI-driven agentic workflow is fundamentally different from the SDLC required to maintain a legacy enterprise system of record.
- Context is King: The process must serve the project, not the other way around. If a team operates better using a continuous flow Kanban model rather than two-week timeboxed sprints, they should be empowered to work that way without being accused of "doing it wrong."
- Reclaim the Metrics: Stop using story points as a stick. Shift the focus from output (how many points were delivered) to outcome (how much customer value was generated, and what is the stability of the platform).
- Engineering Over Ceremonies: Excellent software relies on solid architecture, comprehensive QA testing, robust deployment pipelines, and deep technical expertise. No amount of perfectly executed sprint ceremonies can save a poorly architected system.
Agile, in its purest form, is a sensible set of guiding principles. But companies must stop worshipping at the altar of the framework if they are to sccceed in the new era. We need to trust our technical leaders, empower our engineering teams to adapt their workflows to their specific realities, and remember that our ultimate goal is to build great software, not just a perfect burn-down chart.