52. Feature Soup

“Beautiful Soup, so rich and green,
Waiting in a hot tureen!
Who for such dainties would not stoop?
Soup of the evening, beautiful Soup!”

—Lewis Carroll, Alice’s Adventures in Wonderland

The product sports a superabundance of piecemeal features, many of which do little to address the customer’s real business needs.

It starts innocently. One of the marketing staff has a request from a customer to add an extra pull-down menu. Then a requirement arrives to add an export interface to the product, the product manager wants to include a new analysis report, and the DBA asks for another new field in the database and to change the color of the background. All of these requirements, and many more, are passed to the developers for inclusion in the product. The features of the product grow with each addition, but after a while, everyone—marketing, customers, and development—loses sight of how all these pieces fit together and how they help achieve the business goals. The project that once set out with the intention of meeting a specific purpose has instead become an indigestible soup of unconnected features.

The situation becomes soupier because each of the interested parties views the product’s requirements very differently and there is no common, connective thread. Marketing groups each collection of requirements as a marketable feature—not necessarily with any functional cohesion. The developers group the requirements according to the implementation technology they are using. Each customer thinks of the requirements in terms of the individual fragments of his own work. The impact of these unconnected requirements is that nobody has a consistent way to talk about progress or to make decisions about changes. It becomes impossible to make trade-offs in terms of the themes of a product release because there are no coherent themes; instead, the product becomes a bag of miscellaneous tricks.

So, why do so many products end up as feature soup? It starts with the sources of the requirements—people.

People naturally think that their own requirements are the most important. Different locations of the same organization, or different customers, want their own, idiosyncratic features, and it’s no surprise that their demands do not take the overall business integrity of the product into account. That is the job of the analyst.

When piecemeal requirements arrive, the analyst needs to map them to the business processes that they affect. This mapping provides a way to show different people the effects (sometimes surprising) that a proposed change might have on their work. This analysis provides the analyst with the basis for discovering what people really need—and whether a change offers a real benefit or is just another feature tossed into the soup.

Another contributor to feature soup takes the form of designers including a new feature without considering its overall connections with the existing product. Designers should ask, “Is it within the declared scope?” “What are the interfaces with the existing product?” “Does it overlap or confuse anything that already exists?”

Repeated failure to address these issues leads to a product made up of disconnected fragments. The nature of requirements based on disconnected features means that there is no objective definition of what is in or out of scope. Hence, it is easy for extra requirements to seep into the project from a variety of sources—and they do. The more fragmentary the product becomes, the more difficult it is to assess and to make coherent changes; the downward spiral continues.

Organizations that stay out of the soup share a number of characteristics:

• Project goals and non-goals are defined as crisply and as early as possible.

• Project scope is declared and kept up-to-date against a precise definition of input and output data (see Pattern 24, “The White Line”).

• Iron will is exercised in rejecting requirements that do not advance stated goals and fall demonstrably outside the project scope.

• New requirements follow an approved, traceable change-control process during which they are evaluated against the stated goals of the project.

Avoiding feature soup takes discipline. And it pays to keep in mind that it is you, the project team—not the requestors of piecemeal features—that will be in the soup.