Last week I had the opportunity to participate in an “Extreme Manufacturing” event at Lockheed. The event was run by Joe Justice of WikiSpeed, and organized by Scrum Inc. The plan was that by using agile methodologies, we would build a street legal car capable of getting 100 mpg in six half hour “sprints”.
Agile has been high on my radar recently.
At #BBCcon a couple of weeks ago, I attended a number of sessions focused on moving organizations from “waterfall” development methodology to agile. At Dreamforce, I attended another session on Agile.
But pretty much all I had seen in the Agile world was about software development. This was different. Extreme Manufacturing is all about bringing the techniques and methods of Agile to hardware and systems design. In this event we were told to build a car over six sprints.
We started with groups of components including a frame, an engine 4 wheel assemblies, a body, a steering assembly, a windshield, and a few others. There was Kanban board up and a “project manager” would write tasks on yellow sticky notes, and put them into categories of either ready or not ready. Scrum teams of 3-5 would then choose one of the tasks from the ready column, move it into in progress and start working. The organizers intentionally put some “mistakes” in so that the team(s) would need to work together to solve some problems. Unfortunately there were some real mistakes in some of the components, most notably that one of the cross pieces on the frame was welded 4 inches too far back, that prevented the car from actually fully coming together. We ended with something that looked a lot like a car and steered, but the engine wasn’t hooked to the wheels.
Does it work? The jury is still out. Here is what I see.
- The WikiSpeed Team has clearly had some success with using agile methods. They built a car that took 10th place in the Automotive X Prize competition, while spending $20,000 and using volunteers working an average of 2 hours per week. They beat out companies spending millions of dollars. They have had other successes, such as bringing the development cycle for a new radio down from 18 months to three weeks.
- Architecture, Architecture, Architecture. In order to successfully develop hardware in an agile environment, the architecture must be very well thought out. Ideally there should be no more than 7 major modules, each of one is truly independent. The example Wikispeed uses is the engine. They claim that they could take out the gas powered engine, but in an electric, natural gas, or fuel cell engine without having to redesign any other part of the car.
- Test, Test, Test. As soon as possible have a test of the integration of the subsystems. Find the errors as quickly as you can. The earlier an error is found, the lower the cost of fixing it.
- You still need someone with an overview of what is going to happen. In order for agile or scrum teams to work effectively, someone has to be really clear on when a task is really “ready” to be begun. We did several tasks out of order because some teams thought a task was ready, when it really wasn’t
- Communication is crucial. Especially since we were all working in on the same object. If a team putting on the front right wheel lifted the car, the team putting on the back wheel was impacted.
- Teamwork is learned. Teams need to get to know each other to develop a flow.
- Using Agile DOES NOT MEAN that you don’t need to plan or think about requirements. The requirements may be different than waterfall methods, but they are still important. In hardware, requirements for the interfaces between systems is crucial
This was an interesting, fun event. Of course there are some real differences between a learning exercise and real world applications, but I thought that there were some great lessons. Overall, I think that agile methodologies, applied properly to the right problems can indeed speed and improve hardware and software development.