Have you ever been in a situation where you have not gotten enough sleep for some period of time? At some point you are able to sleep normally again which does wonders for your recovery. In times of extreme exhaustion we might want to sleep more than a normal amount. We believe we can make up for our earlier deficit of sleep. As my wife is fond of saying, “you can’t catch up”.
In fact, sleeping too much in an attempt to “catch up” can exacerbate the situation. There are a number of studies that show too much sleep can lead to increased anxiety, mood swings, and continuing to feel sleepy throughout the day. What seems intuitive is not.
Similarly, the same “catch up” behavior often occurs in software development. I’ve heard more than once in my career something like this – “we have some extra bandwidth with our business analysts so we’re going to “catch up” on requirements. We can get enough done so that we will be 6 – 8 months ahead of development”.
I hope most of you agree that this is wrong thinking. Do you agree that this is not an optimum approach? Why do we fool ourselves in behaving this way?
What’s The Big Deal
Software development has inventory just like any other organization that produces something from raw materials. It is very difficult to see that inventory. Just ask your company how much inventory do they have and I’m sure you will get a questioning look or a statement that there is no inventory in software development. Any work we do that produces output (e.g. requirements documents) results in inventory. Requirements are just one example. What other examples can you think of?
Why is this inventory bad?
Uh Oh, It Is No Longer Fresh
This analogy may break down but why do grocery stores not stock their shelves will months of inventory, say bread or vegetables? Those products must remain fresh to provide value to the customer. If they are no longer fresh then they must be thrown out and that is waste.
Continuing with the requirements example, they too must remain fresh. Do you believe that requirements created 6 months before they are acted upon have not changed and are still “fresh”. Not likely and in fact, some of those requirements may no longer be relevant. You’ll either have to rework them or throw them out and that is waste.
Focus On The Constraints
Software development creates a variety of output needed to build functionality delivered to the customer. The process of software development creates inventory which has a real cost. We operate under a model that seeks to keep all resources at maximum capacity. We believe creating something is the higher order goal and we don’t recognized the potential waste.
The Theory of Constraints would show us that our focus should be on eliminating bottlenecks in our development system. This is a very different view from what I’ve described and it implies situations may exist where we do not maximize output in all stages. This is NOT how most companies operate and that focus on maximizing resources unwittingly causes dramatic increases in unseen costs.
Be careful about “catching up”, it can be a very expensive proposition and not one that provides value to your customer in the most efficient manner.
I’m absolutely captivated by this area of study and have more to say. If you would like to learn more then I would recommend the following texts:
- The Goal: A Process of Ongoing Improvement
- The Future of Management
- Agile Management for Software Engineering