Agile Waterfalls (Part 2)

Early and Continual Testing

Another prime directive of the Agile manifesto is the early and constant testing of the software. This can be more problematic for waterfall style projects as they have no obligation to provide working software until the very end, or at least close to it. Can a project still be called a ‘waterfall’ model if it does deliver early and often? In some sense, that is what Kanban tries to do; avoid the concept of iterative development, but still deliver working software regularly. So, it can be done, but it requires a whole lot more planning to ensure that elements are developed in such a way that there is a (partial) system that should work at fairly regular intervals.

What About Customer Involvement?

Customer involvement is a very important element of the Agile manifesto. It would seem strange that a seemingly obvious angle should need to be stated explicitly. Why shouldn’t waterfall projects involve their customers at all steps in the process? Well, perhaps it would encourage users to change their minds all the time, which can be a problem for traditional one-shot development methods. So, can waterfall processes allow requirements to change up until the end as Agile processes do? This is perhaps the most difficult of the Agile principles to apply to old-age development methods because those developments are seen as one huge black box of ‘stuff’ being implemented all together. But does that need to be the case? Just because traditional methods do not produce regular working code does not mean we have to see all the requirements as one large amorphous bundle of interlocked functions. If Agile projects are able to implement requirements incrementally, and more importantly, independently from one another, then why should waterfall-style projects not organize requirements in the same way? One could argue that because requirements in waterfall projects are fully formed from the start, separating and untangling them should be easier than with requirements not yet fully explored as in Agile approaches.

Working Code Over Documentation

The most accurate depiction of an elephant is an elephant. Equally, the most accurate depiction of a piece of software is the piece of software itself. Working software over documentation is how Agile projects interpret this and as we have discussed, this is partly realized by regular releases of working code. There is no significant reason waterfall projects should not take a similar approach and reduce documentation to a minimum, referring instead to the product.

Measurement and Improvement

What about constant process measurement and improvement? Old-style project processes tend to have masses of unread procedural guidelines which sit on the shelf gathering dust (or virtual dust for electronic documentation.) The intention is for the processes to be followed until the project ends. But in my experience, the guidelines often go unread because they are not being followed and managers and users both know that to open those dusty tombs would require them to acknowledge this. So, in a conspiracy of silence, they all ignore the procedures and change the way they are working as the project progresses. Now, this is the rather informal and unstructured equivalent of the formal Agile measurement and improvement, so why not just bite the bullet by formalizing and building in flexibility and adaptability to waterfall processes? There may not be separate iterations to which modified practices can be applied but people are adaptable and provided the procedures are written with the knowledge that they are going to change, it could be successful.

Self-Organizing Teams

Finally, Agile projects are typically made up of self-organizing teams. This aspect alone may highlight the most significant difference between many waterfall organized projects and those following Agile practices, namely size. While it is practical for small teams to organize themselves, (although in reality there is always some person in charge, whether formally or not, and so the reality of ‘self-organization’ is debatable,) it is hard to see how a team of 30 engineers can be self-organizing. Could the team be fragmented into smaller units that could be self-organizing? Possibly. Although it is not easy to conceive of separate development teams each working in its own way and yet interoperating successfully.

So In a Nutshell?

Given all these ideas, can a waterfall-style project adopt Agile principles without actually becoming Agile? The answer is yes, and provided the project does not actually implement multiple, short iterations, it will remain waterfall, albeit non-traditional waterfall. Perhaps what we have here is ‘agile waterfalls’, with a lower-case ‘a’.

And can Agile processes learn anything from waterfall practices? Well, let’s leave that for another day.