Enterprises want to increase their capability to deliver value to their customers in less time. Many are adopting agile software development, enabling them to iteratively develop and deliver software solutions. But it can be difficult to determine the business needs and decide which products to develop? The lean startup method aims to support developing new businesses and products. Several authors shared theirs views on how combining agile and lean startup methods can be beneficial.
Startup Tucson described in the blog post intro to agile development for lean startup practitioners how agile and lean startup can complement each other:
Agile is a set of principles on which to base your software development methodology, whereas Lean Startup pertains to how to run your business and product development. The two can marry quite well together. You can certainly do Lean without Agile (and vice-versa), but putting the two together is like chocolate and peanut butter, they go well together :).
The blog post explains how agile software development differs from waterfall, and describes the guiding principles of agile development, release cycles (sprints) and user stories. It also gives several examples on how agile and lean startup can fit together:
- When you’re working with your customers, you are trying to understand what problem they have (and you’re coming up with the solution to that problem).
- The problem you’re trying to solve has a set of hypotheses you will need to test, and each of these should have a priority (in a business sense) and you should use these priorities to estimate and commit to delivery (if development is required to test those hypotheses)
- Each release should be focused on what you’re testing currently and using the results of the last tests so that you can re-prioritize as needed
- Release retrospectives can be used to review the deliverables to make sure they meet the User stories defined
Laurence McCahill wrote a blog post called 10 things I’ve learnt about lean startup. He mentions some of the benefits that you can get from combining agile with lean startup:
The longer you go without releasing the product, the bigger the risk attached to it. Spending 6 months in a dark room developing something isn’t the best way to create startups. What works much better in most cases is a more agile or lean approach to releasing. ie. early and often. This helps to mitigate risk and means our focus is on learning and validating, rather than purely developing.
Laurence describes his view on the key principles of lean and lean startup. These principles are related to the principles behind the agile manifesto, for instance on satisfying customer needs and early delivery of working software:
(…) lean promotes the notion of creating value and this manifests itself in digital products as focusing on user needs. Anything that doesn’t satisfy these can be seen as wasteful.
Another way of reducing waste is to move away from documentation to more doing. Whether a workshop, a prototype, interview, etc lean requires working models to help communicate ideas. Rather than talk in conceptual terms or on paper, show people something. It can be a sketch, a wireframe or a Bootstrapped prototype. Whatever is the cheapest, fastest way to test out your assumptions with users.
In lean startup for your agile toolbox, Sergey Shishkin explains how ideas from lean startup can complement agile software development and help to focus on the customer needs. He starts by explaining how the user roles from a user story can be linked to lean startup:
“As a [role] I want [feature] so that [benefit].” The most important part of a user story is not the feature but rather the user role and the benefit he wants to achieve.
You have to know your customer segments and their must-have problems in order to provide benefit to the user. If your user stories don’t mention a particular customer group and a problem (which you’ve validated qualitatively), chances are you’re building some sort of waste.
Next he explains how you can use ideas from lean startup in the way that you manage your product backlog:
One scientific approach to prioritization would be to eliminate risks highest first and thus accelerate learning. After qualitative validation of the biggest assumptions it’s time to verify them quantitatively. So building an experiment for quantitative verification of the riskiest hypothesis is clearly the most important thing right now. And if the simplest possible way to build that experiment is by giving a working software in the users’ hands, great.
He also describes how the definition of done can look when applying lean startup:
You’re done, when you’ve validated, verified or denied a hypothesis. The difference between validation and verification being that you validate qualitatively and verify quantitatively. Registering either a positive or a negative signal when talking to people is qualitative validation. Turning 10% newsletter recipients into paying customers is quantitative verification.
Sergey concludes by stating that the success of agile depends largely on the product owner managing the customer needs:
You can pretend to be doing Scrum or some other agile method just in the IT, but local optimization will inevitably bite you in the ass. Customer development techniques are a powerful tool to help a product owner with his homework – backlog grooming and prioritization.