Just finished reading The Lean Startup by Eric Ries. It is definitely a great book. And probably it says as much about software development as about entrepreneurship (most examples are from software development). It should be a must reading about agile software development.
However, reading The Lean Startup, the discussion about “best practices” popped into my head again and again. I have a more moderate position towards “best practices”. Maybe “best practice” and “requirement” are not the best terms if we consider them from the original meaning of English words, but the meaning of these notions deviated from the original word meaning and “best practice”, as far as I understand, means a good practice in an appropriate context – not “the best” “practice” (as “hot dog” is not “hot” “dog” anymore). And it looks like attempts to replace “best practice” and “requirement” with something else rather confuse people – at least I haven’t seen a good replacement yet. So I don’t think that words “best practices” are especially dangerous, it is just any good idea / practice / framework applied outside of the proper context may hurt.
No words “best practices” are in the book, all practices described are good in the specified context [of entrepreneurship], the author himself warns many times against blind application, but I clearly see how people would start to use some of the lean startup principles out of the appropriate context.
Let’s look at testing. Testing (and performance testing) is a way to mitigate risks. My interpretation of Eric Ries’ message is that don’t be abscessed by possible risks when you don’t have anything to lose yet. Nothing to say against it. However at some point you are getting something to loose, and you need to introduce some practices to mitigate the risks. How much – depends on your business. Perhaps the main example of “The Lean Startup”, IMVU, has higher tolerance to risk than most other business (single-site, not critical business, low cost of losing a user). I, of course, understand that you can’t cover everything in a single book, but I am still concerned that the topic of introducing of risk-mitigation was not covered. Actually testing was mentioned at least once: p.189 “we had an extensive set of automated tests that assured that after every change our product still worked as designed”. So even in IMVU, with their relatively high risk tolerance and early stage, they had “an extensive set of automated tests”. I hope that other readers of the book won’t miss that, but I am afraid that many will.
By the way, it is interesting what would be opposite to lean? Probably not fat (although it is what using the word “lean” hints) – you probably don’t want to have fat in whatever approach you use. Maybe “Build to Grow”? Lean means that you do absolute minimum (accumulating technical debt) – so the opposite would be if you build infrastructure / framework to grow from the beginning. So, I guess, the dimension we are talking here about is Build to Grow – Lean. Maybe it would be a next book explaining when you need to be very lean and when you need to start building up muscles?
