Life, Liberty, and the Pursuit of Agility

Requirements Gathering

In the traditional phased SDLC approach, a phase for  “Requirements Gathering” is done very early on in the process.  We can argue about all the issues with this some other time – I am just covering one issue here.

My opinion of this “phase” is that it is pretty much worthless: THERE IS NO WAY TO PROVE THAT THE REQUIREMENTS WE’VE GATHERED ARE COMPLETE AND CORRECT UNTIL WE HAVE WORKING CODE.  Working code, in this sense, means code that is actually being used to do real work for the real users. Does that make sense?  If not, you probably don’t want to read on, and probably shouldn’t bother reading anything I have ever written or will someday write.  Plain and simple.

Requirements Hunting and Gathering

One issue is that requirements will rot if not used promptly after collecting them.

Early humans are thought to have used a subsistence strategy where they hunted and gathered (and scavenged and stole) their food for immediate use.  If the food was not eaten shortly after it was obtained, it would rot or otherwise become useless.  The food needed to be put to work within minutes or hours, or at most a few days.  Otherwise, the effort of hunting and gathering would go to waste.

Just like the early hunter and gatherer folks, we have no way to “preserve” the requirements we’ve gathered.  We don’t even know if they are edible.  And yet we store them for a long time, and do a lot of work with them during that time, and base a lot of decisions and work on them (like estimates, budgeting, designs, architectures, ramping-up efforts, coding, testing, marketing, and so on) and all the time the requirements are rotting.

It isn’t until the code becomes true working code that we can get real information about the correctness and completeness.  Until then everything is just assumptions and guesses.  Unfortunately, by the time we learn that the requirements have indeed rotted it is too late.  They have become toxic, wasting our money, time, and effort, and killing the usefulness of the project they are supposed to define.

Early Humans understood this, and therefore rarely wrote software, and never ate mayonnaise that had not been “refrigerated after opening”.  Fortunately for Late Humans (us, that is), someone eventually figured out how to preserve foods so we could buy and eat them days, months, or years and years after they had been plucked, prepared, and packaged.   However, to this day, I have seen no way to preserve requirements.

Requirements MUST be used while fresh

So, my recommendation is: Eat your requirements as soon after you have picked them as possible.  Between the garden and the kitchen they have already started to lose their sweetness.  [Please imagine that there are many other very funny food based metaphors here.  I am not having trouble coming up with them as such, they just don’t seem all that meaningful, and they aren’t as funny as I thought they would be].

How do you do this with software?  You use a very short “discover, define, code/review/re-discover, deliver, discover more, repeat” approach during which we are continually discovering what it is we really need to do:

1. Keep your requirements at a very high and general level until just before use.  Details in the requirements are a smell of the rot.  Pay attention to that.  Understanding the business need is important, details about how that translates into software is not.
2. Pinch off a small but useful bit of one of the high level requirements – preferably something of immediate and high value to the end user, but anything of value will do.
   • Find something that you have a pretty good chance of turning into working code quickly – in a day or two if possible.
   • Prune as you go as needed.
   • Identifying small bits, pruning as you go, and getting something of value quickly are skills you must aquire.  It takes practice, dilligence, and close attention.
   • You don’t have to understand the requirement completely – you will discover the details and what is important as you code it up while partnering with the business experts/users.
   • Prioritizing is useful – you want to take on features in a prioritized manner, but don’t go overboard on this – close enough is close enough.  We’ll talk about this some day.
3. Code it up.  The code-it-up process is not just coding – we must work closely with the business people discovering the details as we go.
   • Code some tiny bit the business expert can see and use (click a button, see a list, choose an option, whatever)
   • Get her feedback, comments, and direction continuously – early on and frequently – every 10 minutes to 2 hours.  Every time you have something meaningful you can show get it in front of the business expert.
   • Sitting side-by-side works well when appropriate, but if that isn’t practical at least be within shouting distance.
   •  If you go longer than 4 hours without getting useful feedback you are wasting your time and need to learn how to work in smaller chunks.
   • You might discover you have completed some small but deliverable bit of funcitonality that is just a part of what you had chosen to work on.  If so, then deliver it, and go on to the next bit.
4. Deliver it.  That is – put the code into actual use with actual users.
   • You’ll discover more things about it as the users use it.
   • This will help expose the next thing to work on.  The real next priority.
   • If they don’t use it once delivered, you’ll have learned something else of value: It wasn’t of value. I’ll cover that some other day – but that is a magical and very valuable bit of knowledge to gain early.
5. Do it again tomorrow (or today, I suppose) with another bite-size chunk of functionality.
   • You are now steering the project toward the best possible result given the abilities and knowledge you and your team have.
   • Important things will become apparent and be added to the working code in a prioritized manner.
   • Useless things will show themselves or be ignored and you’ll waste as little time as possible on them.
   • You’ll get better and better at it.

Following this approach the requirements will not rot because you leave them “on the vine” until you are ready to eat and digest them.  Of course, what comes out after the eating and digesting is not covered in this article:  At some point all analogies break down.

[NOTE: Everything I say in this post and on this blog is based on my experiences, study, and observations.  It is MY OPINION. It is the way things seem to me.  It might be useful to you, might not – I don’t really care.  If you want to argue about it, that is fine.  I am suggesting that there are better ways to do almost everything we do in software development, and that it is worth thinking about it and doing something about it. You might already have better ways to do things, and I want to hear about it.]