Imagine what would’ve happened to the Ford Motor Company if Henry Ford focused on building the best planning organization in the world. Or if he’d decided to offer a broad range of features and options in his cars? Imagine how great the Ford Motor Company might have been!
Henry Ford focused on adapting production techniques from the meatpacking industry to auto manufacturing. The result was the birth of the mass production line.
He also focused on 1 car, 1 color (Model T). The result was a simple product that could be understood and executed with known needed features.
The decisions to make production predictable and make the product simple was the bedrock of Ford’s success. It also changed the manufacturing world. His innovations are the cornerstone* of how “unicorns” produce software (Amazon, Netflix, Facebook, etc). There are some Enterprise sized companies moving in this direction.
Many Enterprises remain in the Best Laid Plans model where planning is the approach to manage and solve for production issues.
Let’s look at the world of building software in an Enterprise.
Best Laid Plan delivery model
We plan the “best” possible product with a wide range of features. The wide range of features create lots of dependencies. The dependencies span multiple teams and disciplines. The disciplines are often organized in silos to create scale, and concentrate and deepen subject matter expertise. The silos produce solutions that are designed and implemented independently from one another. After everything is built, the various teams work to get their systems to work together. It doesn’t usually integrate as planned. The Teams go off to their own corners to repair defects. They come back again and test. The pattern repeats until enough defects are resolved.
The complexity of the product feature set, the organizational mapping of the teams needed to produce the features and the implementation of the features creates execution issues (time and money). Choices must be made between sub-optimal shortcuts and cuts in scope. The planners don’t see the cost of the shortcuts (Tech Debt). They see the cuts in scope. Shortcuts are chosen. The shortcuts increase complexity and lower quality of the product. The product integration gets harder to acheive. Eventually, scope is reduced in order to deliver. Or the project is cancelled as a failure.
Conclusion/Problem: It’s all ITs fault! They can’t ever execute the plan!
Chosen Solution to the Problem: Better planning next time
This has been the story playing out over and over for half of a century. Mr. Ford identified the solution 50 years before that
- Limit product features
- Mechanize the methods to produce the product
Enterprise IT is slow to take up the manufacture’s lessons learned.
It makes sense that the Best Laid Plans delivery model (BLPDM) approach is resistant to change. Executives are where they are because of their success executing things … getting things done. Their success has occurred over the course of the last 15-30 years.
Many executives are formed in the Project Management mold. They hold high a belief that a better plan is the path to a better outcome.
Other executives came up from a technical background where their technical experiences were derived over a decade ago. They came up in an era when hardware was expensive and automated solutions to manage and deploy infrastructure and software wasn’t prevalent. Today, we live in a world where everything can be virtual and automated with accurate repeatability.
Executives believe in a better plan. They think of computing environments as fixed metal that isn’t a adaptable. “If we could just estimate better and control the computing environments, better plans would work.”
The things that have gotten these folks promoted is their ability to get things done despite the complexity and uncertainty. Rigidity, structure and perseverance has been has propelled many leaders to the executive ranks.
We plan big scope projects because building and shipping a product has taken a long time and required significant effort. BLPDM operates by the “blivet principle”- Cram 10 lbs of Features into a 5 lb bag. This results in an impossibility that looks possible/plausible at certain angles but is really recipe for features hitting the fan.
Human cognitive bias to diminish the pain felt after the victory is won is critical to our very survival (e.g.- childbirth and families with more than 1 child). This affects our organizations ability to adapt to the new mechanistic delivery models.
We choose the harder but familiar planning approaches by relying on muscle memory and distorting cognitive bias. Instead of investing in a solution to improve outcomes, we keep doing what we’ve always done and getting what we’ve always gotten.
There is a better way.
Mechanistic Delivery Model
Mechanistic Delivery Model (MDM) focuses on investing in building the production plant and defining the process by which software is produced. This is a tough sell. This is the inverse of the choice given during the BLPDM example before — shortcuts that will be unseen vs. scope cuts that will be seen: Investments that will build things unseen and smaller scope to begin with.
Our planning and structure is what got us our wins (WE did it). We use this to deal with the hard stuff. And the lack of experiential knowledge with non-traditional IT practices creates sense of risk and uncertainty when talk about building a Mechanistic Delivery Model. It sounds like magic (Think a combination of Clarke’s first and third laws). Magic isn’t credible. Therefore we’re not willing to invest in it.
Imagine if Henry Ford focused on planning the “best” car with a wide range of choices and features and didn’t innovate a mechanistic, repeatable way to produce vehicles. There’s a good chance Ford would have gone out of business. **
A production system that does not produce mechanistically reliable and consistent results cannot be fully planned for. You can build in probabilities to account for the system’s variation. You cannot effectively plan in a way that is manageable when the system of production is not manageable.
Businesses and their Technology/IT Teams that build planning teams to compensate for unpredictable IT delivery systems are on a fool’s errand. No decent manufacturing business would try to plan its way out of a weak production line. They would fix the production line to be predictable and reliable. This would allow planners to focus their efforts on value creation and priority instead of wasting their time solving for problems outside of their control.
Planning is an art. Production is a science. The DevOps Revolution is about using the science of the probably to enable the art of the possible.
Mechanistic Delivery Model allows planners and developers to imagine and take chances with small bets. It allows them to work scientifically. Defining hypotheses, testing them. Learning and adapting.
Turned into a habit, we come to trust the mechanism to produce predictably and reliably. We shift from the “blivet principle” to the scientific method. We build trust in people and process. We enable the Enterprise do what their customers really want: Make magic.
* It’s understood Toyota Production System (TPS) and Lean derivatives are where the halo floats for DevOps / Pipeline delivery models. TPS was predicated upon Ford’s mass production model.
**Ironically, Ford’s commitment to constrained set of choices for his customers became a weakness when GM chose to offer choice. One of the toughest choices a company or product manager has to make is whether to change the past to adapt to the present. Philosophically, it’s useful to commit to as simplicity before choosing to optimize. It’s more important to test whether a product or feature is needed than it is to make the best feature possible. Any effort spend optimizing is waste, if the feature isn’t wanted or needed by the people who use the product. The topic of innovating and optimizing isn’t for this post except to say that it should wait until the most basic version of the product possible can be proven as being valuable and needed/wanted. Here’s a Harvard Business Review blog post from Patrick Vlaskovits on this. I found the HBR piece after writing this post.
