23 Comments to “Agile vs. Waterfall – More Thoughts”

• June 19, 2009 at 5:22 pm
  Bob Barnes says:

  It is unfortunate that the title is Agile VERSUS Waterfall (or standard). Another perspective could have been Agile AND Waterfall. Boehm and Turner, in their work on Balancing Discipline and Agility, do an excellent job of showing benefits of both and how to effectively manage among these two approaches. Alistair Cockburn’s introduction to the related book is most informative.
• June 20, 2009 at 9:22 am
  Lance Walton says:

  Hi.

  I’m going to try this one more time.

  Agile Methods are about adaptation, not about following a prescribed set of rules. Now, what is the sensible adaptation to having full and perfect knowledge of the requirements and the ability to perfectly execute the project?

  I would say that it is:

  a) No testing needed because you are excecuting perfectly. Even the aspect of TDD that helps with design is not needed because you can execute the design perfectly.
  b) No need for customer involvement because you already have everything you need from them
  c) No need to iterate or evolve because the shortest path is known.
  d) etc.

  So, in the circumstances you describe, the agile thing to do is to adopt waterfall (which also will not need it’s testing phase, since the requirements and execution were perfect). That is, unless something more efficient that waterfall can be found given the perfect circumstances.

  In this case, agile subsumes waterfall.

  Now if you are actually asking, in the circumstances presented, if the agile guys keep behaving as if everything was unknown or subject to change, then yes, waterfall would be better. But then the agile guys would not be behaving in an agile way.

  Does that make sense?

  Regards,

  Lance
• June 20, 2009 at 10:10 pm
  Glen B. Alleman says:

  Lance,

  Agile processes are highly rules based. Scrum and XP have explict step-by-step processes that must be performed in order to acheive the desired results.

  I don’t think that’s the definition of agile.

  If you keep comparing agile to a mythical “waterfall,” which is actually prohibited by US DoD, so why condsider it a comparison.

  A better comparison, would be the POOR project management practices, where the rules are not adapted to the project?

  Regards,
  Glen Alleman
  VP, Program Planning and Controls
  Aerospace and Defense
  Denver, Colorado
• June 21, 2009 at 12:45 am
  Lance Walton says:

  I would rather avoid comparing waterfall to agile. I only do so because that’s what the original question was about. Actually it was about comparing agile to ’standard’, a term I find utterly specious, but I’m prepared to go with it rather than start on a whole different discussion. I will not make the comparison in this reply, because it actually isn’t necessary.

  Those rules are a starting point and they are geared towards the imperfection found in software development. All of the Agile Methods big names advocate adapting them. I think most suggest going by the book initially, but this question is about perfection, so we’re not talking about an agile team that is learning the ropes or their circumstances. So we can assume that they can adapt their method to the situation perfectly.

  If that means that they started with Scrum, found that everything was perfect and adapted their approach so that what they are now doing can no longer be called Scrum, it doesn’t matter. They have still behaved in an agile way. The genius of Scrum, like that of the American constitution, is that those who wrote it understood that they could not consider every eventuality, so they built into it the means to change it.

  For example:

  I have a perfect set of requirements. Part of this perfection is presumably that the scope is absolutely right such that given a perfect execution, the ROI (or whatever else you care about) is optimised. i.e. releasing less or more scope would be less than perfect.

  Now suppose I also have a perfect agile team. Everything they do is exactly right. No more than it needs to be, but no less either.

  The agile team would not argue for smaller releases, because that would be less than perfection. The basis for smaller releases isn’t relevant or necessary in this scenario. The appropriate adaptation is not to do smaller releases.

  Now, let’s suppose they do a bit of work. I don’t care if it’s design work or implementation work or any other kind of work. Do they ask the user to have a look? Why would they? The requirements are perfect and the team has done their work perfectly. The user cannot tell them anything they don’t know already. The user will not change their mind or suggest improvements, because what was said in the first place is perfect.

  So, an agile team, looking at this scenario would say: the user can produce perfect requirements. Once we’ve been given the requirements, we don’t need user involvement. In fact talking to the user any more would slow us down and give us absolutely no benefit. An agile team would adapt their process so that they didn’t waste the user’s time or their own. No user involvement needed.

  Now we could go through all of the XP practices (or any of the other agile methods stuff) and look at them the same way. Either the practice provides benefit and contributes to the perfect execution, in which case it is retained, or it is an impediment and it is removed or adjusted. Maybe some other things are added as part of the adaptation. Whatever.

  The point is that agile teams adapt to the circumstances. If they are just following rules then they have missed the point. If we are allowing perfect execution, then the adaptation would be perfect too.

  What I am trying to say is that the perfect agile team would adapt to the circumstances in such a way that they would outperform *any* non-adaptive process or method, unless that process or method is itself perfect, in which case the two ways would be equally effective, by virtue of them both being perfect.

  Now, if the original question was ‘given a team that can execute a perfect set of requirements perfectly, and a faux-agile team rigidly following a particular set of practices which are geared towards imperfection, and they do so without adapation, would the first team be better’… well of course. But that would be a stupid question.

  If you’re still not convinced then can you name a practice that would, in the perfect circumstances given, yield a less than perfect execution but which would not be eliminated or modified by adaptation to the circumstances? If you can, please tell me why it would not be eliminated or modified?

  Regards,

  Lance
• June 21, 2009 at 1:28 am
  Brad Egeland says:

  Glen- I’ve very much enjoyed all of these comments and I’ve actually learned alot. I’d like one thing clarified though…are you saying that “waterfall” is prohibited by the DoD? If that’s true, that’s news to me. I just completed a very large market analysis for the DoD and there was no indication that waterfall would not be allowed and I’m certain that most if not all of the vendors will use waterfall methods. Please clarfiy that point.. I may not be understanding your comment correctly. Thanks.

  Brad
• June 21, 2009 at 7:14 pm
  Brad Egeland says:

  Glen – I realize that I’ve used Waterfall – after others started referring to Waterfall – possibly out of context. Waterfall essentially doesn’t allow for ‘looking back’ by definition, I guess. But we know that’s not really the case in the real world. There is almost always a need to adjust requirements throughout an engagement and these affect budget, timeline, and quite possibly satisfaction. They often result in change orders. What I’ve described I would more loosely refer to as ’standard’ rather than ‘waterfall’ because to me, it is standard. It’s what I grew up managing and what most companies I work with still practice. Not saying it’s the best way, just saying it’s common.
• June 22, 2009 at 5:28 pm
  Glen B. Alleman says:

  Brad,
  I agree it’s common. I think the bigger issue to to learn to invert the conversation and describe what should be done and connect that with some measureable benefical outcome. Brad Appleton has suggested a value proposition for agile be build. I’d suggest a general value proposition of “good” management practices can be a framework for discussion on how to move forward.

  That way the labeling of processes becomes moot.
• June 22, 2009 at 10:02 pm
  Ron Jeffries says:

  What good is a thought experiment that begins with an assumption that things are going to go perfectly?

  What would you do differently tomorrow if the answer to your question were “yes”? What would you do differently if it were “no”?

  I know this: I’ve done nearly a half-century of projects in many disciplines, and I would do any project that came up today using Agile methods.
• June 22, 2009 at 10:15 pm
  Brad Egeland says:

  Ron- I still think it’s a reasonable question to ask. I had to state ‘perfect’ because otherwise the outcry against ’standard’ or waterfall would be even greater. It just came to me that if things went smoothly each way and requirements were solid, then the ’standard’ way should require less testing and oversight and therefore less cost. I realize that it is not a likely scenario at all – especially across many projects, but wanted to bring it up as an exercise for discussion.
• June 23, 2009 at 8:36 am
  George Brooke says:

  Guys,

  please keep in mind the original, hypothetical question. In postulated a “perfect” world, and if that is not a basis for heated argument then I do not know what is!
  It would also help if we shared a few definitions of terms, but the industry being as it is, that appears to be in no one’s interest.

  In general, “Agile” is equivalent to “non-Waterfall”. I can only state that by assuming that everyone understands precisely what “waterfall” is. This discussion ends up in theology. Basically there are a core set of techniques, assumptions and prerequisites which go to make up what is generally taken to be an “Agile” project. I should make a similar statement for “project” so as to be precise, but let’s ignore that for now. In the real world, most projects benefit from iteration and this is a core technique for the Agilists. There are other core techniques which are well-known (I have referenced some papers defining these previously).
  Whilst we do not have a properly accepted definition of terms this discussion will run and run. It has been fun perhaps it is now exhausted? Now how about a thread on Core Agile Principles, the CAP and how they can be applied to projects of varying types/risks?
• June 23, 2009 at 3:19 pm
  Glen B. Alleman says:

  George,

  The problem with the hypothetical questions is you get hypothetical answers. Both are of little use in practice.

  Since Project Management is a practice, here’s some practice answer.

  1. In general agile is NOT equivalent to non-waterfall. We practice non-waterfall in the defense business, but we don’t practice agile for software development in avionics systems. We practice DO-178B.

  2. The discussion is far from theology, since money, sometime small amounts ($100K), some time large amount (we provide planning and controls for a $9B telecommunications software infrastructure progam) are at stake. The success of the project is a stake.

  3. ALL project benefits from iteration. In DoD 5000.02 iteration is mandated. So if the largest defense systems program on the planet can be it, two guys in a room with their customer can do it.

  4. There are properly accepted terms for agile, waterfall, iteration, etc. Start with Winston Royce’s TRW paper for the “near” first use of Waterfall. Which BTW has feedback loops.

  They’re in the dictionary, they’re at the DoD Defense Acquisition University Glossary Site, They’re at DoD 5000.02 and FAR (Federal Acquisition Regulation) sites and they’re in Ron’s book and the agile manifesto site.
• June 23, 2009 at 3:39 pm
  Glen B. Alleman says:

  Brad,
  When don’t go smoothly, the requirements aren’t stable, there are many approaches to the problem. Agile (in the sense of Scrum and XP) are popular ones, there are others.

  The notion of “less” testing is counter intuitive for agile. Agile is heavy testing focused. Agile projects have many times the numbers of tests that the traditional approach to software development. Agile depends on this near 100% unit testing for its ability to rapidly repsond to change.

  In the absence of 100% unit test, there is no way to assure that the changes youmade in respons to the extranl needs of the project did not break something.

  In the “poor” inplementations of traditional software develoment – linear development. Testing is at the end, has poor test coverage, and produce poor confidence the software is ready for use. Defects are found after “go live,” and it’s all down hill from there.
• June 23, 2009 at 4:43 pm
  George Brooke says:

  Glen,
  Exactly, hypothetical questions give hypothetical answers…. both of little use and explains why politicians never answer such questions. Technical people on the other hand …..
  Moving out of the theoretical and into the real world, let me refer to your points individually.

  1) I am arguing that Agile is not a well-defined term, in practice. I understand what you are saying, but the terms are too loose.. except perhaps in your specialisation. Here in the UK we may or may not subscribe to DOD definitions and for significant projects ( e.g government, NHS etc) we would run them under PRINCE2 and plug in an iterative methodology to deliver the actual products (as opposed to the management products).

  2) My point about theology was referring to the way the discussion was going in this particular thread. With the original parameters, the discussions become circular and not particularly important. E.g. are we discussing Religion or religion?

  3) I agree with you about ALL projects ( those in real-world .. not those in the scope of this discussion) benefiting from iteration. I don’t think, for real-world projects, I would ever say otherwise.

  4) Re “properly accepted terms”. I am familiar with Royce’s paper and many others on these subjects. They all contain good definitions of terms. However, in the world which I occupy they actually have many interpretations, particularly in the minds of management who would like the apparent benefits of going Agile without putting in place some of the prerequisites. I would be pleased and surprised if all discussions in this thread assumed the definitions of terms as defined in “DoD Defense Acquisition University Glossary Site, They’re at DoD 5000.02 and FAR (Federal Acquisition Regulation)”. More likely is the feeling that “waterfall” is the fixed, rigid, sequence, finishing with a big-bang roll-out, and Agile is iterative, close contact to customer, variable scope. In fact, we can mix and match according to the project. This is less easy to do in a rigid environment, but it seems to me that the way things are developing that is exactly what is happening. We can “pull down” from a standard library of processes those needed for our current project.. that is they are project-specific. It might involve elements of various methodologies, as they exist right now; what it will be is specific best practice for the particular project. Now that is what I think of when I think of real Agile projects, not shoehorning a project to fit some preconceived idea of how it should run. See http://www.eclipse.org/epf/general/description.php
• June 23, 2009 at 6:10 pm
  Glen B. Alleman says:

  George

  1. OK, I not a defender of Agile. We use agile processes in our commerical and defense business. But having specific defifnitions, hasn’t impeaded our progress.

  2. That’s the problem with starting with a theoritical question.

  3. Agree

  4. Interpretating existing definitions seems to be the source of many problems. Don’t do that. ;>)

  This is why I try an stay away from theoritical discussion when someone mentions waterfall in the agile context.
• June 23, 2009 at 6:46 pm
  George Brooke says:

  Wow,

  I think it would be nice to go back to running a project after all that. Excuse me for a while… I have an Watergile project to run, or should that be Agifall?
  Before there are any responses to the above, that was supposed to be a joke, from the other side of the pond :-)

  George
• June 23, 2009 at 7:41 pm
  Glen B. Alleman says:

  George,

  AgileFall Watergile I love it. Says everything about the methodology wars.

  “OK, everyone ack to work,” we got spacecraft to build.
• June 23, 2009 at 10:07 pm
  Sam Barnes says:

  The question of the moment.

  Working in a small web agency (not quite building spacecraft) I’m often confronted by this question and always seem to find the answer is the following…

  It depends on the project and the client as to what methodology you adopt.

  Although a joke, Agilefall is very much how I tend to run things for website builds. The planning stages start out as very Waterfall-based, but if the client wants changes to the design or functionality after “sign off”, we will openly discuss how we can be flexible and fit it in so long as the budget and milestones are addressed.

  Fixed cost, constant client review, flexible scope = Agilefall ;)

  My clients tend to be much more comfortable with a Waterfall approach, but love that we can adapt as we go along when requirements change throughout the course of a project.

  I honestly dont believe there is a right or wrong way to do things, it really depends on each individual project. Web applications seem to benefit more from a more Agile approach and websites from Agilefall – if the project comes in on time and on budget you’ll hear no complaints!
• June 24, 2009 at 4:01 am
  Glen B. Alleman says:

  Sam

  AgileFall is actually how DoD does it. High level linear flow, with approriate maturity assessment points conducted during design and test reviews.
  Preliminary Design Review, Critical Design Review, Flight Test, …

  But inside each work package, “scrum-like” processes used by the WP Manager. They are in fact fixed cost – the BCWS for the WP is on baseline and can only be changed by the Change Board.

  Linear above the line (outside the work packages), agile inside the work packages.

  That picture of the duck – calm on top, paddling hard underwater.

  I do know that web apps are special in many ways.
• June 24, 2009 at 8:50 am
  George Brooke says:

  Glen,
  Sorry, I cannot resist it.. do you think AgileFall could become an accepted term? It was supposed to be a joke, but it combines serious governance with the iterative/evolutionary approaches which are so successful. Many years ago (compilers) we did exactly this reporting in a linear sense but implementing in an “agile” sense. Of course that was faking it. Nowadays we should be able to do it more seriously. As I mentioned, a generic methodology such as PRINCE can be used for governance, and the specialist technique selected on a needs basis. The big advantage for senior management is a uniform reporting and management approach, separated from the underlying specialisation. This is a form of abstraction.. we have pulled out the special features and propagated the general. This has got to be a healthy and mature approach. In the UK, PRINCE is mandated for a major government projects. It is pretty straightforward too.

  In the creative industries, apart from having an established system architecture, much of the specifications/requirements come from “show me” approaches. They are not very analytical. Similarly, small fixes to existing systems exhibit the same sort of characteristics. I would be quite surprised if the approaches suitable for this work would work with spacecraft (if you do work on spacecraft I am really envious… years back I did a fire-control system for the Navy and numerical control development for the military… great stuff). I seem to recall on the Telstar satellite that early tests indicated a misunderstanding between the UK and the US in terms of the direction of signal polarisation. That got detected and fixed after launch. I suppose that was either Agile or beta-testing? The nature of the projects needs to be taken into the equation for specialist technique selection too.

  AGILEFALL ….. a new term… spread the good word.

  Now I have got to get back to designing a new course on Requirements Capture and Specification….BFN
• June 25, 2009 at 6:51 pm
  How to Ensure Project Success Every Time | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] here (see “Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”) might make you think differently based on comments by staunch Agile supports. But we all know [...]
• June 26, 2009 at 8:52 pm
  George Brooke says:

  Historically PRINCE2 has been seen as “non-Agile”. However, we now have PRINCE2:2009 and I have written a summary of PRINCE2 pluses and minuses at http://www.oaklodgeconsulting.co.uk/Articles.htm if you are interested. There are few other articles there too… so peruse and argue with me :-)
• June 28, 2009 at 8:08 pm
  Agile Software Development in a Standard Project Management Methodology | Project Management Tips || Project Management, Collaboration and Knowledge Management Blog says:

  [...] I’m sorry everyone, but I’m going to do it again. I’ve learned a lot from the Agile vs. Standard software development process discussion that is still going on based on two other articles (“Agile Software Development Project vs. Standard Software Development Project” and “Agile vs. Waterfall – More Thoughts”). [...]
• March 17, 2010 at 9:43 pm
  Bruno Spinelli says:

  Hi Folks,

  I believe the secret is adaptation, for the situations you can’t avoid working with strict constraints, I believe Agile methodologies can be adapted.

  If you need to deliver something, in a fixed time and budget , you have no time to loose and no money to waist. In other words: “You better completely and precisely understand the requirements written on that RFP (Request for Proposals) otherwise you are going to get burnt.”

  The best way to make sure that you are achieving the expected results without spending time and money with unneeded efforts is to make the stakeholders aware of every significant piece of software built as soon as possible so the unavoidable mistakes of any project are always corrected before is too late.

  I see iterations, incremental releases and constant reviews as essential tools to support this scenario and meet the requirements effectively. Agile methodologies leverage all these factors naturally and natively, and that’s where I think they have so much to contribute to any project, even the ones with so many restrictions.

  I invite you all to take a look on the post “Agile for Fixed Price and Time Projects: http://whiteboardworks.com/2010/03/agile-for-fixed-price-and-time-projects/

  Regards,

  Bruno Spinelli.

Search for:




Become a contributor
Share you project management knowledge and expertise with the hundreds of thousands readers of PMTips.net. Apply here!
Advertise with us
If you are interested in conveying your message to your target market, please contact us at advertise@pmtips.net!
Who's Talking
Popular Posts
Popular Posts
• A Lessons Learned Template
• Project Management: Is PMP Certification Worth It?
• The Project Kickoff
• Lessons Learned
• Engagement Management vs. Project Management
Recent Comments
Recent Comments
• Brad Egeland on Why you need a decision log
• Elizabeth on #500 – What I’ve Learned So Far
• Priyadarshini on A Lessons Learned Template
• Nicole Pletka on Getting Your Organization Started in Project Management
• Project Management on Getting to the Actual Project
We Recommend
• Seavus DropMind™
• Seavus Group
• Seavus Project Viewer
Categories
• Project Management
  • Tips
  • News
  • Tools
  • Opinion
• Knowledge Management
  • Tips
  • News
  • Tools
  • Opinion
• Collaboration
  • Tips
  • News
  • Tools
  • Opinion
Resources
• Gantthead
• ICPM
• Mind Tools
• PM Toolbox
• PPMNG
• Project Smart
• Reforming Project Management
• The Lazy Project Manager
Subscribe for e-mail