In agile process, the product owner put the unformal ideas/user story/backlog items to the sprint/iteration. Sprint/iteration is like a plan for a short term and it is drived by daily meeting. Planning is made in both processes. So what's the difference between agile and the old plan based developing?

  • 3
    a sprint is not a requirement of agile, rather it is a requirement of scrum. People constantly think the two are homonyms, they are not. agile is: Individuals and interactions over processes and tools, Working software over comprehensive documentation, Customer collaboration over contract negotiation, Responding to change over following a plan Commented Sep 5, 2012 at 2:41
  • 3
    One of them don't work with customers who care to know how much the system will cost up-front, or God forbid, when will the development (ever) finish.
    – NoChance
    Commented Sep 5, 2012 at 3:08
  • @EmmadKareem: Trouble is, the waterfall model isn't actually any better at predicting those things, it just pretends to be better during the analysis phase. RUP is a good compromise if you want a little more planning but embodies many of the same scheduling uncertainties as capital-A Agile. Throwing darts at a board would probably be more accurate than the majority of long-term (more than 6 month) project estimations I've seen.
    – Aaronaught
    Commented Sep 6, 2012 at 0:40

4 Answers 4


Planned vs. agile processes for software can be quickly characterized by some pairs.

  • Waterfall vs. iterative/incremental
  • Watts Humphrey vs. Kent Beck.
  • Management driven vs. team driven.
  • SEI CMM vs. Agile manifesto.
  • Microsoft project vs. burn down lists.
  • Interim xyz review vs. scrum stand up meeting.
  • Annual release vs. daily build.
  • Code inspection vs. pair programming.
  • Planning schedules vs. planning game.
  • Committees vs. visionaries.

In someways, this question is already answered by the Agile Manifesto, but instead of reading left to right, read right to left.

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Some of the comparisons above may be a little harsh, because certainly there is a lot of feature driven development that is practices with planned, and releases may be quarterly (but probably not monthly).

The best thinkers behind planned process were influenced by problems with ad-hoc or poorly suited approaches to software such as were described in Mythical Man-Month. As early as 1968, NATO had a conference on Software Engineering to try to solve the crisis and at that point. I think they had some great innovations. Page 12 of their conference report has a remarkable drawing describing waterfall but with curves instead of boxes. It also includes material about the challenges of estimating software projects. Later, planned software process experts borrowed and stole from QA pioneers like Demming and the many Japanese experts who proved its worth in manufacturing cars and electronics.

I think the best agile thinkers were extremely familiar with planned process, and reacted against its limitations, while retaining some of its strong points. Planned process has not lost all of its relevance, and some would argue it is essential for large projects. Planned is still widely used, particularly in large organizations, but many try to hybrid with agile techniques. Perhaps System of Systems design approaches are planned, but they have a good characteristic of creating small teams which is a more practical place for agile. Planned was sensitive to the need for local tailoring, but expected it would be facilitated by meetings and committees.

Great references on this topic include Watts Humphries books, articles, and technical reports on organizational, team, and personal software process. Contrast those with Kent Beck's introductory sections from eXtreme Programming Explained.

One of my professors described the history of software development something like this:

  • 1970s : Tools - a Cambrian explosion of operating systems, programming languages, and tool evolution.
  • 1980s : Process - don't blame the people, blame (and fix) the process.
  • 1990s : People - empower decision making and communications and interactions among people.
  • +1. I wonder how your professor would continue the list on 2000
    – Doc Brown
    Commented Sep 5, 2012 at 5:57
  • He is a dean now, probably too busy to get super involved with it. In class he made it easier to remember by labeling sides of a triangle, so unless we go square, we might be done. New candidates for top influencers might be open source or globalization. Maybe virtualization or agile or cloud connectivity or Xaas would have something in common that could be described as the new focus of software engineering change. This might be blog material, but what do you think are the big changes for software engineering in the 2000s and 2010s? Commented Sep 5, 2012 at 6:44
  • Maybe its "2000s: beyond software engineering" - a statement of Tom DeMarco (www2.computer.org/cms/Computer.org/ComputingNow/homepage/2009/…)
    – Doc Brown
    Commented Sep 5, 2012 at 19:34

Theoretically @JVXR is is right. Waterfall means you get requirements, plan the work, set the price and delivery schedule an off you go. At the end, it all comes together, often the requirements were wrong or changed, the work was more than expected and it turns to a big ball of mud. Agile promises to solve all the problems of waterfall by doing small bits of work in response to changing needs and increase knowledge, regularly delivering something that value to the customer, and stopping when the customer decides the job is done (in reality - when the money runs out).

Waterfalls problems are well known and documented, and therefore easy to suggest solutions to. Agile has it's problems also, however they are less well known and even less well documented - we, as an industry, tried waterfall and failed miserably. Now were are trying Agile, and failing (slightly less miserably, but still failing), and no one wants to suggest it's not working until they can see/sell a better solution.

As a result, for every 100 software houses, there are probably 200 claimed 'agile' processes in use (Many shops have more than one team, and part of agile is a team can do it however they like. Maybe 10 of these processes are truly Agile, the rest are best described as waterfall in drag (i.e. Waterfall without the documentation)


By "Old planning" I presume that you mean waterfall, There is no customer feedback until the product is developed and delivered, and usually thats when stuff hits the fan in the waterfall process. Waterfall heavily relies on "requirement docs" - which the customer will swear that he/she never said anything of that sort in a months time.

In agile, theoretically you produce small working increments and get the customer's feedback and incorporate it in the next release. So chances of stuff hitting the fan is lowered.Overall the customer feels that he's getting something out of what he's paying you for.

  • The "stuff" hits the fan when the target dates come and go :-) and then again when (or if) the customer sees the product. Realisticaly though very few do this sort of traditional 100% waterfall development anyways.
    – Guy Sirton
    Commented Sep 5, 2012 at 3:11
  • Got downvoted for giving a non technical explanation :) ? Whatever..
    – JVXR
    Commented Sep 5, 2012 at 6:42

Plan based developing focuses on creating a detailed upfront plan whereas agile, or more accurately scrum, defers detailed plans until the work is about to begin and allows the order or priority of work to change. This minimizes change impact and means decisions (i.e. plans) can be made when the most knowledge is available. Whereas plan based development requires the plan to be revisted when changes occur and requires most decisions to be made upfront when the team knows the least about the problem and solutions.

  • 3
    "More accurately scrum"? How do you figure? Not that I am a fan of methodologies to begin with, but Scrum wasn't the first version of Agile, and it definitely isn't the only one.
    – Aaronaught
    Commented Sep 5, 2012 at 2:39
  • 2
    Agile is a manifesto (en.wikipedia.org/wiki/Agile_software_development) or a class of development methodologies. For example, Agile does not mention sprints or iterations but it is the most common way of implementing it. Most people use the term agile when they mean scrum en.wikipedia.org/wiki/Scrum_(development). Perhaps I am being pedantic but it is possible to be agile without using scrum but not vice versa.
    – akton
    Commented Sep 5, 2012 at 2:42
  • @akton you've clearly never seen someone implement scrummerfall, or what happens when people want to use the new cool thing without actually changing what they do at all ;) Commented Sep 5, 2012 at 5:04
  • @JimmyHoffa Oh, I have. I have been in many situations where people dive into scrum without doing any planning or doing scrum inside waterfall. I have used scrum in small teams (5 people) and also been the architect for 6 sprints simultaneously with teams in India, USA and Australia. However, the original poster asked about the differences between the methodologies as written.
    – akton
    Commented Sep 5, 2012 at 5:06
  • @JimmyHoffa, I thought that was "scrumbutt". As in, "we do scrum, but we don't do cycle planning or estimation or pair programming or code review or testing or cross-functional teams or any of the other things we find inconvenient."
    – Aaronaught
    Commented Sep 6, 2012 at 0:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.