Warning: reading this article may result in a substantial craving for doughnuts!
I can’t think of many things better than taking a bite of a hot, fresh Krispy Kreme doughnut! The corners of your mouth can’t help but curl to a smile as the first bite melts in your mouth. You’ve polished off the first one and are well into the second before you realize that you’re going to have to run an extra couple of miles today to make up for this!
The Analogy
So, what can we learn about software development from a batch of delicious Krispy Kremes? Let’s shift from thinking about how good the doughnuts taste to looking at how they are made.
Step 1: The Mixing. The process begins as the dry ingredients are mixed with the liquids to make the dough according to their secret recipe. At this point, significant cost has been expended to put all of the ingredients together; and the ingredients, now mixed, have a shortened shelf life and need to be pushed through the process quickly. But what if the dough wasn’t mixed correctly? The team needs to quickly identify the problem and pull the batch as early as possible. Otherwise, each step in the process will continue to add time and cost, but will result in a bad final product.
Do you see where the analogy with software development is headed? This stage is akin to the your business product development team investing time into a new product idea or enhancement. Once the idea is in place, tech teams need to act on it quickly – either to get it implemented or to help them determine that it is a “bad batch of dough.”
Step 2: The Rising. As you walk into a Krispy Kreme, you see one of their famous machines – including the “elevator” section where trays full of doughnuts spend about an hour traveling up and down as the dough is “proofed” to perfection. This part of the process doesn’t add much cost. It simply takes time for the dough to rise.
Similar to software requirements gathering, this stage isn’t too costly, it takes time. It also gives us an opportunity to look at the individual doughnuts (or software requirements), see which are misshapen or not rising, and pull out the bad ones before they go the next stage.
Step 3: The Shortening. On the next step of their journey, the doughnuts are dropped from the elevator tray into the hot shortening where they cook. The doughnuts slowly float forward until, halfway through the river of shortening, they are flipped so that the other side will cook. If you watch the process for long, you will notice that every once in a while a doughnut doesn’t get flipped over and only one side is cooked.
What you may not realize is that the moment they hit the shortening, the cost of the doughnut goes up substantially – they absorb some of the expensive shortening as they cook. In software development, it is much easier and less expensive to make changes on paper or in a prototype than it is to make changes once coding has been started. It is important for our tech teams to quickly identify the doughnuts that aren’t cooking properly.
Step 4: The Glazing. This step is my favorite part. The doughnuts are lifted from the shortening and continue down a conveyor system and go through a waterfall of glaze. The sugary, sweetness coats them as they continue on down the production line as the glaze cools and dries.
The glaze is another expensive part of the process. It doesn’t make sense to glaze a doughnut that wasn’t properly cooked or is misshaped. Again, these need to be identified and addressed early…before more time and cost is wasted on them.
Step 5: The Boxing. This is the final check point before the finished product hits the shelves. At this point, all of the cost for making the doughnuts has been incurred. This is simply the final check before the doughnut is sold to the customer.
Too often, we rely on the “boxing” process (Software QA) to identify the issues. Instead, we need to create an environment where the entire tech team takes ownership of identifying issues…and prides itself in identifying and resolving these issues as early in the process as possible!
The Krispy Kreme Principle
One of my customers had 1,674 items that had been partially developed then set aside to be addressed later. Unfortunately, this wasn’t because they were applying the Krispy Kreme Principle. Instead, it was because they didn’t realize how much cost had gone into requirements, development and testing before they realized that the product was bad.
The Krispy Kreme Principle is about defining and understanding your critical cost points. Similar to the shortening and glaze stages, each organization has specific points at which the cost goes up substantially. Identify where these points fall in your process. Then build in checkpoints before these critical cost points and focus your teams are identifying and addressing the issues.
Use the Krispy Kreme principle to stop wasting money and time!
