Defect reduction through early and detailed requirements specification is a common outcome of process improvement efforts in product development. Enterprise requirements management becomes a specialization that requires expert business systems analysts to gather and document specifications that are detailed, accurate, and complete.
If we apply Lean principles to the requirements gathering effort, we see a backed up queue. Working to "Eliminate Waste" is a fundamental premise of Lean thinking in Software Development. Mary and Tom Poppendieck consider this so fundamental that they make it principal number 1 of 7 in their Principles of Lean Software Development. [i] They dispel the myth that "early specification reduces waste."
In fact, for software development, early specification is waste. This article extends this myth-busting by exposing what can happen when process improvement techniques are blindly applied to requirements gathering. The suggested solution is to replace early detailed specification with solution roadmaps that can be detailed by collaborative teams at just the right time. Agile methods provide the structure and mechanics to allow business vision to lead product development with cross-functional teams that unfold detailed requirements when needed.
There are many accepted processes and approaches to managing enterprise requirements. [ii] These approaches vary from model-focused to document-focused and are well known and practiced by requirements-gathering specialists throughout the business world. These approaches all have common objectives that can be summarized to be:
- Eliciting requirements
- Managing scope
- Managing risk
- Managing change
- Validating for accuracy
- Validating against business and enterprise architecture
The real intent of any enterprise requirements management organization is to accurately capture and manage needs of the business, and organizations are built to create repeatable processes for doing so. However, once the focus shifts toward processes for eliciting and managing requirements, and away from the business goals, problems can arise.
Author Alan M. Davis emphasizes this in his requirements primer, where he states "Requirements management is a means to an end; it is not a goal." [iii] Organizations that focus on processes to manage these objectives represent an anti-pattern that clearly violates Agile and Lean Principles. At the simplest level, this creates an immediate distraction from the reason the requirements are gathered in the first place--to create business value. [iv] This is called out as an impediment of the enterprise in Dean Leffingwell's nice treatise on scaling Agile practices. [v]
The notion that process-focus can create dysfunction is not new. The originator of Lean thinking, W. Edwards Deming, warned of poorly applied productivity measures back in the 1950's. In Out of the Crisis , Deming states: "Measures of productivity do not lead to improvement in productivity... On the other hand, an orderly study of productivity, to enquire whether any given activity is consistent with the aim of the organization, and what it is costing, can be very helpful to the management." [vi]
Focusing on process allows work to occur that is not governed by business value. It's reasonable to see how the good intentions of creating a controlled requirements management organization can create intense focus on processes to gather and manage requirements. These good intentions can result in a very efficient requirements gathering "machine."
Unfortunately, this machine creates a backed-up queue of work, and creates a chasm between the people implementing the requirements and the visionaries that are driving the direction of the business organization.
By insisting on efficiently and accurately documenting requirements as understood by the analyst, the overall organization is left with volumes of "locked-down" requirements specifications that make the organization brittle, since these documents must undergo rigorous change control that slows down the organization's ability to change direction. The well-intended requirements silo represents clear violation of three values