Agile SCM - Review of 2007 and Predictions for 2008

rise and importance of  ITIL last year, and this has only strengthened with the release of ITIL V3 during 2007. In general, V3 makes the link between ITIL's best practice and business benefits both clearer and stronger. The main development is that V3 takes a lifecycle approach to guidance, as opposed to organising according to IT delivery sectors. It is more tightly aligned with business usage, and is more compatible with internation standards such as ISO/IEC 20000.

ITIL has achieved a lot of management mindshare in countries such as the UK, the Netherlands, Scandinavia, Canada and Australia, and is steadily growing in the US.

In some ways ALM can be viewed as a subset of the service management lifecycle, and there are many benefits of taking this approach. Application development is often 30% or less of the whole cost of the application through its life. The advantages of considering the transition into service (release management traditionally) from very early in the lifecycle, and also taking a holistic view of the whole lifecycle through to maintenance and retirement, and considering the integration with other services, tend to be more cost effectiv    e in the long run.

The Backlash
The interesting thing with some of the developments discussed above is that there is in some quarters almost a backlash in that some approaches have been overhyped and are perhaps harmful. We are certainly of the opinion that Agile SCM itself has been accused of throwing out good SCM principles in pursuit of some uncontrolled chaos or "license to hack". This is a failure to communicate the disciplines required for good agile development.

A backlash is also a positive sign in that it fuels debate, and as long as this is kept constructive, the results are only going to be positive for all of us.

In a recent 2-part article in Better Software  magazine (Nov & Dec 2007 ), Gertrud Bjørnvig, James O. Coplien and Neil Harrison discuss the problems with TDD (Test Driven Development). This builds on Coplien's blog article: Religion's Newfound Restraint on Progress . The reference to the research by Siniaalto and Abrahamsson is perhaps over stated. This paper (available for purchase via IEEE) actually does two things: summarises 16 studies (in industrial, semi-industrial and academic settings), and does a comparitive case study of the effects of TDD on 2 iterative test-last projects vs. a single TDD project. The summary questions the generalizabilty and significance of some results, but does conclude that TDD may enhance software quality and may not decrease developer productivity!

The results of their comparative study are rather more ambiguous - they indicate that TDD does not always produce highly cohesive code as predicted in the literature, but qualifies this by referring to their single TDD project having less experienced developers than the other 2 projects. It does note that test coverage is improved by TDD. This sort of paper is definitely to be encouraged, and more examples are needed, but we should not perhaps read too much into one example. The rest of the Better Software article contains many good points and points out various dangers that, in our experience, do occur if TDD is not sensibly applied. For now, we think the jury is still out, but as ever a realistic approach, as opposed to naive belief in the hype, is going to bring you the best results.

On the ITIL front, there is anecdotal evidence that some companies and individuals are annoyed that their ITIL V2 qualifications now need to be redone to make them ITIL V3 compliant. In addition, the various changes in