Agile Lean development – learning from the best

Posted on December 11, 2011


I’ve just discovered what is possibly the most important world-class successful case study in terms of distributed voluntary cooperative engineering: Wikispeed.

Wikispeed collaborative 100mpg+ car

Joe Justice and his friends put together an extremely ambitious engineering project: build a +100mpg commuter car that was really fast, safe, and affordable. Basically, they built it from scratch in 3 months, just in time to participate in the Progressive Automotive X-prize.

They didn’t get 1st place, but they got 10th and got noticed and respected worldwide — and they placed better than Tesla and MIT, which were very well funded! They proved that there is no such thing as “conflicting requirements” or “technical impossibilities” when people are passionate about their work.

And how did they start? quite humbly, by bolting some recycled parts together with a square chassis in Joe’s garage, and using second-hand tools. Oh, and by simulating everything they could inside the virtual world of software. Does this ring a bell?

These videos blow my mind. In fact, they confirm my suspicions: R&D is a lot easier and cheaper to do once you leave the heavy traditional framework (and mindset!) of mass-production companies. And most importantly, a lot more fun!! I’m well aware of how medium and large sized R&D companies operate, but I never knew exactly how completely informal and self-organized groups faired in the field of R&D.

It all has to do with a fundamental change in attitude: embracing change (risk and uncertainty) as a natural part of life and especially innovation, letting go of a priori control measures, and just be light and quick enough to adapt and respond. However, Agile and Lean methodology is definitely not a chaotic mess where people just get together around some tools and do whatever they fancy; it’s almost like that, but everyone has a very precise notion of how they and the others are contributing to the final goal of the team.

The Lean and Agile methodology they follow is a mix of several methods, taking the best parts of each to solve the real life problems as soon as they come up. I already knew about Agile’s power to deliver results soon and adapt fast, but I hadn’t thought it could be used in volunteer or even distributed teams. And I certainly didn’t expect newbies to become productive so fast and everyone to have so much fun while doing world-class competition and development. This is a case-study to inspect and remember with great care.

So what do we take away for our project?

Since we are not in the position of wikispeed (having an external and very demanding client wanting results yesterday), we don’t yet need to accelerate the development so radically. And since the team is quite small and steady, we also don’t have a clear need for extreme modularization (although we have been using it). But we do have to cope with changing requirements, since our clients (ourselves) keep changing their minds about what they want. Basically, we grow more ambitious the more we learn. And we do have to produce results with a shoestring budget, so the Lean aspect also comes into play.

It really does look like a good idea to implement Agile and Lean at MyOwnHybrid.

In some ways, we are already doing it; we always try to get together face-to-face to work on the project; we try to work in pairs or in threesomes in order to have implicit on-the-job learning and fast cross-correction and problem unblocking; and I’ve tried to at least maintain an electronic version of lightweight project management in a private server that all team members can access (but usually don’t 🙂 ). Also, the publication of results in this blog is a kind of “Sprint Review” (the Show-And-Tell session that the Scrum method does of results to the customers).

So, using Scrum terminology, we’ve been operating as a “Feature Development Team” that tries to implement the “Product Backlog” created by the “Product Owner” (me), only without the benefit of a “Scrum Master” to help people cooperate and grow their skills.

This is clearly not enough — motivation and commitment could be a lot higher. I think it’s time to put up an old-style “Sprint Task Board” in our workshop, complete with sticky notes and all, and run a weekly Scrum meeting at the beginning of every encounter. This alone should be able to pick up the pace of development and give a sense of cohesion to the team that is now a bit lacking.

It is very important, from a psychological and emotional point of view, to be aware of what it is the whole team is building, how much it has already achieved, and how much work remains to be done. Another fundamental point is to avoid over-specialization and promote task swapping and collaboration: we are here to learn and have fun. So a weekly Scrum should give us more opportunities to do just that.

And when this present sprint/iteration ends, it is also a very good idea to hold the “Sprint Retrospective” (a “Lessons learned” gathering) and do a full-blown “Sprint Planning” meeting to determine exactly What we want to build next and How we want to build it.

None of this had been an issue until now due to the simple fact that I had been working alone; but from the moment other people started contributing to the project at many levels, the simple process that went on in my head is no longer valid. I had been struggling with this reality without knowing exactly how to transition from one-man-band into team mode; but the Agile methodology came to our rescue.

All this does not come by chance; I’ve just completed a Scrum Master course in the context of Software Project Management, and after seeing how Wikispeed has done it for a manufacturing process I believe that all innovation projects are a natural fit for Agile/Lean methodology.

I do have a problem though; I shouldn’t be Scrum Master (the guy that coaches others into the Agile process) and Product Owner (the guy that decides what effectively should be built for the product) at the same time. I need to offload one of the roles onto someone else. But I clearly have stakes in both of them. Hmmm… any volunteers?

Another lesson I learned from the Wikispeed example is that I should be more transparent about the problems we have. This blog doesn’t have a whole lot of followers, but the few that hang around will probably feel more engaged and interested if they can help us solve our problems. So I’ll start doing that more.