Not so Agile

Authored by

In Greek Mythology, Procrustes, a bandit, killed his victims by force–fitting them into a standard iron bed. If the victims were shorter than the bed, he would forcefully stretch them; if taller, he would cut off their limbs as per the size of the bed.

This torture technique can be compared to how a predefined standard scale is used to forcefully “size up” work in an environment of high variability.

Sprint-based agile methodology of software development is suffering from the Procrustes Phenomenon. This concept’s boundary conditions of applicability are highly limited in the real world. To understand why and how, one needs to go back to the history of software project management processes.

The Dubious History

The history of software projects delivery performance is dubious. Probabilistically speaking, as per the annual Chaos Report , software projects are most likely to fail in terms of cost, quality and timelines. Interestingly, the1 trend has remained the same through the years.

There is now wide spread consensus to declare Waterfall Methodology of software development as a major reason for the poor track record.

Problem with Waterfall Methodology: Process Over Speed?

The waterfall methodology meets two main objectives in software development projects
1. Ensure clear accountability in relationship between supplier (one who is developing the software) and
the customer (one who will use it)
2. Ensure process is highly stable, and that level of rework is minimal

For the first need, freezing requirements before starting the project is an absolute must. Once requirements are frozen, the accountability for any effort or time overrun can be clearly traced back to either of the stakeholders.

The second need requires one to approach software development like one would development of a new physical product. Developing a new physical product requires the design to be complete before start of the actual building. Allowing the design to remain fluid during implementation leads to uncontrolled rework and interruptions.

Borrowing from these principles, a waterfall methodology requires one to move the project into following phases sequentially with clear “gates”, marking completion of each phase

1. Requirements
2. Design
3. Development
4. Testing


Strict change management processes are to be put in place as a “deterrent” against any rethink late in the process. As a result, one of the overheads of this methodology is lot of documentation and sign-offs.

However, when the customer-testing phase comes at the fag end of the entire project, “hindsight” clarity issues create severe conflicts between customer and developer on what was “told” initially in the requirement phase and what was “understood”. So, practically speaking, a strict change management process becomes difficult to implement, more so when the relationship between customer and supplier is that of unequal. Resultant effect is scope rework detected too late in the process, leading to uncontrolled delays. It is no surprise that contractual conflicts, delays, effort spiking and associated stress towards the end of the project are chronic to software development projects.

Leave a Reply

Your email address will not be published. Required fields are marked *