Agile Isn’t Broken — We Just Stopped Practicing Engineering

Agile didn’t break engineering; it exposed where we quietly stopped doing it. Agile was designed to shorten feedback loops and surface risk early. But in many teams, it became a substitute for engineering discipline rather than a framework that depends on it. Ceremonies scaled easily—standups, sprints, retrospectives—while harder practices that require deliberate time and technical ownership slowly eroded.

Infrastructure and database engineering are where this erosion shows up most clearly. Practices like intentional schema design, explicit migration planning, and backward-compatible data changes often gave way to “we’ll fix it in a later sprint.” Database indexes are added reactively instead of modeled up front. Query performance is discovered in production rather than load-tested in staging. Stateful systems demand careful coordination and deep understanding, yet Agile workflows often assume everything is as malleable as stateless application code. The result is operational fragility hidden behind abstractions until traffic, data volume, or latency make it visible.

Many experienced engineers have been making this point for years. Martin Fowler has repeatedly emphasized that Agile only works when paired with strong technical practices like refactoring and continuous design. Charity Majors has argued that speed without observability and operational discipline is an illusion. Michael Feathers’ work on legacy code reminds us that systems become hard to change not because of age, but because they lack tests and clear structure. This post isn’t a rejection of Agile—it’s an extension of those ideas into the infrastructure-heavy reality most teams live in today.

The missing piece is that engineering practices must be explicit inside Agile, not assumed. Design work should be visible in the backlog: schema reviews, migration strategies, capacity modeling, and failure-mode analysis deserve first-class tickets, not side conversations. Definition of Done should include infrastructure criteria—safe deploys, reversible migrations, performance budgets, and verified rollback paths. Sprint planning should account for engineering risk, not just feature scope, and retrospectives should examine technical signals like incidents, query regressions, and operational toil.

Product owners and managers play a critical role here. They reinforce engineering discipline by making space for it and by treating system health as product value, not overhead. When leaders ask about reliability, data integrity, and long-term cost—alongside features—they signal what actually matters. When they protect time for refactoring and infrastructure work, teams stop treating engineering excellence as optional. Agile works best when product and engineering share responsibility for outcomes, not just output.

Agile isn’t broken. But without intentional engineering—especially in databases and infrastructure—it becomes theater. The teams that succeed aren’t faster because they cut corners; they’re faster because they never stopped doing the hard, unglamorous engineering work that makes change safe. 

References

Fowler, M. (2018). Refactoring: Improving the design of existing code (2nd ed.). Addison-Wesley Professional.

Fowler, M. (2001). Agile software development: Principles, patterns, and practices. Prentice Hall.

Feathers, M. (2004). Working effectively with legacy code. Prentice Hall.

Majors, C. (2019). Observability engineering. O’Reilly Media.

Kim, G., Debois, P., Willis, J., & Humble, J. (2016). The DevOps handbook: How to create world-class agility, reliability, and security in technology organizations. IT Revolution Press.

Humble, J., & Farley, D. (2010). Continuous delivery: Reliable software releases through build, test, and deployment automation. Addison-Wesley Professional.