Before we go into the details of lean startup vs. agile, let us first explain what the above words mean, because even I have been coming across it for a long time, without grabbing the actual meaning of it.
Let us start with some Wikipedia (like we have any other reliable source).
Lean startup is a method for developing businesses and products first proposed in 2008 by Eric Ries. Based on his previous experience working in several U.S. startups, Ries claims that startups can shorten their product development cycles by adopting a combination of business-hypothesis-driven experimentation, iterative product releases, and what he calls validated learning.
Ries’ overall claim is that if startups invest their time into iteratively building products or services to meet the needs of early customers, they can reduce the market risks and sidestep the need for large amounts of initial project funding and expensive product launches and failures.
In his own words Eric Ries says that,
“Startup Success can be engineered by following the process, which means it can be learned, which means it can be taught…”
The Lean Startup provides a scientific approach to creating and managing startups and get a desired product to customers’ hands faster. The Lean Startup method teaches you how to drive a startup-how to steer, when to turn, and when to persevere-and grow a business with maximum acceleration. It is a principled approach to new product development.
Too many startups begin with an idea for a product that they think people want. They then spend months, sometimes years, perfecting that product without ever showing the product, even in a very rudimentary form, to the prospective customer. When they fail to reach broad uptake from customers, it is often because they never spoke to prospective customers and determined whether or not the product was interesting. When customers ultimately communicate, through their indifference, that they don’t care about the idea, the startup fails.
Scrum is an iterative and incremental agile software development framework for managing product development. It defines “a flexible, holistic product development strategy where a development team works as a unit to reach a common goal”, challenges assumptions of the “traditional, sequential approach” to product development, and enables teams to self-organize by encouraging physical co-location or close online collaboration of all team members, as well as daily face-to-face communication among all team members and disciplines involved.
Agile refers to a set of values and principles put forth in the Agile Manifesto. The Manifesto was a reaction against heavyweight methodologies that were popular, yet crippling software projects from actually doing what they needed to do – create software that helped the customer! I believe Agile’s values & principles work becauseof the science behind Lean and so you’ll see a lot of similar themes repeated in agile.
The Agile Manifesto’s values are:
Individuals and interactionsover processes and tools
Working softwareover comprehensive documentation
Customer collaborationover contract negotiation
Responding to changeover following a plan
And its principles are:
1. Highest priority is customer satisfaction
7. Progress measured by working software
2. Welcome changing requirements
8. Sustainable development pace
3. Frequent delivery of software
9. Continuous attention to technical excellence
4. Business people & developers cooperating daily
5. Build projects around motivated people
11. Self-organizing teams
6. Face-to-face conversation is best
12. Regular reflection & adaptation
But being agile is not always good; it has certain drawbacks to it too,
How do you apply it at scale?
How can a large project run using agile methods?
One team working on one project in an agile way is not hard to envision. But what about running 10 or 20 teams, each working on part of a product?
How does the list for each iteration get sorted out and synchronized?
How does the result of each iteration become integrated into the larger whole?
Can Lean startup and agile methodology work together?
In today’s dynamic business world, we transform our project planning focus from an expanding control change process to an adaptive process that embraces change: a process that responds to business requests whenever they are made, a process that is flexible enough to change even the process itself.
That process entails practicing Lean Startup with the Agile Methodology, in addition to the traditional project management focus on controlling activities. Lean startup principles measure ongoing results but then challenge those requirements as needed, as part of a build-measure-learn loop. A true picture of success or failure starts to emerge–and a true picture of failure may induce even the most intractable project sponsors to make significant changes before things go off the rails.
In the traditional uses of Lean and Agile, the main difference is the following:
Lean is used to help build and define a marketable product. Agile is the means to achieve this in software development. Below is a chart depicting the high level differences from a terminology perspective BUT they equate to the same meaning in a different context.
Of course, all work and no play make Johnny a dull boy, so for a startup the qualities of agile wont really fit in good, in the words of Jeff Patton of Jpatton associates who has had 20 years of experience product design and development,
When working with startups individually or coaching in an accelerator, I often get asked to do a basic Agile tutorial. And, every time I’m asked, I get this sinking feeling. What most people believe Agile development is today isn’t at all what you need if you’re a startup. In fact, trying too hard to get Agile “right” is a good way to slow down the stuff that should really be happening.
When most people think of common Agile practice today, they think of this Scrum/Extreme Programming hybrid – or XcrumP as I like to call it. It goes a little like this.
A product owner builds a backlog of user stories that describes your Minimum Viable Product – the smallest product you think will succeed in the market (stories came from XP, backlogs from Scrum).
Prioritize the backlog highest priority first, (which is hard because we need it all, at least we’re pretty sure we do).
Use a Sprint Planning Session to plan the details for 2 weeks worth of work (but we’re hopelessly optimistic so we often over-commit to 3 weeks or more).
Start a 2-week Sprint (Scrum’s name for a time-boxed development cycle, and they could be as short as one week, or as long as a four).
Every day hold a standup meeting (which actually feels like a status report to the people who are stressed because development isn’t moving fast enough).
Every day move sticky notes around a task board (which looks more like a Kanban board).
Try using some sort of tracking tool to track the backlog and progress (and show burndown charts which for some reason people really hate to create by hand).
Use engineering rigor like test-driven development, automated acceptance tests, and continuous integration (but throw it out when it looks like we’re not going to get everything done in time).
As stories are finished coding, the tester thoroughly tests them, and the product owner reviews them (but usually we hand off a pile of finished stories to the tester the last day of the Sprint and tell them to test it all, then watch the tester melt down).
At the end of 2-weeks, stop and do a Sprint Review where we briefly show what we got done, and reflect on how we could improve (but we spend a lot of time arguing about whether things are really “done-done” because we want a high velocity, and then we make excuses for why we couldn’t get 3 weeks of work done in 2 weeks).
Repeat steps 2-10 till done or out of cash, whichever comes first.
That’s the basic flow. And my snarky comments in parens are what I see usually go wrong. And sadly, they may sound way too familiar to some of you.
A few guys in a garage programming day and night stopping only to eat pizza and play Call of Duty.
Is that the mental model you have for a startup? This is the sort of startup where the founders believe their idea is fantastic, so fantastic that their biggest problem is getting their big idea built faster so they can release it to much fanfare at a big launch party. A startup thinking this way might adopt an Agile development approach with the hopes of building faster, or to at least get a bit of visibility into how fast the team is actually going.
Imagine a Silicon Valley startup adopting Scrum so they can go faster. Actually, don’t imagine it. Watch this short excerpt from the HBO series Silicon Valley – but watch out, because there’s lots of “adult language.” (If you offend easily – go back to just imagining it.)
If you’re in software development today, you really need to understand Agile development. But, if you’re a startup, be aware that common Agile practice is about predictable delivery and is best suited for the times when you’re confident you’re building the right thing. By using an Agile time-boxed development cycle, you can more predictably build it right.
If you’re biggest risk is building the right thing, focus on building your learning muscles.
Go back to original Agile values and principles. Remember that Scrum and Extreme Programming are good delivery approaches to using Agile thinking, but not the only approaches. As a team frequently ask yourselves these questions:
Are we working together as a team collaboratively and effectively?
Are we making our ideas visible fast so we can learn fast, whether it’s working software, or a simple paper prototype?
Are we learning directly from our real customers, the people that will buy and use our product?
Are we stopping frequently to take stock of what we’ve learned and to re-think our product idea, our plans, and the way we’re working?
Those four questions are what the manifesto really means from a startup’s perspective. Keep those basics in mind, forget all the other agile dogma you hear, and you’ll be using Agile right.