The phrase „post-Agile“ gets thrown around a lot. Sometimes it means a team has outgrown ceremonies and found something better. More often, it means someone is packaging old ideas under a new name.
But what if neither is quite right?
What if the discipline that high-performing software teams are quietly converging on isn’t new at all – it’s just engineering, done properly?
At Agile Tour Vienna 2025, Dave Farley – author of Modern Software Engineering and Continuous Delivery, and one of the most practically grounded voices in software development – made exactly that argument. This article unpacks it, connects it to the data on what actually separates high-performing teams from the rest, and asks the question most Agile conversations avoid:
What does it actually mean to engineer software well?
Farley opens with a definition he defends word by word: engineering is the application of an empirical, scientific approach to finding efficient solutions to practical problems.
Not bureaucracy. Not documentation. Not certification. The application of a scientific approach.
This matters more than it sounds. Most software teams treat development as a production problem – how do we move faster, ship more, clear the backlog? But if you start from that premise, you optimize for output. And output is almost never the constraint. Understanding what to build, and building it in a way that can evolve, is where most teams actually struggle.
Farley’s book makes the case that software is fundamentally a design discipline – not manufacturing. The implications of that distinction cascade through everything from how you structure teams to how you evaluate quality.
The Modern Software Engineering framework distils the whole discipline into two things: optimizing for learning and managing complexity. Everything else – every practice, every tool, every ceremony – either serves these two ends or it doesn’t.
Five principles support learning: iteration, feedback, incrementalism, experimentation, and empiricism.
Five principles support complexity management: modularity, cohesion, separation of concerns, abstraction, and loose coupling.
None of these are new ideas. What’s new is the framing – treating them not as best practices to be adopted when convenient, but as the foundational logic of the discipline.
Software is fundamentally about uncertainty. You don’t know exactly what customers want until they use something. You don’t know if your architecture holds until it’s under real load. You don’t know if your approach works until you try it.
The practices that survive Agile’s brand collapse – continuous integration, short iteration cycles, automated testing, continuous delivery – survive because they are mechanisms for learning quickly. They shorten the gap between „we think this is right“ and „we have evidence this is right.“
DORA research has been making this concrete for years. Organizations that deploy frequently, recover from incidents quickly, and keep change failure rates low aren’t trading speed for quality. They’ve found the same thing. Fast feedback loops and high quality turn out to be the same property, not a trade-off.
Which means: if your team is treating speed and quality as competing priorities, the problem isn’t prioritization. It’s the feedback loop.
This is where Farley is at his most useful, and least fashionable.
Modularity, cohesion, separation of concerns, abstraction, loose coupling. These have been principles of good software design since at least the 1970s. They appear in structured programming, in object-oriented design, in every major architectural pattern. And teams still routinely violate all five of them – because the pressure to ship overrides the discipline to design.
TDD, in Farley’s framing, isn’t primarily a testing technique. It’s a design technique. Writing a test first forces you to define what a piece of code should do before you write it – which forces the kind of clarity about interfaces, dependencies, and boundaries that produces modular, loosely-coupled systems. The O’Reilly edition of the book goes deep on why this works at both the micro and macro scale.
The uncomfortable implication: complexity management isn’t a phase of the project. It’s either a continuous discipline or it isn’t happening at all.
Farley’s most memorable line from the talk:
Quality is determined by the ease with which you can change your software. Nothing else matters.
Not performance. Not reliability. Not security. All of these are important – but the only durable path to any of them is writing software that can evolve. A system you can’t change is a system you can’t fix, scale, or secure over time. A system you can change can become anything.
This is a provocation, and it’s meant to be. It cuts against the instinct to define quality as the absence of bugs, or as performance benchmarks, or as test coverage percentages. Those are measurements. Quality, in Farley’s framing, is structural.
One question that came up from the audience: does AI change any of this?
Farley’s answer was clear. AI accelerates code generation. It does not remove the need for engineering thinking. The bottleneck in software development has never been typing speed. It’s the clarity of thought required to specify what you want, decompose it properly, validate it rigorously, and integrate it with everything else.
AI lowers the cost of producing code. It raises the stakes for getting the thinking right. Teams that have strong engineering discipline – that understand complexity management, that write testable code, that build with feedback loops – will benefit enormously. Teams that were already unclear about what they were building will now be able to produce unclear software faster.
If you take Farley’s argument seriously, the question stops being „are we doing Agile correctly?“ and becomes „are we learning efficiently, and are we managing complexity well?“
Those are harder questions. They don’t have ceremony checklists. The Certified Scrum Master training with Mitch Lacey is worth approaching in exactly that spirit – not as a framework certification but as a grounded context for understanding why the principles behind iterative delivery actually work. The Software Architecture Foundation Level Training sits alongside it for teams who want to take the complexity management side seriously.
The „post-Agile“ era doesn’t need a new name. It needs the same things good engineering has always needed: rigorous thinking, short feedback loops, honest measurement, and design discipline applied at every level of the system.
This talk was recorded at Agile Tour Vienna 2025. The 2026 edition is live – the full program is available now.
Build your solid foundation through our training and continue developing your leadership and coaching journey.