Agility Beyond Stand-ups: An Engineering Approach to Results-Driven Agile

In this article we look at how engineering teams can use agile principles to drive engineering excellence in an effective, result-oriented way. There are plenty of good resources describing how agile practices and frameworks work from an engineering-management perspective — so today I want to focus on the engineering side of agile: how an organization's engineering infrastructure must reflect agility through its value-delivery process.

First things first — what do we really mean by agile? There is a clear and unambiguous definition in the Agile Manifesto, published in 2001. It is a simple set of principles and values to guide software development toward building better software.

We all agree that agile software development is about delivering working software faster through continuous feedback loops, enabling continuous learning and improvement. But the factor that separates people who know agile from people who do agile is whether the organization's underlying infrastructure — CI/CD, development practices, QA practices, and leadership approach — actually supports that continuous learning and feedback cycle.

The most common way to measure an organization's software-delivery performance is the DORA metrics. They simplify measurement into clear, definitive goals that primarily capture the speed and stability of the delivery process. The DORA metrics emphasize the importance of a great CI/CD system that lets organizations iterate and learn fast. In fact, there is no point talking about agile software development without an engineering approach to building this build-measure-learn (CI/CD) feedback loop.

Learning and adapting is the biggest survival skill we have as humans. Organizations are the same: the faster the build-measure-learn cycle, the faster the organization can adapt and innovate. So regardless of industry, every organization needs the underlying infrastructure that supports faster feedback loops. Experimentation should be a normal course of action in day-to-day work.

That is why I believe we need to talk beyond small batch sizes, sprints, sprint reviews, retrospectives, and daily stand-ups. Let's talk about Test-Driven Development, trunk-based development, test automation, deployment automation, feature flagging, integrated analytics, and knowledge management — the groundwork for agile software development. When an organization has the right infrastructure, clear metrics, and a fast feedback loop, teams can optimize for delivering quality software to their customers as a team, instead of falling behind a vanity metric.

Let's say you need to change the appearance of the call-to-action button on your website, but you're not sure how this change affects conversion — or whether it moves the needle at all. If you're already thinking about A/B testing, we're on the right track. But the real question is: how much effort does it take to run that little experiment and objectively validate your hypothesis about the CTA's placement?

If your answer is "we can do it with little effort," congratulations — you've passed the Turing test for engineering agility. But if your mind wanders to "Will changing the button break production?", "How do I gather and analyze the experiment's data?", "Is the time spent worth the learning?", or even "I don't know how to do this," read on — we're going to find out how.

How we do it

We use trunk-based development, where every developer commits their short-lived feature branch (the experiment) to trunk every day. We maintain a monorepo per product so developers can group all the changes for a particular experiment in one repository.

We follow TDD, ensuring unit testing happens even before the code is written, and BDD for end-to-end testing, where every critical user interaction is tested automatically. Before a developer pushes changes, we run unit tests and local builds to give fast feedback, and we use conventional commits to track application versions automatically.

For CI/CD, we use Infrastructure as Code, so every change we make to the infrastructure is also versioned. When a feature is ready for QA, a pull request is opened against the main branch (trunk) for review and to deploy to a QA environment — fully provisioned with IaC so we're testing on a 100% production-like environment. After deployment, the full E2E suite runs against the QA environment, and QA engineers write and evaluate tests against the experiment branch. On approval, the PR is merged into main, and changes are applied to production automatically.

That is what it means to build for agility: not just the ceremonies, but the engineering infrastructure that makes a fast, safe feedback loop the default.