Welcome to EMC Consulting Blogs Sign in | Join | Help

Rizwan's Blog

NOTE: My blog has now moved to HTTP://MULTICHANNELTHINKING.BLOGSPOT.COM - I'm writing about multichannel innovation, customer centricity, future technologies, and social media for business. Please change your subscription link to http://feeds.feedburner.com/rizwan :)

 

Waterfall vs Agile for Client-based work and R1 teams

Waterfall is the standard process oriented methodology employed by most (particularly large) organisations that need rigorous procedural control and auditability. It is particularly relevant for client side work because it involves a step by step process with a relay race approach involving up front analysis costing and estimation, and an incremental project life cycle with different skills being employed at different periods, thus allowing resource to be managed more easily. It is also easier to certify and compare against standards, and the focus on documentation means that there are easy reference points and improved knowledge transfer among the people involved. Organisations like to work this way, and people get comfortable with it because it can allow them to point fingers when things go wrong, and can remove the need to change and be flexible.

Agile comes at projects from a completely different angle, placing the onus firmly on people rather than process. It does away with documentation that does not add immediate value to the project development, and to be successful requires all team members to be more cross functional and work together in a fluid supportive way, dependent on a high level of goal congruence and motivation. It is a trust based approach that is not easy to tick off against quality standards, but much easier to measure against return on investment. It provides high visibility on outputs and relevance, and allows for much greater client side involvement and ultimately satisfaction, and delivers greater recognition for team achievement. However the lack of documentation raises risk in areas of knowledge transfer, trust is fragile across organisations, and Agile does not necessarily deliver whole projects any faster. Organisations are rarely set up to cope with Agile requirements, but professionals like to work this way because it allows them to control the way they work and they don't have to waste time on non-core activity that detracts from delivery.

The point to note is that client based work, particularly for clients with limited or no Agile experience, and/or delivery with novice (R1) or limited experience Agile teams, has both pros and cons. In the rush to sell or implement Agile against Waterfall, the cons are often ignored, but these must be recognised and mitigated against if you want your Agile project to really be successful.

The following is a brief outline of both the pros and cons of Waterfall and Agile you can use as a starter for ten.

Waterfall Agile

Overview

  • Relay race approach 
  • Good for clear, well defined & fixed requirements
  • System specs
  • Functional requirements
  • Software requirements
  • Analysis
  • Design
  • Coding
  • Testing
  • Operations

Overview

  • Holistic rugby approach
  • Good for projects with unknowns
  • Cross functionality
  • Parallel working
  • Working together
  • User stories (supported by use cases, models, UML etc. as necessary) rather than detailed Requirement Specs
  • Ongoing Analysis and Design 
  • Coding and testing in tandem

 

Pros

  • Audit
  • Structured management
  • Budget and schedule predictability
  • Control
  • Scale
  • Skills Specialisation
  • Documentation = knowledge transferability
  • Familiarity / often part of organisational culture
  • Structural support from other departments

Pros

  • Early ROI
  • Flexibility
  • Team control
  • Better understanding of both bigger picture and immediate priorities
  • Better delivery
  • Higher visibility
  • More client involvement

 

Cons

  • Late ROI
  • Embeds rigidity
  • Heirarchical control
  • Lack of client involvement
  • Big delivery surprises late in the project
  • Too much documentation
  • Poor visibility
  • Poor long-term goal coherence
  • Difficult to control output relevance over life-cycle
  • Protracted delivery
  • Reduced personal involvement
  • Higher risk of failure

Cons

  • High learning curve
  • Early process surprises
  • New ways of working
  • Resistance to evolving information
  • More regular dependency on client involvement
  • Harder to manage third party dependencies
  • Harder to manage resource
  • Requires much tighter team working
  • Requires greater cross functionality within teams

 

 

Published 05 March 2007 13:39 by Rizwan.Tayabali
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

 

Julian.RHarris said:

I think your comparison is an essential conversation piece thanks for kickstarting it Rizwan.

The objections on both sides will be that there are lots of points that are completely reasonable and normal on the other. For instance 'user stories not requirements specs' -- this suggests all you capture are user stories. Actually, you capture what you need for the audience and timespan of the document. Remember 'CCC' -- card / conversation / confirmation -- the conversation and confirmation may well result in some pretty dense documentation if it need be. Domain object models, process flows requirements... these all still need to be maintained clearly and unambiguously in the minds of those who benefit from it.

March 5, 2007 23:45
 

Rizwan.Tayabali said:

Hi Julian,

Agreed. I've updated the post. I had originally kept the comparison as simple as user stories, because this is a key selling point of Agile that causes confusion in novice teams. The 'lack' of documentation becomes an excuse for not writing things down, and conversely a space to hide behind when things don't go so well. Different team members often have different views on what constitutes essential documentation. In the end the user story, effectively broken down to an atomic level seems to be the consistent approach across Agile projects.

March 6, 2007 09:42
 

john.rayner said:

I started to draft a long comment, but the more I thought about it the more it seemed to me that your post could be summarised in one statement: "If you don't know agile, don't bother starting it - stick to waterfall" Is that really what you are suggesting? Examples of this: - you imply waterfall is better when the client and the delivery team have limited experience with agile - you talk about familiarity with and organisational support for waterfall as reasons to stay with it - you list "new way of working" as a negative point around agile I agree that there are a number of risks inherent in the agile approach and we probably don't shout loudly enough about these. Some that you pick out are: - clients might not commit to the required level of involvement - teams might not work together closely enough - team members may be resistant to working outside their area of specialisation But it's important to weigh these (and other) risks against the rewards of a successful agile project: - higher quality delivery - business value delivered earlier and more reliably - early warning signals about project deliverables - a more pleasant experience for the team - etc, etc
March 6, 2007 21:06
 

Rizwan.Tayabali said:

As a statement that's probably a very extreme summary. The point I'm trying to raise is that in implementing Agile it is important to recognise the risks up front, and also to appreciate their comparison against waterfall, which if run properly can work very well. In any other circumstance a cultural change in ways of working would be accompanied by a formal change programme, but as this is a development methodology, the business and people impact is not always given the consideration it needs. Ignoring the risks can throw up a whole range of working and delivery difficulties which will appear to be unnecessarily unexpected, and the client will invariably compare against waterfall and its familiar comforts. What I'm also alluding to is that I feel this is a consideration that isn't always taken seriously enough, or effectively prepared for by organisations looking to deliver Agile projects into new clients.

March 7, 2007 09:47
 

John.Swanson said:

I sat and watched a Waterfall the other day and I observed ….

That not all the water flows at the same speed, that some droplets overtook others, that some droplets were allowed to grow and some allowed to fall by the wayside.

I noticed that they all flowed in the same direction working in perfect harmony, arriving at different, but expected, times into the greater pool below. After a few ripples the pool was calm.

Doesn’t seem like a bad approach to me …

March 8, 2007 11:55
 

Rizwan.Tayabali said:

Agreed. I've seen waterfall work well. The key is to be flexible rather than rigid with waterfall, and of course to focus on the people involved and build trust - which essentially is then not so different to Agile. The value of Agile of course is that it is predicated on these principles, meaning that they never get lost in the chaos. It also reduces the avenues provided by waterfall for pedantic argument and positional bargaining.

March 8, 2007 12:08
 

Eve Sheridan said:

It's an interesting topic. Which is more important to the success of a project - the processes or the people? The reality is that it's both. You need to implement structured processes to get people to work in a logical, predictable fashion. And you need people that can work in an agile manner, that focus on building deliverables not not completing "the next document in the chain". the best project management methodology I've come across that seems to balance both is MPMM, from http://www.mpmm.com
March 13, 2007 10:15
 

Phillip.Thompson said:

Rizwan, good points

I'd just like to say that the document heavy waterfall approach does have some benefits. Often following from the technical delivery of a project is the production of a user manual or a training manual.

This is often easier with a waterfall requirements spec than it is with a collection of agile user stories.

This, like any other issue, can be reduced by forward planning, but structuring the Agile documentation as it is produced into some huge document but I don't think it will ever reach the same ease of use as a waterfall spec.

March 16, 2007 12:22
 

David McLean said:

A good summary Rizwan - just picking up on the point about people and process - the agile manifesto states People over Process in the statement "Individuals and interactions over processes and tools " but does qualify that with "That is, while there is value in the items on the right, we value the items on the left more." And with this qualification allows for process but not at the expense of and only for the benefit of - the people.

I am at the beginning of a project to produce a simple tool called CardConversationConfermation which Julian may be interested in where I am trying to epitomise these values.

See...

http://agilemanifesto.org/

http://www.cardconversationconfirmation.com/

June 6, 2008 19:01
 

Chris said:

Thank you for clearly defining why I have been miserable for the last 3 years. I come from an Agile-esque development background and have been put in the Waterfall model without ever being able to specify the differences so succinctly.

Thanks again.

June 26, 2008 22:06
 

J Zee said:

I am in a super crazy project at the moment. Some times I think, what the hell is going on.

Only yesterday a senior developer got on my nerves. She is big time guilty of  pedantic argument and positional bargaining :o(

i have been analysing software in an Java/XP/Agile team and coming into the world of rigid AS400/Waterfall team is freakin me out!

Trust, Trust and More Trust! Thats what is needed.

July 10, 2008 21:37
 

Waterfall model to Agile Software Development said:

In waterfall model Writing specs in a fast changing environment and delivering huge updates just does not work. By the time the ink is on paper, it is out of date.

Agile method's greatest strength is actually about early delivery of working results. The end of the first iteration (usually somewhere between one and four weeks) results in a little bit of software that actually works.  Here is comparison of Agile Methodology  waterfall Model

<a href="http://www.techbaba.com/q/1057-moving+waterfall+model+agile+software+development.aspx"> Waterfall model to Agile Software Development</a>

August 5, 2008 15:54

Leave a Comment

(required) 
(optional)
(required) 
Submit

About Rizwan.Tayabali

Background in business and management consulting. Current focus - Retail Sector.

Blogs:
http://multichannelthinking.blogspot.com
http://urbansurvivalproject.blogspot.com

Powered by Community Server (Personal Edition), by Telligent Systems