Book Review: "The Lean Startup" by Eric Ries

I recently read "The Lean Startup" by Eric Ries. Much of his book focuses on creating a minimum viable product (MVP).  Often the MVP is cited by agile gurus as a way to create a simple product for learning. But, Ries says something about the MVP that is practically heretical for people who focus on quality software:
"We build a minimum viable product, an early product that is terrible, full of bugs and crash-your-computer-yes-really stability problems. Then we ship it to customers way before it’s ready. And we charge money for it. After securing initial customers, we change the product constantly—much too fast by traditional standards—shipping new versions of our product dozens of times every single day."
This process of creating the MVP, however, gets to the heart of agile software development: creating short feedback cycles to improve the Plan-Do-Act framework.
"The MVP is not necessarily the smallest product imaginable, though; it is simply the fastest way to get through the Build-Measure-Learn feedback loop with the minimum amount of effort."
The goals of the MVP can be summarized as:
  • Get the product to the customer ASAP
  • Achieve good enough quality. "If we do not know who the customer is, we do not know what quality is."
  • Test the business model. "Customers often don’t know what they want."
  • Test business assumptions (get paid, share the risk)
  • Measure usage. Ries measure four key qualities: Registration, Activation, Retention, and Referral.
  • Learn what are the most important features & qualities
  • Iterate quickly over the phases: Build, Measure, Learn.

Sometimes it seems overwhelming to think about starting a business like this, but he has a case study of a business called "Food On The Table" that started with one customer and one grocery store. From that one customer they learned the requirements and eventually provided a service that spans across the US.

Key takeaway from the MVP process: "Remove any feature, process, or effort that does not contribute directly to the learning you seek."

As an aside, Ries says he didn't create the idea of a Minimum Viable Product. He cites a paper by Bill Junk from 2000, but it appears the URL is broken.

Bottom line: The Lean Startup is an inspiring read, but maybe not everyone wants to develop a business this way.


Prioritizing Software Enhancements by Business Value

Five years ago I made this graphic for my boss. He was wondering how to prioritize development projects, and considering venturing into new lines of business.

I had recently been working with several business consultants and noticed how often they used quadrants. At the same time, I had been reviewing a paper a colleague was presenting at PNSQC wherein he describes a way to prioritize and organize software enhancements.

I took the two ideas and put them together in an Excel spreadsheet (because your boss is always more impressed with a spreadsheet, right?).  This was the result.

The bottom line:  To create value in your product, prioritize high-value, low complexity enhancements.  Immediately cancel any complex, but low value enhancements. For high-value enhancements that seem complex, try to decompose them into simpler chunks.

As far as customer growth, the paths of lowest risk are either selling existing business functions to new customers, or develop new business for existing customers. The riskiest path is to develop new business for new customers.

This philosophy has worked well for me, and I still use it for prioritizing enhancements. I forgot about the graphic, but finding it among some files impressed me enough that I wanted to share it.


Learning from the Humbug

When I was a kid one of my favorite books was "The Phantom Tollbooth," by Norton Juster & illustrated by Jules Feiffer. I loved this book about a kid called Milo who explores a strange land called the Kingdom Of Wisdom. He gets there by driving an electric toy car through the titular tollbooth, and ends up on a quest to save the Princesses of Rhyme and Reason from the castle in the air. Both the book and many of the characters in it promote education as a virtue, which was a theme that rang a bell for me.

There was one character, however, the Humbug, who was a downright uneducated character.  As the Spelling Bee declaims:
"This...is the Humbug. A very dislikable fellow."
"NONSENSE! Everyone loves a Humbug," shouted the Humbug.
Feiffer clearly made the Humbug one of Milo's companions as a foil to his journey through Wisdom. Whenever the Humbug fails to learn something, Milo benefits by learning from it. For example, in one passage, the Mathemagician poses a problem:

Then he looked up expectantly.
"Seventeen!" shouted the bug, who always managed to be first with the wrong answer.
"It all comes to zero," corrected Milo.
I have often thought about the poor Humbug, who was always first with the wrong answer.  It seems to be both a curse, and a failure of personality. Feiffer obviously thinks that the Humbug cannot learn from his mistakes.

And then I had a revelation. It came to me while reading a quote attributed to one of the signers of the Agile Manifesto. The revelation is this: The Humbug provides value to Milo by setting an anchor for the right answer.

How many times have you had to make a decision, but resorted to procrastination?  You gather and process all the information, yet end up with analysis paralysis. This is analysis over action and it's an agile anti-pattern that should be avoided. It's better to make the decision, test it, and learn how to adjust based on the results of the action. Of course, keeping the action small and measurable is a key tenet of agile.  For example, a heart surgeon doesn't jump directly to making the first incision, but instead advises the patient on the risks and benefits of multiple procedures and works from that to provide the best outcome for that patient.

But even small decisions have anchors. As Daniel Kahneman writes in "Thinking Fast and Slow," the anchoring effect can skew subsequent judgment.
"Estimates stay close to the number that people considered—hence the image of an anchor. If you are asked whether Gandhi was more than 114 years old when he died you will end up with a much higher estimate of his age at death than you would if the anchoring question referred to death at 35. If you consider how much you should pay for a house, you will be influenced by the asking price. The same house will appear more valuable if its listing price is high than if it is low, even if you are determined to resist the influence of this number; and so on—the list of anchoring effects is endless. Any number that you are asked to consider as a possible solution to an estimation problem will induce an anchoring effect."
The value of the Humbug, however, is that you know his answer is always wrong. This is an easy way to get free from the anchoring effect.

Even Stan Lee, known as a co-creator of Spider-Man and The Fantastic Four, claimed to be a Humbug once in a while. In one interview he told how he worked with a comic book artist who had a fear of the blank page. The artist would sit for hours at the page, poised to draw, unable to bring the pencil to the paper. Lee saw that the only way to overcome it was to scribble on the page, so he did. After that, the artist could begin drawing.

Who was Agile Manifesto signer who spurred my thoughts? Ward Cunningham, inventor of the Wiki.

According to Steven McGeady, Cunningham advised him in the early 1980s, "The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer." McGeady dubbed this Cunningham's law.  Interestingly enough, Wikipedia points out: "Although Cunningham was referring to interactions on Usenet, the law has been used to describe how Wikipedia works."

So, the Humbug has his value: to be first with the wrong answer. Being wrong makes it easier to fail early and fail fast.  A known bad starting point helps formulate the right direction.  Use what was learned from the wrong answer to head for a better one, and hopefully you will be like Milo and finally find Rhyme and Reason.


Brain Teasers & the FLL Lego Challenge

For five years I coached First Lego League teams. These were 5th - 8th grade kids who were interested in Lego robots, but sometimes had a hard time sitting still, or focusing on tasks for extended periods of time.  For three months, teams of up to 10 kids would work on a building a Lego robot to do the FLL challenge tasks, put together a science project based on the challenge theme, and generally work to assemble themselves into a functioning team.  It's a lot to ask from kids, but in addition to what they learned, I'd reward their hard work with a pizza party at the end of the season.

I started gathering brain teasers, both as a way to break up sessions of intense work, and as a fun thing to during the pizza party.  After five years, I had accumulated pages and pages of riddles and brain teasers.  They were great puzzles, and I wanted to share the collection with others.

I wanted to do little JavaScript project, so I finally put this page together. Have fun, and share them with your FLL teams.