It seems like time for a new contest with the winner getting a free copy of Succeeding with Agile, my new book.
In Succeeding with Agile, I describe a waterfallacy as “a mistaken belief or idea about agile or Scrum created from working too long on waterfall projects.” And I give some examples, including these:
- Scrum teams don’t plan, so we’re unable to make commitments to customers.
- Scrum requires everyone to be a generalist.
- Our team is spread around the world, and Scrum requires face-to-face communication.
- Scrum is OK for simple websites, but our system is too complicated.
To enter the post, add a comment to this post telling us about one waterfallacy you’ve encountered and how you overcame that waterfallacy or convinced someone that it was a waterfallacy instead of the truth.
Let’s run this contest until midnight Mountain time on next Monday, 18 January. I’ll then announce winners on Tuesday, 19 January. I’ll pick two winners–the entry that I personally like the best plus one that will be randomly selected.
Good luck and let’s enjoying putting some waterfallacies to rest!
I’ve met many developers who follow a traditional waterfall process, but they don’t call it that. I’ve seen this mostly in companies with less than 4 developers total. When I say that I follow or am a proponent of agile, I hear something like, “We’re not that formal here, we get along fine without all of that”. The implication is that agile (or any process with a real name and books and conferences) must be unnecessarily bulky, and would just slow them down. The waterfallacy is that if you don’t give your process a name, then it can’t be broken. I usually reply that agile is much more about doing what works than it is about following rules. Then I might “change the subject” to talking about what they usually do, where the bottlenecks are, and applying simple, common sense fixes to them (ie. Applying agile but without the fancy jargon or requirements)
A potential customer commented this to me:
“Scrum is a lot like waterfall in that it uses command-and-control and is inflexible, for example iteration length doesn’t change.”
A complex system consisting of roughly 100 productized and packaged components can be managed through single backlog and spread over several teams over different continents. Old product management ways were ported to Scrum. We released only BigBang-releases and no alternatives were seen when starting to transfer to Scrum.
It was seen during the first year of transformation that it does not work. Backlogs were split so that each team now has their own backlog that they can commit to and take responsibility of. Each team is responsible for keeping their area clean and functional.
The waterfallacy was that product management would be still the same with Scrum. That you could centrally control everything from the top down and everyone would deliver just what was needed.
Things are looking a lot brighter at the moment.
One Waterfallacy that I have been working to overcome is that ’stories are a test mechanism and not relevant to the way that we develop’.
A lot of our developments are ‘epic’ and often require multiple sprints to implement. There was a perception that these requirements required building ‘from the ground up’ by first implementing the full framework to support all functionality and then adding the wrappers to expose this functionality to the user interfaces. The approach being taken when I joined the organisation to track these requirements was to have Word based requirements documents covering each epic. If a requirement was not completed in a sprint then another document would be produced containing all of the items from the first not implemented. This left it very difficult to establish what was being delivered and completed when, and also very difficult to establish a test status at the end of the iteration.
I have taken steps to resolve this issue by:-
- Added a new object into our requirements repository of a story at a level under the epic and used this object to assign and track work within iterations. The story has an updateable summary containing current status information plus a notes history to trace decisions made to reach the current status.
- Created reports and interfaces to this online system to replace the static Word documents, with a workflow to trace through creation, allocation, design, dev/test and documentation.
- Created a new white board to give visibility of high level story progress in the sprints and to highlight blocks, this is used as a basis for discussion in scrum meetings
- Worked with Product management and the development teams to break down requirements into testable stories which provide value to the user, using previous requirements to give examples of how we could have done things better using this process.
As my postings to the Yahoo Agile discussion group will attest, this is very much still a work in progress. There is still some feeling that stories are a test mechanism rather than a development one, however in our last retrospective one of the main subjects that was raised was the need to break down further into smaller stories, and this suggestion was driven more from those in developer roles than test.
“Our top management won’t allow us to try agile.”
I know at least two cases of the situation one in small-to-medium company and one in huge corporation. The concept is that management doesn’t know, doesn’t understand, doesn’t want to know and won’t understand how agile may be beneficial in some projects thus won’t allow people to do it.
The truth is top management rarely cares. Usually it’s enough when a group of people working on a project or part of a project is convinced they want to try agile out. If they believe they are able to deliver at least the same functionality and at least the same quality they most likely would be allowed to try. If they do a good job people high in organization structure who were reluctant (those who had any opinion at least) will likely to change their mind.
In smaller organizations it is often a decision which can be made by functional manager. In bigger companies you’re likely to need some negotiations to be allowed to do something but every big org like to boast they are innovative as hell so they should at least start it as an experiment.
One of the classic waterfallacies is that Scrum or Agile aren’t concerned with requirements or documentation. So the company can’t adopt Agile because they have complex business rules. When someone say this to me I present to them your two books: “User Stories Applied” and “Agile Estimating and Planning”. Usually the people say after reading them: “Wow, Agile have a lot of customer input!”
I don’t have a waterfallacy for you but I am interested in hearing your rebuttal to the ‘generalist’ and ‘global teams’ waterfallacies you listed. Thanks!
My favorite waterfallacy is called “Secret Crunch-Time”. Its the belief that testing is the last phase, as in analyze, design, code, test. Actually there is a secret phase many call “crunch-time”. Crunch-time is when the team does whatever it takes to actually build the system because the phases up till now are incomplete. Crunch-time is “Agile-lite under maximum-stress”. All of a sudden the team uses daily builds and daily or hourly testing, and panic stricken iterations. Crunch-time is agile. But it’s agile in a not-good, unsustainable, very-bad, way. It’s agile with a small ‘a’. The waterfallacy is two-fold. One: “crunch-time” is not a real phase. Two: we don’t do agile here.
Any team doing “crunch-time” knows it’s real. They may not realize that it has many of the qualities of an agile process but without being effective, sustainable, or fun.
This is about a very big project that was started October 2009.
The team was initially not convinced Scrum was the way to go.
Than one day one of the functional people asked me when he could speak?
Not sure what he meant I asked him to explain a bit.
Well, he said, in the daily meeting I can only talk about what I have done, what I will be doing and the impediments I had, in the planning meeting it’s all about planning and in the retrospective we talk about how the sprint went and what have we learned from it.
That is correct I said, but I still don’t see the problem.
What if I have a question, or a suggestion I want to make? When can I do that, when am I allowed to speak?
I couldn’t believe what I was hearing, so I asked him, if this were waterfall, what would you do then? He replied he would schedule a meeting.
I asked him, did anyone ever tell you that meetings are forbidden in Agile?
He was overwhelmed by my reponse as if it was only normal that you don’t have meetings (formal of informal) when doing Agile, even though they were in the same room, he felt he wasn’t allowed to speak.
Unfortunately the project didn’t continue with Scrum, there was to much resistance from the functional people who felt they could not explain a functionality in a meeting, they ended up writing 7 pages per functional specification. The management wasn’t supporting Agile anymore and so they went back to Waterfall, and I moved on to another project.
“Without defining every task in detail there is no way to estimate the project effectively. We *need* a detailed design doc.” As if there are no similarities in this web app to the 10 previous ones we’ve created.
The past 3-4 years, I have usually been brought in after the fact of a company starting up with Agile. The biggest “waterfallacy,” I almost always run into is iterations that are just short waterfalls. Now folks will get this, though it can be hard to overcome this in many cases such as:
1) Testers are matrix managed and expected to behave according to established test procedures that are tuned to waterfall;
2) Contractors are used and judged based on metrics that don’t work well with an Agile approach;
3) Teams are “fully” distributed and daily “handoffs” make it easy to get into a waterfall pattern.
But there are ways to work on overcoming these.
The bigger problem is getting teams to think of iterative development as happening, not on the calendar, but in their heads (or on the clock). That is, not based on the iteration length, but on development “episodes” of a couple hours.
It’s very easy for teams to look at their development cycle as the length of the “official” iteration. This allows mini-waterfalls to occur. To overcome this, I try to get folks to think of being iterative in 2 hour (at most) cycles (hence, “on the clock” of in their heads, both of which suggest short periods of concentration).
A problem in doing this is that developers think of the whole piece of code they are working on. Advocating a TDD-like approach is one way to start overcoming this. But, even if they cannot do this right off the bat, getting them to think about developing individual “modules” in logical pieces helps.
This latter approach works well with folks coming from very traditional development situations, in particular. Most people taking an Agile approach are doing some form of OO these days, but there are a lot of places where this isn’t happening (i.e., lots of mainstream IT work). So I try to get folks in this situation to think of developing modules in this order:
1) All I/O “calls”
2) Mainline flow, but not all sequential code, just structure
3) Other flow paths (again, not all sequential code yet)
4) Add, incrementally, the sequential code within the structure.
This may require some “mock” data so there is something that can be tested incrementally. But, the overall idea is to get people used to thinking, creating and testing in small chunks. Now, you may argue that this is just really small waterfall cycles, but it’s a big change for teams new to Agile development. It begins to prepare them for a more TDD approach and, perhaps, pairing without having to do these immediately while they are getting used to other aspects of the Agile approach.
Surprisingly, or maybe not for those with some Agile experience, folks can believe it is easier to dive into agile technical practices than it is to adopt the “social”/”business” ones. I think it is the reverse because it is so hard to “simulate” the technical behaviors compared to the others. The technical practices are more “invisible” early in Agile adoption (at least beyond the team), so they are more easily “tailored” to be more like the way folks are used to operating.
It can be harder, I believe, to break the old technical behaviors than the “social” ones, though the latter seem harder because they involve more people, are more initially visible and are, after all, “people skill” matters. But because of all this, I find folks willing to address these, then, when they get these going better, they feel they’ve “got it,” i.e., are now “doing Agile.” But the actual development work is still waterfall-like and, to me, much harder to overcome.
I believe this is because folks already follow some form of technical practices and they feel these constitute the core of their value as employees. The “social” practices may be things people will, at least internally, admit they are less comfortable with, so feel they can try as something “new.” But changing how they behave technically is going after their self-image, I believe, as well as their basic competency. To try some very new approach(es) technically can make people feel much less competent and, hence, more nervous about the changes being asked of them.
My favourite (if that’s the right term!) waterfallacy is the way many waterfall-turned-agile managers plan iteration contents for weeks/months/years in advance, normally without any team input. If any iteration goals are not finished, they are expected to slop over into the next iteration in addition to the pre-planned goals, with the command “Work harder!”. Naturally this overloads the team, resulting in more slop, resulting in more overload….
I handle this by asking the team (including the manager!) what the situation is really telling them, focusing on why the overload is happening, and what is it really telling them about the likely end date. As an aside, this can uncover previously hidden problems and misunderstandings with the agile process outside the team itself, eg hidden pressure to deliver on time, to spec, on budget, which we all know is almost impossible.
My waterfallacy is that Agile means you don’t have to do any architecture or documentation – you just start coding. This is usually seen as a good thing by the team. This is one of the most dangerous waterfallacies out there. Agilists still do architecture, maybe in a different way like collaborative whiteboard sessions or on napkins rather than in a tool. We also do document but only the important things that need to be captured rather that documentation for documentation sake.
Our biggest waterfallacy was the fear that we’d miss important requirements if we didn’t do a big up-front requirements gathering phase. The truth of the matter is that if we miss the requirement throughout the iterations, we almost certainly would have missed it at the beginning. Using agile methods, the most pertinent and important requirements emerge, giving us more confidence that they are captured and turned into features.
When I explain about Evo (my flavor of Agile), there is always at least one person who politely says: “Nice story, but my project is different. It cannot be cut into small(er) increments”. Nice waterfallacy!
Invariably, it takes less than an hour, usually less than 10 minutes, to let the very same person cut the next work into very small deliveries.
People have been educated to do as much as possible. They have to learn to do as little as possible* (and repeat many times). It’s like turning a switch. Once the switch is turned, they can keep doing it themselves.
* If you do as little as possible, it takes as little time as possible and your future is longer. If the stakeholder decides that the delivery was “Exacly as I said, but not what I need”, we lost as little time as possible. So we do just enough to find out whether we are at the right track to success.
In Evo, we are humble enough to admit that our perception of the perception of the stakeholders is probably wrong at least somewhere. The faster we find out and improve our vision about what really is needed, the less time is lost.
The 2 biggest waterfallacy I was told are:
- There are no analysis in Agile/Scrum. This is not true, the analysis is done in iterations as well
- There are no documentation in Agile/Scrum. This was already commented above quite extensively.
waterfallacy: “You can do iterations all you want, but we can’t write acceptance tests (or do any acceptance testing) until you’ve finished the whole project.”
I’ve had a consultant report to my management team that the Project does not have a plan, because every detail of a 2 year project is not designed down to the mouse click. When attempted to explain the idea of JIT Design, he laughed. Thankfully, my management team had already decided to throw the consultant on his ear out the door.
I think the #1 waterfallacy is that you can achieve agility without changing any part of your organisation or its approaches other than the directly affected development teams.
In my experience this always fails, or results if a far from optimum development outcome.
Waterfallacy: “A sprint is like an iteration in RUP”
People who work many years with RUP often think that a sprint is just a very short RUP iteration. But it’s not. A sprint does not have the “waterfall phases” analyze, design, code, test following each other. In a sprint, everything is done continuously or per user story.
A demonstration of how a team works with stories normally helps to get that straight.
Scrum Masters are great but we need a proper Project Manager as well because what we’re going is so critical.
Waterfallacy was: ‘No one do great things using Agile, using Scrum, they are done only using Waterfall or RUP, since high quality product could be created only in case of spending a lot of time for analysis, creating 100% covering plans and specification and then construction and verification’.
Short reply was: ‘Toyota switched to Lean and JiT principles 50 years ago, and they beat waterfalling vehicle manufacturers. And that became a basis for Agile methodologies’.
After some time of reading and consulting, Agile was finally allowed. And even first project shown a lot of advantages from the result prospective.
Waterfallacy: Without detailed user interface documentation, the user won’t get what he wants.
We have found that the customer often doesn’t know what they want until they see it at work inside the application. If we can successfully split up requirements into a set of user stories and get user feedback at every iteration, there is a much greater chance that the user will be able to use the application effectively and that we will deliver the 20% of the features they use 80% of the time and not the 80% they use 20% of the time.
I had someone try to convince me that Agile is inappropriate for “complicated” projects because complicated projects require a requirements change management process, and (according to him) Agile allows the business to change/add/remove any requirement to any degree at any time and at any point in the project (up to the day of delivery) without the development team’s approval.
I was so stunned by the magnitude of his misunderstanding and his willingness to believe that ANYONE would actually be a proponent of a methodology like the one he described that I had to pause for a moment before educating him about his misunderstanding.
Another fallacy by the same guy mentioned above (who this time was attempting to apply waterfall-based metrics company-wide and wanted to prove that they still provided value to Agile teams):
(Paraphrasing) “Agile projects have all of the same sequential phases (analysis, _requirements complete_, design, _design validation_, construction, testing) that waterfall projects do, they are just much shorter so that they all fit within a single Agile iteration, and then they are repeated during each subsequent iteration.”
One of the metrics he was trying to promote (requirements volatility) even had a formula with a “magic number” multiplier based on the project phase. E.g. Analysis equals 2, Construction equals 5, QA equals 7. When I pointed out that this was rediculous, and that an Agile project that detected a need to change a requirement in the so-called “QA” phase of it’s first 2-week Scrum would look like a more volatile project than a waterfall project that detected the same requirement change during the 5th month in the Construction phase, he didn’t have any response, and instead started trying to show me again how the metrics were correct.
“Agile projects don’t need requirements. We just write user stories and talk to the users about what they need.”
This is a waterfallacy because it’s throwing the baby out with the bath water. It’s a mistaken sense of liberation from the burdensome documentation work of traditional big up-front requirements approaches. All projects require requirements. And they most likely need written requirements. It may be a photo of a white board drawing, but we need something. We just relax the requirements for requirements in Agile. It actually means that the team, including Product Owner, know their modeling tools better than ever. They need to create just the right model or document to suit the need. Create a flow chart to communicate a workflow. Create a UML sequence diagram to clarify a system behavior. Create a UML deployment model to make sure we’re able to scale the solution. Someone on the team needs to be passionate about this and evangelize the others. Don’t tolerate lazy, document-free sprints. In fact, account for the modeling activities during sprint planning by explicity putting tasks in for modeling/design work. Demand proof of this by having quick (15 minute) model reviews. It avoids ambiguity, siloed understanding of the solution, and disputes during QA or sprint demo to the Product Owner.
“There’s no time for testing in Agile”
Yes, I know this is quite hilarious, but this has been a criticism I’ve genuinely heard, because people conditioned by the waterfall method believe that there simply has to be a big QA push at the end of a project, or where else would you do it?
Although it’s proving incredibly hard, a pilot Agile project is showing that early deliveries of the product can be fully tested and signed off, and when they are, the tests are fully specified, written, automated and so on, meaning that subsequent QA activity is much easier. Access to testers is absolutely critical here and it’s a massive barrier to diving into Agile for a traditional set-up, particularly one with a poor tester to developer ratio as I’m painfully learning.
Pointy-Haired Project Manager:
“We can’t put our Requirements on Index Cards. They’ll get lost or blow away! What if the cleaner comes in and steals them?”
“We can’t afford to plan the sprint with the whole team, that would take ages”
So each group lead talks to his group (of 1 or 2 people after the cost cut…) in advance, “what are you planning next sprint?”.
After a meeting of the group leads and the project lead there’s the official sprint ‘planning’ where the prepared task-postIts for this iteration are presented.
-> zero commitment, zero collaboration, no learning from e.g. velocity
Alas, I can’t report successful steps against that:
“We can’t do _real_ scrum, because we are _different_! We have fixed delivery dates and a special hardware” – as if Nokia was developing only for i386 PCs …
To make it worse, the company is now introducing MSProject, so we are probably just keeping the daily standups.
Hi,
I’d like to share several beliefs I had the chance to cope with, about Agile and waterfall projects:
First is :
“Agile is more expensive than waterfall”.
As long as I could observe, this popular myth is stemming from the image of “upfront identified exhaustive costs” of a waterfall project. The best arguments for me to challenge this is to analyze (and retro…) if any project in today business dynamics can be exhaustively forcasted & designed 12 months upfront (or even 6 months..)
The second( my very favorite) is to illustrate the “Business value/time” curves for an Agile and an Waterfall project. The message is pretty clear: with Agile a value product can be achieved earlier in time, and the client can decide to stop the project if he or she got enough value of it. That’s an effective way to control and adapt costs. In waterfall projects you need to wait and see … at the end of the delivery cycle. And you need to pay all of it … even if you don’t need that anymore (or not quite like that).
The second strange “phenomena” is a complete opposite reflection about what Agile brings for the development group:
The first one is : Agile is “developer’s police”
The second is : Agile leaves all the power of planning to the developers. Managers and other actors have no way to put some pressure on the development team.
I can tell you that the two camps were pretty passionate about their position.
For the first situation: Developers passed 40% of their time on and calculating and reporting of individual daily velocity to the group of 4 managers (for a team of 6 developers). First step was to create a recurrent story to reflect this task that was planned in each sprint. Proved to the management that over-reporting velocity speeds down value creating velocity.
The second situation : A project that made a transition to Agile from a very top-down management. The way to make management adopt Agile was somehow the following: *
Well the basis : the project was blocked before Agile was deployed, so it needed some new ideas…
Second, anytime Product Owners were not happy with the volume realized/sprint, we used to review at the retrospective time the following items : Complexity embarked was understood and accepted? the priorities were efficiently defined?
After a while, the SCRUM mechanisms were well adopted, as the monthly project review (we were based on 1 week sprints) showed that it advanced better than it did before.
So, these are my favorite stories,
Best to all!
I had a new CTO start halfway through a large Scrum project. He was very uncomfortable with the amount of change we were making to scope and schedule and placed the blame on the fact that in Agile we did not have the scope clearly defined up front.
The fallacy as we know is if we had waited until the point someone thought the scope was fully defined we would have started months later. Also, the reason why our scope was changing is because we were learning things as we were going which we would not have had the insight into before development began.
The resolution was to demonstrate a project schedule where you do requirements definition up front and still have some factor of change vs. one where you do just enough to define your vision and initial details and have potentially a higher (but similar ballpark) factor of change.
In the end getting started and building in shippable increments will deliver value to the organization faster.
The major waterfallacy I’ve come across in the past 18 months is “Agile would be fine once you have something, but it won’t work on our project because we’re starting with nothing.”
There is no doubt that Scrum is a challenging paradigm shift when coming from a waterfall mindset. Even if it is known that Big Up-Front Requirements Gathering, or Big Up-Front Design is not going to provide complete requirements or a stable design, it at least gives people comfort that they have _some_ idea of where they are going, that progress has been made. The difficulty seems to be acknowledging the incompleteness problem, and recognizing that there may be a better approach. Learning to be comfortable with an incomplete set of requirements is like learning to sleep without your teddy bear.
The project I’ve been working on for the past 18 months has been a technology update of a VB6 application. The not-appropriate-for-greenfield-projects waterfallacy has been reiterated to the team fairly consistently, even though we have the older application to which we refer. Despite the backlog being in a good shape, and the business analysts and product owner having input into it, this waterfallacy still comes up about every couple of sprints. Something seems to scare them every now and again, and the comfort of the waterfall teddy bear is all too appealing.
Waterfallacy – There is no documentation in Agile
I have run up against this waterfallacy many times. Here are some of the things I have heard:
- “Agile is all about coding, not about documenting.”
- “The Agile manifesto says documentation is not important.”
- “How can you deliver software without a requirements document?”
The assertion is that there is little or no documentation in Agile and the implication is that Agile cannot possibly work.
How to overcome these statements? I talk about 4 things:
- Agile manifesto – what it actually says
- Why Agile values face to face communication
- How Agile documentation works and how Agile teams document a lot
- If you are using Scrum, it’s up to the organization to define what is right.
*Agile Values: Working software over comprehensive documentation*
In the Agile Manifesto we talk about valuing working software over comprehensive documentation. So, working software comes first since that is what will make our businesses succeed. The manifesto does not say to avoid documentation entirely – that’s a mis-read!
*Agile Principle: Use face to face communication*
One of the key Agile Principles is: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.”
This signals that people should talk to each other rather than communicating through documents. Does not it say not to document? No!
*Agile Documentation – just the right amount*
Agile teams tend use wikis as a lightweight and searchable knowledge base. They document things that they think are important or useful. It may be text, photos, diagrams. For more info on how to make this work, check out this article on Agile Modeling.
Most of the Agile teams I work with produce a lot more useful documentation than more traditional teams I have worked on.
*Scrum lets the organization decide how much to document*
If you use Scrum, let me remind you that Scrum is completely silent on documentation. It’s up to the organization to decide how much and what types of documentation need to be completed every Sprint.
One that is funny: “In an ideal world, when are you going to deliver the project?”
Waterfallacy: The end date of the project can be fixed with a fixed set of User Stories delivered.
The problem, I believe, is that the Waterfall practitioner sees Story Points as related to time. “If you tell me how many SPs you have I can tell you when the product will be delivered.”
This comes up a lot, especially if the Team has at any point related SPs to Ideal Days. Everyone seems uncomfortable, at first, with the concept of SPs not having a time element.
Teams usually get over this after playing Planning Poker or Team Estimation games through a few Planning Meetings. Stakeholders who aren’t getting the concept are invited to sit in and it seems to work (perhaps they just don’t want to have to sit through another Planning Meeting!).
Another step that helps is I get the Team to drop the estimation and recording of time for Tasks. This further separates SPs from hours. The added benefit of dropping hours is that planning and updating of Stories is much quicker.
It’s time to announce the winners. First thank you to everyone for sharing your waterfallacies here. These were all fun to read (perhaps because I wasn’t the one living through these instances of them!). Along the way I recognized some oldies but goodies such as agile doesn’t have time for documentation or architecture (Tony G) and that meetings are forbidden in agile (Peter W). I also got a chuckle out of others like that there’s no time for testing in agile (from Iain Charlton).
On to the winners:
My favorite waterfallacy was Jose Papo who wrote about the common waterfallacy that since there’s no documentation on agile projects, we can’t use agile because our system has complicated business rules. I’m also shocked by the responses I get when I tell people they can augment a user story with a great big Visio flowchart showing a business rule if needed.
As for a random winner, I asked my assistant Jennifer to pick one randomly and she selected Niels Malotaux.
Thank you again to everyone for the great ideas. And congratulations to Jose and Niels.
One thing I’ve come across a couple of times is ‘We do agile development with a waterfall front end’. In other words all the requirements are written out and estimated up front and development and testing plotted out as blocks on a Gantt chart. It’s like having a traditional project which is a week long but claiming it is iterative because the work takes place in blocks called ‘Monday’, ‘Tuesday’, ‘Wednesday’, ‘Thursday’ and ‘Friday’.
To my mind an agile variation of this is ‘We’ve already written 200 stories’. I think a lot of people don’t get that the ability to work on requirements as you go is one of the great benefits of agile. They think agile development is like Forrest Gump’s box of chocolates – you never know what you’re going to get.
Hmmm… some interesting waterfallacys seem to be being propagated here:
http://games.slashdot.org/story/10/02/09/0551202/Game-Development-In-a-Post-Agile-World?from=rss&utm_source=feedburner&utm_medium=feed&utm_campaign=Feed:+Slashdot/slashdot+(Slashdot)