Fat Companies and Lean Requirements
Jeff Gothelf, an interaction designer and proponent of agile methodologies, wrote a great piece titled “A Better Project Model than the ‘Waterfall'" for the Harvard Business Review blog network. The article is good because the ideas are spot-on. What makes it great is that the language will resonate with folks trapped in large-company, waterfall bureaucracies who want to get some of that “agile mojo” but don’t see how to change their organizations. The title references process, but the best part of the article is about writing good requirements.
Gothelf focuses on one of the key ideas of the lean movement—form and then validate hypotheses. If you are involved in discovering or authoring requirements and haven’t already read The Lean Startup by Eric Ries, you should. You will start writing better requirements, and your teams will start building better products—even if you’re not a startup and you're not using lean or even agile methodologies.
The key aspect of hypothesis-driven development is to explicitly acknowledge a few key ideas:
- Requirements start with an assumption of why doing something will be valuable.
- Well-reasoned requirements identify a quantifiable aspect of the assumption—a definition of “good enough” that clarifies the definition of success.
- Well-written requirements include a measurable aspect of what needs to be accomplished in order to realize—based on the hypothesis—this quantified measure of success.
Gothelf touches on one of the key behavioral perspective shifts that happens on a team when you write requirements in this fashion:
Instead of presenting their teams with lists of features to build in a sequence, organizations should present their teams with business problems to solve. Provide constraints for the solution and any assumptions that currently exist about that business problem and its target audience.
Most importantly, each team should be handed specific success criteria. These criteria should be quantifiable and point to specific outcomes that prove the customer's need has been met and the business problem has been solved.
The value of taking this approach to writing requirements is completely realizable for both agile and waterfall teams. Yes, it is one of the by-products of the agile movement. Yes, it is “baked in” for teams that are operating effectively with an agile development process (or at least a lean process).
And yes, you can start doing this today—even if your team is using a waterfall process—and start realizing the benefits as soon as you deliver something measurable against a requirement that has identified the measure of success.
