Agile and the Lean Startup

This is part of my ongoing series devoted to understanding the connection between Disruption Theory, Lean Startup, Lean product development, and Agile software development.

The Lean Startup is most likely the best example of how to translate Lean into software development directly. This set of management tools uses nearly all the Lean tools identified in the famous texts of Lean, such as Toyota Way, Lean Thinking, and Toyota Production System. In fact there are so many similarities between the two people have accused the author of basically writing a book about Lean and not adding anything to the topic. I, personally, don’t agree with this as the portions about pivoting is definitely not part of the Lean framework and is novel capability he introduced.

Furthermore, he’s had to translate a great deal of the language from manufacturing or office settings into a development setting. While there are similarities there are differences between a piece of finished goods and a completed piece of code. This difference is that the code can be pushed to “production” servers and active for users, while the finished good has to be purchased by a customer, which still may take weeks to occur (if the production system is linked to purchase orders and directly to customers). To that end Reis pushed to make as many changes to production as quickly as possible – not without testing of course, but as soon as testing was completed the change went live. This is an extreme case of single piece flow. One change goes through testing and pushed live.

Pushing in the “Continuous Deployment” model of course causes a lot of issues if you don’t have robust testing. You need the testing to be fast but comprehensive. It’s impossible to do this from the beginning so over time the team has to develop more and more sophisticated tests based on how the team breaks the existing piece of software as they deploy changes. This is where Root Cause analysis plays a key role. Do a 5 Why’s analysis (ask why 5 times until you come to an underlying root cause) fix that problem so it never happens again. In the case where you cannot prevent the issue then you need to be automatically testing for the issue to fix it before you publish the change.

Agile has similar concepts in that they there are short cycles of development called “sprints” these sprints can last anywhere from a week to a month. At the end of each sprint the goal is to have a series of features that are deploy-able (including testing) that a customer would be willing to pay for. These pieces of work are broken down into something called a “minimum viable feature” which is smaller than a product but not so small that it wouldn’t completely work. For example, an MVF of WordPress would be the “publish button” initially it would need to convert all the text in the text editor and turn everything into a viewable website and create the URL associated with that article. Over time new features can be added like the auto-tweeting capability that exist now.

One common theme between both approaches is the concept of minimum viable product, which is a set of features that makes up the product. The difference between the two approaches in developing the MVP is that the Product owner does this in Agile, while the MVP is determined through a great deal of customer interaction in Lean Startup (Ideally the Product Owner is doing a similar activity for the customer but typically acts as a proxy).

There hasn’t been a lot of authors that have looked into combining these two approaches. There are a lot of similarities as they both emerged from the Lean philosophy, which means they should be fairly easy to combine into a larger framework. The only book I’m aware of that has even attempted to tackle this is the “Lean Mindset” by Tom and Mary Poppendieck. Even in this book though, they have decided to go with a 4 step approach that has more phases than what the Lean Startup recommends. They propose the stage gate to help determine minimum levels of details. I believe that this is because of the typical levels of bureaucracies in organizations, where a Project Management Organization will require adhering to some sort of phased gate approach. The Lean Startup uses Pivots as a way to manage projects that are failing, but not with the same level of rigor or structure as the approach the Poppendiek’s recommend. Instead, the Lean Startup approach recommends setting goals and targets for metrics (non-vanity like number of views) determining when to pivot. The timeline has to be long enough to get a clear view of what your customers actually want.

Lean as a tool for new and mature companies

Today, I finished the book “The Lean Startup” by Eric Ries. Despite the focus on entrepreneurship, I think this book has applications at many levels. First though, I must say that I’ve been using Lean for several years and I walked into this book with an understanding of Lean and how  to apply it at a company. What does Lean mean though? Well, it certainly doesn’t mean cutting staff, reducing the amount of money you have or anything along those lines. It’s a methodology for managing projects, processes and products. It does this by basing decisions on actionable data.

What is actionable data? Well, it’s data that you can do react to quickly if the data is showing trends. This could be a positive trend or a negative trend. If you see something going well and a process is improving over time, (which is abnormal processes typically go out of control over time) then you want to understand how and why it is improving. If it is getting worse over time, you want to understand why and work to improve the process. This isn’t just for machines but also for business processes.

Once you have valid metrics there are several different things you can do. You can simply jump in and try to fix whatever problem is there or you can take a different track. The other track is to do some root cause analysis of the situation. This is called the Five Whys. This is a series of questions that ask Why to understand the real cause of the problem. In one case you may have had a new employee upload something to the production server and it kills the production server. Understanding why might not be as simple as saying, don’t do that again. First you might want to know why the action of the employee took down the server, was it something he did that no one else would have done or was it something else. As you dive down you may realize part of the problem was lack of training but there were issues that would have arisen eventually from someone else. This deeper understanding allows you to make changes at multiple levels rather than installing knee jerk reactions.

That’s a reactionary use of Lean, some other interesting uses of Lean have to deal with experimenting with your product. Ries argues that most companies wait to long to engage customers and put too much effort into the first version of the software. He argues that a company should create a minimum viable product that can be tested to get the basic point across of the end product. Doing this early allows for experimentation with customer feedback. In the software world this is pretty easy to do. You can get to something that early adopters can use and then test changes. As you can route different users to different versions of your website for the product you can have slightly different tests to see what increases the metric that matters. Getting people to continue using your product, but you need to have very targeted metrics to understand what is actually happening with your software. If you use the incorrect metric you will do a lot of work that isn’t driving usage and isn’t driving your revenue.

If you decide to change the way users interact with your GUI, it would be useful to have a goal metric to truly understand if the GUI is an improvement over the previous GUI. This could be tracking the number of clicks it takes to get to an important function. The number of times the user uses your product, the number of times a new user uses the product, but stops using a specific GUI. Once you see your metric moving in the correct direction and you can be sure that it is the result of your changes, then you should end you experiment understand why the users reacted the way they did and try to learn what you should test next.

The early goal is rapid experimentation with purpose and data to back up the decisions you make. These techniques will work with any company, but will also be very successful for a startup.