Requirements Paste (Photo credit: C_Knaus)
In his book Agile Management for Software Engineering, David Anderson draws a parallel between software production and manufacturing production.
In manufacturing, you start with raw inventory (say, steel) that has a certain cost. This inventory then goes through the chain of operations necessary to transform it into some product that has more value (throughput).
In software development, ideas/requirements/feature requests are the inventory. They are the raw materials that get transformed into something that has more value. This seems reasonably straightforward but, if accurate, it has some pretty big ramifications for businesses and how they handle their requirements.
This inventory is expensive.
When a manufacturing plant buys steel, this has a cost associated with it. If a plant wants to be profitable and generate a good ROI, they buy enough inventory to keep production flowing but no more. It’s a waste of money to buy raw materials you can’t put to use, and there are all kinds of associated costs with holding on to lots of inventory, such as storage, etc.
As I have noted earlier, requirements aren’t free. It costs money to generate them. It costs money for executives to have meetings to come up with ideas. It costs money to get those ideas into a format where they could be made into a product. It costs money to record them. It costs money to update them. In larger organizations, there may even be business analysts who also factor into that cost.
The fact is, it actually costs a great deal of money to generate and maintain requirements. Why most organizations don’t take this cost seriously, I’ll never know.
The inventory can only be processed at a given rate of speed.
If a manufacturing plant can only process 10 tons of a steel a week, it’s a huge waste of money to buy 50,000 tons of steel at a time. Not only am I spending a huge amount of money for that inventory, but I have to store it. Furthermore, there is no way all that steel will become a valuable product nearly fast enough to recoup my investment.
What I want to do, instead, is buy enough steel to match our capacity and a little bit more as a buffer so that my plant doesn’t go idle waiting for more steel. The ideal amount of steel to have on hand is the amount my plant can be making into valuable product at any given time.
Requirements are the same way. There is no reason to put together a hundred page requirements document and give that to the developers. It’ll take months and months to produce all those requirements. What I want to do is procure enough requirements to keep everyone busy and with a buffer so no one goes idle. Why spend all the money nailing down Requirement #197 when Requirement #197 won’t be built until a year from now, if at all?
This inventory degrades in value over time.
Steel isn’t a great analogy for requirements because steel lasts a long time and is just as good ten years from now as it is, today. You have to store it, but it doesn’t seriously degrade over time.
For software, the requirements do degrade over time. Business rules change. Markets change. Strategies and initiatives change. Priorities change. Regulations change. Technology changes. This quarter’s Super Important Project is next quarter’s back burner.
Therefore, as soon as a requirement comes into being, it’s a race against time to turn that into a valuable product, because the value of that requirement and the value of what you produce with it starts to drop almost immediately until, eventually, it’s not even worth turning the requirement into a product. It’s too stale and no longer reflects the business and market realities that drove it in the first place.
Maybe a better analogy for requirements as inventory would be like milk for an ice cream production plant. It’s just going to go bad over time. It needs to become ice cream in a hurry, because it’s not going to be a viable substance forever.
This fact alone speaks to the destructiveness of a traditional Waterfall model of building software or doing projects. The more time that goes between getting a requirement into throughput, the more value is lost. If you spend all that time getting all the requirements, doing design, etc., building all at once, then releasing all at once, the odds are very good many of your requirements have much less value or no value at all. ROI goes through the floor.
Don’t have too much inventory at any given time.
All of this seems to tell us that, if you want to waste the least amount of money and generate the highest value in your throughput, the best strategy looks something like this:
- Only high-value features should be requested. If a feature isn’t worth $1000, don’t spend $1000 talking about it and documenting it.
- Only generate enough requirements to keep the developers busy with a small buffer so they don’t have to wait for more things to do.
- Get a requirement into releasable value as quickly as possible. Don’t wait for the other requirements to be done.