Method Overview

Classification

In terms of cycle and ceremony, Evo classification is illustrated in Figure 10.1. For average projects, a common length of a timeboxed iteration is one or two weeks.

Figure 10.1. Evo on the cycles and ceremony scale.

Evo recommends some initial work to define a "critical top ten" list of measurable project objectives, and when specifications are written, Evo encourages unambiguous precision. It also encourages brevity, promoting one page summaries. Evo avoids big up-front specifications, although evolving specs that could be part of a small or large set are acceptable if shown to be valuable.

When describing high-level requirements, a structured language call Planguage^[1] is possible; it encourages clarity, precision, and measurement. If used, it raises Evo on the ceremony scale.

^[1] Rhymes with "language."

Similar to Scrum, it has only a small set of predefined workproducts, such as an impact estimation table. Others may be adopted from different methods as needed.

impact estimation table

In terms of the Cockburn scale, Evo covers the cells shown in Figure 10.2. Since the 1970s, it has been applied on a wide range of projects of many sizes.

Figure 10.2. Evo on the Cockburn scale

Introduction

Evo [Gilb76, Gilb88] was created by Tom Gilb, a pioneer of iterative and evolutionary development.

I'm including this chapter on Evo less well known than Scrum, XP, and UP not only because of its inherent interest, but to balance the historical oversight of this pioneering iterative method and to show that some agile method principles have long been part of Evo, such as a adaptive, client-driven planning of iterations.

Agile Principles

Gilb has been an advocate for an iterative, light, and adaptive approach to systems development since the 1960s; he first wrote about this in 1976, and his 1988 Principles of Software Engineering Management is a milestone early book presenting an evolutionary and iterative process.^[2]

^[2] Gilb also wrote the first book on software metrics, coining the term in [Gilb76], and continues to refine Evo, e.g., [Gilb03].

Evo's evolutionary emphasis is consistent with the Shewhart/Deming cycle of Plan-Do-Study-Act (PDSA), and makes reference to PDSA as an underlying conceptual model.

Evo is not just for software. It is applicable in a larger systems engineering context new software is just one solution to fulfill project objectives. For example, if more education (on the existing software) or operational change has a better value-to-cost ratio than new software, the former approaches are preferred.

It emphasizes short iteration by iteration making maximum progress towards the client's current highest-priority requirements, for the lowest cost. And each iteration, delivering into the hands of some stakeholders some useful results, so that early benefit and feedback is achieved. This is the practice of client-driven adaptive planning and evolutionary delivery.

Evo is pragmatic, has some qualities similar to newer agile methods, is customer focused and results oriented in the spirit of the Agile Manifesto and Principles. Anything necessary can change (based on the PDSA model) to reach the requirements (function or performance) within the project constraints.

Agile Manifesto

One of Evo's distinguishing ideas is its emphasis on clearly defining, quantifying, estimating, and measuring the performance requirements that need improvement over time.

these bold terms are official Evo terms

Performance includes quality requirements such as reliability, workload capacity requirements such as throughput, and resource savings requirements such as money. The impact of Evo steps on budgeted resource consumption is monitored both in design activity and iteration project management activity.

example requirements

Evo requires evaluating proposed solutions for their impact on the state of these requirements, and then actually measuring the impact of those introduced.

This structured approach and emphasis on improving the performance characteristics, rather than just on delivering functionality, is a key part of Evo's unique flavor.

Thus, note that in Evo there is explicit recognition that the requirements delivered may be either functions or performance objectives (quality, workload capacity, or resource saving).

Evo expects that each iteration there is a re-evaluation of solutions which yield the highest value to cost ratio, guided by feedback and estimates. As such, Evo requires active stakeholder participation to steer the project each iteration client-driven adaptive planning. These practices are part of evolutionary project management.

adaptive planning

Measurable progress is a key principle of Evo, which takes seriously Drucker's maxim: If you can't measure it, you can't manage it. Quantifiable measures for performance requirements, and their regular measurement, is required. Unproven improvements, and vague quality goals such as "usable" are discouraged.

In Evo, the value system is that management doesn't schedule the details of the entire project, but they must be able to measure, control, and steer a dynamically evolving project. In other words, adaptive planning.

Evo encourages precision and (where relevant) quantification in specifications. It does so by encouraging (but not requiring) the use of a compact, structured specification language called Planguage to record requirements iteratively and incrementally.

Planguage

It is a misunderstanding to interpret Evo's promotion of high-quality, low-volume critical specifications as an attempt at large up-front analysis. Evo promotes avoiding unnecessary analysis and detail until it is needed.

Inspection especially of these specifications is encouraged in Evo as an economical method to improve quality. Indeed, research verifies this [Russell91], and Gilb has been an active promoter of inspections for decades, including co-authoring the text Software Inspections.

inspection

Evo also encourages a risk-driven approach, as does the Unified Process. As Gilb has aptly said,

If you do not actively attack the risks in your project, they will actively attack you.