In Chapter 1, The Software Industry and the Agile Manifesto, we took a look at some of the issues that the software industry faced prior to the Manifesto for Agile Software Development and the formation of the Agile Alliance in 2001.

The main issues we saw were related to attempts to control projects through predictive planning, an approach which requires gathering all requirements up front so that a detailed estimate can be made to determine project costs and timelines.

Business Analysts (BAs) often write traditional requirements documents and carry out the analysis work as well, either simultaneously or as a subsequent phase.

A traditional requirements document might contain the following:

• Use case diagrams
• Sequence diagrams describing events and the flow of information
• Data models detailing data and rules
• User Experience (UX) mockups and graphic design elements to give us an indication of how particular user flows might work and look
• Paragraphs and paragraphs of text

As a result of needing to know everything upfront for planning purposes, the document itself would often run into many pages and would require a great deal of time and effort.

Large documents in general also cause something known as "irrational artifact attachment." When a change comes along, which it inevitably does, the reluctance to modify the document is proportional to the size of the investment already made versus the change. This means small changes will often be included, but larger, more fundamental changes might be sidelined until later.

Large-scale requirement gathering and analysis also tend to trigger Big Design Up Front thinking as well. The software design is carried out by an architect who will prescribe the solution, but as they often aren't the people who are going to implement the design, they don't know if it will work.

The following are a few problems that upfront thinking creates in traditional requirements documents:

• Firstly, they're quite difficult to read because technical people write them for technical people. The customer will almost certainly find themselves having to sign off on a document that has little or no meaning to them, and is therefore hard for them to translate and understand what will be delivered.
• Secondly, they often prescribe possible solutions. Prescribing a solution gives the Development Team little or no ownership of the problem; they have to interpret and follow the prescribed designs unwittingly. If they run into aspects of the problem which the design doesn't cater for, the team will find it hard to move the solution forward. 
• Thirdly, it's hard to pull out individual requirements because the detail is often buried deep in the hierarchy of a large document, each requirement seemingly linked to the next. These serve to make the requirements difficult to order and prioritize.
  Requirements written in this format are also hard to prioritize because there is little or no indication of the business value. The requirements document tends to get treated like a laundry list, with people often asking for requirements that weren't necessarily important but, once in the requirements document, became as important as everything else.
• Fourthly, human languages can be ambiguous and have multiple interpretations. It was only relatively recently that we started to write things down. Before that, we passed information from generation to generation by word of mouth in the form of stories. 
  When stories were handed down in this way, the storyteller was right amongst us, often using body language and actions to act out certain scenes. This is a much richer environment to be in as a communicator, as we were able to directly interact with the storyteller, ask questions, and seek clarification.
  As Mike Cohn puts it in his book User Stories Applied, we lost some, or all, of our shared understanding when we started to write things down. In part, this is because we assume accuracy in the written word - more so than when communicated verbally. However, language is ambiguous regardless of the medium. When the nature of storytelling changed to the written word, it became much harder to seek clarification; the author of a document is often not in the same location as you, there's certainly no interactive element as we tend to read documents in solitude, and each reader often forms their own interpretation.

All of the preceding means that large requirements documents don't lend themselves to being broken down into small tranches of work. So, even if the team implementing the design is using Scrum to try to deliver this incrementally, they are unable to negotiate priorities easily. In Agile circles, we call this Water-Scrum-Fall. The following figure illustrates this process:

The preceding diagram shows us using waterfall upfront to gather requirements, carry out analysis, and create a design. We then implement the design iteratively, before going through a protracted integration, testing, and deployment phase. Hopefully, we've interacted enough with our customer during the iterative phase, and we've got closer to the original intention of the requirements document than if we were working in isolation. However, this approach only solves some, not all, of the problems Agile was intended to solve.