Team Wikispeed

From Open Source Ecology
(Redirected from Lessons Learned)
Jump to: navigation, search

Contents

[edit] TED talk:

[edit] Team Wikispeed

Wikispeed is a team of volunteers that formed around the work of Joe Justice as he competed in the Progressive Insurance Automotive X-Prize. His greatest innovation was applying lean/agile/SCRUM software program management to hardware, specifically the iterative design of a 100+ mpg passenger vehicle.

The dramatic success of Team Wikispeed's activities pretty much demands listening to what Joe has to say.

For clarity, and because I wasn't clear on this point until I researched it, it is important to point out that Team Wikispeed was eliminated in the first round of on-location testing at the X-Prize competition. "Without even bothering to look at the finite element analysis and computational fluid dynamics Justice had brought as proof of his design’s validity, the inspector rejected the car outright. Justice felt like he’d been slapped in the face. “It was like fireworks going off in my cheeks,” he says. “This is something I’ve had a whole lot of design input into, and this one person is saying, ‘This isn’t good enough.’...Rather than spending hours pulling apart the SGT01 to get to the suspension, the team simply unbolted the body, removed the suspension module, and began fabricating a new one. They got it done, too, just in time. The only problem was that as they finished, minutes before the deadline, Justice and another team member cut a wire in the electrical system. The car wouldn’t start, and Wikispeed’s run for the X Prize was done. They finished in a tie for 10th in their division." article

[edit] General

  • First functional prototype built in 3 months.
  • Existing manufacturing processes are slow to change because they're exceptionally expensive to change.
    • Major manufacturers typically operate on 10-25 year design cycles.
  • Wikispeed uses 7-day design cycles.
  • Iterated a process that brought the cost/time of a full structural carbon fiber car body down from $36,000/3 months to $800/3 days.
  • Went from 1 guy in his garage to 100+ volunteers, in 8 countries, and a production-ready car in 6 months.

[edit] Specific

  • Modularity.
    • Every system in the car can be separated from every other system as quickly and easily as changing a tire.
  • Test-based.
    • The customer-value standard, and the test for it, is designed BEFORE the solution is designed.
  • Use less stuff.
    • The parts for the frame of the car can be built with stock 4" aluminum tube, an $80 band saw, and a used-kit-built CNC milling machine.
    • Reduce costs in tooling, machinery and complexity wherever possible. This allows for improvements to be incorporated into the design immediately because there are so few sunk costs.
  • Distributed, collaborative teams.
    • Use free online tools.
  • Morale for velocity.
    • It's not additive or subtractive, it's a multiplier.
  • Work in pairs.
    • Put a newbie with a pro and the newbie learns AS the job gets done. This eliminates time devoted to training. The pro gets help, the newbie gets hands-on experience.
    • Also eliminates the need for most types of documentation.
  • Visualize workflow to eliminate any time spent not creatively solving problems.

[edit] Keynote American Council of Engineering Companies


[edit] Summary: Scrum Gathering in Seattle


This is a summary of the talk:

[edit] History

  • Initial Goal: build the lightest chassis.
  • Share on the blog
    • asked silly and nerdy questions
  • passes technical deliverables for the X prize.
    • became finalist to compete with 136 cars, most of them funded by millions of dollars
    • iterating the car at the race track, inspired a higher driver of a team competing against WikiSpeed to spend a lot of time hanging out with the Team.
    • got 10th place.
    • Received several tens of thousands of dollars in road legal certification and testing.
    • Press
  • Team grew: 56 members in 6 countries.

[edit] Learned

  • Contract-first Design: by Modules.
    • Suspension - changed for 10 minutes - adjustable in caster, tow?, camber, wheel-base and track, individually per wheel.
    • Interior in the race car version - aluminum bathtub that lifts out. The 4-seat interior for the contest can be easily exchanged with the 2-seat interior for testing.
    • Engine - at the back of the car. The entire Power Train, with its transmission, fuel tank and cooling system can be rolled out in the time it takes to change a tire while it is running. This let us have one engine on the test bench being evaluated and another engine in the car doing testing, bring the car, switch the engines, test the other one - able to develop and test engines independently of each other.
    • Chassis - all other modules connect to. Side, front, front impact. Peak stress. Our entire car absorbs the weight. 5 star crash rating equivalence.
    • Car Body - cut foam with CNC machine from a CAD design, sand it, (70 volunteers in 6 countries in multiple locations)
      • from Structural Carbon Fiber (normally used in airspace and exotic automobiles) was really expensive, but the material itself wasn't expensive, but the knowledge how to use it was. So Joe Justice went to composite school for few weeks and then they built the carbon fiber body for $800 in 3 days (body would cost $36,000 in 3 months time with traditional manufacturing techniques).
  • Went to North American International Auto Show - put WikiSpeed on the main floor between Ford and Chevrolet. Met the creator of the car body, Rob Mohrbacher of http://mohrcomposites.com from Germantown, Maryland.

[edit] How - Agile and Scrum

  • Weekly stand-up meetings
  • prioritized backlogs
  • and demos

[edit] Tools

  • FreeConferenceCall - for stand-up meeting
    • What I did, what I will do, what is blocking me
  • Skype free
  • Google Groups - up-to-date daily, pictures, updates, backlog from a Google Doc
  • Google Docs - documents collaboration
    • Trust the Team. It is versioned - who changed, what when. Can be reverted.
  • Avoid planning more than 2 weeks out - we learn so fast that things change what we will do next
  • Facebook and LinkedIn for team and public status updates.
    • don't repeat information sharing.
  • DropBox and SkyDrive for sharing large files
  • Youtube to share videos
  • Scrumy - online project management tool loosely based on Scrum.
  • Linoit.com - for backlog http://linoit.com
  • LibreCAD - open source CAD for Windows, Apple, Linux
  • Email Lists
    • Always Reply All to approximate being in a Scrum room. Allows distributed team to skim emails and be appraised of the current state of the project.[1]

[edit] Principles - What worked well

  • By minimizing cost of making change we innovate quickly. Changes in team members, changes in goals, changes in machinery, changes materials.
  • By loosely coupling modules, we make changes in parallel.
    • E.g. split the car into its component modules. Have people working on the suspension system, drive train, emission system, headlights, electronic control mechanism, all in parallel.
    • Modularity: Interior module, Chassis, Pedal Plate, Front Crush Structure, Suspension Module, Engine, Transmission, Fuel System, Emission System, Fuel Injection System, Breaking system.
    • When we started designing the car, we didn't know how the chassis would end up being like, we didn't know what type of drive train, type of suspension, we will be using. So what we wanted to do is to reduce the cost to make change between those parts. So we architect a contract - the way these modules will talk to each other and hold together in a structural way and the way they communicate.
  • By working collaboratively and in shared space we unblock quickly.
    • E.g. every time we had a blocking issues the team was able to bulldoze it that same day. Pairing and Swarming worked very well.
  • By first automating test we quickly know if we improved. (Test-driven manufacturing)
    • Example
      • 100mpg on a highway cycle
      • etc.
    • When changes came we quickly knew whether we moved entirely forward, or moved forward on a few fronts, but actually backed on to other fronts. So we had to quickly kill work that would have been actually damaging and thus we were moving forward very fast.
  • Test our success criteria - everyone cared about the metrics!
  • Team morale (motivation) is a multiplier for velocity.
    • Make sure people are never or rarely frustrated and that they get to share successes. Celebrating every iteration.
  • Team trust is empowering
    • Question access restrictions on documents, avoid group subjugation. Empowerment keeps velocity high.
  • Single Backlog - all prioritized tasks are visible and in one place

[edit] Modular Inventory

  • Whenever possible tools are visually next to their consumables.
  • Fewest possible categories always inside of each other (See everything from where you stand)
  • Minimize time spent doing anything but creative problem solving.
    • E.g. - So it’s not just less meetings, less paperwork, but in our case it is that we have a transparent bin that has screw drivers. And every screw driver is in there. There is not a screw driver anywhere else. If someone needs a screwdriver, it’s at a central location not more than twenty steps away. And it’s a clear bin so that they can see if what they need is inside before they even get there. In fact they can see what’s in there across the room and it is labeled. In software teams we would do the same thing with templates, we would do the same thing with test driven development, we would do the same thing with class naming and interface design, so people understand what goes with what. (See references)

[edit] From Software

  • Agile - reduse cost to make change and iterative development
  • Test-Driven Design - tester and manufacturing
  • XP - pairing and swarming
  • Scrum - almost everything. Clearly defined roles and responsibilities.
  • OOP - clearly defined modules, classes and interfaces
  • Kanban - work in progress limits, not to overload people.
  • Contract First Development - Define precise and verifiable component interface specifications.

[edit] Wikispeed Future Developments

  • Making a family car
  • Developing a truck


[edit] Wikispeed Tenets

  • If I give money, time, cookies or supplies to WIKISPEED, and WIKISPEED is profitable, WIKISPEED will pay me back the value of what I put in plus interest commensurable with their level of success. I can choose not to accept repayment, but WIKISPEED will make reasonable attempts. This is based on value, not quantity (in hours, pounds, dollars, or word count).
  • If I give money, time, cookies or supplies to WIKISPEED, I have no claim on WIKISPEED or its decisions or what it does with my resources after I give them. Other than tenant 1 above.
  • If I share my best thoughts and work with WIKISPEED, WIKISPEED can use them at no cost, and I retain rights to re-use or protect my ideas unless I opt to bequeath them to WIKISPEED or the Public Domain.

[edit] Wikispeed Principles

  • Equitable Distribution of Wealth.
  • Avoid profit from waste (e.g. buying a competitor to shut them down). Grow profit based on visible value.
  • If we focus on profit over value to customers, we will obtain neither. If we focus on visible customer value over profit, we will profit.
  • Use less stuff (Lean) wherever responsible.
  • Make decisions at the last responsible moment, this is when we know the most. but be careful not to wait until it is no-longer responsible. We never make a decision before we have to just to "get it out of the way."
  • Start with the minimum useful solution (porters on roller-skates over a mail-chute), then iterate aggressively to improve visible value and efficient sustainability of the solution.
  • Morale is a multiplier for velocity.
  • We trade estimated future states for knowing the most about our current situation and make changes quickly (Agility).
  • Trust our team. this avoids a culture of CYA, which slows down innovation and kills morale. e.g. a company which spends $6 million on intranet security allowing employees to not see documents above their salary level to avoid leaking potentially libelous documents, instead of $6 million having interns and attorneys aggressively helping all levels of the org identify documents that are potentially libelous, which are usually a sign of unethical action, coach them on how to rectify those situations ASAP as a company with help from all levels of the company).
  • Replace a document with a conversation. Instead of writing a specification document, have a white boarding conversation in a room where as many other team members as possible can over-hear. Take pictures of the white board when you are done and email the team. Documents have a maintenance cost.
  • Produce self-documenting work- a car with a navigation that teaches you how to use it instead of a manual. Can you imagine if Internet Explorer still shipped with a manual? We expect it to be self explanatory. Documents are a hidden expense, requiring editing and re-write to match the current version.
  • Try not to do something alone, pair with another team member whenever responsible. This aids in knowledge transfer and avoids requirements for documentation.

[edit] References

  • CNN on Management a la Wikispeed - [1]
  • [2]
  • [3]
Personal tools
Namespaces

Variants
Actions
Navigation
Open Source Ecology
Toolbox
Topics