You have to feed a lion to know how hungry it is

I am reading a book (Competitive Engineering by Tom Gilb) which has a lot of information on requirements as well as systems engineering. Although the book itself is a bit of a Tome (read as difficult to get through in spots as it pontificates on things I (and most of the world) don't care about) it has some bits that are wonderfully insightful and keep me reading. I thought I would share a few of what I thought were fun quotes and then expand on them a little.

You must feed a lion to know how hungry it is. In the software world this can be stated as unknowable complexity, often described with the phrase "we don't know what we don't know". In essence what this is saying is that you can't have perfect knowledge up front about exactly what requirements are going to be needed and how exactly things should work. In Agile we address this by defining the set of stories then prioritizing and delivering early and often. Do the valuable things first. Many projects get their funding cut due to one thing or another. Projects that are delivering value, regularly not only fight the complexity problem by addressing things in bits and hitting the "goodies" first but also pay as they go allowing business to see value along the way thus reducing their chance of a cut. This statement also applies to the use of Spike solutions. If you don't understand something well enough to give an estimate... don't. Do a spike solution, learn about the problem, reduce the risk and make an estimate with more knowledge.

Even gourmet decays. Another way that I have described this is with the statement regarding requirements that "it's not that I lied, it's merely that the facts have changed since last I told the truth." Requirements change. Any requirement, as soon as it is completed begins to become less and less valid as the business environment and the world the requirement was created for changes. Again, in Agile we address this by delivering value early and often and only going into the nth degree of depth when it is needed. By working with customers on the most valuable items in the backlog for each iteration we are able to keep our requirements as fresh as possible, work on the "right things" and able to more quickly adapt by picking and choosing the stories that have the most value to us at that time. Recent research has shown that only 20% of the functionality in software systems gets used often or always... lets focus on getting that part done first.

Stop the world, I want to get off. We could no sooner say that we are tired of the world spinning and stop it than we could freeze all requirements up front and hope to deliver something that will truly make our customers happy. In Agile this is again dealt with by working on the most important stories first and prioritizing and selecting the new "most important" stories at the beginning of each iteration. By attempting to freeze all of our requirements and not updating them we would cause far more problems (not to mention churn or analysis paralysis) than if we just updated our requirements.