How to Create the Minimum Viable Agile at Your Organization


How to Create the Minimum Viable Agile at Your Organization


We can probably agree on some of the things that agile is, but then either you or I would say something like: “And I also think agile is …” and offer some additional interpretation of what it means to be agile.

Because of this, a number of different agile methodologies exist. There are also many different values, principles and practices associated with agile.

The concept of a Minimum Viable Agile (MVA), that is, the bare minimum needed to say you are agile, isn’t really new. The Nokia test, first developed by Bas Vodde and later revised by Jeff Sutherland, is an example of this thinking. Many other checklists and assessments on whether or not you are agile exist, so the concept of an MVA seems to be interesting to many.

But why is it beneficial? And how do you create it?

Why the MVA is Beneficial

 The MVA would probably have the most benefit for teams or organizations getting started on the agile journey. Being in an early stage, you can easily get overwhelmed by all the different values, principles and practices of agile.

Defining the MVA could be one of the first steps towards a goal of being agile. The MVA could then be used to map the gaps between how the team or organization operates, and how it should operate to be more agile. Having an explicitly defined MVA will make it clearer which changes should be made and what kind of training is needed.

Having an MVA could also help experienced teams and organizations that have been through these transformations with a baseline of agile to fall back on, should they at any point go the wrong direction concerning their agility. 

How to Create the MVA

Creating MVA Based on the Agile Manifesto

A somewhat natural approach towards an MVA would be to follow the Agile Manifesto and use those values and principles as the basis of your MVA. After all, adhering to the values and principles behind the manifesto surely makes a team agile by definition, yes? 

While this could be true, there are some problems related to this approach.

One challenge is that the written values are too vague to translate directly into actions. If you value individuals and interactions, how do you decide if a team adheres to this? The same goes for responding to change—how do you know if a team values this, and to what degree is it followed?

You could probably find some metrics to measure the adherence to the values to some extent, but it is doubtful you will find any specific unambiguous metric to capture this.

It would be great if the principles of the manifesto provided context-specific guidelines for implementing practices based on the values, but the manifesto doesn’t directly prescribe any practices.

What seems like a downfall of the manifesto is actually one of its stronger points. The power of the manifesto lies in its open to interpretation, which leads to agile being more of a mindset than a set of practices.

Therefore, an MVA directly based on the manifesto might prove to be difficult. Also, the manifesto in itself is meant as a living agile document, in that we should always be looking for better ways to make software—not limited to the content of the manifesto as it was written 15 years ago.

So somehow your MVA must reflect this as well.

Creating MVA Based on Existing Agile Practices

Another approach towards creating an MVA for your organization could be to look at all the different agile methodologies and actionable practices from these.

All the methodologies have a slightly different implementation of the core values from the manifesto, so whether your approach is based on Scrum, XP, a Scrum/XP hybrid or a Kanban approach to software development, the idea is to pick just the minimum of practices that makes you agile and call that your MVA.

The challenge is, as mentioned before, that agile looks different to different people. Because of this, there isn’t just one agile methodology.

There are different methodologies with some overlapping practices, but since the creators have slightly different interpretations of what agile is, they also have some non-overlapping practices. As an example, neither Scrum nor Kanban prescribes any of the technical practices from XP. However, often a lot of these are implied when using both Scrum and Kanban.

If you look at the results of the latest State of Agile survey, technical practices like refactoring, pair programming, TDD and collective code ownership are among the least used agile practices. Non-technical practices like the daily standup, prioritized backlogs, short iterations and retrospectives are among the most used practices.

With only 1 percent of respondents saying their agile implementation failed, the problem then becomes which practices to choose as our MVA, given that agile implementations seems to succeed even without technical practices like collective code ownership, TDD, refactoring and pair programming.

My MVA is Different Than Your MVA

The fact is, all teams have different preferences, and the context in which various teams work are not the same. So maybe a generic MVA that we all would agree on isn’t really feasible. A custom MVA for individual teams or organizations that is periodically revised or improved is probably more realistic.

Personally, I don’t think it’s important if there is a single, generic MVA, as long as the teams or organizations are aligned and have a shared and evolving understanding of their own MVA. As long as value delivery is maximized, it shouldn’t matter either.

Do you have an MVA? Share with me in the comments below.



 

Stephan Kristiansen is a product owner at Helse Nord IKT in Norway.

Learn More
comments powered by Disqus