In the software development world there are two main camps for the process of how software should be built: waterfall and agile (usually a form of Scrum). Agile is an iterative incremental process and waterfall is the classical sequential process. This sequential approach is full of inventory, and inventory = waste. As someone who has made software both ways I will show you why I prefer Scrum.

Waterfall

In a waterfall process the development flows sequentially downward through each phase of the model: requirement definition, design, implementation, verification, etc. Each of these steps are really a form of what I call “intellectual inventory”. The phases in the model change from company to company but this is basically what happens:

1. An inventory of requirements is created before the product can be designed
2. An inventory of design is built before engineers can code
3. Engineering produces an inventory of untested/buggy code before QA can test
4. QA builds up an inventory of defects for engineering to go back and fix
5. Maybe user experience then builds a list of usability defects to go back and fix

Keep in mind that each phase in this process will be at least one month and usually quite a bit longer than that depending on the project. That means when you get to step 5 you have two choices:

1. Don’t fix any issues and ship anyway
2. Ship very late and go back to step 2

Neither option is very good for you, your customers, or your company. There is another industry that used to produce their products this way that we should learn a lot from: the auto industry.

Lesson’s from another industry

Cars used to get produced in huge batches as it was seen as inefficient to produce a variety of cars at the same time. Large caches of parts were held in inventory every step of the way to minimize fluctuation in supply and demand. This resulted in greatly reduced flexibility. In fact the Model T famously came in any color you wanted “so long as it is black.” This was the Ford way, and Ford was seen as the epitome of success with their assembly line production.

Then Toyota came along with their Toyota Production System (TPS) in the 1950s and changed the whole game. TPS is now more generically referred to as Just-In-Time (JIT) Production. In a JIT world inventory equals waste, by definition. Consider this paragraph from Wikipedia on a TPS principal known as Heijunka (production leveling):

“To prevent fluctuations in production … it is important to try to keep fluctuation in the final assembly line to zero. Toyota’s final assembly line never assembles the same automobile model in a batch. Production is leveled by making first one model, then another model, then yet another. In production leveling, batches are made as small as possible in contrast to traditional mass production, where bigger is considered better. When the final assembly process assembles cars in small batches, then the earlier processes, such as the press operation, have to follow the same approach. Long changeover times have meant that economically it was sound to punch out as many parts as possible. In the Toyota Production System this does not apply. Die changes (changeovers) are made quickly and improved even more with practice. In the 1940s it took two to three hours, in the 1950s it dropped from one hour to 15 minutes, now it takes three minutes.“

TPS actually does the exact opposite thing to minimize fluctuations in production. Even though this minimizes fluctuations it actually improves responsiveness to customer and market demands. Most cars are available in at least a dozen colors and have so many possible options (sunroof, satellite radio, GPS, power seats, engines, transmissions, etc) that there are potentially hundreds of thousands or even millions of possible versions of a very common car such as a Toyota Camry.

Hidden benefit of Scrum

Of the many advantages to Scrum which are commonly cited the most important benefit is implied but never really articulated and that is reducing what I call “intellectual inventory”. Software development can have many forms of this type of inventory. It can be any artifact (requirement/PRD, design document, untested code, etc) that is completely created before being passed off to another functional role.

The key steps of the waterfall process are actually all forms of Intellectual Inventory: requirement definition, design, implementation, and verification. In fact the waterfall model is basically building up inventories in large batches.

Creating requirements takes a lot of “non-development” time from team members like the Product Owner/Manager, User Experience, Design, etc. The more complete the requirements are the more investment you are making. It takes development time to implement something that doesn’t get tested. Even if it does get tested but the feature is too buggy to pass QA you have still invested in something with zero return; even though your engineers were “done” with their phase of the waterfall.  Make no mistake about it, intellectual inventory is something you spend investment on.

Intellectual Inventory = Waste

In an Agile/Scrum model intellectual inventory = waste as well. Requirements that are twelve months from being implemented don’t need to be refined to the point that the feature could be implemented today. A lot can change in a year and that feature could get dropped, expanded on, or maybe it will be delivered in a different way (iPad app instead of desktop client, HTML5 instead of Flash, etc) because users and the market change. Clearly any time spent refining the requirements that are discarded would have been a complete waste. Of course in practice it isn’t possible to completely eliminate inventory, but it can be greatly reduced.

Let’s go back to that quote from Wikipedia and see what it looks like when hypothetically applied to software now (changes in bold):

“To prevent fluctuations in production it is important to try to keep fluctuation in the final assembly line to zero. Facebook’s final assembly line never assembles the same product features in a batch. Production is leveled by making first one feature, then another feature, then yet another. In Scrum, batches are made as small as possible in contrast to waterfall, where bigger is considered better. … Long changeover times have meant that economically it was sound to create out as many features as possible. In Scrum this does not apply. Requirement changes are made quickly and improved even more with practice. In the 1980s it took two to three hours, in the 1990s it dropped from one hour to 15 minutes, now it takes three minutes.”

I have personally seen feedback from our user experience (UX) team make it into a shipped product in less than a month from when they did user testing on the product that was in development. That type of responsiveness is impossible in a waterfall model because the UX would be done in a batch that would then lead to a batch of requirements, and so on. Just as in automobile production, reducing batch production of intellectual inventory allows much more responsiveness to consumer demand and reduces waste.

Waste is probably actually worse in software development than the auto industry. Even if a batch of cars is built that ends up having low demand they probably won’t be sold for less than the marginal cost to produce them, so the inventory still retains much of its value. If a requirement or design is never built because consumers don’t want it then the value of that inventory is zero. All of that investment was lost.

Just one similarity

Using JIT concepts to reduce intellectual inventory is of course just one aspect of Scrum that is similar to the principles of TPS. Here are some others:

• Self-organizing teams with daily status meetings and weekly retrospectives are just a form of Kaizen.
• Ability for any team member to bring any issue to light at any time in the development process is also a similar to the role of an Andon system.
• Using a “pull” system (as opposed to waterfall’s “push”) is basically Kanban.

So the next time you are trying to convince someone in your company of the virtues of adopting a “radical” process like Scrum point out how well these same principles worked for a plucky up-start named Toyota.

Full disclosure: I have an MBA (that’s how I learned about MBA-ish stuff like the Toyota Production System) and am a Certified Scrum Product Owner. ;)