Agile Without Empiricism
Have We Created the Worst of Both Worlds?
Many organisations now work with Agile, using Scrum, Kanban or larger-scale implementations of SAFe. Yet I often see us dismantling established quality safeguards as part of that transition, while increasingly insisting on a predefined scope, budget and deadline.
Teams are expected to deliver faster, with quality built into the entire process. But that requires investment in quality and an empirical approach: deliver something small, evaluate what happens and adapt accordingly. Without those investments and the freedom to act on new insights, we lose both the safety nets of traditional development and the ability to learn that Agile offers.
That is how we create the worst of both worlds.
Budgets and deadlines are not the problem
A recent discussion about story points brought this back to mind. The argument was that story points do not provide enough predictability, so we need more accurate estimates based on hours and capacity. But how much certainty are we actually trying to get from an estimate?
Software development involves uncertainty. You simply cannot know in advance exactly which solution will work or how users will respond. You find out by delivering something and gathering feedback. You then need to be able to act on what you learn. Of course organisations have budgets and deadlines.
But having a fixed budget and an end date does not automatically mean the entire solution must also be defined upfront.
Agree on the problem you want to solve, how much you are willing to invest and when you expect results. Focus on the outcome. Use what you learn to decide what to build next within the time available.
Perhaps fewer features are needed than originally expected. If you have already achieved the desired outcome, why keep building? When scope, budget and deadline are all fixed upfront, with little room for new insights to influence them, a Product Owner has too little freedom to guide the product’s direction. The role is reduced to turning a roadmap into a backlog and deciding which story comes first.
A Product Owner must be able to make different choices based on new information. If that freedom is missing, it needs to be addressed with the wider organisation. Telling teams they are autonomous does not help. We are doing traditional software development dressed up in Agile terminology.
We remove safety nets without putting anything better in place
Given my background in testing and quality, this is where I see the biggest problem. Traditional software development had plenty of shortcomings, but it also had quality safeguards: reviews, test plans and acceptance checkpoints. Someone deliberately assessed the risks before software was allowed to move forward.
Agile and DevOps aim to build quality into the entire process. I fully support that, but we actually have to follow through.
Unfortunately, I too often see that:
the testing phase disappears while test automation is still inadequate;
we document fewer requirements without properly discussing the intended behaviour and risks together;
necessary documentation is skipped in the name of Agile;
we release more frequently with little visibility into how the software behaves in production.
Some of that speed comes from leaving work out. We are buying speed on credit. The bill comes due in the form of defects, rework, technical debt and increasingly difficult releases.
Without quality, you cannot learn quickly
If we remove old safety nets, we need to put something better in place. Otherwise, we are fooling ourselves. When it takes weeks to establish whether a change is safe, you cannot learn quickly. Without good feedback from production, you also cannot tell whether that change is having the intended effect. And when every release is stressful, the demand for additional checks and coordination naturally grows.
That is why Quality Engineering enables agility. Built-in quality gives teams the confidence to deliver small changes safely, gather feedback and decide what to do next.
This requires investment in testability, automation, effective collaboration and visibility into production. That takes time, but these disciplines are part of making Agile work. Teams also need the freedom to change direction based on new insights.
At Conexxia, we work to bring organisation, engineering and quality together. In my next blog posts, I will explore how this helps us deliver on ‘Get Quality Outcomes. Faster.’
