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”.
Are you ever caught in this situation , either willingly or by someone who really believes you can get ahead by “catching up”? From my experience, this is just wrong thinking, and is far from 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. If you work in a software development organization, ask your colleagues how much inventory exists, I’m sure you will get puzzled looks and a response that we have no inventory. Any work we do that produces output (e.g. requirements documents) results in a type of inventory. Requirements are just one example. What other examples can you think of?
What is so bad about having inventory?
Uh Oh, It Is No Longer Fresh
This analogy may break down but why do grocery stores not stock their shelves with 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 which is called waste.
Going back to our requirements example, they too must remain fresh. Do you believe that requirements created 6 earlier will not have changes or are still “fresh”. Not likely and in fact, some of those requirements may no longer be relevant. The needs of the customers may have changed or the market opportunities have shifted. In either case, you’ll either have to rework those requirements or throw them out and that is waste.
Focus On The Constraints
The goal of software development is to provide something of value to the user of the software being created. Software development does create inventory – requirements documents, design documents, etc. This type of inventory does provide value, in most cases, and we must not allow the creation of them to be our goal.
Most of us operate in companies that focus on maximizing capacity. Sounds great, right? Our focus on maximizing capacity can create unwanted side effects such as too much inventory much of which will become waste. Remember, delivering value to the customer is the goal.
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 can create situations where capacity is not maximized. The goal is to increase flow through the system, reduce cycle time, to get value to the customer as soon as possible. Increasing flow will force a look at bottlenecks within your “system”, it will illuminate situations where too much inventory is being created and waste exists. Focusing on flow and reducing inventory may be a foreign concept for many software development organizations. It is certainly NOT how most companies think about software development.
Be careful about “catching up”, it can be a very expensive proposition and not one that provides value to your customer.
I’m absolutely captivated by this area of research and study. If I have sparked your interest to learn more, then I would recommend starting with the following texts:
Rick Austin is a director of Research and Development Enablement, Capability Development at Fiserv. His teams are responsible for delivering utility services, software development capabilities, innovative delivery, and capability development within business units. Rick has a passion for improving the craft of software development with a focus on the people side.