Waterfallgile

The worst possible way to manage a project

Every organization manages their projects differently, even if they use the same terms to describe their strategy. “Agile”, “scrum”, “kanban”, “waterfall” - these are all just labels, often misapplied. This can make it very difficult to quickly convey how your organization handles itself. However, a pattern I have seen far too often is a Frankenstein-esque mutant hybrid of waterfall and agile I call Waterfallgile

Due to the variation in the understanding of what “waterfall” and “agile” are, I’m going to be define these terms as I understand them.

Waterfall

Waterfall is a top-down project management technique. It lays out, from the outset, the entire project roadmap as a sequence. Step 1 is followed by Step 2, which is followed by Step 3. Some steps can be completed in parallel, but overall the sequence is linear. Finish the steps, and your project is complete.

Waterfall’s history is rooted in non-software projects, like construction and manufacturing. Waterfall makes sense here. If you’re building a house, drywall has to go up before you can paint. You also know which steps have to come first, because a construction crew has built a house before. Some of the specifics and details change, but overall the process is the same. Foundation goes in first, then framing, etc. Once the house is built, it’s done.

Software, on the other hand, rarely has a “done” point. At best, it has a point where it’s deprecated, replaced, or abandoned. And while many of the steps are similar, rarely will a project be built by developers who have done exactly the same thing before. This is due heavily to the reusable nature of software. After all, if you’ve built this software before, why are you building it again? Sure, it happens. Tech debt bankruptcy is a common culprit, though these projects are rarely successful. As such, waterfall isn’t a particularly useful way to manage a software project.

Agile

Although the concepts proposed by The Agile Manifesto have existed in some form or another for decades, it was first written in 2001. It proposes certain values commonly found in successful software products:

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

All of these are general guidelines, not hard rules. By that, I mean Agile doesn’t dictate that following a plan is bad, just that it’s more important to respond to change.

Basically, it means iterative development, with the customer involved directly in the process on a regular basis. The closer the customer is to developers, the better. It can often be annoying (to both the developer and the customer) to have the customer directly involved in the process on a regular basis, but it’s still a success multiplier. Last thing anyone wants is to have a development team go hide for months building a thing, only to have that thing not bear any resemblance to what the customer wanted.

Common techniques for “being Agile” include sprints (breaking work up into one or two week blocks of time) and stories (outlining how a user is expected interact with the software to achieve something). The overall goal is for the developers to understand what they’re building, and why.

Capital-A Agile™

Since the Agile Manifesto was written, an entire industry has sprung up around the concept. Experts, consultants, certifications, courses, books, magazines - millions of dollars are spent annually trying to explain the core values of Agile. This money is, more often than not, wasted. I’ve seen Agile consultants come into a company and explain that “this process is the ‘right way’ to Agile”. This completely overlooks the first principle of Agile - Individuals and interactions over processes and tools.

The worst sin of Capital-A Agile™, however, is that it often leads to Waterfallgile.

Waterfallgile

Waterfallgile ignores the Agile manifesto completely. It takes the trappings of Agile, such as sprints and stories, and uses them as a way to micromanage what is, in essence, a waterfall process. This makes not only for a terrible development experience, but also for terrible products.

You can easily recognize a Waterfallgile if you see project management lock themselves in a room for hours, breaking down a product they’ve defined into stories. Sometimes, these stories are fed piecemeal to developers every two weeks. This results in products that are architected by people who don’t really understand software architecture, and built by developers who don’t see the big picture of what they’re supposed to build.

Even worse is when project management thinks that software ever hits a “done” point, where the development team can walk away and go do something else. This is only true if the software has no users. But any software that has users will require maintenance, upgrades, enhancements, and optimizations. That’s just the nature of software, and it can’t be avoided. Despite what some people claim, there is no such thing as future-proof software. Often, future-proof software is over-engineered and full of stuff that will wind up being unnecessary (either because it’s too complex to be useful, or worse - users just don’t care about it). The closest thing to future-proof software I’ve ever seen meets the current needs, and tries to be clean and flexible enough to be changed later.

Another pitfall of Waterfallgile is that it lulls people into a false sense of security. It gives plans. Plans are good to have, but it’s important to remember that a plan is, at its core, just a guess. The best plan ever created would be useless if you blindly ignore the constantly-shifting landscape around you.

Waterfallgile fails on nearly every metric for making good software, but it continues to be frustratingly popular.