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.
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.
I remember the first professional project I worked on when I graduated. It was a big C++ Windows application using MFC. And it had thousands of pages of requirements. There were rules about what the word "shall" meant in a requirement and what the word "should" meant in a requirement. And yes, the definitions were different. The authors of the requirements documents had tried valiantly to document every single behavior of the application. You see, we developed this project when our industry was at the height of its love for waterfall development.
This was a time when our industry generally believed they could solve all the problems in software development with more process and more documentation. Our project invested a huge amount of work hours trying to keep the documentation up to date. There was a constant battle to keep the software in sync with the documents and to the documents in sync with the software. At times it felt like requirements were the problem. Looking back I can see why people overreact to this style of requirements.
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.
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.