The first thing that slapped me in the face while reading The Lean Startup by Eric Ries is the difference between the Agile and the Lean Startup methodologies.
Honestly, I thought that they were the same thing: Iterations! Right? I don’ need to read that book… Wrong!
I have been applying a number of variations of the Agile Software Methodology successfully for many years for custom development projects… you know, for building software for business.
However, the Agile method alone has ended up in a lot of wasted effort for us when applied to creating a new product to end consumers.
It has nothing to do with how efficiently we build things, but it’s more related to building the wrong thing and not having a self-correcting mechanism embedded into the process that can adjust quickly enough.
What is the wrong thing? The cool feature which looked like a great idea, and no one wants it, and we really stressed and worked hard to build.
A startup is a human institution designed to create a new product or service under conditions of extreme uncertainty.
The Lean Startup by Eric Ries
It probably comes down to core concepts:
- In Agile software development, “Working software is the primary measure of progress.” For this to happen there has to be a common understanding of the definition of done between the developers and the customers.
- In The Learn Startup method, “validated learning” about who is the customers and what the customer might find valuable is the measure of progress. This allows to adjust course quickly enough and avoids waste.
In short, what I understand is that:
- Agile Methodologies are a set of processes focused on building things efficiently and being able to scale production
- The Lean Startup is a set of processes focused on making sure the thing we are building is useful, by rapidly testing the creative guesses (hypothesis) a startup might have.
If a hypothesis was incorrect, it is discarded, and the learning is recorded and forms a part of the progress.
As an Engineer, if I am working on pure Agile, I am done with a feature when the feature is deployed in production.
However, as a Lean engineer, I am done with a feature when I have learned if the feature was useful or not, and why.
In the book (which I highly recommend) Eric tells stories of companies that add an extra validation step to the process
In this example, features B and C have been built, but under Kanban , cannot be moved to the next bucket for validation until A, D, E have been validated. Work cannot begin on H and I until space opens up in the buckets ahead.
So, if an Engineer wants to increase productivity and that of her team, she would prefer to pick a feature that is testable and implement ways to test it from the beginning. This way the feature will be easier to validate and her work can move better through the board
Personally, I found this fascinating!! I can’t way to try it! In fact, we are already putting mechanisms into place to allow this workflow
Hello! My name is Ernesto Buttó, and I have always wanted to be an innovator, this series of posts are meant to help me stay accountable by sharing our journey building a product I really like, LingoStand, that I intend to use to become a true product builder.
I will share our progress and thinking in this blog series starting by using the Lean Startup framework, as we apply concepts like:
- Validating Learning
- Build-Measure-Learn
- Innovation Accounting
Have a great day!
Recent Comments