No it is Not

I knew this would happen. I wrote one 'why, oh why' piece that clearly struck a chord and now I am irresistibly drawn to write another. Soon you will find me writing on the shortcomings of public transport, litter in the street and the manners of youth. Anyway this time I am going to confine myself to 'agile software development' so those with more general concerns for the state of the nation should probably find a copy of the Daily Express.

In short I am fed up. Fed up with those who promote ill disciplined software development under the false flag of agile. Who do you think you are kidding? 'We use agile development' they say. No, you don't, you are engaged in old fashioned, straight out, ad-hoc software development. You are not going to pass off your lack of documentation and arbitrary schedule as good software engineering. You are certainly not going to pass off disorderly bug-fixing as anything other than what it is. It is not refactoring, it is hacking.

Now don't get me wrong ... I am, in general, a proponent of agile software development. Agile development methods, scrum, xp and so on, when adopted systematically, with expert support can be excellent ways to develop software. But, they have clear limitations, to do with system size, the development setting, the strength of the team and the technologies to be deployed. They are not universally applicable.

Many of the practices, both technical (such as test driven development) and social ('stand-up' meetings and the like), associated with agile approaches are easy to adopt and support both rapidity of delivery and product quality. Some of these practices are appropriate for general adoption and with some adaptation may be suitable for use in a wide range of settings. It should be made clear however that simply taking on an random selection of these practices does not permit a developer to claim to be doing agile development.

Further, no set of practices or method can buy you out of a basic set of egineering responsibilities. These are: to maintain a systematic account of the (emerging) understanding of user requirements; to have an architectural vision (subject to change) about how the system as a whole will fit together; to have a basic roadmap that gives a 'direction of travel' and relates the architectural vision to the ongoing development process; to have a conceptual framework that encapsulates a shared understanding of the 'problem domain'; to have some capability to provide global estimates of cost and schedule. None of these necesarily conflict with the aims of agility nor inhibit the use of the underpinning techniques and tools.

So, just to be clear, agile development: "do not talk the talk unless you can walk the walk" ... or something like that.