Get the Balance Right

APR

Agile v Waterfall?

05 APR 2011 | Posted in agile methodology, waterfall | Author Rob Smith |

4 Comments

In the same meeting as the proclamation of the “Agile expert” Scrum Master, we were also told that you can’t have a hybrid of Waterfall and Agile, “this simply leaves you with a Waterfall project”. Leaving aside the fact that the supplier was proposing an “Agile” process in which the requirements would be fully documented up-front, this statement betrays a fundamental lack of understanding of Agile.

The suggestion appears to be that Agile is absolute with no opportunity to vary it to address the prevailing context. If this were true, the boundaries of applicability would be very narrow. Fortunately it is not. A project can be viewed as a machine, in which requirements (in their many forms) are fed in, and the output is the working system. The project manager has at his disposal a number of controls that can be varied in order to tune the machine and optimise its performance. Some of these are Agile, others less so.

In a waterfall process the controls that relate to predictive management are set to high e.g. up-front analysis and design, pre-planning, documentation, formal delegation etc. In an Agile project the focus is on responsiveness to support incremental delivery and the controls that support this are set to high e.g. check-point development (test-driven implementation), direct communication, collaboration, emergent analysis and design etc. As the Agile process becomes more responsive there is less need for predictive techniques.

In an ideal situation this can mean that all of the predictive controls are removed, however, in the majority of cases this is not true; it is essential to get the balance right, and this is the skill of the project manager. Within any organisation there will be constraints that limit the ability to be responsive (legacy code, disperate customers and developers) and therefore it may necessary to invoke some of the more predictive techniques; not fully (as one would in waterfall) but to a sufficiency to ensure success. For example, if one were to develop a control system for a nuclear power station you may choose to document and review the complex monitoring algorithms (up-front analysis high) but still have the developers and the nuclear experts working together at the point of implementation (collaboration high) in order to make sure it works. Equally you would also use a very high-level of testing (check-point development high) and deliver incrementally to maximise control and feedback. The resultant process certainly wouldbn't be pure Agile, but it would be far from waterfall.

Comments

Roy_Trubshaw (not verified)
07 Apr 2011 12:15

The problem with the Nuclear Power Station example is that systems are required to be provably correct, either because of regulatory constraint or due diligence on the part of the client in an effort to avoid the inevitable lawsuits when something goes wrong (especially in a US legal environment).

I'm not sure that a purely Agile development methodology can deliver such a system, without compromising the perceived benefits of the methodology.

That said; I, two other contractors and a Westinghouse Employee completely rewrote the existing nuclear power station monitoring system software in under three weeks. But that was probably down to working 20 hour days rather than any specific software development methodology.

Regards,
Roy

Jim Cuthbert (not verified)
10 May 2011 16:57

Even nuclear power monitoring software is incremented, as Roy has demonstrated, can be completed in a 3 week sprint.
Fukushima reminds us that much uncertainty remains about "good enough" in nuclear safety. There are few if any absolute standards, especially in a field as inherently probabalistic as nuclear physics.
Even the most formal requirements turn out to be better addressed by Agile thinking. And in the end, they usually are, in the agile last mile.
The complex algorithms are almost certainly developed iteratively, with much trialling, testing and refinement.

Maybe the increments aren't daily, or even monthly, but there are increments. Moreover the response to changing need often must approach "immediate", with no loss of quality.
Agile demands powerful regression testing capability to ensure high quality - you can't iterate daily with a two day test cycle.

Agile recognises that 20 hour days are not sustainable, and are rarely indicative of a high quality output - our subjective assessment of quality often decreases with fatigue. Agile therefore proposes that a teams should maintain a constant velocity.

Without wishing to sound too zen hippy, my agile journey has probably been going for about 30 years, now. I am beginning to realise that Agile is about organising to manage how stuff actually happens, how we naturally behave. We are humans, not computers, carbon not silicone. We are agile by nature - enjoy your agility, don't fight it.

Rob Smith
10 May 2011 17:26

Thanks for the feedback Roy, Jim.

The example of the nuclear power station was used to demonstrate that all projects can be agile, and I did suggest that an incremental delivery approach was appropriate. I was simply (and probably badly) trying to express the view that there are situations that will constrain agility but this should not prevent an agile approach from being implemented; merely that one may have to modify the approach from pure Agile.

I'm absolutely with Jim on his final point. My view is that Agile is about optimising teams for delivery (how stuff actually happens) and optimising the what is actually delivered (i.e. maximising value of the product).

Jim Cuthbert (not verified)
10 May 2011 17:50

As the Irish supposedly said - I wouldn't start from here.

Not everyone sees the agile vision. We have to work with people, and deal with their concerns.

Everyone is on their own agile journey. Our responsibility is often to help them take the first step (on the long march -this is getting too oriental!), and to sustain them when they falter.

Post new comment

WHAT WE'RE SAYING

MAY

Business Change in the Cloud

There were three excellent presentations at yesterday's seminar Business Change in the Cloud, and an interesting question and answer session. Summary notes and the presentation slides are:

16 MAY

The Importance of Business Agility

09 MAY

Agile Governance - Article

08 MAY

HTML5 in the Headlines