This time a post I posted in dutch on our company intranet a few weeks ago about a book I read and liked a lot: The Lean Startup, by Eric Ries.
In march this year I attended a conference where Lee Copeland was one of the presenters. In a presentation on Innovations in Testing, he mentioned the book and the fact that a tester recommends a book that, judging by the title, is about startups and enterpreneurship, got me interested in reading it.
The description on amazon.com reads:
“Most new businesses fail. But most of those failures are preventable. The Lean Startup is a new approach to business that’s being adopted around the world. It is changing the way companies are built and new products are launched. The Lean Startup is about learning what your customers really want. It’s about testing your vision continuously, adapting and adjusting before it’s too late. Now is the time to think Lean.”
The book focusses largely around a concept called “Build, Measure, Learn”. The development of a (new) product is done based on “validated learning”, which is the engine in the “Build, Measure, Learn” cycle. Once a first (very basic) version of a product is built, it is released, used, observed and (very important) measured how it behaves. Based on those findings the chosen strategy (based on a hypothesis before development of the version was started) is examined and determined if it is still the right strategy based on the findings of the released product version. If the observations and measurements support the chosen strategy, continue the development according to strategy. If not, see how to change the strategy and start development based on the new strategy. This decision is called the “Pivot or Persevere” moment and is a clear moment in each development cycle. By keeping those cycles as short as possible, efficient product development is possible.
The value of “validated learning” cannot be overstated according to the book. Instead of hoping you built the right thing in a very big bang only to find out it’s not what your (potential) users want or care about, the reader of the book is challenged to think about the assumptions and expectations the founded the reason to start developing the product, specifically the growthpotentatial and valueproposition of your intended market. How many users are willing to pay for your product. How much revenue can be generated in the first month for example. By setting and measuring these expectations you can quickly get valuable feedback about your assumptions and expectations and whether or not the product you developed lives up to those expectations. If it does not live up to the expectations, you can quickly change course based on measurements instead of guesses and opinions.
The book contains many cases of both good and bad examples of developed products. It guides the reader to defining clear and useful datapoints along which to measure growth, development and succes.
While I was reading the book, I was part of a pilot scrumteam in my company. Scrum is both new to the company and (fairly new) to me and while working and reading I noticed several parallels: specifically the short cycles in which build-measure-learn happens, very similar to the sprints in a scrumteam. It allows you to quickly deliver, learn and adapt if necessary.
However, what I have not yet seen in scrum, but the book did mention is the measurement of your deliveries and the “pivot or persevere” decision. My scrum experience so far is mostly focussed around chopping up a large project into smaller bitesized bits, and less about the feedback of the delivery after each sprint and if changing the project-goal is necessary. There is of course the retrospective, but that focusses mainly on the scrum process and not the product.
A lot of the thoughts and practises in the book do apply to (software) testers: it constantly challenges the reader to look at a situation or product from different perspectives. Trying to find ways along which to measure the succes of a product that is being tested. What makes the product tested succesful? When built according to coding guidelines? If it indeed does what the specifications state? I am sure it all helps, but if your users do not need or want it, find it unintuitive, it is not succesful. Even if it was beautifully built. So, the role as a tester is not (only) to determine if the product does what it says it does, but also to test the assumptions. Test the implications. Test the developers and the testers. Test the context in which it is used, user experience, side effects, etc.
In short: this book is an interesting read for budding enterpreneurs (although I am really not a fan of the word “enterpreneur”), but it can also be a very valuable read for those (testers) interested in agile or lean-manufacturing methods. Recommended reading!