Agile or Waterfall?

A popular buzzword in software development is Agile methodology. Cynics call it the programmer’s approach to software development while the agile manifesto is full of praise for it. My own experience is that both agile and waterfall are just models and real life does not follow either of these to the dot. Agile projects need the discipline that the waterfall approach imposes and the waterfall approach also needs to demonstrate sufficient flexibility. Change is a perennial issue in software development and software engineering can very much be called as nothing more that ‘managing chaos’.

There is a very insightful passage that Roger Pressman1 quotes from a paper by Nogueira and colleagues that needs to be quoted in full:

The edge of chaos is defined “a natural state between order and chaos, a grand compromise between structure and surprise”. The edge of chaos can be visualized as an unstable, partially structured state… It is unstable because it is constantly attracted to chaos or to absolute order.

We have the tendency to think that order is the ideal state of nature. This could be a mistake. Research…. supports the theory that operation away from equilibrium generates creativity, self- organized processes, and increasing returns. Absolute order means the absence of variability, which could be an advantage under unpredictable environments. Change occurs when there is some structure so that the change can be organized, but not so rigid that it cannot occur. Too much chaos, on the other hand, can make coordination and coherence impossible. Lack of structure does not always mean disorder.

In a SharePoint based project, for example, I found that the management of user requirements can best be done by managing them in an agile based manner, even though the overall project was done in waterfall model. The diagram below (from the Ambysoft site) proved to be very useful.

I created a requirements management sheet with a number of columns with the following key ones:

  • Use Case
  • Description
  • Priority (High/ Medium/Low)
  • Development Complexity (High/ Medium/Low)
  • OOTB/RUC/Configuration/ Customization
  • Iteration in which the feature will be built

OOTB: out of the box feature available in SharePoint to be used without any changes
RUC: Reusable component already available
Configuration: an OOTB feature but needs significant amount of effort in configuring it
Customization: Feature that needs custom code to be written, for example, in C#

By keeping the above parameters visible to the customer and end users, I found that it was very easy to negotiate as each iteration of the system was built. Each time this re- stacking was done, a number of features that were initially high priority go down the stack as users became aware of the implementation complexity and  its impact on timelines and cost. This negotiation is required because there are always the constraints of time and funds. This excel sheet based “requirements stack” is pretty much all one needs for projects based on platforms like MOSS 2007.

(1) Roger S. Pressman, Software Engineering: A Practioner’s Approach, 6th Edition (2005), page 77

This entry was posted in Tips and Tricks and tagged , , , . Bookmark the permalink.

One Response to Agile or Waterfall?

  1. Pingback: Conquering by Inaction | Bhupinder Singh

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s