"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.
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