Requirements? We don't need no stinkin' requirements

Sometimes, this is true. I’ve written hundreds of programs, sometimes very large ones that took me years to write, without a single line of a requirements document. We only really need requirements documents when one person needs to communicate to another what needs to be built, or to help organize our own work.

Requirements documents can be the bane of a software developers existence. Poorly written, confusing, ambiguous requirements have been the genesis of the demise of many a software project. More than once, I’ve had developers come to me and complain about poor requirements, or complete lack thereof. “How are we supposed to write this software without requirements?” comes the oft-heard mendicant whine. Let’s look at solutions to this dilemma.

Non-Agile approaches to the problem
1. Complain that the requirements stink. Complain that the requirements are missing major pieces, are poorly written, are missing functionality, don’t really address customer needs, and were basically written by idiotic product managers who just don’t understand the technical complexity of the software. Then, stumble along and write code that attempts to meet these requirements in a doomed attempt to make the product manager happy.
2. Give the requirements document back to the product manager with a detailed write-up of what is wrong. Create requirements templates for the product manager to use for future requirements documents. Install processes that strictly formalize the requirements process. Refuse to accept any requirements or specifications unless they are perfect. Teach those product managers not to mess with IT.

This approach often builds an adversarial relationship between development and product management, and usually in environments such as these you see similar adversarial relationships between development and QA, where everyone is so completely focused on adhering to the letter of the requirements and adopting process for process sake that the customer is forgotten.

Agile approaches to the problem
1. Remember three of the four agile principles: value individuals and interactions over processes and tools, working software over comprehensive documentation, customer collaboration over contract negotiation, then
2. Go to the product manager. Ask them to clarify what they wanted. Spend 10-15 minutes drawing workflow diagrams and/or UI on a white board. Take a picture of the white board with your iPhone and send a copy to the product manager. Go write the code.

This approach, besides solving the problem more efficiently, yields some additional benefits. It builds a trust relationship between product management and development. Customers love being asked what they want, and not just handed what you think they want or meant. A mutual learning environment will blossom from this type of relationship, where product managers learn more about how software is built and can be more appreciative of problems when they occur, and developers get a deeper understanding of the customer. It’s win-win.

Ruthlessly applying the lean engineering axe
You might think that the previous example applies lean engineering, but we can go further. Try this scenario: sit down with the customer in front of your computer, and write the code as the customer elucidates what they want moment by moment. Have QA sit with you as you write, checking your unit tests as you go. Sound farfetched? It’s not. This model has been used successfully in agile environments for years. They are “a strong and direct expression of the Lean principles of pull, flow and value" (http://leansoftwareengineering.com/2009/04/07/feature-crews/).

The two approaches outlined above are somewhat idealistic, and reality usually falls somewhere between the two based on a number of factors, including organizational size and trust (more on trust later). We must always be careful not to fall into the trap of installing process for process’ sake, tools because we like new shiny toys, templates and documentation or any artifact because we think it will add customer value. Agile and lean are always trying to remove wasteful processes. Always be examining your customer value stream, and feel free to apply the lean axe when it’s needed.