Skip to content

Category: waterfallSyndicate content

10 Ways to Save a Slipping Project

November 19, 2008 by Peter Stevens

If anyone is looking for proof that agile and waterfall are from different planets, you just need to check out this article by Tom Mochal at TechRepublic, 10 ways to get a slipping project back on track. Overtime was top of this list, even if the deadline is months away! My first reaction was to roll my eyes. But this raises the question, what do you do to save a slipping project, especially if you are trapped in a waterfall?

Waterfall - Agile team cooperation

January 2, 2007 by Artem

When agile software development is tried in a large corporate environment, it often happens that the agile pilot team or even teams have to cooperate with the old good waterfall team around the corner. It sounds reasonable that the new things (like the agile process) is tried first on the project of not too big importance, that are supposed to add value to the more important activities. For example, an agile team might be asked to develop a web-interface to the client-server system being developed by a waterfall team.

I don't have an experience with a really hard dependency, but I've been in a situation when our dependency on a waterfall team was rather weak. What happened is that the waterfall team tried

Waterfall in schools

April 23, 2006 by Artem

Grig Gheorghiu tells about the funny experience of interviewing the graduates for a QA position. All of the candidates have been taught only a waterfall method.

He said they spent a lot of time writing design documents, and since they *only* had one semester for the whole project, they almost didn't get to code at all. I couldn't help laughing at that point, and I told him that maybe that should have been a red flag concerning the validity of the Waterfall methodology.

Process over the individuals

April 9, 2006 by Artem

Individuals and interactions over processes and tools © agilemanifesto.org

Lately on a Russian programmer forum I've read a story about the usual victory of a process over the individuals.

One software development company had Windows and Unix stations. As a result from time to time the wrong endline characters leaked into the repository and caused the build breaks. There were two ways to overcome the problem:
1. To oblige everybody to check the files before the commit

Waterfall 2006

March 19, 2006 by Artem Marchenko

A great sample of satire: Waterfall 2006 conference.

After years of being disparaged by some in the software development community, the waterfall process is back with a vengeance. You've always known a good waterfall-based process is the right way to develop software projects. Come to the Waterfall 2006 conference and see how a sequential development process can benefit your next project. Learn how slow, deliberate handoffs (with signatures!) between groups can slow the rate of change on any project so that development teams have more time to spend on anticipating user needs through big, upfront design.

Best of AgileSoftwareDevelopment.com