Skip to content
* / softthoughts

Waterfall vs Agile methodology (and the bigger picture)

When I was surfing for some waterfall related information a nice site popped up WATERFALL vs. AGILE METHODOLOGY. It is a nice comparison of the 2. The bottom line in this comparison is the aspect of certainty and uncertainty. if I need to make a choice I would sign the Manifesto for Agile Software Development. 🙂 Having certainty in your implementation process is unrealistic and the Agile methodology gives a nice frame to handle the uncertainty right away.

Important to mention is that both of these methodologies position analysis, design, development and testing, but only form a basic frame and are general. When these “development” methodologies are positioned in a real business context, they have big gaps, which are issues that are very important for the business who demands the product. Gaps like

  • how to communicate the request and the change to the relevant stakeholders,
  • how to do the request and change follow up,
  • how to tackle quality (architecture, user interface design…),
  • how to handle functional and datamigration,
  • how to do the documentation and training,
  • how to handle releases,
  • how to handle the needed infrastructure,

Development aspects are tackled with these “methodologies, but the business for which the product needs to create value is not positioned well. Application lifecycle management or more widely a full implementation methodolgy is needed. It is not the development method but it are the other implementation processes that the business experiences the most and it are in those parts they need to feel confident. Confident that for their needs a solution is build. These needs also mean: Does the business need to experience a lack of information of how and when their request is tackled? Can the architecture and its automated processes be undocumented so a top level view is unfamilar and what is realized unclear? Is it ok that the user interface is still widely discussed a few weeks before the go live and it feels unfamiliar? Will the development company still want to do the billing run 10 months after the go live? …

The development method can’t live without the other processes and a fit between the 2 is needed. Additions to the methodologies are therefor very important. The methodologies can’t be used without putting it into a business context, without matching it to the full (daily and future) business needs.

Looking to the bigger picture makes the complexity and also the possibility of uncertainty in the implementation process even bigger. This gives me the idea that only a more Agile approach in the development process can create the most assurance for quality on all levels. This by taking the right time to achieve maximum quality on all levels, ofcourse still with determination, and anticipating change in the development process.

Advertisements

2 Comments

Leave a Comment
  1. Kevin E. Schlabach / Oct 7 2008 10:49 am

    I’m not sure I agree that the following gaps exist in agile (or PMI), but I’m not sure what you are measuring against:

    # how to communicate the request and the change to the relevant stakeholders,
    # how to handle releases,

    If you are talking about the manifesto alone… then yes. But when working with people who are implementing a flavor of agile, these questions are answered pretty well.

    These are answered within the context of sprints/iterations. If you adhere strictly to the sprint definition, then requests only come at the beginning of the sprint, and they are seen at the end. If you are doing sprints longer than a week, then the team quickly learns how to inform the customer/stakeholders mid-sprint because the customer is part of the team (or a representative who then handles that communication. Releases should be possible at the end of every sprint (shippable), therefore it is simply up to the customer to take the drop if they want (including data migration, etc).

    If you wander from the strict definition of a sprint, then how you handle this may change… but if you are doing this I assume that team understands the value of customer communication and involvement and will include that in their evolution.

  2. softthoughts / Oct 7 2008 6:42 pm

    Hey Kevin,

    Nice to hear an Agile evangelist! 🙂

    The essence of what I mean is that the Waterfall and the Agile methodology are paradigms with their own perspective and their own principles that need to be used as basic principles during software development. On both of these methodologies or maybe better said paradigms, additions are needed that position more business needs.

    When you talk about Scrum I think it is like you say, a flavor. In Scrum a request gets a clear position, like you say, in a product backlog, a release backlog and a sprint backlog and no changes are allowed on the sprint backlog during a sprint. The Waterfall paradigm also gives a request a position, while only on the level of the Scrum methodology and not clearly in the Agile paradigm a request gets a position. Instead the Agile paradigm directly tackles other issues (for example the very important one, Agile organisations), which the Waterfall maybe only tackles in a flavor but in the example case (Agile organisations) even never. 🙂 Both paradigms bring specific qualities to the core of the implementation methodologies, but a lot more is needed. Like you use Scrum to fullfill more business needs in an agile context, Regatta tries to position the business more in a Waterfall context.

Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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 )

Google+ photo

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

Connecting to %s

%d bloggers like this: