What's Wrong With Agile Methods
Some Principles and Values to Encourage Quantification

Tom Gilb, http://www.gilb.com/
Lindsey Brodie, Middlesex University

Abstract

Current agile methods could benefit from using a more quantified approach across the entire implementation process (that is, throughout development, production and delivery). The main benefits of adopting such an approach include improved communication of the requirements and, better support for feedback and progress tracking.

This article first discusses the benefits of quantification, then outlines a proposed approach (Planguage) and, finally describes an example of its successful use (a case study of the ‘Confirmit’ product within a Norwegian organization, ‘FIRM’).

Introduction

Agile Software Methods (Agile Alliance 2006) have insufficient focus on quantified performance levels (that is, metrics stating the required qualities, resource savings and workload capacities) of the software being developed. Specifically, there is often no quantification of the main reasons why a project was funded (that is, metrics stating the required business benefits, such as business advancement, better quality of service and financial savings). This means projects cannot directly control the delivery of benefits to users and stakeholders. In turn, a consequence of this is that projects cannot really control the corresponding costs of getting the main benefits. In other words, if you don’t estimate quantified requirements, then you won’t be able to get a realistic budget for achieving them. See Figure 1 for a scientist’s (Lord Kelvin’s) opinion on the need for numerical data!

Figure 1. A statement made by Lord Kelvin on the importance of measurement. 
From http://zapatopi.net/kelvin/quotes.html

Further, quantification must be utilized throughout the duration of an agile project, not just to state requirements but, to drive design, assess feedback and, track progress. To spell this last point out, quantification of the requirements (what do we want to control?) is only a first step in getting control. The next steps, based on this quantification, are design estimation (how good do we think our solutions are?) and measurement of the delivered results (how good were the solutions in practice?). The key issue here is the active use of quantified data (requirements, design estimates and feedback) to drive the project design and planning.

One radical conclusion to draw, from this lack of quantification, is that current conventional agile methods are not really suitable for development of industrial products. The rationale for this being that industry is not simply interested in delivered ‘functionality’ alone; they probably already have necessary business functions at some level. Projects must produce competitive products, which means projects must deliver specific performance levels (including qualities and savings). To address this situation, it is essential that the explicit notion of quantification be added to agile concepts.

See Figure 2 for a list of the benefits to agile development of using quantification.

Figure 2. What can we do better in agile development (or ‘at all’), if we quantify requirements

Defining Quality

The main focus for discussion in this article will be the quality characteristics, because that is where most people have problems with quantification. A long held opinion of one of the authors of this article (Tom Gilb) is that all qualities are capable of being expressed quantitatively (see Figure 3).

Figure 3. Tom Gilb’s opinion that all qualities can be expressed numerically

A Planguage definition of ‘quality’ is given in Figure 4. Planguage is a planning language and a set of methods developed by Tom Gilb over the last three decades (Gilb 2005). This next part of the article will outline the Planguage approach to specifying and using quantitative requirements to drive design and determine project progress.

Figure 4. Planguage definition of ‘quality’

Quantifying Requirements

Planguage enables capture of quantitative data (metrics) for performance and resource requirements. A scalar requirement, that is, either a performance or resource requirement, is specified by identifying a relevant scale of measure and stating the current and required levels on that scale. See Figure 5, which is an example of a performance requirement specification. Notice the parameters used to specify the levels on the scale that is, Past, Goal. And Fail.

Figure 5. Planguage parameters used to specify a performance requirement

Copyright © 2006 by Tom Gilb

Page 2   Back to the archive list