Wednesday, September 27, 2006

[Process] Measuring "Agility"

"Agile Manifesto" Agile Trends in Software Engineering

The "Agile Manifesto", eXtreme Programming (Kent Beck), Scrum... Agile methods of software development can be found everywhere these days. And there are good reasons for this trend. Traditional software engineering apparently found it's limits. Particularly in software projects dealing with fast changing requirements, fast changing technologies and unclear user-demands.

Measuring Agility


Talking about agile processes I have the impression, that there is yet no propoer definition of what agility actually is. Particularly not a definition that could be seen as a foundation for a quantitative measurement of agility. Or a measurement if a (software) team is able to react agile on changing situations. So following internal discussions I want to propose an idea on how we could treat this question.



This figure should illustrate the idea (please click on the figure to enlarge it):

  • The x-axis shows the timeline
  • The y-axis actually shows two things: on the left (according to the red line) the overall increase in "business value" e.g., of a Software product (number of features, ...) the right side indicates the ideal level of maximum fulfilment of feature request at a given time (iteration time). The "100%" shift upwards, as from iteration to iteration higher business value is demanded; or expressed otherwise: as the complexity of the environment is continually increasing (right scale) the business value of a static application is continuously decreasing
  • As the overall complexity increases, the "100% line" gets higher with time
  • However, this means, that the actual quality (according to the business value) of the product decreases over time as the scales shift. This could be measured as d (deterioration).
  • The time needed between two iterations is r (retention) time
  • Then total gain in quality (absolute according to the left scale) between two iterations is indicated by i (improvement)
Agility now should be a measure that follows the following structure:

A system is more agile if
  • r : d is small (the faster deterioration d takes place the shorter r should become)
  • i1...in in relative terms (right axis) stays constant, meaning the relative quality over iteration stays constant (or gets better)
  • (d+i) --> 0; ideally the steps between iterations are low, and a continuous improvement is observed
This is the initial idea; I hope, that discussion brings improvement to this concept and maybe a better (formal) description than offered here.

5 comments:

Josef Schiefer said...

I don't fully understand some things in the chart. In particular, the Y-axis is confusing to me.

It seems that with every iteration the complexity gets worse and worse. On the other hand the complexity gets less while implementing the system (I am just saying what I see on the chart).

In my opinion, what you acutally want to show with the red line is software quality or business value.

I think that the following aspects would be worthwhile measuring in context of agility:
- Business value of a software solution
- Quality of a software solution
- Adaptiveness of a softare solution
- Responsiveness to new requirements


Maybe we can develop a triangle of characteristics for agility, similar as for instance risk management does (http://paroxys.com/SoftwareRiskManagement/SoftwareRiskManagement_files/image006.gif).

Alexander Schatten said...

Yes, I agree. The initial draft had a significant flaw there. I changed the article and the figure to that respect.

I hope it reflects my idea better now.

however, this figure and concept should be the starting point for deriving concrete measures!

Gerd Saurer said...

Measuring Agility in my opinion is not equal to measuring the Business value you are trying to do with this approach. Further more agility as it is defined in the Agile Manifest means how fast we can react on changes of requirement for our customers as the first point form the manifest points out:

‘Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.


Other very important points are:

- Working software
- The persons and their satisfaction developing the Product
- Simplicity

Taking all this into account I think it is very hard to define one number for the agility of a Project/Company. I believe we need several metrics and not all of them are representative or even useful for every project special because context information is needed to interpret them correct.

rmeindl said...

I do not agree with your specific attempt to measure agility. For one thing, what your diagram displays is the history of an project which is based on a “Spiral Model”. For one thing, in iterative processes the business value never decrease over the iteration, it is only lower if and only if the iteration can not deliver. If the business value realy decrease, then the planning was wrong but the iteration succeeded. The other thing is, the measures have nothing to do with agility: agility is the possibility of an development team how fast they are able change if the environment itself is changing. To achieve this, the team has to be small, has to share all knowledge, has to use as less artifacts as possible, is self organizing and they have to commit to their work and improve themselves. To achieve this, most teams use iterative cycles, there iterations are not always follow in serial manner, instead they can overlap and can be used for different targets (eg. bug fixing, feature development, shipments, release). Normally they are also flexible in their internal structure, the steps can be varied from iteration to iteration. But the point is, iterations are a tool of an agile team, no necessity! So I think there is a misunderstanding what agility means but I thought the agile manifesto described it very clear.

Alexander Schatten said...

Rupert, here I do not agree with you, but probably, because I did not make myself clear enough.

Everything you say about agile processes is clear to me, but the misunderstanding is this: in the real world everything is discrete. There is no continuity.

The diagram does also not say anything on how long such an iteration step might be. It can be even hours. The diagram does also say nothing about the underlying process. Except for the fact that in a proper process all these steps have to be done (unless you have a process without testing, analysis...)

However, the business value is of course decreasing, otherwise we would not need continuously new versions of all applications we have. By various reasons: because we expect more, competitors deliver more, bugs are detected, and so on.

And there you are: you have to react to change. With small teams and whatever, but this is only the strategy how to react.

In fact every development looks like so:

You have to evaluate whats wrong with the current system, or what should be changed, you have to analyse and implement the change (and even if it is just a minor thing! It does not matter how long these steps take). Then you have to make or adapt tests and eventually you have to roll out a new version.

You see: this diagram reflects what happens, not how and in what time span it happens.

And I think, when you analyse it carefully, you will see, that it's measures reflect the agility (a posteriori) from the team.

Btw.: this fig. is a derivative from Josefs "spiral" figure in agile bpm, with which I was not happe about.