Agile Software Development

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

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.

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

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.