Mr Downey spurred a bit of conversation on Twitter about the idea of ‘alpha’ stages in the GDS delivery cycle.

One of the responses was from Martin — which I liked up to a point but it also didn’t totally work for me and part of that was the terminology — unfortunately MVP has attracted so much baggage at this point it is like Kim Kardashian on a weekend away.

Personally I think Michael Brunton-Spall did a great job of describing the approach to ‘alpha’ I subscribe to in this post from last year — I especially like this quote →

..we want teams to move fast, to explore the possible solution space and feel confident that they’ve learnt more about what possible solutions there are and which ones should be progressed.

We failed at the final stages bidding for a few alpha projects recently so I have been spending quite a bit of time trying to boil down my thinking about our approach and I’m not sure it is always what the potential client wants to hear. While I totally believe with the idea that alphas are “not the first n weeks of the project” and that the code should be throwaway I have definitely seen a little wincing on the other side of the table when I say that.

I like to treat the alpha phase as a funnel. Discovery should have sufficiently explored the problem space and art of the possible to give you some hypotheses to explore and the goal of the alpha is to experiment, explore and iterate via prototypes with the tightest feedback loop you can manage (I tend to talk about one week sprints with continuous user research). At each stage you should be narrowing your focus based on that feedback. You need to be ruthless in pursuit of the alpha goal —you need to ‘kill your darlings’ if that is what the research says. The balance is difficult — you can’t risk narrowing focus too early as you could miss something but also I don’t think we should treat alpha like R&D — it is not experimentation for the sake of it — it has an end goal. To prove (or not) there is a next stage — that there is something that needs building. This is the only time I talk about an MVP (and honestly I’d rather not but for now I have nothing better) which is what I want to end with — I don’t want to finish with just ‘learning’ — I want to finish an alpha with an MVP that provides a stepping stone towards the Beta build (not from a code point of view — burn that down!). I want something that illustrates the next phase to users, to stakeholders, to the team on that build.

Working in the open throughout means none of that learning from the experiments is lost and if you need to revisit things down the road it is still there and provides a trail you can back track through if need be.

You also need to genuinely complete an alpha with the option to walk away — this shouldn’t ever be seen as a failure — unless you cannot adequately demonstrate that you did sufficiently explore the space. If you did that and you don’t end up with something to take forward…congratulations. That is a successful alpha.

The reality is we need to be pragmatic about these things — Beta builds are often a slog — a forced march to Live. You will still be researching, still testing, still iterating but the room to manoeuvre is tighter, the pressure is greater, the spotlight brighter, the investment bigger. The alpha needs to validate things to the extent that everybody is confident in the direction of travel — because once you are in Beta it is harder to change path (harder not impossible.)

Honestly I’m not sure this is how others see it — I’m sure some will see significant flaws in this approach but after a few alphas as Product Lead and an advisor on the edges of a few others this is what works for me…for now. I’m always a work in progress after all — always a few iterations away from ready.