"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)
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
4 comments:
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).
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!
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.
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.
Post a Comment