Lean Startup and Agile (whether the latter is Scrum, Extreme Programming, or Kanban) share common roots in Lean Manufacturing, the work Deming did with Toyota beginning in the 1950s to increase quality and throughput through teamwork. (Lean was virtually synonymous with the word Kanban just a few years ago, in programming, until the advent of Eric Ries’ book Lean Startup usurped the word.)
Lean Startup and Agile differ in impact, but they belong together. Lean Startup is a market experimentation system focused on maximizing long-term monetary value through short-term iterative experimentation and market feedback. Agile is a product development value-maximization system focused on waste-reduction, highest-value-delivery and team-performance-optimization. Both value iterative, incremental delivery and customer feedback.
Agile, even practiced poorly, can improve product development substantially. And when it’s practiced well, agile results in teams emerging highly performant, delivering not just stellar process but team synergy – team results that are greater – in the best case, far greater – than the sum of the individual people and their individual skills.
Similarly, lean startup, even practiced poorly, can reduce cost (and thus risk) and improve value creation (and thus value delivery) for new products substantially. When practiced well, lean startup reduces up-front investment, minimizes time-to-market and dramatically increases the opportunity for success.
Eric Ries did agile a service and a disservice with his book Lean Startup. The disservice to agile was to cast it as something that hadn’t worked for him when, by his own description, he had at best used a few agile practices but clearly never been agile (he failed to use frequent delivery and get frequent customer feedback and instead did entirely too much upfront design and undertook entirely too much upfront development).
Fortunately for us all, Ries’ disservice to agile was far eclipsed by his contribution: by providing a business-side view to agile – as lean-startup, a product process, a design process, and a business-side process – Ries made agile understandable, palatable and amazingly desirable to the business world.
Whether agile or lean startup, whether we’re technologists or business people, we’re called to think, plan, try, deliver, get feedback, talk with each other, create experiments and hypotheses (and learn from them) and fundamentally delight customers.
In our book, Managing the Unmanageable, my coauthor and I collected hundreds of rules of thumb and nuggets of wisdom for managing software development. Among my favorites is this one, from San Francisco CTO Joe Kleinschmidt:
In the beginning, everyone will talk about scope, and budget, and schedule, but in the end, nobody really cares about any of those things. The only thing they care about is this: People will love your software, or they won’t. So that’s the only criterion to which you should truly manage.
What resonates for me is not so much that scope and schedule and budget are not important – we know that we have constraints, often in all three areas – but that we too often get lost in the maze of scope and schedule and budget and lose sight of the fact that, unless we delight our customers, we’ll not be in business long!
Agile backlogs are by definition ordered by ROI, by bang for the buck. Every developer knows that just by delivering the top backlog item, he or she is delivering the things that customers value most. By delivering them frequently, we have opportunity to get feedback early and often that lets us adjust our course to optimize for customer delight. By, as a team, defining “done” before we code a single line of code, we hold each other accountable to a level of quality for every feature that we’ll expect for the product as a whole. By writing stories that steer clear of the “how” but include not only “what” but “who” and “why”, we engage every developer and every tester in identifying the best possible solutions to our customers’ wants and needs. Mastering the practices themselves represents a level of discipline seldom seen in software development prior to agile. And by not only mastering the practices but embracing the values and principles, we have the possibility of emerging high-performant.
Similarly, by embracing lean startup – by posing our proposed product as a series of experiments – we can get frequent, recurring feedback that ensures we’re delivering just what it is that customers most want. By repeatedly, iteratively testing a minimum viable product, a team can rapidly leverage market feedback to tailor or if necessary pivot the product concept to meet marketplace needs. Developing repeated learning experiments costs dramatically less than developing upfront, spec-driven, perfectly polished, finished products. And learning experiments dramatically reduce the time from ideation to market feedback – time otherwise lengthy for spec-driven product development; it’s market feedback that limits the risk of being wrong about our product concept – sometimes very, very wrong. By leveraging the lean-startup build-measure-learn cycle, we substantially reduce that risk for the products we conceive and dramatically increase our chances of success.
Whether we’re startups or mature companies, whether building devices or web products or enterprise software, by leveraging highly disciplined agile and lean startup approaches together, we pair development and design processes to ensure that what we ultimately deliver customers delivers delight!
If you want to learn more, please reach out to us, and follow us on Twitter @_svsg.
Ron Lichty
Ron Lichty has been managing software development and product organizations for 25 years. Focused on untangling the knots in software development and transforming chaos to clarity, he spent the last 15 of those years in the era of Agile, the last 3 as a fractional VP Engineering consultant. He has trained teams in Scrum, transitioned teams from waterfall and iterative methodologies to agile, coached teams already using agile to make their software development “hum”, and trained managers in managing software people and teams. Ron’s most recent book is Managing the Unmanageable: Rules, Tools, and Insights for Managing Software People and Teams. In his continued search for effective best practices, Ron also co-authors the annual Study of Product Team Performance.