From P2P Foundation
Jump to navigation Jump to search

= (SGT01 is) a 100 Mile per Gallon (MPG) car using processes borrowed from the software world; Agile, Lean, Scrum and Extreme Programing.


See: Joe Justice on Rapid and Agile Industrial Development at Wikispeed

Introductory Citations


'To build a car that can really change the game, you have to think outside the box. That’s what Joe Justice is doing with his SGT01 car and his network of volunteer mechanics called WikiSpeed. Let me start by saying the SGT01 isn’t electric. It isn’t even a hybrid. But it is one of the most fuel-efficient, intelligently designed cars ever made. It gets 104mpg city and 114mpg highway, which with a 4-gallon tank gives it a range of 400 miles. Couple that with 0-60mph in 5.5 seconds and 5 star crash safety and you’ve got a pretty good car. Oh, and it only costs $25,000." (


"Team WIKISPEED uses methods developed by the fastest moving software companies. In fact, in many ways we have more in common with Google or Twitter than GM or Toyota. Manufacturing and old-thought software teams gather requirements, design the solution, build the solution, test the solution, then deliver the solution. In existing automotive companies, the design portion of that process alone takes more than 10 years, and then the vehicle design is built for 5 to 14 years. This means it is possible to buy a brand new car from a dealer and that car represents the engineering team's understanding of what the customer wanted, 24 years ago! Team WIKISPEED follows the model of Agile software teams, following the same cycle but compressing it into 1 week "sprints". We iterate the entire car every 7 days. That means every 7 days we re-evaluate each part of the car and re-invent the highest priority aspects, instead of waiting 10 to 24 years. This enables a completely different pace of development." (,-lean,-and-scrum)


On the origin of the name, Joe Justice writes:

"wiki-wiki is the Hawaiian word for "quickly". So Wikipedia is "fast-pedia". So we are "speed-speed"." [1]


Charlie Rudd:

"Here are some highlights of what Joe and the others from Wikispeed have accomplished:

  • Designed and manufactured a 4-passenger street-legal car that gets 100 mpg

Most of us would agree that is quite an achievement.

There is more:

  • The car was constructed using off-the-shelf parts

This means, among others things, that the car is easily serviceable using existing maintenance infrastructure

  • The car is entirely modular in design

All sub-systems are essentially snap-out/snap-in, making replacement of engine, brakes, suspension, etc. a process that takes just a few minutes. BTW, this is not simply replacing like-for-like but also to switch to a new technology (e.g. change to a new engine).

  • They innovated a new process for carbon-fiber body construction that costs 1/360th the traditional process

With this process, they were able to switch to a new body type for less than $1000.

  • You can pre-order cars now for less than $29,000

This is not just a one-off prototype. Currently they are manufacturing one car per week (yes, that’s the low volume manufacturing retail price). They are targeting a future price of under $20,000.

Last but not least, all this has been accomplished:

  • With no capital investment

Although they do solicit donations through PayPal on their Web site.

  • No paid employees

Everything is done by volunteers." (



"One of the core concepts behind WikiSpeed cars is the ability to swap components. This doesn’t mean you get to choose between real or faux paneling, or how many cup holders. If you owned a WikiSpeed car, for about $1000 you could take it into the shop and get the body swapped for a newer model. Or if a more efficient (or powerful) engine came out, just bring your car in and let them upgrade it. The idea is that the car isn’t a single entity, it’s a modular assembly of parts that can be traded in or upgraded at will. ... With a modular car, you don’t have to worry about it, you can just take it in and have them swap the engine for a better one. And as your car begins to look dated, you can upgrade it’s appearance. Or the audio input, or the GPS system, or anything else you don’t like!" (

2. Matthew Halverson

"What makes the SGT01 really intriguing, though—aside from the fact that Justice will sell you one for about 21 grand—is that virtually every system and component can be pulled out and quickly replaced by someone with no automotive experience. Have a sporty body on your Wikispeed car but want something more practical and sophisticated for carpooling with coworkers? Unbolt it from the chassis, lift it off, and drop on your four-door sedan body. (The carbon fiber construction is so light that two people can do the job without breaking a sweat.) The interior in the car you bought last year looking a little dated? Swap it out for the 2013 model. “Let’s say tomorrow Volvo comes out with an amazing new air bag,” Justice says. “You’d have to buy a new Volvo to get that. Even if they wanted to they couldn’t give it to all of their existing customers. Well, when you modularize a car, suddenly that’s not true anymore.

“Think about your email client—maybe you use Outlook or Gmail,” he goes on. “You don’t have to buy a new computer when you change email clients, right? Imagine if you did.” Ah, computers. This idea of interchangeable, plug-and-play components has been around for years in the computer industry, and that’s where Justice got it." (

3. Benjamin Tincq:

"From Joe’s words, “this was only possible because the car was modular”. Like modern software applications are comprised of several modules, the WikiSpeed car is a combination of 8 parts that can be dismantled and assembled back quickly.

- I don’t know whether we will need gasoline, electric or hydrogen cars tomorrow. I don’t have to know, because I designed my car so that I can change the motor in about the same time that it takes to change a tire.

This allows the team to iterate the entire car in hours, or to work on specific parts without impacting the rest of the work. For instance, as a result of feedback from their first crash test, a WikiSpeed volunteer and his son teamed up to build a better front crash structure. They came up with a better design in a few days. The whole car can transform from a race car, to a commuter car, to a pickup truck, by changing only the necessary parts.

The eight parts are bound by a modular contract, or a set of specifications ensuring that they will always fit together, whatever changes are brought to one part or another. Joe also imagines customers or third party manufacturers coming up with custom parts that sit upon the chassis, through what you might call an AMI, or Application Manufacturing Interface. This “LEGO mindset” is reminiscent of other modular manufacturing projects, such as the OpenStructures manufacturing grid community, or the Objectomie project (modular kitchen appliances).

To enable interoperability, modular manufacturing calls for Open Source / Free Hardware. On this topic, which might scare your average engineer, Joe Justice is unequivocal:

- I don’t understand people that tell me that open source hardware does not make any sense from a business perspective. The minute they ship their blueprints to China for manufacturing, clones start popping up because there is no IP protection there. Since it’s open source “by default”, why not open up everything from start, build a true community around your product and co-design it for real impact ?

With this mindset, the blueprints of the car, as well as the WikiSpeed methodology are shared freely with the community, so that anyone can start building a WikiSpeed car in their garage. Like Arduino, the only thing that is not open source is the brand – to ensure quality control." (

The Development Process

"From Lean software design we take the concept of using less stuff wherever responsible. This is based on the common sense true-ism "use less stuff" and then defined in a clear applicable way by the contemporary software team.

From Extreme Programming (XP) we take the practices of pairing and swarming. These date back at least as far as the apprentice model, but have been carefully defined to replace the need for most types of training and process documentation.

From Agile software development we take the principle of reducing cost to make change; changes in team, materials, machinery, and even goals.

From Scrum software development we take clearly defined team roles and responsibilities, which allows us to spend more time rapidly developing product with no non-working (management only) roles and only 2 meetings.

From Test Driven Development we start with failing tests then develop solutions. This allows us to quickly identify if current work is not targeted to passing a test or causing problems elsewhere in the system, which avoids waste.

From Object Oriented Programming we take Contract First Development, this is what enables the modularity of the WIKISPEED car and all of our solutions." (,-lean,-and-scrum)


  1. The Wikispeed development process videos, part 1 and part 2
  2. article on CNN Money analyzing how we do it:
  3. Forbes: ;

Agile Development

1. Matthew Halverson:

"Agile development: Justice and his volunteers pull out the car’s components, tweak them, and test new versions every seven days. Metal shelves in Justice’s garage are lined with plastic bins that hold car parts in various stages of testing. One houses an accelerator pedal attached to a series of wires that can be hooked up to an engine to develop a more fuel-efficient shifting mechanism. “People coming from other disciplines don’t think that way,” he says. “They say, ‘Well, here’s the best idea I have. Let’s try it.’ And it’s not modular, so it costs a lot to change. They kind of have one shot at it. I created a software project because I didn’t know any better. I did tests first and said, ‘Okay, this is the range of parameters that can achieve more than 100 miles per gallon. What’s the cheapest thing I can do with that design?’ ” (

2. Benjamin Tincq:

"In the software industry, projects used to take several years before the customer was able to lay his hands on the product he ordered. This often resulted in delays, cost overheads and disappointing deliverables. During the last decade, the Agile approach has been taking over software projects management, shortening product cycles from a few years to a few days. Guess what happens when you apply this to the building of physical products?

Agile is an umbrella concept encompassing several complementary approaches such as Lean, Scrum, or Extreme Programming / Extreme Manufacturing. All of these share and embody the values of collaboration, flexibility and “getting it done” from the Agile Manifesto:

  • Individuals and interactions over processes and tools
  • Working product over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

Being Lean, WikiSpeed uses dramatically less resources to produce a car than your average manufacturer.

While the latter uses a $100M CNC milling machine that would barely fit into our workshop room, WikiSpeed uses a $2.000 machine found in the average FabLab for 1/50.000th of the standard cost. While modern cars embed various costly, non-interoperable, proprietary computers to manage various features ranging from airbags, to gas levels, to air conditioning, WikiSpeed uses a single $20 Arduino circuit board.

The tools we use to coordinate ourselves at a global level are Skype, Dropbox, Google Docs, or Scrumy. All of them are free, and none of them existed 10 years ago.

To organize collaboration, WikiSpeed relies on Scrum, a very simple and effective way to coordinate a team by distributing roles and responsibilities, and enabling the generation and circulation of new ideas. In Scrum there are three main positions:

The Product Owner is the person who has the clearest vision of what should be the outcome of the project. This can and does change on a regular basis - and benefits from regular feedback. The whole team relies on the Product Owner to set this vision.

Self-Organizing Teams deliver product increments during each iteration cycle (or Sprint). All the work is done in pairs, to enable knowledge transfer from experts to newcomers, drastically reducing the need for documentation and training, and thus saving time. This approach enabled WikiSpeed to build a car in 3 hours backstage at the Agile Alliance conference, even though relying on people who had never built a car before. The Scrum Master is a servant leader, helping the team to reach maximum efficiency by guiding them through the application of Scrum principles, while keeping them away from distracting issues. Joe compares it to a coach who brings water to an athlete when needed.

The entire project management system of WikiSpeed is comprised of a giant wall of sticky notes, called Kanban. This board maps all tasks necessary to run the project, from marketing to hardware development, to delivery or finance. Visualizing the task backlog allows any team member to get an instant grasp of what has been done (or pending review), what is happening now, and what is yet to be done, thus avoiding hidden delays. They know exactly how long a task will take, how much it will cost and what features are expected.

All team members pull from a unique backlog which is open to anyone (even the public), and all required tools are at hand in a WikiSpeed garage, enabling anyone to jump in and take ownership of a task at any moment. This includes personal objectives of the team:

- We found out that when the team was happy, we were able to complete up to 10 times the amount of work we were delivering when the team was just feeling okay. For this reason, we treat our team members as customers. Making them happy is one of our top business priorities, and tasks that support the team morale are prioritized with other tasks in the same backlog." (

The Five Characteristics of the WikiSpeed Development Methodology

Steve Denning:

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.

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 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.”

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, 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.

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." (

Extreme Manufacturing

Benjamin Tincq:

"Treating hardware products like software by applying modularity and agility principles to the physical world, gave birth to a revolutionary process: Extreme Manufacturing (XM). The name was coined after Extreme Programming (XP) software development by Joe Justice and Marcin Jakubowski, founder of Open Source Ecology. OSE has been developing a set of 50 open source industrial machines capable of building a modern civilization from scratch, and is now using XM after Joe gave an Agile crash course to Marcin earlier this year.

The Extreme Manufacturing approach enables maximum velocity and minimum cost of making changes by adopting multiple short development cycles rather than a long one, in order to recieve early and regular user feedback. While standard development cycles in the manufacturing industry take several years, WikiSpeed has 7 day development cycles – called “Sprints”.

Applying the mindset “working product is the deliverable”, XM applies Test-Driven Manufacturing: before any work is done, the team defines the tests for quality goals on criteria such as road-legal safety, comfort or efficiency. Passing the tests while meeting the vision of the Product Owner validates an iteration of a working product. When tests are too expensive to carry out every seven days – for instance, road-legal crash tests – WikiSpeed replaces them by computer simulations, of which the accuracy is refined by real data whenever they can afford a crash test.

We practiced XM during the workshops in Rome, Barcelona and Paris, where Joe guided a bunch of improvised Product Owners among us through the process:

1) Defining the product vision (role of the Product Owner)

2) Crafting user stories to make the vision tangible for everyone

3) Defining the tests required to validate each user story for the product

4) Defining the tasks that need to be done to iterate the product on each user story

5) Prioritize the user stories (features) : some may need to come before others

6) Planning the demo time to showcase the new current state of the product

7) Planning the work time (including tests) ahead of demo, and assigning tasks

The last two steps basically consist of “Planning a Sprint”, in other words: figuring out the leanest thing that can be done to successfully iterate the product before next week. For this purpose, WikiSpeed hosts a 1 hour weekly standup call with the global team which is distributed across several countries. A short YouTube video of the current state of the product is shown, then people assign themselves tasks; each garage relies on its own Kanban board to optimize its workflow during the week, and all boards are all synced on a weekly basis with Scrumy, a free online tool for backlog management.

A recurring question from workshop participants was: is this Extreme Manufacturing or Extreme Prototyping? In other words, how does it scale?

Firstly, scale is not relevant to WikiSpeed. Cars are produced on-demand, when a client offers to pay for it. This implies almost no capital investment upfront to produce a SGT-01 commercial unit, which costs $14K for a $25K price tag. The new WikiSpeed commuter car will be sold around $17K, and Joe is already thinking about a future $1.000 “mini car”. R&D being carried out along the way, its costs are supported both by sales and donations made via the WikiSpeed homepage.

WikiSpeed does not grow, it distributes itself. This development model is pioneered by Open Source Ecology and puts the open, independent replication of its business model at the core of its operational strategy. Shared knowledge and radical collaboration allows economies of scope rather than economies of scale, and quality is ensured by common tests and a shared kanban.

The Distributive Enterprise model is an expression of human-centered economics of collaborative production, where people regain their autonomy in a complex world.

To distribute even more quickly, WikiSpeed members are currently practicing to build cars within a rectangular space marked on the ground. By achieving this, micro factories could be encapsulated within containers, and shipped to where there is demand for local production. Once the work is done, a micro factory could be moved to a surrounding area to meet new demand." (


"How many sales have you made so far, if you can reveal this?

We have had team members build cars that they use before, and our very first cash sale occurred in December 2011. ... we won’t go out of business if we don’t have any on the road, and we are equipped to produce more than 100,000 cars within the next three years if the market place is interested. ... Using the Scrum framework to run our teams with Lean principles lets us keep the rapid problem solving of focused small teams as we scale out. We’ve recently grown in Vietnam and Spain ... There has been strong multi-national interest. The Swiss and United Kingdom markets have been especially vocal, and recently the Vietnamese and Indian markets have folks expressing strong interest as well. We are currently looking for a location to produce vehicles in Europe and Asia in addition to our capabilities in North America. A best case scenario would be distributed, collaborative multi-national manufacturing and R&D. Our automotive goal is to produce products desirable in each market, with top safety and efficiency performance, and total cost of ownership similar or even below current economy commuter vehicles for that market. Of course that’s a dream goal, but in team WIKISPEED we seem to keep making unreasonably quick progress towards that goal, and have prototypes for sale now in the U.S." (

Is the car street legal?

Joe Justice 08/12:


"Yes. we have two prototypes with license plates on them and insured through Progressive and we've gotten quotes from USAA and Gieco. We drive them around just like normal cars. We are building two cars for customers now, that they will drive around just like ordinary cars, but about twice the efficiency of a Prius, and quite a bit faster too when they do decide to put the pedal down to the floor."


"We have road legal cars on the road now ( and could probably have one to you buy Christmas. These cars are prototypes though. Ferrari would call you an "Owner Test Driver", we would call you a "Lead Customer". They are very simplistic and the only creature comfort is an iphone dock in the dash and a stereo." (


"an interview with Joe Justice, who is a founder of the organization, by Jake Richardson.

What prompted you to begin building your cars in the first place?

I was passionate about efficiency and safety, and had a deep curiosity if safe, reliable, quick cars could be inexpensive. It seemed to me that some very high end sports cars had about the same amount of similar materials, or even less, than some very inexpensive commuter cars, and people might be paying more for just putting the material in a different place. I wanted to know if that was true.

Because of the modular design, and the self-directed nature of your work, it seems a person who bought one of your cars would be someone with a mechanical interest and enough mechanical knowledge to work on the vehicle themselves.

We aim to make the cars self-explanatory. If our web browsers, or even smart phones now, come with a manual that is considered a usability failure. Our car modules are designed to be switchable by anyone who is comfortable changing a tire; allowing them to choose a gasoline or electric drive train, or a pick-up-truck or a convertible, and switch their WIKISPEED car between all of those things in about the time it would take for them to put snow tires on their car.

Did you design the vehicle with a do-it-yourself audience in mind, or did the modular design result from something else?

The modular design resulted from needing to test many ideas quickly at a low cost; we needed to be able to test many different engine types without building the rest of the car each time and many different safety systems without building the rest of the car each time. I had an aspiration of enabling do-it-yourself folks through usability, but that was secondary to the driver of needing to compete with teams wielding multimillion dollar research budgets.


How many people volunteer their time to work on the cars?

We have more than 120 team members in 10 countries. They all volunteers, working nights and weekends. They don’t all work on cars though. WIKISPEED is involved in rapidly solving problems for social good. Ultra-efficient cars are a social good by our definition, and many team members rapidly prototype and manufacture those cars. We also are involved in vaccine delivery to wipe out polio and reduce cases of rotavirus, and work on low-cost medical centers and environmentally sustainable housing for developing communities.

How many of your cars do you imagine can be on the roads in the next three years?

Using agile methods, we opt not to predict and instead increase the pace at which we can take advantage of opportunity. So I’ll answer that by saying we won’t go out of business if we don’t have any on the road, and we are equipped to produce more than 100,000 cars within the next three years if the market place is interested.

Will you continue expanding, or would you prefer to keep your organization small?

We grow as fast as responsible. Using the Scrum framework to run our teams with Lean principles lets us keep the rapid problem solving of focused small teams as we scale out. We’ve recently grown in Vietnam and Spain, and will continue to do awesome anywhere we are able.


Has there been any interest from people in other countries to build and drive your type of car abroad?

There has been strong multi-national interest. The Swiss and United Kingdom markets have been especially vocal, and recently the Vietnamese and Indian markets have folks expressing strong interest as well. We are currently looking for a location to produce vehicles in Europe and Asia in addition to our capabilities in North America. A best case scenario would be distributed, collaborative multi-national manufacturing and R&D. Our automotive goal is to produce products desirable in each market, with top safety and efficiency performance, and total cost of ownership similar or even below current economy commuter vehicles for that market. Of course that’s a dream goal, but in team WIKISPEED we seem to keep making unreasonably quick progress towards that goal, and have prototypes for sale now in the U.S." (


What the software Industry got from the car industry is returned with interest

Charlie Rudd:

"It is well known that Scrum and XP practices, the cornerstone of Agile and Lean software development, were inspired by lean manufacturing methods, most notably as applied by Toyota. Since their introduction approximately fifteen years ago (Kent Beck’s Extreme Programming 1999, Scrum 1995, Agile Manifesto 2001), Agile methods have resulted in dramatic productivity gains throughout the software industry.

And along the way something else happened. As Joe explains it, since the design and production cycle-times for software development are typically much shorter than they are for manufacturing, respective incremental process improvement has often progressed at a more rapid pace. Consequently, there are instances where Agile and Lean methods in the software industry have surpassed their counterparts in manufacturing, the industry from which the originated. In addition, just as the software industry gained insights that led to huge waste reduction and quality improvements by applying the manufacturing metaphor to software development, so now is Wikispeed achieving transformational results in the automobile industry, by applying leading edge software design and Agile methods to car design and manufacturing.

In short, the Lean methods that crossed over from automobile manufacturing and transformed software development are now (through Wikispeed’s efforts) crossing back over and transforming the car industry (again).

The rapid innovation displayed by Joe and Co is a great example of, as Stephen Johnson puts it, “Where good ideas come.” As we recently discussed, Stephen Johnson makes the case that through the ages, most important innovations were the product not of single-minded geniuses but the byproduct of human collaborations.

Agile values are founded on the notion that innovation happens through collaboration. Stephen Johnson states this idea succinctly: “Chance favors the connected mind.” Wikispeed demonstrates to a broader audience what we in the software industry how have known for some time: Agile methods accelerate innovation." (

How Open is Wikispeed?

Joe Justice:

"The goal of the modularity- that the car is made of 8 interchangeable parts- is that folks can modify or evolve their car. We've posted CAD of one version of all 8 assemblies in Open Source to help folks modify or design their own. We warranty modules we make, and will test modules other people make for a nominal cost if they want us to. If modules someone else makes pass our tests, we can offer our warranty on those and sell them through our store in exchange for a % of sales. So modifying modules or inventing your own can be a revenue stream for you and us too." (

Why WikiSpeed refuses Venture Capital investments

Joe Justice:

"Aptera took Venture Capital, a few million dollars worth, in exchange for the VC firm having the right to cancel the project and retain all rights and IP if they got cold feet. These terms are common from VC. While we were in the X Prize with them, the VC firm fired the original team of engineers (7 of them I believe) and by contract those engineers are forbidden to work on anything related to the Aptera project or its technology ever again. The original engineers had personal loans that in aggregate were over a million dollars in order to produce the first working prototypes that attracted the VC in the first place, and now those engineers had no job- no way to continue working on their passion and area of expertise, and still had these massive personal loans. the only group that was paid were the VC, which then liquidated the assets of the company ( Many revolutionary companies are looking for VC to help them "make it big" or otherwise take outside debt and then struggle with the reports, predictions, and process imposed on them by the larger non-innovative firm until they are smothered and go under, or are simply liquidated outright for short term gains that seem to make sense to the larger firm who is using cost-accounting. WIKISPEED has no debt- even if we don' sell another car for another 3 years we will be here, innovating and iterating our products.

I'll clarify, although we met the Aptera original engineers and their VC, I wasn't in the Aptera or VC firm board room during the events above. This is my take, from what I observed in the news and from team Aptera themselves. Those original engineers are probably the best to ask, but are likely legally bound by a gag-order with further financial penalties if they speak about certain parts of the business deal. I'm so glad we've open-sourced a version of our car to the public domain- no matter what silly contract we sign that will always be out there. It's like an insurance policy that the project has produced something the world can choose to use." (

How is WikiSpeed funded?

"We have micro investors at $10 a month (see the right-hand side of and that's what drives almost all of this. At that level it's too much administrative overhead to authorize stock, so instead we have an agreement that if we make it at recognize profit, we repay them, and if we can afford interest, we repay them with interest. This makes sure we won't laugh all the way to the bank and leave a supporter in the dark. Then we have traditional investment at $10k or bitcoin equivalent and on up. We offer them a promissory letter or convertible debenture- standard Angel investment documentation. What we do though is investors never retain the right to liquidate the company and keep IP, this protects us from what happened to Aptera. email [email protected] to rock with us.

So far every investor has declined signing any promissory note with us- they have simply said "when you profit and it is sustainable for the company please repay me with interest." The world is awesome, I never expected this level of altruistic support from the global community." (

More Information

The WikiSpeed Development Methodology

  1. The Wikispeed development process videos, part 1 and part 2
  2. article on CNN Money analyzing how we do it:
  3. Forbes: ;