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.

Agile Transformation: Tips for Organizational Change

Jason Little describes his career as helping organizations "discover more effective practices for managing work and people." He is the author of the book, "Lean Change Management: Innovative Practices for Managing Organizational Change," a speaker, agile coach, Certified Scrum Professional, ScrumMaster and Scrum Product Owner. 

In this interview, Jason reveals what to watch for when trying to implement agile into an organization -- especially in larger companies that value control and stability. Here, we'll dive into the concepts featured in his course on Front Row Agile: "Agile Transformation: Four Steps to Organizational Change." 

In your course at Front Row Agile, you talk about the idea that understanding your organization’s culture is a good start, but it may not be a good idea to intentionally try and change it. Why is that?

Jason: Despite the agile community’s consistent message that agile isn’t a quick fix, it’s still perceived as being one. The pace of change, disruption and innovation is constantly increasing, and agile isn’t going to undo years of cultural baggage and organizational debt in a short time period.

I mention it’s a good idea to understand what your culture is because it’s important to pick an approach that is more likely to work. That means in a “control” culture that values structure and stability, you may want to start with considering agile to be a new process. 

What I mean by that is approaching an agile transformation in this type of environment by leading with the agile values and principles might be perceived as “fluffy,” and it may turn people off. 

In this environment, people might need a bridge built between how their processes work today and what they might look like tomorrow. For example, larger organizations I work with have more governance in place so developing an “agile governance process” can be a good short-term strategy for people to figure out how to move forward. 

After they’ve seen how what they do works in an agile environment, then more focus on agile values and principles might be a good approach. 

You teach different options for how organizations can learn about what agile means before they get started. Can you elaborate on that?

Jason: Back in 2007 when I started with agile, there weren’t nearly as many options as there are today for learning about agile methods. I still see organizations using only training and certification as a way to learn about agile, which is one of many ways to get educated about agile.

The agile community has grown substantially since 2012, and there are numerous conferences, meetings and virtual learning opportunities.

One of my favorite education tools is to send people to agile coach camps of which there are many around the world. That is a great way to connect people in the organization to experienced agile coaches that they can learn from.

You stress the importance of retrospecting often in your course. How can larger organizations use this technique at scale?

Jason: I recommend conducting retrospectives at the team, management and organizational layer; this helps get people focused and aligned around the purpose behind transforming to agile in the first place.

I recently used that technique with an enterprise client. Their team wanted to know the answer to one question: After a year, do we want to keep going with agile?

I coached the internal coaching team lead on how to do a large-scale retrospective for 30+ teams, management and executives. The short version of the story is that the answer to the question was yes. Even with all the problems and pain, they wanted to keep going.

The interesting part of that exercise was how it was executed. I worked with the internal coaching team lead on how to do the technique, and she then coached the existing Scrum Masters and Kanban team leads to do that exercise with their teams. 

This way, there was no single bottleneck. We took full advantage of a network of people, and then the coaching team lead took all the data from the teams and compared it with the data from the manager and director retrospectives.

She found it to be a great deal of work, but well worth it in order to see where staff, management and executives were aligned or misaligned.

“Scale” often scares people, but it’s not difficult to do large-scale retrospectives. It simply takes a little more planning and coordination. 

Organizations often lose sight of how their journey towards agile is going because they get too caught up in the day-to-day challenges and organizational problems agile is exposing. Taking the time to stop and reflect shows a serious commitment by leadership to helping make agile work.

For more info from Jason or to get in touch, head on over to his website.