Thursday, June 29, 2006

Beware of the Agilites

The development of quality engineered software to time and budget is hard. In recent years the hub-hub of agile development methods has increased to deafening levels. There are agile development processes, agile modelling and even agile UP. Many people embrace the agile approach on blind faith. The writing in this area is seductively persuasive, but few readers take a moment to reflect on what is actually being said.

The underlying theme of the Agilites (the advocates of agile methods and approaches) is to pooh-pooh ‘waterfall’ development processes and to claim that there is only one approach, the agile one, to the application of iterative development techniques. We all accept that a pure waterfall development is not ideal for the development of large-scale software, however they reject so much by dismissing it completely, this is like throwing out the baby with the bath water. Many of the Agilites base their views on not understanding large-scale development, being poor practitioners of it or having experienced it being done poorly. Iterative development can be conducted in a non-Scrum, non-XP, non-FDD manner without being a pure ‘waterfall’.

Agile projects do fail just as often as ‘waterfall’ ones, I’ve experienced all kinds and seen both fail. It has nothing to do with the approach and all to do with the experience of the practitioners.

You can see the misunderstands of the Agilites by examining the Agile manifesto.

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work we have come to value:

  1. Individuals and interactions over processes and tools
  2. Working software over comprehensive documentation
  3. Customer collaboration over contract negotiation
  4. Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Let me take each of these points in turn.

  • Point 1. As the old adage goes ‘a fool with a tool is still a fool’. The application of a development process and the appropriate use of tools requires skill and experience. A development process is only as good as the people (no fools please) and an endeavour of any complexity requires interactions. No development process espouses the absence of individuals interacting. Many neo-Agilites reading this value interpret this as a rejection of process and tools. They roll their eyes at the merest mention of the dreaded ‘P’ word and heaven forbid if you suggest that capturing a UML diagram in a tool can provide anything other than an inconvenience. I’ve applied both processes and tools very successfully thank-you.
  • Point 2. This value is based on the premise that there is no benefit to be gained in producing artefacts other than software. The word ‘comprehensive’ is used in an almost disparaging way. All documentation should be produced for a purpose. We’ve all seen people/projects who go through the motions producing documentation that serves no purpose. This is not a problem with documentation per-say. Who can dispute the creation of a succinct domain model that provides insight into a business problem? These things cannot be uncovered by hacking software or if they can the problem domain must be trivially simple.
  • Point 3. Can’t really dispute this point. However, I would say there are few of us who are in the luxurious position where commercial accountability does not come to bear. We all have to produce software on time, to quality and on budget.
  • Point 4. This completely mis-understands the purpose of a plan and the art of project management. This is more a problem with poor project management (managers) not plans. A plan isn’t, as implied here, something that is created at the offset and blindly followed. It is a valuable tool that enables progress to be tracked, dependencies to be managed, changes to be easily assessed and is continually refined and revised (dare I say agilely!?). A project that follows a plan is not to the exclusion of accommodating change, far from it. It is only poor project plan practitioners who create a rigid plan and blindly stick to it. A plan should be revised daily (and not to just reflect progress).

In my next entry I will discuss how an architectural driven approach can be used to drive a plan based project which is adaptable to change and incorporates iterative techniques. It embraces the pragmatic application of precision and formalism whilst rejecting the ‘dash to code’ and ‘random walk’ approach to development software proffered by the Agilites.