Manufacturing is about consistent output.
Steady manufacturing is about consistent output at regular intervals. The Ford Motor Company is the classic case study for an assembly line process and mass production. Think about the big idea for what Henry Ford accomplished. The assembly line reduced the labor hours required to produce a vehicle and increased the number of vehicles that could be produced in a given time period. The assembly line started a consistent output of units. It was incremental output, one car at a time.
The analysis of manufacturing involves incremental costs and margins.
If you studied business or economics in school you’ll remember that the marginal cost of a product is the change in total cost when one more unit is produced (incremental unit). The contribution margin is the profit when one more unit of a product is sold. The contribution margin is used with break-even analysis to determine the point at which costs are equal to revenue. In the world of manufacturing, which may deal with thousands to millions of units, the break-analysis is an essential equation. It’s an analysis that gets down to single incremental units.
Why I like incremental programming.
I like the concept of agile software development because it focuses on incremental improvements to software. Agile focuses on delivering one feature at a time, rather than looking at software as a project with a variable number of features. That sounds like a manufacturing machine or an assembly line. Agile programming aims to create a steady flow of output instead of an output flow determined by project scope (variable).
What are some advantages of an incremental approach?
- More predictable delivery dates. Smaller scope makes delivery of releases easier to control and predict. There are less moving parts. What’s ready to be delivered is released and what is not ready waits until the next delivery date.
- Easier to manage scope. Bloated projects can have huge scope lists and are often difficult to manage. It takes more paper work, longer meetings, and more coordination of changing items.
- Reduced risk. With large project scopes the team is “all in”. Then scope is managed by a “change control” process which takes paperwork and meetings. With incremental features the team is only at risk of missing that single feature rather than putting a group of features (in a project) at risk if there are delays.
- Flexible decision making. With smaller work units and quicker delivery dates, business leaders can make decisions and shift direction as business needs dictate. If you are half way through a large project and have to abandon it because of shifting business priorities then none of the items in that project are delivered to stakeholders. All of the effort spent is wasted.
So why is it so hard to get out of the big project mentality?
Habits. Training. Finance rules for capitalizing labor. Budgets. Tradition. “Best practices”. The reasons go on-and-on. If we think about our software delivery process like an assembly line then why would we accept periods of inactivity where the machine spits out nothing? If manufacturing had periods where the machines didn’t produce output they would get shutdown. I don’t think the break even analysis would be favorable.
Simple is as simple does. Think and act incrementally.