Agile Waterfalls (Part 1) | Inflectra

Agile Waterfalls (Part 1)

June 17th, 2014 by inflectra

For companies making the transition from traditional linear / phased methodologies (often called waterfall methodologies because of how they look like a series of waterfalls with arrows between them), to agile methodologies such as Scrum or Kanban, there is often a question of how make their methodology "more agile" without completely changing everything all at once. This two-part entry describes how you can embrace agile in an iterative or agile manner.

How is Agile different?

When I looked up ‘agile’ in the dictionary, the first entry I found was, ‘able to move quickly and easily,’ which is odd when you think about it because that’s a pretty good description of how water moves over a waterfall. In software terms however, agile and waterfall are supposed to be distinctly different; not opposites exactly but very different, like alternative universes. Agile is the anti-waterfall software development method. As if to stress the fact that Agile is not the same as traditional development methods, it is often described by all the ways in which it differs from the waterfall model.

Can we mix Agile and Waterfall Safely?

In all the best science fiction we are told that if two alternative universes were to meet there would be an explosion beyond imagination and in a flash we would all disappear into nothingness. I wonder if this is true of software worlds. Can we take some of the aspects of Agile and inject them into a waterfall process or will it kill the patient? For that matter, are there any aspects of waterfall processes that would benefit Agile projects?

Integrated Teams

One of the tenets of Agile processes is the integrated nature of teams, working closely together with a fluid delineation of function. Could this be applied to waterfall projects? I can think of no serious reason why close knit teams should not be effective in traditional processes; on the contrary, it would improve communication and reduce surprises. My only reservation is the degree to which test engineers can become entrenched with software engineers and still act as effective gatekeepers. We’ll come back to this in a moment. This risk aside, close teams can only be a good thing.

But, can individuals on waterfall-type projects share duties in the way that they do on Agile projects? This might in fact help with the problem most traditional projects have in their staffing profiles. There is an initial high demand for analysts and requirements engineers followed by a peak need for software engineers before a final call for test engineers. Rather than shifting people from project to project – creating an undesirable inter-project dependency – a waterfall project manager could ‘recycle’ her people from one skill set to another. Think how helpful it would be to still have all the software engineers on the payroll when it comes to pre-release bug fixing. As long as engineers are not testing their own code, there would be no conflict of interest.

Keeping Testing Honest

As we said earlier, Agile methodologies promote teams of test engineers tightly integrated into the overall development team. Waterfall projects can certainly benefit from closely integrated teams but we must be careful not to end up with everybody standing on the inside looking out. Agile methodologies encourage test engineers to work closely with software engineers so that they are all pulling in the same direction and trying to get high quality code out of the door. While that is a worthy goal, it is important to still have people who are really trying to find defects, not simply stop them being introduced. We cannot have the fox guarding the henhouse. But, provided we have some degree of ‘gatekeeper’ testing, having others work closely to improve quality is a good thing.

Agile Waterfall Software development Agile manifesto