Category Archives: Lean Startup

New Startup Accelerator Program Coming To Boston

There is a new startup accelerator looking to set up shop in Boston this summer.  The thing that caught my eye is that this accelerator, Bolt, will focus on connected devices.  Real…physical…stuff.

I think that this is great for the Boston area.  We already have a lot of energy and effort in the area around startups for mobile, web, and software services, but I think this will help bring other engineering disciplines into the Boston startup community.  The ability to iterate in the mechanical/electrical world has improved a lot over the years, especially with the widespread use of 3D printers, electronics prototyping, and OTS platforms like Arduino.  It will be interesting to see how lean startup principles come into play in the physical world (yes, I know that’s where they came from initially)

As someone who has spent most of his career doing software for robotics, automation, and medical devices this will be something to keep an eye on.


Agile and the Lean Startup

I was at a Windows Phone 7 Firestarter at Microsoft in Waltham and ran into The Hacker Chick.  We had just started a conversation about the Lean Startup and Agile when we were interrupted by someone who asked Abby “Excuse me, do you work for Microsoft?  Do you have any tape?”  I managed to bite my tongue and not say the obvious “It’s a hardware problem”.  Needless to say, the conversation got cut short while Abby ran off in search of tape.  I had no idea the life of a Developer Evangelist could be so demanding.  Who ever said Microsoft is not responsive to the needs of the marketplace?

So we never got to finish the discussion, but I have some thoughts about it.  There are certainly many similarities between Agile and the Lean Startup movement.  In fact, the use of Agile methodologies are one of the key components of a Lean Startup.  I see the Lean Startup as an evolution of Agile practices.

Both Lean and Agile involve the customer and welcome customer feedback.  Both are designed to get working products out into the customers hands as soon as possible to be able to incorporate customer feedback into next iterations of the product.  One way that I think Lean goes beyond Agile is that a key component of its practices is customer development.  Most of the Agile projects I have worked on already had a customer in place ,or at least a proxy for the customer in the form of an in-house product owner.  Customer development is critical in learning about the problem you are trying to solve with your start-up.   These slides describe how customer development combined with Agile practices can be used to address issues where neither the problem nor its solution are fully known.

Another concept that I think is key to the idea of the Lean Startup (or at least successful startups) is the pivot.  The idea behind a pivot is that there is a vision behind the product (there is a vision, right?).  As start-ups continue to develop the customer and get more feedback there will most likely come a time where what you are learning isn’t in line with that initial vision.  Start-ups that are unable or unwilling to deviate from that initial vision are most likely doomed for failure.  Companies that can incorporate that feedback and change the vision have a chance to succeed.   Eric Ries describes the pivot as

the idea that successful startups change directions but stay grounded in what they’ve learned. They keep one foot in the past and place one foot in a new possible future. Over time, this pivoting may lead them far afield from their original vision, but if you look carefully, you’ll be able to detect common threads that link each iteration.

Keeping one foot in the past is critical, otherwise you make drastic jumps from one vision to the next, and risk losing what you have already learned about the customer.  There are a lot of interesting examples of several successful pivots by companies like Flickr, Paypal, and YouTube.

To sum up, I think that Agile helps us build software right whereas the principles of the Lean Startup try to make sure that we are also building the right software.

P.S. To learn more about the Lean Startup, take a look at some of the presentations from this year’s Startup Lessons Learned Conference or see if you can find a local Lean Startup meetup in your areas.

Startup Lessons Learned Conference

Yesterday was the Startup Lessons Learned Conference in San Francisco.  Although I heard it was a beautiful day in SF, I enjoyed the conference from Cambridge, compliments of the Lean Startup Circle – Boston.  It was a great day, met a lot of interesting people in Cambridge, and heard a lot of interesting folks via the simulcast.

This was my first time at a meetup of the Lean Startup Circle in Boston and I really enjoyed it.  The group may gravitate a bit to the entrepreneurial side, but that is not unexpected.  Still I would like to see a broader spectrum of people and industries embracing the ideas of lean/agile, but it is a movement and that will take some time.  But thanks again to Matthew Mamet and John Prendergast for putting the event together.

Keynote – Eric Ries

Eric Ries kicked things off with the keynote.  The takeaway for me here was the definition of a startup:

A human institution creating a new product or service under conditions of extreme uncertainty.

It has nothing to do with the size of a company, what industry it is in, how it is funded, etc.  We need to develop practices that are geared towards managing and responding to that uncertainty.  He talked a lot about the Build, Measure, Learn loop (which Kent Beck later turned around to the Learn, Measure, Build loop), ways to fail fast, and knowing when it was time to pivot.  If you follow Eric’s blog there was not much new here, but he was setting the table for the presentations and case studies that would follow.

Build, Measure, Learn – Kent Beck

Kent Beck followed Eric Ries.  Kent was part of the Agile Manifesto and invented test-driven development and pair programming.  As a developer, TDD and pair programming are two of the most powerful tools/practices I have seen in all my years.  As I mentioned earlier, Kent talked about the Build, Measure, Learn loop, which makes sense from an engineering/development point of view, but by running the loop backwards, we are pulling the build (from Lean Manufacturing‘s concept of pull) from what we learn.

Kent also went through other aspects of the Agile Manifesto: people over processes, collaboration, accepting change.  He was preaching to the choir, so he didn’t go into too much depth.    He did go into some depth on knowing when to live with a simple solution to get a product out (he used the term “hackery”) and when you need to refactor.  As an example, he cited Amazon Dynamo.  At the scale they operate at now, this is an essential service, but if the had tried to start with that, they would have ended up in the scrap heap.  As a developer, I have seen many projects get behind by over-designing or over-engineering early on.  Getting out there early allows you to see if you have a viable product and as you learn more about usage/features you can refine your design and implementation.

Agile Development Case Study – Farb Nivi

A real highlight for me was the Agile Development case study at Grockit, by Farb Nivi.  Farb went into a lot of great info about accepting change/chaos, how to write good user stories (make them narratives, not “to do” lists).  He talked about an Agile planning  tool they use called Pivotal Tracker that I need to take a look at.  His presentation also had a very cool feel to it and was done with a tool called Prezi.

The thing that really caught me about Farb’s presentation was the development culture and the way they have embraced pair programming.  The interview process at Grockit is simple.  Candidates come in and pair program with one of the development team.  I can’t think of a better way to get to know whether a candidate is someone I would want to work with and has sound software engineering skills. I have had a few posts on the value of pair programming and the challenges in getting more developers to adopt it, so having this question about a candidate answered up front is invaluable.

Grockit’s philosophy on languages is simple and straightforward too.  They don’t care what languages or tools you have used, if you have good skills and work well as part of a team you will be able to produce good code in whatever languages they are using.  That is an incredibly refreshing and enlightened attitude (although on their website they say you need to have programmed in Java and Ruby for at least a year.  Jeez, Farb which is it LOL).  Developers at Grockit spend 70-80% of their time pairing, with the reminder spent on spike’s or some other stand-alone tasks.

Getting to Plan B – Randy Komisar

After the break, Eric Ries sat down with Randy Komisar in a talk titled “Getting to Plan B“.  This was a great back and forth discussion between Eric and Randy.  Randy talked about answering the “Leap of Faith” questions.  These are the questions that you need to answer, that if you don’t know the answer to will kill your product.  They can be technical, marketing, whatever.

Randy also talked about the importance of a “dashboard”  to guide you and track your progress: are you measuring the right things to answer your leap of faith questions.  I found some interesting articles with the Sloan Review and Sramana Mitra that touch on a lot of what he talked about.  When the presentations go online I strongly recommend watching this presentation.

In Closing

There were several other good presentations, more than I can write about.  When the presentations go online I strongly recommend checking them out and finding the things that hit home for you.  And thanks again to the folks at the Lean Startup Circle – Boston for putting on the simulcast and giving a place for people to get together and exchange ideas.

Update: The videos from the Startup Lessons Learned conference are available on