In my last post, I criticized agile frameworks for bringing too much complexity with too little impact. What was meant to make teams more adaptive often ends up doing the opposite. They slow engineers down with rituals that add ceremony but not value.
So, what’s the alternative? In my view, most engineers don’t struggle with the principles of agility. People like short release cycles, continuous feedback, and rapid learning. What they struggle with is the performance of frameworks. The endless stand-ups, fixed sprint lengths, and overengineered processes that drain creative energy.
If we could apply agile principles without the noise, we might actually build faster, learn faster, and deliver more meaningful value. That’s where the idea of Minimum Viable Agile (MVA) comes in. A lean, practical approach that keeps what works in agile and discards the rest.
MVA - Minimum Viable Agile
What’s MVA?
I define Minimum Viable Agile (MVA) as applying the core principles of agility without the excess baggage. No rigid ceremonies, predefined roles, or convoluted processes. The idea borrows from the concept of the Minimum Viable Product (MVP), which helps us test a product’s essence with minimal effort.
Similarly, MVA helps us test and practice agility itself. Quick, light, and with just enough structure to move forward. It keeps what accelerates progress: short feedback loops, teams that can make decisions, and constant learning.
Principles of MVA
The essence of MVA lies in keeping just enough structure to stay effective, no more and no less. It follows three simple but powerful principles:
- Enough practice to get things right, not to look busy. Focus on the practices that directly improve quality, clarity, or speed. Anything else like recurring meetings, unnecessary rituals, over-polished documentation is optional.
- Small teams, big impact. A small, focused team (ideally three people or fewer) can move faster and make sharper decisions. When communication flows naturally, alignment becomes effortless. If the product is large, divide it into smaller, autonomous groups rather than scaling bureaucracy.
- Deliver value early and often. Technology choices, frameworks, and abstractions matter only insofar as they serve the end user. Every iteration should reach production or get meaningful feedback from real users. Until then, nothing is truly done.
These principles might sound deceptively simple. MVA is not minimalist for its own sake. It removes everything that doesn’t contribute to learning or value.
How to Apply
With a small team focused on delivering value, every iteration should aim to produce something real, testable, and useful for the customer. That means building in small, meaningful slices, one feature, one improvement, or one workflow at a time.
Let the release cycle follow the work, not the calendar.If your next release includes a few quick features, a week might be enough. If you’re tackling a deeper architectural change, a month could make more sense. The timeline should be flexible. It’s a tool, not a constraint.
You’ll still need a way to organize what gets done. Keep a simple backlog or task list, prioritize ruthlessly, and decide what fits into the next release. A whiteboard, a Confluence page, or even sticky notes can do the job. The medium matters far less than the clarity.
If possible, involve the customer early. Discuss what they actually need, agree on priorities, and adapt as feedback comes in. The closer the collaboration, the shorter the feedback loop. Minimize the guesswork your team has to do. In MVA, planning isn’t a ceremony; it’s a conversation. Once that loop of communication is healthy, everything else, releases, retros, even metrics, falls naturally into place.
Conclusion
In the end, software development doesn’t need more frameworks. It needs fewer distractions. We’ve spent years optimizing how we talk about work instead of how we do it.