Ignore requirements to gain flexibility, value, insights! The power of why
I would like to share an eye-opening experience I have recently made. I have learned that if we do not just passively accept the requirements given to us but carefuly analyse the reasons behind them (and the reasons behind the reasons), we gain incredible power and flexibility. By understanding the real value behind it and by discovering other, related sources of value, we might find a superior solution and, more importantly, we gain a few degrees of freedom in the solution space, the ability to scope up or down the solution and optimize it with respect to other solutions. Let's see how a seemingly fixed requirement can be easily expanded or shrinked once we bother to trully understand it.
The requirement to
could be taken as is and we could run crazy adding proper labels, navigation helpers and whatnot. But what if we stop and ask the simple question why?
Now this triggers a few thoughts:
Voilà! We have found out that we actually don't "have to" fulfill the requirement and discovered few more ways to increase our profit.
We have thus gained the freedom of decision: We may implement less than the law requires, paying a fine, in exchange for another gain. Or we can do more than presribed, using it as a positioning and marketing tool. Or we can do exactly as asked - but it is us who decides, based on all the other factors and constraints at any given moment. This freedom and flexibility is what enables projects to succeed (i.e. deliver business value exceeding the costs) in the face of constantly changing conditions.
Understanding the true value behind requirements gives us a great flexibility in how to attain the value and provides a foundation for rational trade-offs between various values and constraints. It can also lead us to alternative courses of action and other, more important gains. Net result: more insight, more flexibility, more business value created.
Don't get me wrong - I am not suggesting that you should ignore your stakeholders. Just the opposite, I am asking you to leverage the maximum of their knowledge and to truly respect them by caring to discover they actual needs. But regarding requirements, we should be cautious - as Mary Poppendieck said:
Inspired? Read the great book(let) Impact Mapping (sample) and, if you live in Oslo or London, attend the next (free) Real Software Architecture course organized by Tom and Kai Gilbs (schedule).
I would like to thank Gojko Adzic, Tom Gilb, and Elena Abilova for inspiration and help. The credit for applying 5 whys to requirements belongs to Tom Gilb. This experience originated at Tom and Kai's course while me and Elena worked on an exercise.
The requirement to
Be fully compliant with the accessibility law and its requirements on usability w.r.t. physically impaired users.
could be taken as is and we could run crazy adding proper labels, navigation helpers and whatnot. But what if we stop and ask the simple question why?
- Be fully compliant with the accessibility law
- Why? So that we won't pay a fine.
- Why? Because we don't want our profits decreased.
Now this triggers a few thoughts:
- Couldn't we increase our profit more if we used the development resources needed for the compliance on something else? (Where gain > fine.) What is the actual cost of not fullfilling the law (at least for some time)?
- Or maybe we could actually do more than the law requires. We would thus perhaps attract more of impaired customers (gain 1) and we could even gain a positive social reputation and our customers might be thus willing to pay slightly more knowing that they are helping a good cause (gain 2) and it could help distinguish us from our competitors and help our marketing (gain 3).
Voilà! We have found out that we actually don't "have to" fulfill the requirement and discovered few more ways to increase our profit.
We have thus gained the freedom of decision: We may implement less than the law requires, paying a fine, in exchange for another gain. Or we can do more than presribed, using it as a positioning and marketing tool. Or we can do exactly as asked - but it is us who decides, based on all the other factors and constraints at any given moment. This freedom and flexibility is what enables projects to succeed (i.e. deliver business value exceeding the costs) in the face of constantly changing conditions.
Conclusion
Understanding the true value behind requirements gives us a great flexibility in how to attain the value and provides a foundation for rational trade-offs between various values and constraints. It can also lead us to alternative courses of action and other, more important gains. Net result: more insight, more flexibility, more business value created.
Don't get me wrong - I am not suggesting that you should ignore your stakeholders. Just the opposite, I am asking you to leverage the maximum of their knowledge and to truly respect them by caring to discover they actual needs. But regarding requirements, we should be cautious - as Mary Poppendieck said:
All too often, detailed requirements lists and backlogs of stories are actually bad system design done by amateurs.
Inspired? Read the great book(let) Impact Mapping (sample) and, if you live in Oslo or London, attend the next (free) Real Software Architecture course organized by Tom and Kai Gilbs (schedule).
I would like to thank Gojko Adzic, Tom Gilb, and Elena Abilova for inspiration and help. The credit for applying 5 whys to requirements belongs to Tom Gilb. This experience originated at Tom and Kai's course while me and Elena worked on an exercise.
You might enjoy also other posts on effective development.