addressalign-toparrow-leftarrow-rightbackbellblockcalendarcameraccwcheckchevron-downchevron-leftchevron-rightchevron-small-downchevron-small-leftchevron-small-rightchevron-small-upchevron-upcircle-with-checkcircle-with-crosscircle-with-pluscontroller-playcrossdots-three-verticaleditemptyheartexporteye-with-lineeyefacebookfolderfullheartglobegmailgooglegroupshelp-with-circleimageimagesinstagramFill 1light-bulblinklocation-pinm-swarmSearchmailmessagesminusmoremuplabelShape 3 + Rectangle 1ShapeoutlookpersonJoin Group on CardStartprice-ribbonprintShapeShapeShapeShapeImported LayersImported LayersImported Layersshieldstartickettrashtriangle-downtriangle-uptwitteruserwarningyahoo

ATL ALT.NET: Introducing Agile in Waterfall Environments

From: Josh G.
Sent on: Sunday, November 16, 2008 11:14 PM
Hello everyone,

I was speaking tonight with a friend of mine from another meetup group I help organize, The Atlanta Science Tavern (, about Agile development. I told him I would give him some links to some videos that our team has found helpful, and I thought they would be of help to this group as a whole.

He is a Java developer and he is working with a team that is following a primarily waterfall style approach to development. Most of us know the waterfall model well. It was a style of sequential development that Winston Royce criticized in 1970 as a flawed way of developing systems that he said was "risky and invites failure" due to the fact that system testing is done at the end in this sequential approach. To read Royce's original paper on this subject, visit this link: *

Royce went on in the paper to describe a modified version of the sequential view that he thought could make it work more reliably. Of course, we know that, ironically, his unmodified failure-inviting, risky model has often been used throughout our industry, most famously on many large government systems.

Introducing Agile to Waterfall Shops
We know that the ideas behind Scrum in particular and Agile in general advocate for a much more iterative and empirical, customer feedback-driven approach to delivering software incrementally. In this process, a project is broken down into smaller parts that can be delivered in smaller phases. Each delivery phase itself contains all the analysis, design, coding, and testing appropriate for that specific increment.

So, what are some simple ways to get started learning more about Agile, Scrum, and other related topics?

To get the conversation going you can watch some recorded materials available on YouTube. In this way you can bring in "guest speakers" to your office for free! Here are some good ones that can help you and your team learn more about Agile and Scrum:

Agile and Scrum Videos
Jeff Sutherland and Ken Schwaber are the co-inventors of Scrum. Learn more about them at and They've given a number of public talks available now on YouTube.

Jeff Sutherland on Agile Project Management Lessons Learned at Google:

Ken Schwaber on ScrumEtAl, presented at Google:

Ken Schwaber on Quality in Agile: In this presentation, Ken discusses why quality software must be the yardstick for each iteration.

Jeff Sutherland on The Roots of Scrum:

Michele Sliger on Agile in the Waterfall Enterprise:

Stacia Broderick on Introduction to Agile for Traditional Managers:

Mike Cohn on Agile Estimation. Mike Cohn, of, is prominent in the Scrum community and has written two of the most popular works on the subjects of requirements and planning, User Stories, and Agile Estimation and Planning. Visit his site for more information.

Mike Cohn on Agile Estimation Part 1 (63m):
Mike Cohn on Agile Estimation Part 2 (32m):

Mary Poppendieck on The Role of Leadership in Software Development:

Jeff Sutherland on Hyperproductive Distributed Scrum Teams:

I hope you find these presentations as helpful as our team has found them as we've learned about Agile and Scrum.

* Comments on Royce's Paper
It is fascinating to read this paper from 1970 and see how Royce's own recommendations for what it takes to make the model work actually map to practices we know from today. For example, on page 8 under the heading "STEP 4: PLAN, CONTROL, AND MONITOR TESTING", he writes:

"Without question the biggest user of project resources, whether it be manpower, computer time, or management judgment, is the test phase. It is the phase of greatest risk in terms of dollars and schedule. It occurs at the latest point in the schedule when backup alternatives are least available, if at all.

The previous three recommendations to design the program before beginning analysis and coding, to document it completely, and to build a pilot model are all aimed at uncovering and solving problems before entering the test phase. However, even after doing these things there is stillatest phase and there are still
important things to be done. Figure 8 lists some additional aspects to testing. In planning for testing, I would suggest the following for consideration."

He goes on to enumerate those suggestions. Here they are, abbreviated, and followed by my own comments on how this maps to modern practices:

1. Many parts of the test process are best handled by test specialists who did not necessarily
contribute to the original design.

JSG: This is like the modern QA Engineer, Test Engineer, or User Advocate who uses the system and tests it independent of the business owners, managers, and developers who commissioned, specified, and developed the system.

2. Most errors are of an obvious nature that carl be easily spotted by visual inspection. Every bit of an analysis and every bit of code should be subjected to a simple visual scan by a second party who did not do the original analysis or code.

JSG: We recognize this as code review, but how many of us actually practice this like we should. The way I read this is exactly as he says: every bit of code should be examined by a second party. We also know from presentations from Jeff Sutherland about Google in his description of how Mark Striebeck lead their transition to Scrum that code review is one of the few absolute rules at Google.

3. Test every logic path in the computer program at least once with some kind of numerical check.

JSG: Today we use code coverage tools like NCover to determine whether our testing actually handles all logic paths.

4. After the simple errors (which are in the majority, and which obscure the big mistakes) are removed,
then it is time to turn over the software to the test area for checkout purposes.

JSG: To me, this means the time to hand over the software to QA is not when we as developers have "coded it", but only after we have adequately done our own unit testing, exercised code review, and used code coverage measurement to ensure that we've done our best before we hand it "over the wall" for QA verification.

My last point on Royce's paper is about his step 5, "STEP 5: INVOLVE THE CUSTOMER". He writes this:

"For some reason what a software design is going to do is subject to wide interpretation even after previous agreement. It is important to involve the customer ina formal way so that he has committed himself at earlier points before final delivery. To give the contractor free rein between requirement definition and operation is inviting trouble."

All I can say to that is "Amen, brother!"

Take care,

Our Sponsors

  • Pluralsight Training

    Free Pluralsight .NET training videos -- entire course library!

  • VersionOne

    Hosting space in downtown Atlanta and Alpharetta, and food and drinks!

  • O'Reilly

    Review copies of products, donated books, items, discounts

  • Apress

    Free review copies, 50% off discounts, Giveaways for raffles/events

  • Manning Publications Co.

    User group discounts, Review copies, free books, speakers

  • eConsultants Inc

    Food and Drinks.

People in this
Meetup are also in:

Sign up

Meetup members, Log in

By clicking "Sign up" or "Sign up using Facebook", you confirm that you accept our Terms of Service & Privacy Policy