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:
- Overview / intro: Waterfall vs. Agile: Can they be Friends? | Architects Zone
- Post 1: Agile Versus Waterfall: Part One | Agile Zone
- Post 2: Waterfall vs. Agile: Development and Business | Agile Zone
- Post 3: coming… (a discussion about Management & QA aspects of Agile, from the end of the previous post: “
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.
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:
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!