Book Review Part 5: The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen

In a previous blog article, I mentioned how I was getting back to my programming roots and reading The Principles of Product Development FLOW: Second Generation Lean Product Development by Donald G. Reinertsen. I am in the process of reviewing each chapter. I have already posted my reviews of:

• Chapter 1. "The Principles of Flow"
• Chapter 2. "The Economic View"
• Chapter 3. "Managing Queues"
• Chapter 4. "Exploiting Variability"

Here is my review of Chapter 5, "Reducing Batch Size." As its name suggests, and as it applies to Autodesk, this chapter is about reducing the amount of work that is combined into a software release. To me, this is the fundamental difference between the old waterfall model and the current model of agile development. There are people who claim agile is dead, but I don't yet believe it. The chapter opens up by making the case for reducing batch size by showing that doing so reduces cycle time, reduces risk and uncertainty, reduces overhead and increases efficiency, and accelerates feedback.

Accelerating feedback is the payoff. Let's talk about Autodesk release cycles.

• What seems like ages ago, some years Autodesk would have a release of AutoCAD, and other years would not. New customers would pay for a full release of AutoCAD. Customers who had already bought a copy of AutoCAD would only pay for the upgrade. Not knowing if there was going to be a release or not, existing customers would ask "Are you going to have a release? I need to know so I can do my budgeting for upgrades for the year." Our solution was to develop the maintenance subscription. We took the upgrade price, divided it by 3, and asked customers to pay one-third, one-third, and one-third for 3 years. During that 3 years, they were entitled to any updates that were released during the period where the maintenance subscription was active.

• Though this solved the budgeting needs for customers, this put the pressure on the company. Autodesk wanted to ensure that customers received value for their subscription dollars, so we made sure to have a new release every year. And thus, the annual release cycle was born. We avoid changing the DWG format every year to reduce churn in the industry, but for the last decade or so, we've come out with a new release of AutoCAD every year.

• A one-year release cycle does not lend itself to accelerated feedback. That's where our beta program comes in. Historically our beta program has launched for new releases of our software, like AutoCAD, Inventor, Revit, Maya, and 3ds Max, a few months before the new releases ship. Users provide the thumbs up or thumbs down regarding whether or not these products are ready to release. For new ideas, we have the Autodesk Labs process for getting feedback on whether or not something is a good idea. It's been this way for about a decade.

• Relatively recently, like the last two years or so, in the interest of accelerating feedback, Autodesk has moved to what is termed "rolling betas" for some products (e.g., AutoCAD, AutoCAD Civil 3D, Inventor, Revit, 3DS Max, Simulation, InfraWorks, Vault, Alias, VRED). Rather than initiate the beta process way down the road after development is mostly done, it starts right at the onset of the release. Customers can get their hands on one of the nightly builds and provide feedback right away. And that is the definition of being agile. We have reduced the batch size of what beta testers provide feedback on so that the development teams, customers involved, and the product itself all benefit.

My favorite part of the chapter was how the author pointed out that when most organizations want to improve their results, they first look to remove bottlenecks. Though this may be a worthy objective, a better approach is to actually reduce batch size. The book made this important point with a simple example.

• A company has a company-subsidized lunch cafeteria. The company subsidizes the cost of the lunch to make it attractive for employees to eat in the company cafeteria. Everyone likes a bargain. It's a win-win. The employees get lower-cost lunches, and the company benefits because employees wind up taking shorter lunch breaks. They skip the step of deciding where to go to lunch, traveling there, and traveling back. Everybody wins.

• Now let's say the company cafeteria has long lines. Though the employees are getting the benefit of lower-cost launches, the extra time spent waiting is negating the benefit of getting employees back to work quicker.

• The immediate reaction would be to look for the bottleneck. Is it the food service line? Is it the line to pay? Is it trying to find a spot to sit? Should we hire more servers? Should we hire another cashier? Should we expand the cafeteria space to include more tables?

• There is an easier alternative to all of those bottleneck-seeking-and-eliminating remedies. Reduce batch size. Simply stagger the lunch period for employees to avoid overloading the cafeteria. Send half of the employees to lunch at 11:30 am and the other half at 12:00 pm.

It is our intention to deliver features for some of our software and services in smaller batches to provide better service, much like avoiding the wait in a long cafeteria line. Those who participate in some of our beta programs are experiencing this now.

Getting small is alive in the lab.