Salmon Ladder Development Is Not The Way To Do Agile
By: Eric Potter
All too often, I hear about software projects where development starts with little to no requirements. Usually, teams that do this say they are being agile. But agile is about iteration, not about starting without requirements. This desire to start coding without any requirements is usually an overreaction to the old waterfall software process model.
In waterfall development, the team spent far too much time at the beginning of a project writing a mountain of requirements before writing a single line of code. So there is a negative response to this to want to start with no requirements. That isn't the agile. The opposite of waterfall development is salmon ladder development. And when you do salmon ladder development, you usually end up being eaten by a bear.
Salmon Ladder Development
In agile, the goal is to deliver value quickly by working in short cycles of planning, development, and QA. In salmon ladder development, you start writing code. This seems liberating at first, like salmon swimming in the ocean. But you soon realize you are constantly swimming upstream against the current trying to figure out what to code. And along the way, you have to make a series of difficult leaps up over waterfalls, making architectural decisions without proper information. And you never know when you will get attacked by a bear or an eagle that you didn't plan for.
A few years later, the Agile Manifesto was published. Slowly, it started being accepted. But there was a problem. Many people saw agile as being the opposite of waterfall, meaning that they could work on software projects without having any requirements whatsoever.
I've never heard anyone use the term "salmon ladder development", but I have seen many projects try it out. They try to start coding with little to no specification. And sometimes it works. The team gets away without them. But all too often, when teams try salmon ladder development, they end up between the teeth of a 900lb grizzly bear. Salmon ladder development is an overreaction. It isn't where we want to end up.
Don't start a project without any form of requirements and say "we're doing it agile."
In the Agile Manifesto, there is no prohibition of requirements. Being agile does not mean that you are against requirements. It means that the requirements serve the goal of producing valuable software.
So What's the Solution?
The problem with waterfall development wasn't that we had requirements. The problem was that the way we managed the requirements emphasized them over the software. It made the documentation more important than delivering value to the users. Most importantly, the overhead of managing thousands of pages of documentation made it prohibitively difficult to adjust the plan of what the software should do. It made the projects rigid and brittle.
Agile projects still need to invest the effort to gather requirements and establish a direction for the project. But we need to do it in a way that makes it easy to change that direction along the way. We still need the discipline to define what the software needs to do. But we will write that definition as we go, as we learn more about the characteristics of the software.
Before you start writing software, have at least one clear objective. You might call this a requirement, a user story, or a specification. Give the developers a target to shoot at. Otherwise, you will be swimming upstream.
About Eric Potter
Eric is a Microsoft MVP and Software Architect for Aptera Software in Fort Wayne Indiana, working primarily in the .Net platform. He has been developing high quality custom software solutions since 2001. He is also an adjunct professor of computer science at Indiana Tech. He loves to dabble in new and exciting technologies.