Being confused about the distinction between lean and agile strategies is common; their goals overlap (both aim to eliminate inefficiency and value individuals and their contributions) and so many lean startups nowadays use agile development practices.
Here’s the boiled-down difference: lean is more high-level, referring to a business strategy of beginning as a small start-up and improving gradually, while agile is more small-scale, referring to building a product.
Let’s explore those differences a little more closely.
What Is A Lean Strategy?
A lean strategy is used to optimize existing processes. In a lean strategy, you regularly ask employees about different parts of an existing process that need attention and improvement, prioritizing changes and constantly working on getting better.
Originally, lean strategy was developed by Benjamin Franklin and later revisited by Frederick Winslow Taylor and Henry Ford. A man named Taiichi Ohno later developed the Toyota Production System, applying lean strategy concepts to optimize production lines — strategies that he learned from Ford’s book My Life and Work.
Today, “lean” has become the definitive adjective to describe start-ups that build an MVP and gradually improve it.
What Is An Agile Strategy?
An agile strategy is used to build new products. It was made popular around 20 years ago when it was published as a set of key principles in the Agile Manifesto. It was an alternative to the waterfall approach of building software, where a lot of bureaucracy, analysis, and planning took place before a project could start.
Today, Agile principles provide a way for teams to create new products in a more efficient and flexible manner: iterating over product features to quickly make changes, getting feedback from customers, and learning about what to do next. Agile principles also highlight the value in making gradual changes to project requirements and making frequent product updates and learning a priority.
What Lean and Agile Strategies Are Not
Both agile and lean strategies are often misunderstood as “just-do-it” practices with no time reserved to analyzing long-term goals and outcomes. But that’s not what they’re about.
Being lean doesn’t mean being lean on your vision. A start-up using a lean strategy should still have an idea of where they’re heading or where they’ll be in a few years. They shouldn’t just build an application without doing any prep work. Before you build your product, the appropriate first step is, often, to learn whether someone would even want your product. This can be tested with a series of marketing experiments, which can still be considered a minimum viable product.
Similarly, an agile practice is sometimes seen as a silver bullet, an excuse for having no process at all. The team just starts building whatever the founders have in mind at the beginning of a project, without any planning, scoping, testing, or other necessary steps. This approach may work in the beginning when a product is relatively small, but further down the line, it leads to a lot of misunderstanding, miscommunication, and bad decisions — which eliminates all of the benefits of agile process.
Applications in the Modern Age
We’re approaching the year 2020, where tech startups are nothing new and markets are flooded with products. Investors are more careful now than ever about which companies they choose to invest in. To even raise money, you have to build something, provide proof that you’ve had paying customers, and show a decent growth rate. Even if you’re lucky to get seed investment, your resources will be limited, so you’ll need to manage them efficiently.
That’s why the lean practice is so useful. The lean start-up approach (described by Eric Ries in his book of the same name) allows start-up founders to start small and iterate over product features using the build/measure/learn cycle. You start small with the minimum viable product (which, in many cases, doesn’t need to be an application, even for tech startups). You launch it. Then you measure how well it performs from a business standpoint. Basically, you want to see how many users will find your MVP valuable enough to pay you money. If you’re happy with the result, you start the next cycle, building a new set of features based on the feedback you received. If not, you pivot and run another experiment in a similar fashion.
Starting small in this case allows you to run experiments using a minimal amount of time and money, which in turn allows you to learn much more about your product and its market with each cycle.
Agile strategy works in a similar fashion, but on a smaller scale; an iteration in an agile practice is a smaller period of time, focusing on smaller product features. For example, if, when you released a feature, customers told you that it should be implemented differently, agile enables you to quickly make changes to your product. If your process is rigid and doesn’t support that, you most likely won’t be able to show something valuable to your customers early on. And you for sure won’t be able to make any changes until everything you’ve scoped out is implemented.
Agile allows you to adjust the requirements on-the-go with minimal damage to the efficiency of your team. Of course, in theory, you should be able to quickly pivot from X to Y in the next iteration, but it’s almost never possible — there’s still some inertia in the product development process. The bigger the project, the bigger that inertia. Still, compared to traditional development practices, these practices allows you to learn and adjust much faster.
Originally posted on Medium
