Waterfall vs Agile – some comments on perspectives we’ve found!


We’re going to be doing an Introduction to Agile presentation at the local Refresh Savannah meeting on July 20, 2010 (7pm @ thincspace) so we thought we’d prime the discussion of this topic here & follow it up with a more detailed discussion of Agile in person there. Hope you were there July 20, if not the recap & presentation is available!

There will likely be participants at the meeting who have exposure to both sets of processes and maybe we’ll do a SCRUM “debate” there too – use the rugby approach to starting over that is! 🙂

This post has turned out to be rather involved! Sorry, but when you start looking on the web for perspectives on this topic you find lots of good stuff – stuff that raises the bar on your thought processes about Agile vs Waterfall & Lean vs Agile, etc.

There will be debates because we can & it’s so easy to “discuss” the topics too – in fact the articles referenced here have worthy discussions to peruse too! You’re free to discuss here too – especially as it relates to how Agile can work for our little community of Savannah GA as we try to get us thinking about & understanding these topics in our Refresh Savannah meetings.

So, read on & if you have the time peruse the articles referenced here – even the video if you have 8 minutes or so to spare or you want to share the basics of why Agile works & why Waterfall can fail!

Now, on to the little bit of food for thought (appeteasers that is) before the meeting of Refresh Savannah – btw, Refresh is a global movement & Savannah has had a “chapter” for a little over a year now – thanks to Kevin Lawver, a transplant to Savannah who has brought a fresh face to Savannah that allows us to address the principles of Refresh, making Savannah a better place to work collaboratively & towards a set of common goals. This informal approach of Refresh has made a difference already, allowing the various segments of Savannah’s creative community to come together casually & informally get to know each others needs & to network their ideas on a different level, the Refresh level.

Now on to the topic, Waterfall vs Agile!

There has been a series of articles (blog posts) on the Agile DZone website recently (it’s a site with lots of resources for developers on a variety of topics) about the perspectives of one writer about when to use Agile vs when Waterfall is still appropriate in today’s development challenges or opportunities.

The discussions in these posts & the comments that ensue are appropriate & we all need some exposure to those perspectives.

While the debate is sane, there needs to be a stake in the ground that Waterfall is NOT 100% dead (yet!), it just needs to be evaluated under stricter criteria when its applied to solving business problems inherently addressed in the application development arena these days.

The business or entity supporting or requiring development to be done in a waterfall approach needs to understand their options & in fact look for a melding of waterfall & agile so that at least maybe they can get all (or some of) the value from using Agile processes while still receiving the deliverables (other than working code) required in many “Waterfall-type” projects.

That’s not the only perspective of the differences & applicability considerations of Waterfall vs Agile but one that we’re highlighting here – take a look at the entire series of articles (listed & linked to below) to evaluate for yourself all of the perspectives.

Our comment about mixing the development processes is not founded in any experience but merely a suggestion that if you have a chance to look at melding the processes in some way, are asked to do some of the things that usually are required by Waterfall processes within an Agile-run development project, or just can’t bite the whole Agile bullet yet, spend a little time evaluating the perspectives in these articles & decide how to maximize your rewards from Agile processes while still being able to meet the needs of the sponsor (business unit or funding source) of your development project. If you can convince them of the value in the total adoption of Agile & dropping some of the requirements of the project that are typically considered “Waterfall” requirements then go for it. But the bottom line is, don’t lose the project by being so blind to Agile processes that you miss the opportunity to do good work!

Three articles are to be written in the series, as of this point an intro article & two of the three have been posted. We’ll monitor the Agile DZone site for the third & final post on this topic, which deals with Management & QA issues as they relate to Waterfall & Agile.

The links to the articles are:

It seems that there has been a lot of discussion on the web about this topic. Various people have perspectives that are founded in their personal stakes in the industry, almost personal feelings like the Windows vs Mac debates we see or just plain interest in folks getting an understanding of their perspective for the sake of education & allowing others to develop their own perspective with a sense of ownership of their beliefs or feelings.

There are even videos about Agile vs Waterfall referenced here (broken – oops, sorry), actually here instead!

This author has seen it all in his review of the “literature” on the web. Then there is the newer debate about Agile and Lean – Closer than you think | Agile Zone. References to both debates (discussions) are considered here as it is about an organization or team developing for themselves (with proper guidance & direction) what works for them.

Then there’s the camp that feels like Agilists are a declining breed – read about their views & experiences over the years as an Agilist & why they feel like a declining breed here: The Decline and Fall of Agilists | Agile Zone. There is a VERY interesting point made in this article about the fact that all teams don’t use agile practices in the same way. And he explores Gaming Theory in his discussion at the end of the post! And draws the following conclusion:

If there was one best set of agile practices, it would be a weakness of the system!

There are many consulting organizations who want to help you get started with Agile if you haven’t already begun your quest. There are many options for selecting processes to use in our development of platforms, tools, applications, websites & even games.

When we look at Open Source development approaches we might ask how does Agile work there? Are there teams who collaborate remotely in a global sense using Agile processes or just a set of protocols for sharing development code at various stages & deciding as a group what works for a release? Well often we see nightly builds of code on a repository for a given open source project. That sounds very Agile to me!

But we aren’t here to discuss the greater issue of global open source development projects, although the scale of the processes we discuss here should be considered.

Our interest is not concerned so much with debate of Waterfall vs Agile – those debates are actually being won or lost in the success of the teams that have made their choices. As this one series of articles, or group of articles suggest, there is a place for waterfall processes. Those places where waterfall is to be leaned towards are pretty specific, so if you work on those types of projects go for it, so that you can deliver what’s expected of those types of projects, just look for the opportunities to fine tune your processes, considering an Agile approach to a projects requirements when it makes sense.

The real question comes when the rubber meets the road & you are judged about whether you have met the requirements of the “buyers” of your services!

Try to exceed their expectations by using processes that make you more successful in areas they hadn’t even considered or in areas that benefit you (if you are a contractor or freelancer bring an Agile outlook as a designer or developer to your projects & all will be good).

Hybrid vs rigid adoption of (or flexible vs rigid execution of) principles around your choices of development strategies without having the viewpoint referenced above will more likely get you the results you want & won’t make any results you deliver to your clients very painful, expensive & unrewarding.

So, our advice is to be agile which carries with it flexibility & adaptability by the very nature of the Agile Manifesto. Seek ye the best set of tools & processes for the work at hand!

Advertisements
This entry was posted in Agile, Agile Development, Community, Designers, Developers, Waterfall and tagged , , , . Bookmark the permalink.

9 Responses to Waterfall vs Agile – some comments on perspectives we’ve found!

  1. Pingback: Welcome to Social Usability – the Sociable Usability Study Service | A Blog for Social Usability

  2. thanks for the useful post, useful info i found on your article.i bookmarked this article.

  3. yosef shuman says:

    I do not work in software development, where much of this Waterfall vs Agile debate seemingly takes place, but obviously the repercussions and applications of these two approaches spans many (if not most) other fields.

    Yes, while we could spend our time debating any of the above ideas, I propose not. Agile is pushing 20 years old, and the holistic SCRUM is over 25. These are no longer new or innovative ideas, and their respective debates no more than the ritualistic beating of dead horses.

    Coming from an Industrial Design background, I view the PC vs Mac.. *ahem* Sorry, Waterfall vs Agile debate on par with ergonomics and UI discussions. Are these things important? Yes, Critically! But nowhere near the cutting edge of the field.

    If we Savannites ever hope to make some positive waves, we’ll first need to stop parroting the decade-old debates of our peers.

    • Thanks Yosef, it’s not the debate that’s important actually I believe – it’s moving the discussion forward about Agile & it seems we do need some “refreshing” on the topic as the community of developers & geeks in Savannah who attend Refresh Savannah (based on the global Refresh movement) see a need for us all to come together & make us more nimble at working together too as a community.

      So the topic isn’t so much a debate but putting into perspective where we should be going as a community who needs to come together to facilitate the new discussions of getting things done – nurturing each others ideas & making Savannah a better place that will attract more students to the discussion as well.

      See we are trying to make a “New Savannah” – so come join the Refresh movement here, you’re Welcome here!

      See you at 7pm tonight?

      • yosef shuman says:

        Thanks for the great presentation last night!
        I learned a lot, and I’m planning to incorporate some of the ideas into my own development processes.

        Pleasantly enough, it felt more like a communal retrospective: “Agile Development 101”, which was much more pleasant than the expected Waterfall battle.

        I had an interesting sub-conversation with Juliet about the slow adoption rates of Agile, even with so many successes under its belt. It seems that earlier education and practice (maybe highschool age) would keep people from defaulting into Waterfall-esque mentalities in their fields…TBC

      • Very nice Yosef, so glad you got something out of the presentation & thanks for the response – post coming right now with the links to slideshare & the image we spent a lot of time on… Thanks for coming, participating & getting involved – yes we need to get agile thinking out there with the younger generations, then maybe we can all get more done!

  4. Pingback: Are you trying to be Agile? – comments from: Agile or Iterative and Incremental | Agile Zone | A Blog for Social Usability

  5. Pingback: July’s Refresh: Agile Development, Plus a Quest and a Question | Refresh Savannah

  6. Kevin says:

    I think Agile and Waterfall can work together, and you can be agile inside of an otherwise waterfall process. In Waterfall, you have X amount of time to complete a set of tasks. Break that time up into sprints and see if you can accomplish those tasks faster, with better documentation, happier developer and happier product owners. If you do, then that makes a great case study to take to management and see if you can get everyone to do it. That’s how we did it at AOL – we took a small team on a small part of the project and tried Scrum. It worked really well, so we expanded it to the rest of the project and voila, within a few months, AOL was bringing in trainers to “certify” all architects and project managers as Scrum Masters.

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