… something on Minimum Viable Process

The term MVP, usually meaning Minimum Viable Product, is possibly one of the most overused, possibly misused, terms in technology over the last five years. I find it a very valuable concept, however I have seen it abused.

In this blog a want to talk about a different MVP, using it on the amount of Process you employ instead.

The worst jobs…

The worst jobs I’ve had are where you can’t do your job, what you’re supposed to, because of arbitrary process.

Actually that’s not true, the worst job I had there was NO process, you just did what your boss shouted at you to do, when they shouted at you to do it. It wasn’t always shouted, but it was that bad. Often they would deliberately wait until 5 minutes before home time to pressure you subtly in to staying late.

Pure Scrum

I’ve worked in ‘pure’ scrum teams twice; both times the process had been established before I was there and it was remarkably mature. Both had followed Scrum almost to a fault; the process was handed down on tablets and they hadn’t necessarily done Inspect and Adapt.

Having said that, the work moved through the process like a well-, er, -something-ed sausage machine.

There was flow through the system.

Though far too much estimation going on , duplicated at story and task level in fact.

Whether quite the right stories were being fed in by the Product Owner was a different matter. Whilst sometimes it felt like interminable meetings, refining the backlog made sure only sensible, thought-through, stories made it in to the Sprint, and the team had ownership. I remember someone expressing it like this:

“Refinement is the process of the team taking ownership of the stories from the business.”

This level of team-process seemed sensible for the maturity of product-process. But it would be heavy-weight for many other situations.

Indeed I regard the Scrum process as agile training wheels (when people are completely new to lean/agile), and would expect teams to come to understand the value in the elements of Scrum and become mature enough to move to KanBan over time.

Establishing Minimum Viable Process

When I’ve established teams (rather than inherited them), I’ve tried to be deliberately under-processed to begin with. This is to stop meeting fatigue, but also to avoid unnecessary meetings; only introduce one if you need it, if it can justify itself.

This year we started off with a new team in an extremely exploratory fashion. We ran very small spikes to identify risks. Then we had to do some leg-work before we could add some new alternative implementations. Thinking of the Cynefin framework, we were in a complex domain so had to feel our way step by step. Once we knew more we can regard it as complicated and act accordingly.

Whilst we knew a rough direction of travel, there was no backlog to work through, we really were doing Just In Time planning. Some on the team found this a little unsettling, so we started to make things in the middle-term clearer.

However, once the team is established, we know what we are trying and going to try to do, so it seems sensible to introduce an opportunity to look ahead more, and have some (I don’t want to overdo it) backlog in the pipeline. I don’t want to call them ‘refinement’, just a sort of planning, but that’s what they’re called in Scrum.

Minimum Viable Planning

In early stages, you’re going to learn more by trying things rather than trying to analyse things to death. Start with Minimum Viable Planning, but revisit as soon as you need to; don’t be afraid to ditch a plan — whilst planning is essential, the plan us useless.

Minutes of planning can save hours of development, but minutes of development can save hours of planning. So iterate between the two.

Bare Bone Ceremonies

Even if I’m not doing full Scrum, but something more Kanbanny, I do like to have a regular (one or two week) cadence, this makes sure demoing working software to stakeholders, as well as a team retrospective is baked into the process. It’s too easy to skip these essential interactions, plus it saves organising recurring meetings on an ad-hoc basis, ensuring they’re already there in the calendar. Automate everything, even diaries.

Minimum Viable Process

This is what I mean by Minimum Viable Process. I want just enough process to allow the delivery of value, especially in the early stages of a team. I don’t want process to feel like a chore, it’s value should be obvious to the team. I don’t want the process to be a form of Micromanagement, but one of Transparency. I want to spend the least amount of time performing process, and the most communicating valuable content. I don’t want process for process sake; each bit of it has to justify itself and show it is enabling value to be delivered.

Post-Script: The Antithesis

In the build up to writing this post, I was astonished to hear from someone who advocated adding far too much process on the basis that when it came to the crunch, when corners got cut, you still had enough.

He appeared to be serious about this. I did wonder if it was a wind up.

I might counter that a Minimum Viable Process wouldn’t be there to get cut in the first place, or has value so that it is done.

But some years ago I went for an interview where he works and didn’t see eye-to-eye with his CEO, and this might be why. Turns out it was a near miss.