There's an old saying in software development that, depending on how you hear it, goes something like "Fast, good or cheap. Pick two." Known as the Project Management Triangle, Triple Constraint, or Iron Triangle; this concept will be familiar to anyone who has ever felt the pressure of managing the opposing forces of quality, speed and cost against each other. Having spent my entire professional life as a Software Engineer, Architect, Director and CTO in companies of various sizes, I have felt these pains directly in many ways. Until recently, I have always accepted this principle as a fact of life, like death and taxes as they say. But in 2011, I was introduced to a concept known as "Lean" that changed the way I thought about things. I found myself asking, "Fast, good or cheap. Can I have all three?" I now believe the answer can be "Yes."
The Iron Triangle
The concept of the Iron Triangle has emerged over time out of the following thinking:
- Develop something quickly and of high quality, but it will be very costly to do
- Develop something quickly and cheaply, but it will not be of high quality
- Develop something of high quality and low cost, but it will take a long time
There are a few problems with these statements that emerge pretty quickly when you take a look at them. The first is around the definition of "good", the concept of quality. The Triangle assumes that "fast" and "cheap" is an option, when in truth, delivering a project where the result is low quality is almost never an actual option. Whether releasing a product to market, completing a project for a client or delivering on an internal company project, quality is just about universally an expected requirement.
The second issue is known as The Mythical Man-Month or Brooks' Law, and states that, "adding manpower to a late software project makes it later". While Brooks' Law refers specifically to software development, its concept can be applied to many other types of projects as well. Often simplified by the idiom "too many cooks in the kitchen", the basic concept is that when adding more people to a problem, the additional communication overhead and complexity of project interrelationships often have a negative effect on the timeline as a whole. That pretty much eliminates the combination of "good" and "fast" being a reality. What we're left with is "good" and "cheap", but that means that the project is going to take a long time. Thanks to the concept of Lean though, that doesn't have to be the case.
The Lean Startup Method
Lean, or the Lean Startup Method, is a process for delivering products and businesses developed by Eric Ries in 2008. Chronicled in his 2011 book, The Lean Startup: How Today's Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses, it is based on concepts borrowed from Lean Manufacturing as developed by Japanese automakers in the 1980s. The Lean Startup Method extolls the concept that anything which does not deliver value to the end user is considered waste. This waste is combated by creating testable and measurable hypotheses and then measuring them against honest and meaningful key performance indicators, known as KPIs.
The first step is to build a minimum viable product or MVP, the simplest version of a product that can test your hypothesis and deliver the maximum amount of validated learning. Following the initial MVP, the next step is to iterate over and over using tools like Split Testing and the pre-determined KPIs to make adjustments to that product with one of two outcomes. Either refine it into excellence, or determine failure and make a pivot. [For a deeper dive into the Lean process, I highly recommend reading Eric Ries' book.]
Applying the Lean Process
Armed with what we've learned about the shortcomings of the Iron Triangle, we can deliver a project that is "fast", "cheap" and "good" by applying the concepts of the Lean Process. When we apply the Lean Process we keep teams small, because we know that too many "cooks" is just going to make communication more difficult and limit our ability to be flexible and deal with changing market demands. Because we're building an MVP, we don't make big investments. We're testing our hypothesis so we don't want to spend money or other resources that turn out to be waste if we're wrong. Keeping teams small and limiting our investment in the MVP let us keep the project "cheap". We're also building an MVP because we want to gain validated learning as soon as possible and deliver something of value to the end user.
Focusing on those values, and by limiting what could become a bloated scope full of assumptions and untested hypotheses, we're able to build "fast". When we limit ourselves to the minimum valuable product, we get to market quickly with something of value. Once the initial MVP is released, we can continue to follow on the Lean principles, using validated learning and KPIs to make decisions on what's working and what's not, and iterate quickly. The repetitive iteration and meaningful measurements will guide us toward the goal of delivering a project that is "good". And there you have it; fast, good and cheap all in one project!