Agility without anxiety

Whatever it means ...

The notion of "deliver early, deliver often" may at times equal "deliver badly", however, I don't think it really means 'Agile Development'.

On my projects, I use something that I call 'The Received Methodology', which I describe as 'descriptive' rather than 'prescriptive'. It embodies agile principles, but creates a more formal set of 'hooks' upon which to hang real world development artifacts and processes. It is a reflection of my three decades of experience on actual projects spanning single person one-day hacks on up to multi-year projects with budgets in the hundreds of millions.

'One size' does not and cannot fit all. As projects increase in size, complexity and novelty the requirements for more formal reporting generally increase, but which things are required and at what level depends upon the project. A project charter is wasteful and pointless on projects below a certain size, very useful on some mid-size projects and mandatory in certain development cultures and entirely insufficient on very large projects.

One of the beauties of the Agile philosophies is that they are responsive to the actual needs of the project as those needs unfold.

I do not think that 'Agile' development is either effective or genuinely reflective of all projects, especially as practiced and at the risk of getting horribly flamed, it seems to me to be the sort of thing that journeymen programmers with less than ten years of programming under their belts embrace (as an exclusive discipline) rather than more seasoned developers with decades of experience.

I do not think of these as exclusive to Agile development, but they are well represented by that community:

In the real world, it is people that build software. If you want to get the best quality software you must adjust your processes to the human resources at your command. Formal processes can mitigate damage, but cannot turn poor workers into superstars.

When code and comments disagree, the compiler only pays attention to the code. Code is, by its nature, something of a 'one-up' and working code is its own best specification. If it does not work, correcting automatically changes both specification and implementation. Working software *is* the ultimate product of software development and the sooner a concrete instance exists, the better. Crappy code that works trumps a beautiful intentional design that does not actually do anything.

In the real world, it is not possible to exactly specify in advance what computer systems will do. Evidence of this abounds in all aspects of development from design of silicon on up to website color schemes. All stakeholders in a project require some ongoing concrete manifestation against which to express their views and those views must feedback into the development process. The faster this happens, the better. Agile development reflects this reality by formally placing ongoing customer collaboration ahead of contract negotiation.

Even relatively trivial systems reveal problems and opportunities during development. Excellence demands that these are fed back swiftly and surely to earlier stages, perhaps even back to radically altering or even prematurely cancelling a project. The more ossified a project is, the more likely it is to fail.

Where Agile methods go right, they reflect real-world practices that result in usable software. Where they go wrong is when less skilled practitioners slavishly follow notions like rapid delivery inappropriately.

I think what may irk many accomplished programmers whose work is actually out there running the world is the notion that the latest and greatest things like 'Agile development', 'test driven development' or whatever trivialize a grand and honorable undertaking. They rename cherry-picked high-points already well-established by the literate community, dress them up in new names and claiming to have 'invented/reinvented programming'. The promoters of these things are excellent promoters and I think they are a net-positive force. However, they often seem to me to be at an early stage in their own development and care must be taken to embrace what makes sense without embracing baggage under the same umbrella.

For those who need something more concrete: The Gang of Four did a beautiful piece of work that described many best practices and at the time I read it many years ago actually taught me a thing or two. However, it contained the frighteningly odious 'brain-fart' that is the 'singleton' pattern. It is just a dumb mistake that someone with more years of experience would not likely make. Because it is written down in that book, it continues to get used and even vocally defended by people whose level of experience simply cannot separate the 'visitor' wheat from the 'singleton' chaff.

I like what Agile programming has brought to the table. We should not be too critical of Agile programming just because some practitioners practice it badly. Some of the Agile philosophy and methods are, in my opinion, necessary. They are not sufficient, but more experienced programmers would know that and not consider it a fatal flaw.