History and literature

to Dutch home page
to English home page
to Evo home page

Most descriptions of development processes are based on the Waterfall model, where all stages of development follow each other. Requirements must be fixed at the start and at the end we get a Big Bang delivery. In practice hardly anybody really follows this model, although in reporting to management, practice is bent into this model, because management usually expects this simple model, while most development procedures describe it as mandatory. This causes a lot of mis-communication and thus wastes a lot of energy.
Requirements wpe74.jpg (978 bytes)
Architecture wpe74.jpg (978 bytes)
Design wpe74.jpg (978 bytes)
Code wpe74.jpg (978 bytes)
Test wpe74.jpg (978 bytes)
The waterfall model Delivery

Early descriptions of Evolutionary delivery, then called Incremental delivery, are described by Harlan Mills in 1971 and F.P. Brooks in his famous "No silver bullet" article in 1987 [SC2]. Incremental delivery is also used in Cleanroom Software Engineering [SP8, SP11, SP12, SP20]. A practical elaboration of Evolutionary development theory (Evo) is written by Tom Gilb in his book Principles of Software Engineering Management in 1988 [D4] and in newer manuscripts on Tom's web-site: http://www.gilb.com. Incremental delivery is also part of eXtreme Programming (XP), see http://www.extremeprogramming.org, however, if people claim to follow XP, I hardly see the Evo element practiced to its successful potential.

A recent article by Craig Larman and Victor Basili: "Iterative and Incremental Development: A Brief History" was published in 2003, showing that the application of Evo methods dates back to the mid-50s.

We prefer using the expression Evolutionary delivery, or Evo, as proposed by Tom Gilb, because not all Incremental delivery is Evolutionary. Sometimes we may find Spiral development, however, there are several spiral development descriptions, like from Boehm (1988) and in the NASA Software Management Guidebook [N4]. Incremental delivery methods use more or less cycles, where in each cycle part of the design and implementation is done. However, not always emphasis is put on typical Evolutionary issues, like:

  • Focus on delivering value to stakeholders
  • Very short development cycles (one week)
  • Rapid and frequent feedback
  • Working in time box mode
  • Solving the requirements paradoxes
  • Solving the estimation-planning-tracking weakness
  • Use of criteria for what to deliver to stakeholders in which order
  • Constantly prioritising tasks: working on highest priority tasks only
  • Use of criteria for defining priorities
  • Most important issues first
  • Highest risks first
  • Most educational or supporting issues for the development first
  • Active synchronisation with other developments (e.g. hardware)
  • Dedicated experiments for requirements clarification, before elaboration is done
  • Every cycle delivers a useful, completed, working, functional result
  • Requirements management is part of daily life
  • Risk management is part of daily life
  • What we have done is done, we cannot change it any more, what we do from now, we can control
  • The methods really work (otherwise we would discard them)
  • No other method delivers more and better results faster
  • You can start saving time, saving money immediately
  • Relaxed working, yet higher productivity, no need for excuses any more
  • Happy developers, happy customers, happy management
  • Customer has choice in the time-to-market and features battle
  • Quality is cheaper
The pages on this website contain the interpretation, guidelines and experiences by Niels Malotaux.