Ian Mitchell is Chief Scientist at proAgile Ltd. He can be followed on Twitter: dr_ian_mitchell

As I am sure you are aware, The Mother of All Fixed Time Projects was due for completion today. Global deployment and rollout was scheduled for 6pm on a timezone by timezone basis. But it's now clear that slippage is inevitable. The end of the world must wait.

I still remain fairly well disposed towards these Prophets of Doom. I've managed waterfall projects in the past, so it's easy for me to empathize with their outlook on life, and to admire the peppy confidence they exude when delivering their messages of impending cataclysm. I wish I could have delivered highlight reports with such breezy conviction.  Where I part company with these Oracles of Kismet is in their rather strained usage of supporting material. An Agile project manager should never be so hamstrung by the anachronistic interpretation of evidence, whether it be documented or not.

There is however at least one seraphic text to which I know even the Agile Practitioner can look for reliable guidance. I refer of course to The Ballad of Blasphemous Bill by Robert Service. I have found this to be of great help when struggling with contracts of uncertain scope, but which include requirements that are nevertheless fixed. Even Agile projects can find that these immoveable features are embedded within them, and dug in deeper than the proverbial Alabama Tick. It can take the bending of an inventive mind to bring such projects to fruition, as we will see.

The Ballad of Blasphemous Bill is a poem set in the Yukon of a century and more ago. The author has signed a contract with a trapper...the eponymous Bill. The terms are simple and ostensibly straightforward. If Blasphemous Bill dies, then the author promises to find his remains, and to give him a decent burial.

Perhaps the most important facet of agile software development is its innate ability to satisfy user requirements better, more accurately, more consistently, than what is considered ‘traditional’ software development. Where ‘traditional’ software development begs the user for all necessary information upfront and then reluctantly for feedback at the end of a project, agile development never lets the user out of sight.

This one differentiation separates traditional and nontraditional, slow and fast, waterfall and agile, 50% requirements satisfied and 100% requirements satisfied. The iterative nature of agile development forces engineers to go back to the user regularly, but more importantly, forces them to think of the user continuously. This interaction, and its psychological properties, is at the discretion of the platform employed.

While there are thousands of sales people that will graciously explain why one platform is more worthy than another, I will for once stay software agnostic and comment solely on the significance of the decision. As with any methodology, one platform may lend itself more appropriately to agile development (and the notion of continuous user involvement).