Failing Fast for the Rest of Us

Fail fast entered the business lexicon from the high-tech sector. It has become a powerful buzzword and has ignited a small movement. FailCon offers a series of global conferences for entrepreneurs to study their failures “to prepare for success.”

Failure is not the goal. Failure abounds. More than 90% of start-ups fail to meet their financial goals. On average, 30% of software projects are canceled and another 50% fail to meet expectations.

“Fail fast to succeed sooner”—David Kelley, Founder of IDEO

David Kelley, founder of the famed design firm IDEO, coined the phrase fail fast to succeed sooner. Prototyping, experimentation, and learning are core elements of IDEO’s success. As design thinking goes mainstream, Kelley’s message has been truncated to the sound bite, fail fast. The heart of the message—to succeed sooner—is unfortunately being lost.

Some marquee companies learned early lessons and became wildly successful. Facebook started as a “hot or not” site. PayPal offered encrypted communications for Palm Pilot® users. With the launch of the iPod® in 2001, Apple remade itself from a smallish computer manufacturer into a personal technology juggernaut. Sadly, there are many more companies that failed to learn and simply failed.

Learning from both achievements and failures is not just for start-ups. Large, established companies may think that failing fast is too risky or too hard to implement. They have sprawling, complicated operating environments and a culture where failure is not accepted.

All companies can realize the benefits of fail fast; here’s how:

Prototype

Prototyping is a low-cost and fast way to gain valuable insight into how users will interact with the product or application. Involving users in the design process lets the team learn how the application will be used before committing to an approach. Failing fast with a paper mock-up is one of the easiest ways to learn quickly.

Prototyping is easy. Low-fidelity tools like Post-It Notes® and markers are often best. Sophisticated modeling tools may actually dissuade creativity. Find a representative group of users. Invite them to an open space with lots of white boards and Post-It Notes. Have a good facilitator lead the process. Observe. Experiment. Learn. Try again.

Go Agile, Go Scrum

Agile and the Scrum methodology create practices that allow teams to succeed sooner:

• Agile embraces change. The two-week development sprint establishes short cycles where prioritized items (stories) are included in the next product release. This short cycle creates the ability to quickly experiment, learn, and adjust;
• Direct business involvement improves collaboration. The product owner is embedded in the Scrum team ensuring the voice of the customer is ever-present; and
• Ceremonies ensure alignment of expectations. Sprint planning, stakeholder reviews, and product showcases create an environment where the team and stakeholders regularly meet to set priorities and provide candid feedback on the product.

Know Where to Experiment

All companies have a spectrum of applications ranging from commodity to strategic. Commodity applications may support standard business processes like procurement, accounting, and human resources. Strategic applications differentiate the enterprise from its competitors.

Applications that support strategic objectives may be better candidates for innovation and experimentation. Companies that can quickly implement changes, assess the impact, and integrate the learning into the next iteration have a competitive advantage. Design thinking, prototyping, A/B testing, and Agile development practices should be employed to maximize this capability.

Companies may not realize significant benefits from pursuing a fail fast strategy for their commodity or core applications—there is no competitive advantage to be gained. Companies may benefit from quickly implementing commercial-off-the-shelf (COTS) or software-as-a-service (SaaS) solutions with limited or no customization. This increases the likelihood of success and also allows scarce resources to be deployed to the strategic efforts.

Deliver in Small Increments

Big is bad. Large projects succeed only 8% of time compared to 62% of small ones. Long projects are exposed to greater risk that the business or consumer environment will change while the project is underway. Large projects generally have greater technical complexity, more interdependencies, and are simply more complicated to execute.

Large projects should be organized into smaller incremental builds to increase the overall likelihood of success. Chunking the project delivers functionality faster and improves the ability to rapidly respond to change. Agile naturally reduces these risks; but Waterfall project can also be structured as smaller, incremental efforts.

Improve the Process

Continuous improvement is generally associated with manufacturing. In software development, continuous improvement increases velocity and creates greater capacity for change. This expands the opportunity to learn, experiment, adapt, and adjust.

Agile has adopted lean principles derived from W. Edward Deming and the Toyota manufacturing model. At the end of each development sprint, the team conducts a retrospective. The retrospective is a structured review of the 2-week sprint. The team reviews its internal process by asking:

• What went well?
• What went wrong?
• What can be improved?

After the retrospective, the team develops a prioritized backlog of improvements to be implemented in the next and future sprints. High-performing teams reserve capacity in each sprint to implement these changes. These teams steadily increase their ability to react more quickly to change.

Established companies can learn from start-ups. Failing fast to succeed sooner embodies the principles of innovation, agility, and speed that can benefit all companies. Creating a culture and environment that fosters learning and experimentation is the first step.

© 2016, Alan Zucker; Project Management Essentials, LLC.  To subscribe

Sources:

Brown, T., & Kātz, B. (2009). Change by design: How design thinking transforms organizations and inspires innovation. New York: Harper Business.

Donohue, J. (2015, May 31). Fail Fast, Fail Often, Fail Everywhere. Retrieved August 27, 2016, from http://www.newyorker.com/business/currency/fail-fast-fail-often-fail-everywhere

Fail Faster, Succeed Sooner (SSIR). (2008, September 23). Retrieved August 27, 2016, from http://ssir.org/articles/entry/fail_faster_succeed_sooner

FailCon. (n.d.). Retrieved August 27, 2016, from http://thefailcon.com/about.html

Love, D. (2011, May 03). The 15 Greatest Tech Pivots Ever. Retrieved August 27, 2016, from http://www.businessinsider.com/most-successful-pivots-2011-4?op=1

Pace-Layered Application Strategy – Gartner IT Glossary. (2012). Retrieved August 27, 2016, from http://www.gartner.com/it-glossary/pace-layered-application-strategy/

Image courtesy of: http://slideplayer.com/slide/3547384/