Software companies make fundamental tradeoffs between cost, quality, and functionality (the Iron Triangle) all the time. These tradeoffs happen in the software itself, of course, as anyone who’s ever heard this analogy will tell you. But they also happen in the process of making the software. In software development processes, cost = effort, resources, and time, and functionality = functionality, of course. But what is quality?
I don’t mean this to sound like a Zen primer or a TQM discussion, but software quality is much more than the negative condition of having no open bugs. It’s also the positive condition of building the right thing. Generally speaking, this means product strategy and product requirements. And here is where the arguments usually start, because it’s far from clear how to build The Right Thing. Traditional software development tries to ensure that The Right Thing gets built by requiring a multi-stage sign off and by providing extremely detailed documents at each stage of the process—a marketing requirements document for initial concept sign off, followed by a functional requirement, a technical requirement, a detailed test plan, and so forth. Between each of those stage gates is a lot of work. Many months may pass between initial concept and development.
So using rigorous stage gates to build in “quality” comes at a cost, especially in time. This is particularly risky in a new market space, where time to market and time to benefit is key. If you commit to a lengthy waterfall process, you lock yourself into a feature set that commits the team to a path of several months or even years to build the Right Thing.
But in a year’s time, the market may have shifted out from under you, and not just once. Clearly a way of building software is needed that doesn’t require so heavy a use of resources to define requirements and that can allow the Right Thing to be built more quickly, and that allows for more opportunities for the team to “change its mind” without wasting a lot of work. Agile software development methodologies seek to provide those opportunities by defining the work product to be built in terms of “iterations,” where the software gets built in discrete, short sprints rather than one. Something concrete gets built in each iteration, but the team is free to change its mind about what to build in the next iteration—and it may need to, either in response to feedback about the product of an earlier iteration, or because things have changed in the outside world.
To support a rapidly iterating software product, though, you need a requirements process that moves quickly as well. That’s where Agile gets its emphasis on “stories.” An Agile story is a simple way to specify a requirement, and it follows a pattern of “As a user type, I want to do something because of an important reason.” It’s a streamlined but easy and effective way to specify functional requirements. The idea is that each story is a standalone piece of functionality that delivers value to a user. Therefore, every discussion about choosing features for a release discusses trades between things that actually benefit the user, which is a much easier decision to make than choosing between a functional requirement and a technical requirement.
As you might guess, adopting Stories as a requirements methodology has its own challenges. In this case, the tradeoff between requirements “features” (detailed documentation) and requirements “quality” (preserving flexibility by not overspecifying) has real downstream impacts on other parts of the organization. For instance, Marketing teams are used to using the MRDs for product features as input to their messaging campaigns. And every team in the organization misses the stage gates as a chance to come in and provide feedback about what is to be built. So the challenge becomes how to build a process that remains flexible and adaptable, doesn’t get in the way of the participants, and ensures that the right deliverable gets built and brought to market correctly.
There are some pretty good suggestions out there on how to do this, as it turns out. Googling agile and mrd gets you a variety of good discussions and ideas, including the following:
- Only write an MRD when you need to (Luke Hohmann)
- Let your prototype be your requirements doc when you can
- Demo each “sprint”’s results to everyone in the organization while sharing the prototypes for the next iteration (both from SVPG)
- Keep your requirements at one level. Don’t write high level requirements documents that are then translated into low level documents. These are a good example of Conway’s Law (Roger Cauvin)
- Use a quick 10-question checklist as a way to structure an opportunity assessment (SVPG again)
- Minimize the impact of your iterations on your users by communicating with them (SVPG once again)
I will try to expand on some of these topics in future posts.