Introducing the Minimum Viable Framework for Agile adoption

Why and how it can work for you

Photo by Pablo Arroyo on Unsplash

I recently wrote about the perception that Culture is the leading cause of failure in agile adoption, and offered a couple of solutions to the problem. One was to map the existing culture, design a desired culture, and then introduce the changes needed to achieve that. The other was to use what I termed the Minimum Viable Framework, or MVF.

This post provides more detail on the rationale for using an MVF and explains how.

Where did this idea come from?

The concept of an MVF is my attempt to address three problems:

1. The introduction — or imposition — of many detailed practices that clash with an organisation’s existing culture, or just do not suit the work that a team does, and cause resistance to change at many levels.
2. Without very good training and coaching, agile practices are often cherry-picked for the wrong reasons — to comply with existing organisational values and traditions, not agile ones. Agile practices, misunderstood and mis-applied, don’t offer much benefit.
3. In the State of Agile survey, the next most common factor quoted as a cause of failure in agile adoption was “lack of management support”. Totally understandable this one. Few agile transformations I have ever been involved in have aligned the transformation to business objectives. Why would management support us if we are speaking a different language?

Essentially, the MVF is a way of simplifying Lean and Agile down to their most basic elements, so that senior leaders can understand it and support it. It avoids dictating practices that might clash with existing culture, and it empowers people at all levels to find their own ways of doing things that support the MVF.

What does the MVF look like?

You will — as I did — inevitably look at this through a lens of the biggest, or most common problems you have seen in the organisations you have worked in, so your list may not equal mine. But here’s how I did it.

Take the twelve principles behind the agile manifesto, add in Kanban’s first principle (start with what you do now) and a couple of practices, then de-duplicate and delete anything that may result from something else, and what you’re left with is the MVF.

My first attempt led to a list of 6 ‘rules’:

• Prioritise by Value
• Visualise all the work
• Eliminate waste
• Limit work-in-process
• Deliver as quickly as possible
• Build quality in

After further thought, I deleted the last two, because they were both implied in the other four. So that left me with four, plus one other, then I re-ordered them:

• Prioritise by Value is similar to the first of the Agile principles and means that someone needs to understand and be able to articulate the value inherent in all work requests (projects, Epics, user stories, product backlog items), and that backlogs should be prioritised accordingly. See the Drucker quote in the image above as to why this is important. Implied in this, too, is that backlog items are expressed as desired outcomes, for which user stories are but one — albeit very good — format.
• Visualise all the work is Kanban’s first general practice, and is essential for Transparency (one of Scrum’s three pillars). It refers to not only visualising current work, but planned work too, as well as any work done that is currently hidden, dependencies, risks, deadlines, defects, etc. It also means visualising the workflow through which this work is done.
• Shorten feedback loops is a more general practice common to most agile frameworks. The reasons for its inclusion here are, I hope, pretty obvious. Yes, it could be covered under Eliminate Waste, but I thought it should be its own element in the MVF.
• Eliminate Waste is taken from the Seven Wastes of Lean software development, first defined by Tom and Mary Poppendieck, and based on the Toyota Production System. The article in the link explains them perfectly, so I won’t replicate it here. Suffice to say that the elimination of waste in the software delivery process solves all sorts of other problems too, if one is ruthless about it.
• Manage Flow is another of Kanban’s general practices, and can only be achieved by limiting WIP. The latter is so powerful it has even been officially endorsed by Scrum.org. Limiting WIP is essential for identifying bottlenecks and delays (see eliminating waste below) and for enabling and managing Flow.

To this list, I could have added:

• Something about welcoming changing requirements, but that is specific to product development and isn’t always applicable. It is also covered by 1) Prioritise by Value
• Something about motivated individuals and giving them the environment they need and trusting them. Add it if you feel the need, but I think if you are able to achieve the others, motivation and trust will follow.
• Simplicity is essential. This is my favourite agile principle, and arguably the least followed. I was tempted to add it, but it’s covered by Eliminating Waste
• Self-organising teams, face-to-face conversations and regular reflection are all great, but are related to the one about motivated individuals and if you are ruthless about eliminating waste like relearning or handovers you will get this too.
• Making policies explicit I left out because I didn’t want to get method specific nor too detailed. I wouldn’t argue if you felt it should be included though

How do we implement this?

In my previous post, I listed three essential steps to starting an agile transformation.

The first was to define and communicate the objectives and desired outcomes of the transformation itself. This justifies the expenditure on the transformation initiative, but also helps us identify what changes are needed to achieve these goals (it’s not just about implementing your favourite agile framework). The objectives serve to guide lower-level decisions about what needs changing and what does not. This is the ‘WHY’ of the transformation initiative.

The second was to identify, agree and communicate the MVF. This is the ‘WHAT’ of the transformation at the highest level. It is analogous to the backbone (highest) level of a story map, and these items can each be broken down into specific activities or tasks or learning objectives for teams.

Lastly, training programmes and coaching should be built around this, with each element being its own module. Not every team has — or has access to — a product owner; not every team is building a product. So a training module on prioritising by Value would ask questions like, “how do you identify the value in the work that you do?”; “who determines that?”; “how would you go about prioritising your backlog?”. The trainer — or the material available — would not tell students how to determine value (because one method might not be applicable to everyone), but would provide options and ensure that everyone could apply at least one.

What is important here is that the concept of an MVF is about us avoiding telling people what to do and instead agreeing a minimal set of outcomes and helping them to identify and then to evolve their practices, roles, processes and events to support them. It empowers and motivates teams and it respects their current situation, structure and environment.

The five elements I describe here are my MVF. If you can come up with something more generically Lean-Agile and more effective, please do share in the comments below.