Chris Andrade - Founder & Principal - Archinext, Inc.

Agile has been around for decades and is the de facto paradigm undergirding modern software development practices. While its value has remained unquestioned, it has recently received its fair share of scrutiny and criticism. After experiencing attempts to practice the manifesto's principles at the companies I've worked to help, I can understand why.

On the surface, it's hard to disagree with what agile stands for principally. It's a mindset that helps software teams adapt to change and deliver value incrementally in a way that keeps the business happy and the dynamics of the team healthy. Who can argue with that?

In practice, however, we have trouble getting this right. This is especially the case as I've seen tech organizations implement what's arguably the most popular process associated with agility: Scrum. Backlogs are groomed, stories are written, and sprints are begun only for work to be carried over from sprint to sprint, leaving everyone to question what value is realized from the process.

Many of the mechanisms created by current "Agile" tooling violate the core principles of the manifesto. But the reason why is often overlooked. For budgets to be approved and expectations managed to stakeholders, estimating how long a software project will take to complete is crucial. Projects can't go on forever and "it'll be done when it gets done" is an insufficient answer. The processes are an attempt to provide that visibility to everyone involved.

But it comes at a cost. The process burden on engineering teams and individuals keeps them from doing critical work. And the larger the organization, the more the effects are felt. Large organizations are the opposite of agile: they're slow, rigid, and easily mired in process as the number of participants grows. So, how can balance be achieved? Is it time to throw agile away in search of something new?

If you've tried Agile for some time but have gotten nowhere, the impulse may be to get rid of it entirely. If this is you, the question to ask is: what will you replace it with? You could be throwing out the baby with the bathwater. Perhaps it's time to revisit the agile manifesto and consider: where have we gone wrong? The answer may not require a wholesale change in process, but rather small course corrections around the areas that need help the most.

Questions to Consider

Technology is always in pursuit of something novel or better. But rather than pursuing a replacement, ask:

1. If you're delivering regularly, what process, agile or otherwise, is supporting that?
2. If you're not delivering regularly, what process, if any, is getting in the way of that?
3. If you're barely delivering, what could be improved, changed, or removed to create a consistent pattern of delivery?

If it sounds familiar, it's because it is. It's your standard retro. Maybe an "Agile" replacement isn't what's necessary. Maybe you just need to actually become agile. You may be closer than you think.