Skip to main content

Team WIKISPEED at Agile 2012

Derek Huether
Reading: Team WIKISPEED at Agile 2012

Team WIKISPEED carRegardless of where I coach or teach, there is always someone who approaches me and says something like, “Agile is great for software projects but what about projects that aren’t software related?”  When asked the question, I usually give examples like a U.S. Marine fire team or air crew or a home construction site. (I’ll save those stories for another time).  I now have a new story to tell about a cross-functional, highly collaborative team, which competed for the Progressive Insurance Automotive X Prize.

While I was at Agile 2012, I met Joe Justice of Team WIKISPEED and had a chance to actually touch a car that was designed and built using Agile methods. (see cool photo enclosed)

Here is some back story from a 2011 press release:   Based in Seattle and led by Joe Justice, WIKISPEED is a collaborative team of over 50 experts and volunteers dedicated to offering ultra-efficient, ultra low-cost, mass-production road-legal vehicles. In 2010 the team’s SGT01 prototype placed in the top 10 in their class out of 136 cars overall in the Progressive Insurance Automotive X Prize.

Joe was able to build his first functional prototype in just three months.  The car that competed in the X Prize got 114 MPG (Highway). Compare that to the Toyota Prius which currently gets 51 MPG (Highway) and was introduced in 1995.  The reason auto manufacturers are so slow to “better” their products is because change is very expensive for them.  It is not uncommon for auto manufacturers to operate on 10 to 25 year development cycles.  Before Object-oriented programming methods were introduced, software teams used to operate much the same way.

By modularizing how we build software, we’re able to shorten our development cycles down to days.  By shortening our development cycles down to days, we give ourselves the opportunity to get feedback from our customers and create things that they really want, not things that we think they want.  We save ourselves and our organizations countless dollars in wasted development, due to waiting too long to get feedback from our customers or by operating in functional silos.  My breaking our teams down into small, cross-functional, empowered teams, we shorted feedback cycles as much as we can.

Being Joe is a client facing software consultant, building Agile teams and practices, why would he limit the benefits of Agile to just his customers?  Joe and his team have a car that has a development cycle of seven days.  They do this by modularizing the car.  They can switch the gasoline engine to an electric one in about the same time it takes to change a tire. They could change the car body from a convertible to a pickup truck.  All of this allows them to make changes and develop quickly.

The car is safe (passes road safety standards), because Team WIKISPEED developed safety tests before building the actual parts.  This helps them lower waste (Lean).  Next time you say you can’t afford to do test-driven development, think about that.  They do all of their work in pairs, avoiding time training that is not productive. (XP Practices) Again, the next time you say you cannot afford to pair people, think about that.  Pairing also helps lower the need for most types of documentation.  If everyone has a shared understanding, you have less need for it.  They visualize their workflow to help identify hidden delays and deliver something every seven days (Scrum).

So, do you still think Agile is only for software projects?  The fact that they use 7 days sprints on hardware, when I hear people say they can’t do anything less than 30-days on software, just goes to show you where there is the will there is a way.

Check out Joe’s session from TEDxRainier

Next Discovery is Fun

VP of ALM Platforms; Advisor on #Productivity #Metrics & Tools | Improver of things | Author: Zombie Project Management | Speaker | Podcaster | Always drinking #coffee or #running

Comments (2)

  1. Elizabeth
    Reply

    Derek, not bad for a post written so late at night! Sounds like you had an interesting time at that event. I definitely believe in the ‘where there is a will, there’s a way’ approach. One of my very first managers took this approach and it has stuck with me. He had the whole project team in a room and said ‘this is what we’re going to do’ and from the outset it looked impossible, but we delivered. My very own man on the moon moment!

    Reply

Leave a comment

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Congruence Between Agile Process and Ecosystem

In a recent SoundNotes Q&A with Mike Cottmeyer, our Fearless Leader fielded questions on a range of topics related to organizational Transformation and Agility. One key point he made was that any process or method, such as Scrum, LeSS, SAFe, etc., is designed to operate under certain conditions. Each process or method assumes it will […]

Letting Go of the Waterfall, Embracing Agile,
and Mixed Martial Arts
w/ Brandon Dudley

In this episode of SoundNotes, LeadingAgile’s own Brandon Dudley—Senior Consultant—shares his experience making the shift from a Waterfall mindset to a more Agile way of thinking and working. Brandon got his start in traditional, PMI-centric, project management working in the auto industry in Detroit. His introduction to Agile didn’t involve the hard break that many […]

Completeness & Correctness = Predictability

Completeness & Correctness = Predictability Video Transcript: When we think about organizations, one of the challenges for us as a consulting organization is when we engage with any particular company, we have to identify what that company values and what they’re trying to be, as well as what environment they’re in, because that’s going to […]

Questioning Agile Dogma

When I first learned about Agile methods in 2002, the principles seemed to offer an ideal solution to many organizational issues common at the time. When I applied those principles in real-world situations, they worked remarkably well. Today, some of the same principles seem to present impediments or unnecessary challenges for many teams and organizations. […]