Agile on Non-Software Projects
Regardless 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.
Post originally appeared at LeadingAgile