Developing something new means resolving challenges. Some of those challenges can be planned but many are surprises. Here are some tips on how to profit from surprises.
The journey of discovery is like a walk through the fog, you can plan only as far as you see. Then, just outside your field of vision there might be new obstacles or opportunities to tackle. Many artists use these unforeseen events as “happy accidents”. Events that take you beyond current thinking and into the zone of true creation of value. There is even a word for it - serendipity.
We all want to control our destiny, one way of doing it is making detailed plans that invariably change when problems or opportunities arrive. Another, more effective, is learning to live with and take advantage of surprises. To allow for and make use of the value created by serendipity.
During development we reach the frontier of knowledge and then anything can happen. Surprises can be positive and negative and usually the time when they occur is independent of what has happened before in the project. This kind of system is memoryless and called a Markov process.
Try changing the frequency with the slider and when you press the "run again" button you will see what at Markov process looks like plotted over time:
Poisson processes are continuous-time Markov processes, and are good models of the real world. When we plot incoming tasks like TR:s, restaurant orders or ambulance arrivals, we get the clearest picture when we do it in a cumulative graph:
When you combine two independent Markov processes you get a queue between the two. The size of the queue will vary as it is the time between the next ambulance arrival and the time needed to stabilize the patient enough to leave.
The graph is a Cumulative flow diagram, and is used in Agile Software and Lean product development as well as in transportation. It shows the size of a queue over time:
All the examples we have looked at have the same capacity for service and demand. Their frequency is identical, yet we have queues.
Our intuition tells us that the best way must be to match capacity as closely as possible to demand, but we fool ourselves. Even if we feel that matching resources should remove queues, we can see from the graphs that this is not the case. A single delay in service can cause queues to build up like cars on a highway in rush hour.
The situationen becomes clearer when calculating some statistics:
Let us change the rules. Now let us look at what happens if we have different capacities for service and arrival processes.
If we have service process with a lot of excess capacity, the problems are greatly diminished: Percent queue time goes down and the service process is much better at coping with the load. Even when traffic jams occur, they are quickly cleared.
But, capacity utilization goes way down. When queueing times are low, capacity utilization is also low. We have a lot of idle resources:
It doesn't seem to be possible to have a situation where capacity is highly utilized and queueing times are low. Plugging different combinations into the simulation above almost always makes one or the other get out of hand. Of course, since the processes include randomness, we may sometimes get lucky. But relying on luck is not a viable strategy in the long term. If you flip a coin many times, the accumulated value drifts away and doesn't return to zero as often as you would expect.
Since there is an exponential relationship between queue size and capacity utilization, what if we simply choose to limit the queue size, or in other words, limit Work in Progress? What happens to queueing times and to capacity utilization?
When we combine a tight Work-in-Progress limit with a frequent arrival process, we can break the relationship between capacity utilization and queue time. We can operate at high capacity, and still serve with a short queueing time.
Of course, we do this at the expense of rejecting some of the incoming demand. When work-in-progress is at the limit, we simply drop any incoming work items. Those customers leave unserved.
Dropping demand on the floor is not the only thing you can do when you limit work-in-progress. The WIP limitation technique is a foundation for more advanced strategies:
Let us imagine that a project is made up of many tasks of varying importance, just like clients turning up at a fast-food restaurant and ordering all kind of different meals. Here are some questions to discuss: