The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

EVO, Evolutionary systems delivery

EVO - short for EVOlutionary systems delivery, is an advanced project management method. I attended a course starting 7th November 2011 at the BCS HQ in London run by Tom Gilb. Quote: "I am 70 today ..." pauses for applause and congratulations "... my birthday was on Christmas Eve but I am 70 today."

It adheres to much of the Agile Manifesto; not surprisingly Tom Gilb (its inventor) is considered one of the fathers of agile software development.

Overview

EVO is a great addition to Scrum by adding stakeholder analysis and a quantitative approach to requirements and delivery.

Course notes

Users ask for redundant functionality; much is not used. (Learned by the Norwegian survery company ConfirmIT.com ) There needs to be quantification of essential requirements. There needs to be 'Dynamic Prioritisation' week by week.

Before getting the Top 10 Requirements, identify the stakeholders - the critical ones. What are their values? A stakeholder can be any person or thing (e.g. laws). They can determine project success or failure. Every requirement has a stakeholder.

Functions, Product Qualities, Solutions: keep them separate.

A Function is either absent, or not absent.

Quality consumes resources; perfection is infinite cost and time.

User friendliness, how to measure? Examples:

Number of clicks for a given transaction.
Time to carry out a transaction.
Able to fulfil a specific query online with the customer on the telephone within x seconds.
Can be done by x% of random public members, first time.
It is a multi-dimensional criteria.

"Rules" are standards.

Basic principles:

clear and unambiguous to the intended readership;
testable;
no unintentional solutions (designs)
stakeholder focus (otherwise, who cares?)

Variable requirements must be quantified.

All functional requirements are binary.

Variable requirements (quality, cost, value, resources) are variable.

To find scales, Google for "whatever (e.g. intuitiveness) metric". Scales do need to be adapted according to the domain. Test a scale by applying the number 42.

"Tolerable" = the worst acceptable case; the beginning of getting some value.
"Meter" = how we will measure. A high level idea of how to measure.
"Past" = some reference system.
"Record" = the best done e.g. in the world, the company, for old people, etc. Do we know the state of the art?
"Trend" = looking forward. E.g. how bad will it get? What will the competition do?
"Wish" = It has to value us as a stakeholder.

Enclosed with the course notes was an entire directory on requirements.

Design

The detailed design needs enough detail for an idiot.

Summary of the 10 Principles

Real results, of value to real stakeholders, will be delivered early and frequently.
The next Evo delivery step must be the one that delivers the most stakeholder value possible at that time.
Evo steps deliver the specified requirements, evolutionarily.
We cannot know all the right requirements in advance, but we can discover them more quickly by attempts to deliver real value to real stakeholders.
Evo is holistic systems engineering – all necessary aspects of the system must be complete and correct – and delivered to a real stakeholder environment – it is not only about programming – it is about customer satisfaction.
Evo projects will require an open architecture – because we are going to change project ideas as often as we need to, in order to really deliver value to our stakeholders.
The Evo project team will focus their energy, as a team, towards success in the current Evo step. They will succeed or fail in the current step, together. *They will not waste energy on downstream steps until they have mastered current steps successfully.
Evo is about learning from hard experience, as fast as we can – what really works, and what really delivers value. Evo is a discipline to make us confront our problems early – but which allows us to progress quickly when we really provably have got it right.
Evo leads to early, and on-time, product delivery – both because of selected early priority delivery, and because we learn to get things right early.
Evo should allow us to prove out new work processes, and get rid of bad ones early.

Tips for Success

Assume the customer will not ask for want they really want.

You must help the customer define the results they will really appreciate (not necessarily what they initially say they want).

Help the customer focs on the top ten most critical quantified requirements.

Also, establish the top few most critical objectives, 3+/-2

Quantify all critical and technical requirements.
Evaluate all designs, strategies, architectures based on numeric contribution to the agreed critical project requirements.

Cost evaluated; an estimate of how they satisfy the target levels of the objectices; risk evaluation.

Summary

To do EVO well and to get all the benefits that EVO has to offer, one must:

have quantified the requirements
have specified past and goal levels.

Breaking the development and the delivery of your project into cycles of about 2% of total project costs, e.g. one week cycles.

EVO means learning from each cycle. EVO means changing anything according to what you just learned,. This agility of learning and changing guarantees success, and avoids failure.

Reference Material

The Competitive Engineering book is not meant for sequential reading; Evo is meant for reading.

www.ashleighbrilliant.com for pithy comments.

Search Zachman zifa.com for stakeholder artefacts.

Roxanne Miller's stakeholder lists in The Quest for Software Requirements.

EVO - evolutionary systems delivery

Contents