In a van down by the waterfall

The Goal made me realize some striking similarities between the software development process and regular manufacturing processes in other industries. As some of the readers of this post might quickly recognize and argue to the death, software development isn’t the same thing as tooling a factory to make the same part over and over, even though the bean counters of the world probably wish otherwise. However, there are some undeniable parallels between the software process and a typical manufacturing process.

For instance, those familiar with the waterfall process immediately notice the serialized process represented by the step downs from one discipline to the next, which is very similar to an assembly line building cars. Granted, in the software world, the car would be completely re-engineered each time with a special mosaic painted on the hood, resembling a van with a lift kit; however, the general process for building new software is similar each time. Even when using an Agile process (i.e. not waterfall), there are certain steps that are required before other actions can take place, but with Agile, the length between concept and completion is decreased by iterating through the ideas one at a time.

In many cases, dependent events are created because various individuals on a team are specialized in doing certain kinds of tasks such as documenting, coding, testing, etc. If any one of these functional areas gets too far ahead, a bottleneck is created in one of the other areas; however, this notion of a dependent event is often ignored in the software world until it’s too late to adjust the schedule. The advantage of an Agile process over a more traditional approach is that the planning is limited to a shorter period of time, which prevents one functional area from getting too far out of sync before continuing, but even within an iteration, resources can get out of sync without strong discipline.

Is there a solution or something to be learned from this knowledge of dependent events? Sure, an Agile process is great and wonderful, but it also points to a couple areas of improvement in removing bottlenecks, even within an existing Agile team. First, recognize that dependent events will occur on a team and plan for them. Coding like crazy while the testing lags is like using a Ferrari (or a van as the case may be) to drive around on a mud track. The wheels may be spinning, but the overalla progress isn’t any faster. Second, be creative and think outside of traditional software norms for solutions. In other words, specialization may need to take a backseat to help the bottlenecked areas. As opposed to most planning sessions, focus should first be on the bottlenecks rather than where the resources are abundant. Look for follow-up posts to elaborate on this in more detail.