Visualising Agile: a Risk Reduction Recipe for the Contractually Minded

Many turn to contracts as a way to reduce risk. Agile has several alternative, and proven, was to reduce risk. This blog outlines shows how to get from a contract to an ordered list of clear requirements and why that is a better way to define what functionality your customers would value – and then deliver it.

The following recipe can take us from that contractual mind-set to a more palatable Agile one.. by reducing the bitterness of risk.

Step 1: Take one contact (any size will do)

… and flatten it out to see its many pages of requirements..

Step 2: Go through document identifying the specific requests for functionality and value. Shade the more  important / valuable requirements in a darker shade.

Step 3: Boil off the narrative – to be left with the essence of the requirements. Making it easier to read and comprehend. As independent elements in a list they are also easier to keep fresh – with minor clarifications, instead of having to reissue multiple versions of a document.

Risk reduction: the requirements are more easily comprehended in this form – free of the padding narrative, and sometimes semi-deliberate obfuscation, in a document. Stakeholders can get a better idea of what is being delivered – further helped if we use a visualisation technique like story mapping. Hence reducing the risk of misaligned expectations.

Step 4: Further refine requirements for readability – by writing them in simple, non-technical English, from the perspective of a human user and understandable by everyone. – i.e. user stories.

Step 5: Disambiguate* by paring down stories with the use of clear acceptance criteria

(* yes, disambiguate is a word http://dictionary.reference.com/browse/disambiguate)

Step 6: Line up your requirements/stories with the most valuable at the top –defining valuable in whatever way makes sense to your business… it’s not just about money and revenue Risk reduction: The requirements are clearly prioritised, allowing stakeholders to see and question earlier decisions, thereby reducing the risk of abrupt changes of strategy and direction. Risk reduction: Developers work down the list from the top, making sure the most important functionality is delivered first. This is very different from when a developer team is given a document of unprioritised features, where they may choose to tackle the riskiest or most intriguing part first.

Step 7: Start to deliver the most valuable stories first. Note we say ‘deliver’ not ‘build’ or ‘develop’ or ‘code’. 

Focus on the first shippable slice of functionality – and get it to your customers as fast as possible, to deliver value, learn from feedback and validate your assumptions. This is usually called an MMF (Minimal Marketable Feature) or (MVP) Minimal Viable Product – as advocated in ‘Lean Startup’.

Step 8: Continue to slice the stories down to clarify and ensure you can deliver several (5-15) every iteration.

Alastair Cockburn’s Elephant Carpaccio http://alistair.cockburn.us/Elephant+Carpaccio+exercise is a good recipe for this

Step 9: Slice the stories vertically – so that a user can validate the work and give feedback to the team. Slices should be end-to-end, going through each layer of the cake.

(Excuse the mixing of cake and elephant Carpaccio imagery there.. but you get the point – cake Carpaccio would crumble)

Avoid slicing horizontally i.e. spending 4 weeks building out all the database first – because that doesn’t deliver any value or even prove that the functionality works

Step 10: Working down the list from the top the business may decide that they have enough functionality to go live. You may not deliver the lowest value elements – and that’s great. If the dish is good enough to eat – why waste time and money on that last bit of seasoning… (OK, that might be stretching the recipe analogy..) Risk reduction: Avoid building the low value features which will probably never be used. Save the money – twice – firstly to build it and secondly to maintain it, for ever. Risk reduction: By properly finishing work as we go along, like a good chef, we aren’t left with a huge amount of un-estimate-able testing (washing up) at the end. This significant unknown (unknowable!) risk of back-end testing is almost eliminated with good engineering practices. Allowing companies like Flickr to deploy to live many times a day.

Note: Whilst you _could_ start with a contracted document – a far better place is a user story workshop, with actual users writing stories onto cards. These are much quicker, more energised and almost certainly generate a better set of requirements to start the project with.

There are many other ways in which Agile reduces risk – this blog has only looked at a few of the upstream contracting elements.

Whilst this recipe won’t guarantee a good experience, hopefully it illustrates how the contractually minded a new perspective on risk management in software development.