My most recent books are the Leader's Guide to Radical Management (2010), The Leader's Guide to Storytelling (2nd ed, 2011) and The Secret Language of Leadership (2007). I consult with organizations around the world on leadership, innovation, management and business narrative. At the World Bank, I held many management positions, including director of knowledge management (1996-2000). I am currently a director of the Scrum Alliance, an Amazon Affiliate and a fellow of the Lean Software Society. You can follow me on Twitter at @stevedenning. My website is at www.stevedenning.com.

Transformational Leadership In Agile Manufacturing: Wikispeed

Real leadership is about transforming the system, not just succeeding within or despite the system. We know how to run organizations in ways that that lift up the human spirit, both for those doing the work and those for whom the work is done. In last week’s article I suggested that we get on with it.

Today: manufacturing. In the case of manufacturing, we not only have new mental models. We have a striking example transformational leadership in action: the case of Wikispeed.

The coming transformation in manufacturing

Today, US manufacturing is at the cusp of a massive transformation. As my fellow contributor at Forbes, Vivek Wadhwa, has noted, it’s not just the accelerated in-shoring that is occurring as a result of concerns about manufacturing in China, such as increasing labor costs, government-sponsored intellectual property theft, production time lags, the risks of extended supply chains and pressures from activists on social and environmental issues. Already companies such as Dow Chemicals [DOW], Caterpillar [CAT], GE [GE], Ford [F] and Google [GOOG] have announced the return of some manufacturing back to the U.S. from China.

More fundamentally, a group of new technologies—including robotics, artificial intelligence, 3D printing, and nanotechnology—are advancing rapidly and together will spark a radical transformations of manufacturing over the next decade.

However the winners in this rapidly changing world will not necessarily be incumbent manufacturers or even US firms. The winners will be those firms that have mastered the management techniques that generate rapid and continuous innovation and so transform the current system of manufacturing.

Traditional manufacturing is inherently slow to innovate

Many established manufacturers will find themselves flat-footed and ill-prepared for the transformation. That’s because traditional manufacturing is typically slow to innovate. It won’t be for lack of smart, highly qualified people with lots of good ideas. Nor will it be merely because traditional management is focused on maximizing shareholder value and is ill-suited to innovation.

The case of manufacturing is particularly dire: traditional manufacturing processes are inherently slow because processes are expensive to change. For instance, if engineers want to redesign a car door, they often need to wait years to pay off the existing multi-million door mold before making a new one.

As a result, the mindset of manufacturers is usually in terms of managing long product cycles. For instance, Porsche recently announced that the Porsche 911 will be with us for another 14 years or so. Parts of this excellent car were designed at various times over the last decade. That means that in 14 years from now, someone will be able to walk in to a Porsche dealer and buy a brand new Porsche 911 that will represent the best thinking that engineers had up to 25 years earlier as to what customers might want. Similar time lags are common throughout manufacturing today at the very moment when the marketplace is changing rapidly.

How software development became Agile

Such processes and time lags used to be the norm in software development. Large software companies with teams of narrow specialists worked in dedicated facilities, going through many years of planning and implementation. Over a period of years, specialists would gather requirements, design the solution, then build the solution, then test the solution, and then deliver the solution which might or might not come close to what they had hoped to build, years ago when they started, and even less to what customers might actually want at the time it was delivered. Projects were generally late, over budget and full of bugs. Many projects were never even completed. Because so much money was being wasted, more nimble work processes had to be developed.

The result? Agile software development. In Agile, self-organizing teams work in short cycles (typically called “sprints”) and develop the features and products in a modular fashion to facilitate rapid innovation. The teams continually evolve the product in the light of experience and customer feedback. In 2001 at the time of the Agile Manifesto, Agile software development was a tiny minority school of thought on the periphery of the business mainstream. Now Agile software development is a huge movement involving thousands of firms all around the world.

How Agile is coming to manufacturing

The same revolution is now coming inexorably to manufacturing, because slow-moving multi-year product cycles will be unable to cope with the rapidly shifting marketplace. The only surviving manufacturers will be those that have learned how to be Agile.

We can catch a glimpse of what Agile manufacturing will look like from the experience of Wikispeed, a Seattle WA C-Corporation that recently developed a functional road-safety-legal prototype to get 100 miles per gallon. It was developed in just three months, instead of the multi-year process that traditional manufacturing requires. Wikispeed’s car can go from 0 to 60 mph in less than five seconds. It weighs just 1,404 pounds. It has a top speed of 149 mph. Its ground clearance can be adjusted anywhere from racing to sport utility. It seats four passengers and meets all legal safety standards.

In achieving all this on a shoestring budget, Agile was key. Wikispeed developed the car by doing what modern software teams do: they used the radical management methods of Agile, Scrum and Kanban.

Agile software development is a family of software development methods based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. This reduces the cost and time to make change, which evolves new products faster than stage gates and planning phase approaches.

Scrum is a way of managing self-organizing teams, using a “Product Owner” who is the voice of the customer and a “Scrum-Master” who is accountable for removing impediments to the work of the team. This focuses the work with minimum business overhead.

Kanban is a way of visualizing work flows so as to reflect customer “pull” and identify bottlenecks and waste. This increases speed of delivery by maximizing flow.

Wikispeed works in self-organizing teams with one week sprints. Using Scrum, the team iterates the entire car every seven days. That means every seven days they re-evaluate each part of the car and re-invent the next highest priority aspects to be worked on. This way of working radically accelerates the pace of innovation. Within each sprint, the teams use Kanban boards to picture and optimize the flow of work within those sprints.

The Wikispeed story

Wikispeed is the brainchild of Joe Justice. By day, he is SolutionsIQ business process consultant in the Seattle area. But he’s also passionately interested in automobiles and environmental sustainability and founded a registered car manufacturing company called Wikispeed. In 2008, he saw the announcement of the Progressive Insurance X Prize—a $10 million prize aimed at seeing if it was even possible to build 100 mpg cars to road-legal safety specifications—and decided to compete for the prize. At the outset, he was alone. But he blogged about what he was doing and what he was learning. Through social networking tools, volunteers learned about his project and came to assist.

Many mock-ups and rapid prototypes later, the volunteer team was ready to build their ultra-efficient X Prize race car. Three months after that, he had a team of 44 members in four countries and a functioning prototype that was entered in the X-Prize competition. Despite little funding and limited experience in auto manufacture, Wikispeed tied for tenth place in the mainstream class, outlasting more than one hundred other cars from well-funded companies and universities around the world.

On one view, Wikispeed can be dismissed as a bunch of enthusiasts having fun on their evenings and weekends pretending to be car manufacturers in their garages. But Wikispeed can also be seen as something much more significant: a glimpse of transformational leadership and the future of Agile manufacturing.

1. Customer focus

At Wikispeed as in Agile software development, work proceeds by trying to figure out what customers want, defining those wants in terms of tests, prioritizing which tests are to be worked on, working in short cycles to deliver features or products that meet the tests, finding out from customers whether that’s what they really want, and then continuing the cycle once again. It’s a shift from working in a hierarchy aimed at doing what some boss or some big plan might dictate, to continuously iterating to find the best way to the test and meet the customer’s continuously shifting needs.

The product owner role

At Wikispeed as in Agile, the product owner is key. The product owner is the person responsible for setting priorities among possible things that teams might work on. The whole team leans on the product owner for having a clear vision of the company and the product. That clear vision can and does change from week to week as more information comes in. The product owner role is played by the person who has the clearest vision of the product and the company.

At Wikispeed, the product owner role is often played by Justice himself, but not always. It depends on what’s important in the current sprint. For instance, if the team is doing a lot of aerodynamics work in that sprint, the product owner is whoever in the team at that moment knows the most about aerodynamics. That person would have the clearest vision of the aerodynamics work that needs to be done and so he or she would be the product owner for that particular sprint.

Test-driven development

In developing the car, Wikispeed has tests for road-legal safety, efficiency, emissions, comfort and convenience. Anything that passes those tests can be entered into the iteration and tested. Thus doing work entails a collaborative search to meet both the tests and the vision of the product owner. Together the tests and the involvement of the product owner ensure a cohesive product, not just a set of interesting innovations that wouldn’t work together.

A test is always defined before any work is done. This is critical in working with a very large team. It gives clear success criteria, so that each team or team pair knows what is needed and also when they are done. It enables the team to focus on the smallest, cheapest and simplest way to solve the problem at hand.

The code of Federal regulations has been a big help in using test-driven development, because the regulations are written in terms of tests. So for seat-belt testing, the specifications don’t say: “You need a certain kind of bolt of certain dimensions with a certain kind of mounting flange.” Instead it says something like: “If a test dummy is moved forward with a certain number of Gs against the seat belt, the seat belt anchor is allowed to pull out an inch and a half.” Anything that passes that test works.

Wikispeed can’t always afford to do a physical test this every sprint. So they use inexpensive simulated testing and then whenever they can afford it, they do a physical test to establish correlations to check whether the simulated test is accurate.

Working with customers

Wikispeed works with customers to help prioritize what to work on next. Thus they offer their prototype car to customers and say, “This car isn’t even weather-tight yet. It does have air conditioning. But we would like your feedback on the new seat adjustment.” Yet they have early customers and micro-investors, whom they are able to ask, “What do you like about our car? And what don’t you like? What would be the most meaningful feature for you to have next?” The answers help direct development for the next sprints.

2. Self-organizing teams

Wikispeed uses distributed collaborative teams that self-organize to get the work done. Self-organization helps increase morale and team velocity.

A single self-organizing team

Wikispeed is currently using one large team of more than a hundred people, thus breaking the normal Scrum rule that teams should be less than ten people. Wikspeed did try using smaller feature teams at the outset of the work, but they found difficulty in communicating a clear vision across all feature teams and all sub-teams. The integration ended up being done by another team that didn’t have the expertise on the new feature or the new product. Things still moved forward but it was cumbersome.

So they broke the Scrum rule on team size and innovated with a single massive team. The result? Much clearer communication and higher velocity of the team. The team has a weekly standup call. Ideally, it would be daily but weekly makes more sense, since most of their team members volunteer their time and can only contribute around 2-4 hours per week. A daily standup call would be their entire involvement in the project.

In the weekly standup call, the team pairs say what they did last week, what they are going to do next week and any blocking issues. Then there is a demo of the current state of the product, so that everybody knows what is going on. The video is uploaded to YouTube. Anyone can go to www.youtube.com/wikispeed and see past demos and current demos, along with videos that team members have made from all over the world to share what they are developing.

Pair programming

To the extent possible, Wikispeed does work in pairs, similar to pair programming as developed by Extreme Programming software development. Contrary to traditional management thinking which would say “Why have two people do the work of one?” Wikispeed finds that work done in pairs ends up innovating faster and more cheaply than work done by individuals. It also avoids time spent in training that is not productive. It drastically reduces the need for documentation. The people doing the work share knowledge while working, without having to up-train someone afterwards.

Thus when someone takes a task down from the prioritized backlog, the first question is, “Who would like to pair with me?” and then, “Who knows the most about this and can give me information on the test I have to write for this to work.”

3. Dynamic linking

The teams at Wikispeed work in short cycles and receive customer feedback at the end of each cycle. Each team pair focuses on meeting the test in the simplest, cheapest and quickest way. This reduces the cost of making changes wherever possible. It means that the team doesn’t have to wait three to seven years for the next version of the product. The team is able to make changes to any part of the car every seven days.

To the extent possible Wikispeed uses tools that are free, like FreeConference.com, Dropbox, GoogleDocs, YouTube, Skydrive, Facebook and LinkedIn.

Sprint planning

At Wikispeed, sprint planning takes the form, “What do you think you might be able to take on next week, so that other teams can expect that, and prioritize their work accordingly to take advantage of that and to support you?”

Wikspeed uses an online tool to coordinate work. It’s a free backlog management tool called Scrumy by which team members assign tasks to themselves. Within a sprint, they use Kanban to optimize the flow during the sprint. Each physical location has its own Kanban board that is synced with the online tool at least weekly.

At the weekly standup call, most people talk for about one minute. Some people take just fifteen seconds. Overall, the call usually takes about thirty minutes. Then a YouTube video of 3 to 5 minutes is shown, which gives the current state of the car’s development. Detailed sprint planning is done off-line. After the conference call, people start mapping tasks to their to-do column on their Kanban boards. Overall, the standup meeting is usually completed within an hour, including the call, the demo and sprint planning and then unblocking any issues at the end of the call.

Modular design

Development is rapid because the design of the car is modular. The engine is able to be switched from a gasoline to an electric engine in about the time it takes to change a tire. The car body can be switched from a car body to a pickup truck. Modular design enables Wikispeed to make changes and develop quickly. Simplicity and modularity reduce costs in making changes, in tooling, in machinery and in complexity.

Accelerating the response to problems

Wikispeed has steadily increased its velocity in resolving issues. For instance, on one occasion, within hours of getting a video back from a side impact test, the team realized that there was four inches of penetration into the cabin. It was still survivable, and still road-legal, but it wasn’t the five star crash rating that the team wanted. So within hours, they had a volunteer team update the side impact crash structure and bolt it onto the car. The first time Wikispeed did a safety iteration like this, it took many weeks. Now they are able to accomplish it within a seven day sprint cycle.

“Contract first” development

Wikispeed is able to iterate on a central module of the car like the chassis because it uses “contract-first” development. That means thinking through: how are all these modules going to talk to each other? How are they going to attach to each other and share information with each other? So the chassis has to hold four wheels in space rigidly and dampen them. It also has to listen to the wheels and know their relative speed and apply braking power so that the car can have four-channel four-sensor ABS and traction control. The chassis also has to hold the engine in 3D space and handle the torque of it and the passengers. It needs to be able to communicate with the accelerator and the steering wheel and the brake pedal and with the steering module and the steering plate, which then steers the wheels.

By knowing what information those modules need to share with each other, Wikispeed is able to build anything that meets the contract that talks between modules. Anything that meets that contract is acceptable, whether it is made out of carbon fiber, steel, aluminum or even bamboo. It’s completely flexible. As a result, teams are able to iterate independently and innovate rapidly. That creates the loose coupling of modularity. One module can be changed without changing any of the others. Anything that meets the contract is acceptable.

4. Values: transparency and continuous improvement

Unlike a traditional hierarchical bureaucracy, Wikispeed embraces the values of radical transparency and continuous improvement. At Wikispeed, everyone can see at any time what is going on, who is doing what, what the overall goals of the enterprise are and how their piece of work fits into the bigger picture. Anyone can make suggestions at any time about any issue. Any problem can be flagged at the weekly standups and how the problems are dealt with is also transparent. As a result, even though the team is scattered around the world, everybody knows what is going on and everyone can contribute to identifying and solving problems.

Similarly, Wikispeed’s work is never done. There is a foundational belief that the product can always be improved so as to add more value for customers. The only question is: which are the things to be worked on that will give the most value for customers at this time?

Sustainability is also a key value at Wikispeed. The possibility of producing environmentally friendly transportation is an important factor in bringing together so many volunteers from around the world.

5. Horizontal communications

Instead of the vertical communications of a traditional hierarchy where those doing the work are told what to do, communications at Wikispeed are horizontal in nature.

Although there is a product owner at any given time who is responsible for setting priorities as to what should be worked on in any partiicular sprint, the product owner is not a conventional boss or even a benevolent dictator. The team can ask the product owner at any given time, “Did you mean this? Or did you mean that?” They can get an answer because the product owner has a clear vision and communications are conversational.

The product owner is often leaned on by the team during a sprint. Thus if an issue is discovered during the sprint, the team might ask, “Should I do it this way or that way? Which way is more on track for the vision of the product?” and get an answer. Everyone in the team is empowered to iterate on the backlog, at their own pace, in their own way, so long as it passes the test.

Justice believes that a benevolent dictatorship would work much less well, because it could only be as creative as one person. It could never have built a 100mpg car in 3 months with limited financial resources. Instead Wikispeed relies on the creativity of the whole world. In this respect, it is more like Wikipedia than General Motors.

Is Wikispeed serious?

Wikispeed is a team of a 150 volunteers working part-time with limited financial resources. It’s a legally registered car company that was a finalist for the Progressive Insurance X- prize. It has a working prototype that it is developing for the marketplace. It is a bunch of volunteers working evenings after work and weekends.

Wikispeed’s prototype is not currently serious competition for the major car companies. Its prototype still has no doors: passengers step over the side rails and sit down in it like a race car. It’s not weatherproof, with open trunk bays and a roadster body. The passenger space is cramped and doesn’t yet have cup-holders.

Yet Wikispeed can be seen as an example of transformational leadership, ultimately leading to disruptive innovation. Like all disruptive innovation when it first emerges, Wikispeed’s car looks cheap and inferior in quality. It appeals to a market segment—the environmental enthusiast—that is of little interest to established car companies.

As a result, incumbents may well take no notice of Wikispeed’s rapid innovation and continue to focus on slowly improving their core products for their core customers, until suddenly one day they realize that the Agile manufacture has improved quality and is “good enough” even for the incumbents’ core customers. By this time, Agile manufacture may be innovating so rapidly that the established firms will no longer be able to catch up. It will be too late to change. The established manufacturers will have become yet another set of victims to disruptive innovation.

Yet death is not inevitable. Justice has had some success coaching established firms to mend their ways and learn the rapid innovation approach of Agile.

Post Your Comment

Post Your Reply

Forbes writers have the ability to call out member comments they find particularly interesting. Called-out comments are highlighted across the Forbes network. You'll be notified if your comment is called out.

Comments

In my case, I happen to have a father who is a Shingo Prize winner for Lean, who has several hundred medical products still in the marketplace 8 years after retirement, whose first employer and career mentor was Kelly Johnson at Lockheed Martin’s Skunkworks fame, and … It was a very different mindset and for me was a very different way of growing up – ex. weekends and evenings were regularly spent troubleshooting assembly lines to allow un-interrupted production and the dinner table was always full of engineers working on the latest and greatest. And, I am sure when I was age 5, 10, and …. (though it sticks/sinks in over time), I looked at him in annoyance every time he said “It appears you have a problem, what are the steps going to be for resolving it ?” or similar. And, he exposed me to key management leaders one after the next. He also preaches Engineering as the main function of a business (currently, he is watching Bob McDonald, P & G’s CEO, who is an Engineer, as he sees the company as having its most incredible potential with him at the helm and hopes the Bill Ackman interest will push engineering to its most forefront (and I am avidly following such as well) – it will be no easy journey.

I worked with Agile via a leading global bank and their IT projects (as well as dozens of other project management and process improvement systems). I hate to say it though few people in the organization could really handle such and you found me day in and day out and minute by minute being the Fixer, Facilitator, Keeper of the Entrepreneurial Flame, and …. The problem was twofold: First, the mindset was not driven through the company, but was isolated to certain technology projects. Second, people thought this or that was a good method and thrust implementation on people who just did not have the proper education, training, interest, mindset, or … That all being said though, I commend those trying Agile (or any equivalent) and encourage then to seek out a true to the core evangelist to grow the process – in this case, Wikispeed’s Joe Justice appears “Keeper of the Flame” and without him at the helm (the “key”) this whole example would never exist.

About ten years ago I tried to GIVE almost every auto manufacturer a series of ideas that remind me of the approach as realized by this design. Still a lot of it left on the web. Just Goggle, William Lucas Jones Hybrid. The Volt used some of the fundamentals

I am way beyond that now. I could double or triple the safety of this vehicle with the addition of less than fifty pounds of additional weight. I am aware of electric motor designs that render anything else as obsolete as the horse and buggy. Application of more than one smaller motor per wheel needs to be tested.

As I was saying more than ten years ago, the transmission doesn’t need to be more than a simple copper wire. The technology for precise control is well developed. All it needs is someone with imagination to apply it.

Dear Steve, we have written a case study on Team Wikispeed. We would like to use the picture which shows the modularity of the wikispeed prototype. Can you help us with the copyrights? Do you or Forbes hold the copyrights for the picture? The case study will be published with the Case Centre and HBS and is for educational purposes only. Thank you very much for your support,