Published July 3, 2019 · 4 min read

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 isn’t about rebelling against agile; it’s about reclaiming its essence. Adaptability, focus, and simplicity.

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. Where MVP shows how a product could look and function early on, MVA shows how agility can feel when stripped to its essentials: short feedback loops, empowered teams, and constant learning. It’s not about rejecting the process, but about using only what accelerates progress. In essence, MVA is agility distilled. It’s a mindset focused on outcomes, not rituals.

Principles of MVA

The essence of MVA lies in keeping just enough structure to stay effective — no more, 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, but simplicity is a strength. MVA is not about being minimalist for its own sake. It’s about removing everything that doesn’t contribute to learning, value, or momentum.

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. Minimum Viable Agile is a reminder that progress comes from clarity, not ceremony.

MVA doesn’t dictate a process; it encourages a mindset. It relies on trust, communication, and shared purpose. It is not job titles or rituals. When teams focus on real outcomes, collaboration naturally aligns, and agility becomes something you feel, not something you enforce.

Agility was never meant to be a religion. It was meant to be a rhythm.  A simple cadence of building, learning, and improving. MVA brings us back to that rhythm.