Team WIKISPEED at Agile 2012

Last Updated on Friday, 16 November 2012 01:24 Written by Derek Huether Tuesday, 28 August 2012 10:41

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

Learn More

Effective Risk Management That Isn’t Boring

Last Updated on Tuesday, 4 February 2014 12:39 Written by Jesse Fewell Friday, 24 August 2012 04:00

Last week at Agile 2012, there were a couple Risk Management talks that blew my mind.  I was already comfortable with the notion that Agile methods offer a set of effective IMPLICIT risk management practices (e.g. iterative learning cycles, fully tested iteration increments). But this past week, I learned the community is beginning to mature a set of EXPLICIT risk management practices that can be embedded in your Agile methods.

Mike Griffiths shared his experiments with using collaboration games to improve Risk Management practices. He has a multi-part blog series that goes through the approach in detail, but the most important  can be summarized in 3 points. Meanwhile, LeadingAgile’s very own Dennis Stevens had a talk where he challenged people to move beyond 1-dimensional thinking. Here is my summary of the key points from both talks.

Effective Risk Management Techniques

Make risk planning more engaging. In his talk, Mike asserted that we need to get beyond the idea that Risk Management has to be boring academic exercise. He does this by renaming the standard risk management processes to be more playful. “Risk Identification” becomes “Find Friends and Foes”. “Qualitative Risk Management” becomes “Post Your Ad”, where risks look more like a job board. This helps us get over the anxiety of being perfect or technically correct.

Make risk planning more holistic. Dennis suggested we involved multiple disciplines in risk analysis, rather than just the ivory tower project manager. Technical people, operations people, HR people, all need to be a part of the conversation. He also highlighted our tendency to go straight into the weeds (“IF the shipment of servers is late, THEN our testers will be late getting started”). Instead, Dennis proposed a multi-tiered taxonomy for thinking about risk at progressively higher levels. Specifically, a Risk Category (e.g Security) will cover many different Risk Drivers (e.g. Fraudulent Transactions), which will in turn unearth the Risk Events (“IF a customer deposits  More people thinking about risk at more levels.

Think of risk at multiple levels

 

Make risk planning more visual. Mike shows a few examples of hands-on collaboration games for performing the risk management processes. This moves the risk conversation into a more whole-brained activity, where both left and right hemisphere activities are engaged. Also, it keeps the risks front-and-center in our minds as we perform the project, rather than having them archived in a spreadsheet somewhere.

Team’s visual brainstorm of risks

 

What about you: What EXPLICIT risk management techniques do you add into your Agile projects?

 

Learn More

Best quote so far from Agile 2012

Last Updated on Thursday, 16 August 2012 02:22 Written by Derek Huether Thursday, 16 August 2012 06:20

If you’re curious what is happening this week, the entire LeadingAgile team is here in Dallas, Texas at Agile 2012.  Dennis and Mike are presenting and Dean, Rick, Jesse, and myself (Derek) have been helping PMI man their booth, communicating the facts of the Agile Community of Practice and the Agile Certified Practitioner certification.  This has been an amazing experience and I would strongly recommend attending next years event.

I was going to wait to write a blog post until I got back home.  But why wait?  The most “quotable” event so far happened yesterday when I was in Jeff Patton’s session.  He said

We don’t need an accurate document. We need a shared understanding.

The message was simple but powerful and it resonated with me. I immediately jumped onto Twitter and posted it.  I credit Esther Derby retweeting it to her (over 6000) followers for so many retweets.  That quotable moment has been just one of many I’ve had the last few days.  It’s really too bad there isn’t more time to hang out with and learn from more of these people I’ve met the last few days.

Learn More