Say that you had a recurring problem with your car. Every time you stalled, the radio was playing. While there might be other contributing factors, such as running the air conditioning, or recharging your phone through the car, you’d be inclined to think that the radio is a major contributing factor. The capacity of the car’s electrical system might be the ultimate culprit, but you’d also be suspicious that the radio is drawing far too much power, all by itself.
In 100% of the application lifecycle management (ALM) assessments that I’ve done for clients, requirements are one of the major contributing factors to ALM problems. (If you want to know the assumptions that go into those ALM assessments, here’s a video series describing them.) While I admit to an enduring fascination with requirements, up to the point of inspiring me to start writing a book on user stories, I take care not to tilt the results of the assessment in the direction of requirements issues. A set of questions across the spectrum of software innovation practices point to the points where problems start, or where they manifest themselves most strongly. In this line-up, clients point an accusing finger at requirements as one of their tormentors without any prompting.
Interestingly, people in the software profession don’t move as swiftly to address requirements problems as they might other issues. You can get them interested in better testing practices and the removal of release obstacles more easily than requirements improvements. For some reason, they don’t treat requirements the same way they might treat the music system in their car, if it were creating problems.
I’m convinced that one of the major sources of hesitation is the “softer” nature of requirements. Not only are requirements not amenable to technological solutions, in the fashion that a faster build system allows for earlier testing, but the whole concept of “requirement” is more than a little fuzzy. One of the virtues of looking at ALM as a multi-level strategy is that we can make better sense of what we mean by requirements, and then start addressing the problems with them.
Requirements are where we define value
First, it’s important to recognize that what we now mean by the term “requirements” isn’t what people 20 or 30 years ago saw, in their minds’ eye, when they used the word. Requirements are not merely a set of “system shall” instructions, prescriptive information of a very tactical sort. Old-style requirements — the type that filled documents so large that they made the Codex Gigas look like a pamphlet — were heavily detailed, but frequently not in the way that provided the most help. Despite all the highly specific information about non-functional requirements and other matters, development teams still asked, “Why are we doing this? And for whom? Why is it more important than something else? And what value does it have if we deliver a partial version of this functionality?”
Since then, we’ve made great leaps ahead in requirements approaches. One of the biggest innovations is expanding into more than one medium. User stories are vastly better for many reasons, including (but certainly not limited to) the encoding of value into the “so that” part of the story. However, user stories are not enough, if we are trying to describe more than just how we’re going do deliver something of presumed value in the next sprint.
Therefore, few Agile teams nowadays use stories alone. More frequently, teams supplement user stories with epics and themes. They also have seen a lot of value in various approaches to visualizing the software, through wireframes, storyboards, prototypes, and similar mechanisms. While these make it easier for customers to tell the team whether what they’re delivering will have sufficient value, teams also need to know, more generally, what kind of value they’re creating.
Therefore, it’s not unusual to find teams who use story maps to understand value, from the perspective of the customer’s perspective, independent of any software yet entering the picture. Other techniques, such as the customer mental model that is part of much UX work, tries to achieve the same goal. Project or product charter documents sometimes provide additional context: for example, a PowerPoint that describes why the company is developing a mobile application as a way of keeping customers more engaged may become an unofficial but critical part of the corpus of requirements. One of my favored techniques for getting at the definition of value, serious games like Product Box, also deserve to be considered part of that body of knowledge.
Unfortunately, the result of admitting all these new forms of the content into the family of requirements has been an undifferentiated mess. We need a better way to organize this family photo, so that we can tell who are the ancestors, and who are the descendants, of the various ways of defining value in the requirements, from the progenitor questions (e.g., “Why should we do this project?”) to the most immediate (“Did we deliver an acceptable level of value in how we implemented the story in this sprint?”).
Value depends on strategic alignment
Here is how looking at ALM as a multi-level strategic problem helps make sense of requirements. If we know what each level of software innovation strategy is supposed to accomplish, we can identify the sort of information we need at that level, to continue delivering value. Requirements are a lot like mission orders in military strategy: They define an important outcome, why it is important, and who is responsible for achieving the objective. These instructions flow down the organization, where at each level, the parties responsible for achieving the objective figure out the best approach. They pass down further instructions to levels below them, and so on. In return, each level provides feedback, not only on the current state of the effort, but the feasibility of achieving the objective.
Software innovation has its own multi-level strategic challenge. A software company might see its market position threatened if it does not add a mobile version of its main product to its portfolio. Before rushing to market, however, it needs to understand what value the customer would see in a mobile app. The next steps require alignment among the different levels of effort, to ensure that ultimately the company is capable of delivering something of value to both the customer and itself. Actions that happen below the level of the initial portfolio-level decision either align with this strategy, enhancing value, or they don’t, decreasing value. Developing an app, but failing to master the process of rapid and frequent upgrades to the app, might be a major source of misalignment. If the organization is genuinely incapable of delivering upgrades quickly, the company needs to re-consider the wisdom of delivering the app in the first place.
The different requirements media fit neatly into these levels. The product roadmap, for example, states the current strategy for delivering value, across multiple releases. In the first release, we might have fairly modest goals, such as establishing a market presence, and testing the appeal of our initial product offering. The product team responsible for delivering the software then must devise its own plan for reaching that objective, and then provide feedback on progress towards that goal.
Just to be clear, the particular set of requirements depicted here isn’t for everyone. You might need something that is missing from this picture: for example, you might decide that a functional prototype is a critical early step in every project, both to test out technical approaches and to gather early customer feedback. Another organization might see prototypes as too much effort for too little gain.
Taking this perspective on requirements, and their role in ALM, it’s much easier to see why requirements are a constant source of problems:
- They don’t answer the needs at each level of innovation strategy. Some organizations lack important requirements content, such as roadmaps. Therefore, crafting, communicating, and refining the strategy at a particular level much harder.
- They don’t align with strategic goals. A vague roadmap might not give sufficient guidance to teams to plan releases and decide on backlog contents. An overly-precise roadmap might constrain the team’s ability to come up with a meaningful plan.
- They don’t evolve. Requirements are a classic “fire and forget” technology: once people write them, they don’t change. Agile user stories have altered that dynamic for the better, creating a format that is easy to update, and updates are expected. However, many other types of requirements content, such as themes, epics, and roadmaps, often don’t evolve nearly as often.
Unfortunately, this blog entry, as long as it already is, can’t spell out the guidelines for selecting requirements media, testing their ability to improve the delivery of value, or incorporating feedback loops. If it helps someone to approach the problem of, “Why aren’t our requirements working for us?” with as little trepidation as they might have replacing a car stereo, I’ll count it as a success.