What Software Teams Can Learn From Honda Super Cub Accidental Success

In his book titled How Will You Measure Your Life, Clayton Christensen applies his thinking about business strategy and innovation to life, relationships, and personal success. He shares a definition of strategy which caught my attention:

“At a basic level, strategy is what you want to achieve and how you will get there. In the business world, this is the result of multiple influences: What a company’s priorities are, how a company responds to opportunities and threats along the way, and how a company allocates its precious resources.”

How Business Strategy Relates to Software

This could also be used as the definition of Scrum, which is the official name of our approach to managing software projects. Christensen’s definition eloquently illustrates exactly why we enthusiastically adopted Scrum: Because it infuses strategy into the software development process continuously and deliberately.

Just a quick primer on Scrum for those unfamiliar with it: Scrum describes a process of collaboration between clients and developers as they chart a course through a software development project. The question of “what to build?” is discussed and agreed to on a set recurring schedule, typically every 1-4 weeks. This unit of time is called a “sprint” and the most common duration of a sprint is 2 weeks. Scrum is built on rituals that close the gap between strategy and implementation in small iterative chunks keeping the team nimble and responsive to unanticipated opportunities and/or threats.

Christensen’s definition of strategy broken down:

#1: Priorities – In the Scrum process, the developer’s job is always to work on requirements in order of priority. Before each sprint begins, clients sort requirements based on business value and developer effort. It’s not unusual that the estimated effort required to build a certain feature factors heavily into the prioritization decision, which is why estimating is often done before prioritization. Once a sprint is set, it becomes a contract between the client and the team. This gives the client control over the team’s focus before work begins and protects the team’s focus after they have started.

#2: Responding to opportunities and threats along the way – In the book, Christensen tells the story of how Honda entered the American market with a plan to sell big motorcycles competing with Harley-Davidson. While the original plan failed, the Super Cub took off completely by accident and became the emergent strategy that secured Honda’s future in the US.The story goes like this: Back in the 1960’s, Honda designed a large motorcycle similar to the Harleys that were popular among Americans at that time. The plan was to underprice the competition and establish a presence in the US market. Unfortunately for Honda, their big bikes were judged as poor-man knockoffs and mechanical problems almost crippled the project. Harley, it turned out, was harder to beat than they had assumed.

Honda had also sent over a few Super Cubs, small moped-like city bikes intended for employees to run errands. A buyer from Sears saw the Super Cub when he noticed Honda employees driving around the hills of Los Angeles going on and off road. Others had admired the small bikes which they called “dirt bikes” but were turned away and told they were not available for sale.

Honda, reluctant to abandon their original big-bike strategy, slowly started selling a few Super Cubs. They just couldn’t believe that small bikes would appeal to Americans. However, upon realizing that the Super Cub was the only thing keeping Honda USA alive, they finally relented and began fulfilling orders. The Super Cub took off and today is recognized as the most produced motor vehicle in history.

This story illustrates an important truth that lies at the heart of every web project: The discipline of and freedom to adopt an emergent strategy in response to unanticipated opportunities and threats can make the difference between success and failure. By using the Scrum method, we create pivot opportunities between each sprint allowing us to discuss and evaluate emerging strategies before developers lock in on the next sprint.

Christensen offers a suggestion for deciding between deliberate and emergent strategies: “Discovery-driven planning.” He encourages readers to iteratively build and then question strategy by asking one key question: “What has to prove true for this to work?” From guessing visitor intent to assuming the availability of data to perform an important function, web developers are forced to make assumptions in the planning stages of every web project and this simple question can help them to identify the dependencies that could either derail or enable the strategy before work begins.

#3: Allocating resources – Without proper execution, even a bulletproof plan is destined for failure. In web application development, as in all pursuits, distraction and indecision are the biggest enemies to execution and that’s why we assign a team member with the crucial role of the ScrumMaster.The ScrumMaster serves as the interface for clients and protects developers from interruptions so that they can concentrate on the current sprint. Once developers begin a sprint, Scrum rules dictate that changes and requests beyond the scope of the sprint are to be queued into a backlog for later consideration. These items are then evaluated and prioritized during the next sprint planning session, thus protecting the team in favor of execution and focus.

---

In the end of his definition, Christensen writes “These things all continuously combine to create and evolve a strategy.” All too often web projects start with an RFP that describes the strategy in so much detail that it leaves no room for evolution. This forces developers to propose and price a solution that rigidly adheres to the RFP and enter into a contract that forces change orders and contract negotiation into every pivot.

While there are many problems with this approach, perhaps the most costly is that it prevents businesses investing in technology from changing course. Despite the best of intentions, clients become contractually locked into their initial strategy, slowing down their awareness of, or ability to adopt a better emergent strategy. As a result, we read about countless failed software projects forced into an impossible execution framework.