Lean Startups: Learning Over Working Software

The Agile Manifesto, which we created to uncover better ways of developing software, says,

We value Working Software over Documentation

And we do. We’d much rather have actual, real live, working software then reams of documentation proclaiming all the great stuff this as-of-yet-nonexistent software is going to do at some point in the future.

However, agile is also about learning and adapting. And 10 years after it’s creation, one of the manifesto’s creators — Kent Beck — is looking at what agile means for startups. In a startup, he says, there’s actually something we value more than working software.

We value Learning over Working Software

Agile helps us develop software as efficiently as possible – we can bang out quality code really fast with it. But what good does fast or quality do if you’re building a product that nobody wants?

Startups aren’t just small versions of large organizations. They’re about learning and discovery, not execution. All we’ve got are ideas (Kent calls these “almost impossibles”). And so we take these ideas and we think about how we might measure (or validate) whether people would be willing to pay for them. We might build software in order to validate our ideas, but working software is not our goal here. Our goal is learning.

“The unit of progress for entrepreneurs is learning, not execution.” – Eric Ries

The thing is, we can’t measure progress with working software if nobody is willing to pay for that software. In fact, in lean we have a word for that type of software: we call it muda or waste. So when you look at the Build-Measure-Learn loop, our goal is not about quality or even quantity of the software we build, our goal is speed – how fast can we get through this loop so that we can learn what we need to do next. We’re not building software that’s meant to scale or evolve into a final product, we’re simply building whatever we need to test our hypotheses. Sometimes that isn’t even software!

“Lean Startups are driven by a compelling vision, and are rigorous about testing each element of this vision against reality.” – Eric Ries

We want to focus on the fundamental feedback loop between when we have an idea and when we’ve learned whether or not our idea makes sense. Lean Startups are continuously surfacing hypotheses about what will be successful and then testing those hypotheses and assumptions against facts (e.g., if I use this pitch, will others join my startup or provide me with seed funding? If I make this service available, will customers pay actual money to sign up for it?).

“The ultimate goal of a lean startup is to identify where its vision intersects with what reality can accommodate.” – Eric Ries

Our focus starts then not with product development, but with customer development – finding that intersection of vision and reality that we call product/market fit. Once we’ve discovered this through many many quick (& quite possibly dirty!) iterations of Build-Measure-Learn, once we’re ready to start scaling up, then we can switch gears and begin using agile development to help us create quality, working software that can serve as a measure of our progress:

Lean Startup Model

Lean startups might, at first, feel contrary to agile where quality is king and we take great pride in our work as software craftsman. However, I love the idea behind them because once you’ve dug a little deeper, it’s hard to miss how well they mesh with the the lean principles behind agile. Which, of course, was by design.

Why do we need to move beyond agile for lean startups?

Agile helps us when our solution is unknown, but it doesn’t provide much guidance when our problem is unknown. Sure, you can pick some potential customers and ask them what they want, but with this approach, you’re likely to find what Henry Ford did: that if he’d asked his customers what they wanted, “they would have said a faster horse.”

A faster horse, alas, is not the path to the type of disruptive innovation that startups are seeking when working to build, say, the next facebook. These startups need a different approach. And I like Lean Startups because it shares many of the same principles that we appreciate in agile:

  • Eliminate Waste. Don’t waste a bunch of time building something that no one might want.
  • Create Knowledge. Lean startups are all about learning.
  • Short Iterations with a tight feedback loop to allow us to learn and adapt.
  • Fail Fast! If something isn’t going to work, figure it out as soon as possible so we can move on to something that will.

So, I have to agree with Kent Beck: while it is fun to build things, it’s more important to learn the right thing to build.

Learn more about Lean Startups:
» Eric Ries’s Startup Lessons Learned Presentation (video)
» The Promise of the Lean Startup by Eric Ries (article)
» Kent Beck’s To Agility, And Beyond, Startup Lessons Learned Conference (video)
» Lean Startups 101 by John Prendergast, Boston Lean Startup Meetup (slides)


7 responses to “Lean Startups: Learning Over Working Software”

  1. Michael Avatar

    Nice post Abby,

    I found it interesting in the Kent Beck video that he talks about running the loop backwards “Learn..Measure…Build”. I think that speaks to the idea of doing as little as you need to do to start learning about what to build. It also reminds me of a talk that David Hussman gave at Agile Bazaar (http://bit.ly/c2G8h7) where he talked about knowing when to code (and when not to code) if you didn’t have enough of an understanding of what story/problem you are trying to solve.

    Sometimes Lean Startups can use two teams, a Problem Team to address Customer Development and a Solution Team to actually start building things using Agile practices (http://bit.ly/2xwgE7)

    I get what you are saying about early iterations may be quick and dirty and how that may be contrary to the ideas behind software craftsmanship, but I disagree somewhat. Two of the principles of the craftsmanship manifesto are about “steadily adding value” and having “productive partnerships”. A good software craftsman needs to know when they are incurring technical debt and why. Although it may go against how we feel about building well-crafted software, sometimes it is the right thing to do for the sake of adding visible value and developing partnerships (i.e. customer development). That is also why we need good communication in lean and agile team so everyone knows and understands the consequences of the choices we make.

  2. Vincent vd Lubbe Avatar
    Vincent vd Lubbe

    One small typo: Eric Ries instead of Reis (typo). Iterate 😉

  3. Abby Fichtner Avatar
    Abby Fichtner

    Oh! Thank you! Hopefully all fiixed now =-X

  4. Abby Fichtner Avatar
    Abby Fichtner

    Thanks so much. And to anyone reading the comments, also check out Michael’s post on the same topic (we were both inspired to blog after a conversation at a completely unrelated event last week):

    I sadly missed David at Agile Bazaar, but I DID get to see him present with Jeff Patton on Customer Discovery techniques, which ties really well into all of this.

    Re: quick & dirty. I am a little torn on this. I totally see what you mean. Although my own experience with early stage startups was that the initial things you build all get thrown out anyway so there’s no use trying to do anything quality about them. It’s that minimum viable product idea – just enough to get to the next stage (seed funding, your 1st customer, whatever) and then once you find something that can be scaled up, THEN you throw that out and build the real thing. While it sounds really wasteful, it allowed us to move as quickly as possible to prove out technology and check our facts against people outside the building 🙂 and then as devs, we learned so much from building that we were better prepared to build the real thing.

    But, for sure, there was a lot of waste… and I remember at least one product that should NEVER have stuck around doing just that, which was a nightmare. 😉 I dunno, it’s an interesting question.

    Thanks for all the links – will check those out!


  5. Michael Avatar

    I guess the point I was trying to make regarding craftsmanship is that a good software craftsman knows when they are building something that will be thrown away and has worked to communicate that understanding throughout the whole product team. As you pointed out, not throwing out something like that becomes a nightmare down the line. As one of my past co-workers was fond of saying, I think we are in violent agreement here 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *