In This Video

Gene Kim has been studying high-performing IT organizations since 1999. He is the author of the highly acclaimed “Visible Ops Handbook,” “The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win,” and was founder and CTO of Tripwire, Inc.

Gene is passionate about DevOps, and believes that it is the logical and inevitable continuation of the journey that the Agile movement started in 2001. The DevOps movement shares many of the goals, culture, values and ideals of the Agile movement, but requires a degree of collaboration between Development, QA and IT Operations until recently has been all too rare.

He will be presenting his findings from an ongoing study of how high-performing IT organizations simultaneously deliver stellar service levels and deliver fast flow of new features into the production environment. To successfully deliver against what on the surface appear to be conflicting objectives, (i.e. preserving service levels while introducing significant amounts of change into production), requires creating a highly-coordinated collection of teams where Development, QA, IT Operations, as well as Product Management and Information Security genuinely work together to solve business objectives.

Gene will describe what successful transformations look like, and how those transformations were achieved from a software development and service operations perspective. He will draw upon fourteen years of research of high-performing IT organizations, as well as work he's done since 2008 to help some of the largest Internet companies increase feature flow and production stability through applications of DevOps principles.

Transcript

Joe: I'm Joe Justice. I am a business process coach and consultant with Solutions IQ. That's my day job. Nights and weekends I volunteer my time to be team lead of team Wikispeed. We built a fast, affordable, safe, ultra-efficient, fun to drive car and the first working prototype of it to achieve more than 100 miles per gallon was built in just three months. Deloitte Consultancy has a think tank called Center for the Edge. They're set up to study the radical changes of business in our time. One of the trends they noticed is that Fortune 50 companies now have the shortest life span ever in recorded history, and they're trying to figure out why. To talk about how what team Wikispeed is doing, it seems to be a larger trend that everyone in this room is taking advantage of by being part of the Agile community. I'd like to introduce Christopher Gong from Deloitte Center for the Edge.

Christopher G.: Great thank you. I'm absolutely thrilled to be here as part of the Agile 2012 conference and this is my clicker, next, awesome, great thank you. I've been working with Joe over the last 6 months. We found him actually from his Ted talk online, and we were absolutely inspired by the different techniques and tools that he's been using. The Center for the Edge is a Silicon Valley based think tank that looks at the fundamental shifts in the economy and the marketplace and interprets what that means for the CEOs and C-suite of Fortune 500 companies. I'd like to share with you quickly two trends that we've been following very carefully.

Well, Shift Happens, this is the first trend. The rate of change and progress has been growing exponentially for the last 40 years, and you can see that here. We've developed a technology performance index which looks at the cost of computing, the cost of storage, the cost of connectivity across all industries. You can see very clearly that the rate of technological improvement has been growing exponentially. Given this unparalleled growth, you would expect a corresponding leap in productivity from our corporations and from our institutions, but in actuality we're seeing something very different.

We're seeing a decline in performance across the board in many of our key institutions across the Fortune 500. We measure that by the return on assets, which is one of our key performance indicators. The trillion dollar question is, why is that? What is preventing our institutions from reaching higher levels of efficiency? We believe that part of the problem lies in the very structures and cultures of the institutions we have, many of which are hand-me-downs from the Industrial Revolution era, which was a time of slower change. These institutions were designed to maximize consistency through tools like centralized planning, rigid hierarchies, and inflexible procedures. These are great for times of predictability, but as we all know here, we've moving into a time of unparalleled changed and unpredictability. We're seeing that rate of change is only increasing.

What does this mean? It means essentially that we have 19th century institutions trying to solve 21st century problems. Even when you give these institutions 21st century tools, they have been struggling. Here's what that looks like. Boo. It means that we have corporations that are ill-prepared for the disruptions in the marketplace. It means that our schools and other important social institutions are falling behind. Don't even get me started on this one. It means that our governed procedures are falling woefully behind as well. Fundamentally, if we want to solve the problems that we as a society are facing today, we need to find fundamentally better ways for our institutions to solve problems.

Let me show you the state of progress in the auto industry, which is what we're talking about today. Here we have the Honda Civic and it's progress over the last 6 years. You can see that there have been no fundamental changes to the form of the vehicle, and only incremental improvements in the miles per gallon. We've increased two miles per gallon in the last 6 years. In contrast, let's look at team Wikispeed. In three months they built their first prototype, which got 100 miles to the gallon. This is the car they entered into the X-prize competition. Then in three years they've gone from this, to this, to this. The question that we as a center were looking at was, how does a guy in a garage with pockets change for funding develop a car in three years that is aesthetically pleasing, that is high performance, and gets 100 miles to the gallon?

I've had the opportunity to work with Joe and his team in the team Wikispeed shop in Seattle several times over the last few months. Joe will walk you through in greater detail his processes and his methodology, but let me walk you through a few of the things you'll notice first when you walk into his shop. The first thing is that Wikispeed is staffed entirely by volunteers. There are over 100 people now spread out across the world. The team uses a variety of tools, everything from conventional weekly phone calls, to con-bon boards, to social media to coordinate the efforts of these teams. Some of these volunteers are highly specialized, they're experts in their fields, but many are not. Many are just amateurs who are motivated by the chance to work on a project that they think is inherently meaningful.

The Wikispeed methodology is able to incorporate these people very quickly no matter where they start to help them be part of the process. One of the most interesting things that I saw in the shop was Joe's C&C machine, which is the one on the right. It cost him $2,000 on Craigslist. You can compare that with the C&C machines that major auto manufacturers use, which is on the left, which costs about $100 million dollars. Obviously there are some differences in the capabilities of these machines, but Joe has been able to compete with the design teams of major manufacturers at one fifty thousandth the cost. Another round of applause for that.

You'll notice in the shop how easily that the team comes together around these tools and processes. It's a very natural process and sometimes you forget that many of the tools that they're using weren't available at this level until only 5 or 10 years ago. The more time you spend with the team, you realize that it's not so much about the tools they use, but the better practices and the better cultures that they've created around these tools. It's not that Wikispeed uses a con-bon board, it's that Wikispeed has created a culture that promotes enthusiasm and draws people in who are eager to participate in solving problems. It's not that Joe uses social media, it's that he's committed to radical transparency and openness in a way that compels people from across the world to participate. It's not that they have a C&C machine, but that they are committed to rapidly iterating on their vehicle, which they do every 7 days.

It's the combination of these tools and these practices that have created the results that team Wikispeed has been able to achieve. Seeing the way these tools have been applied in the auto industry begs that question, how much better would the world be if we were able to apply these agile methodologies and Joe's methodologies not only in the auto industry, but across the economy to solve all of the problems that we're facing as a society today? As Joe walks you more through this methodology, and how that applies to different clients and situations that he's worked in, I want you to think about just that. I would invite you to think about where we can apply these methodologies and these tools to make society a better place.

Joe: That's so much Christopher. Now Christopher's day job at Deloitte Center for the Edge, and my day job at Solutions IQ are basically competitors. What we found though, is that there's a trend, which I'm going to call and explain as agile, agile project management, agile delivery, that seems to be disrupting all industry now. It's already disrupted software. I just looked through Google finance again and looked at the top IPO generating companies of all-time. If I look at the tech companies, where Agile already has a strong foothold, all of the top 10 have Agile teams or are all Agile companies. Agile is dominating in returns and in investor confidence right now in tech and that trend is beginning to happen outside of software companies.

If we look at manufacturing today and hardware development today, we see it looks almost identical to the waterfall delivery model of software teams we used to work on, where we have the best products we can buy today being the best thought of what a product designer thought we might want 10 years ago. Porsche announced this year that the current generation 911 will be with us for the next 14 years. Parts of that car were designed over the last three years. Parts of that car were designed over the last 10 years. That means it will be possible to go to a Porsche dealer and buy a new Porsche 911 and have it be the best thought of what their engineering team thought you might want 25 years ago. New software teams, Agile software teams, lean software teams, con-bon teams, XP, and we'll now call something XM, which is extreme manufacturing and it's the same thing you already know, but applied to building physical things.

We see these teams iterating much faster. We see when the term scrum was first published as a book that we could take home and learn and apply outside of Mike Beetle, Ken [Schwaber 00:10:50] and Jeff Sutherland's business in 2003, Agile project management with scrum. We saw recommendations of three months sprints or faster, with a preference towards the shorter time scale. Now one week sprints are becoming the standard, and in mobile application companies where competition is very high, we see continuous delivery becoming the norm. Team Wikispeed, to my knowledge, is the firs automotive company, registered automotive manufacturing company, to have 7 day iterations. That's very different than a 2 1/2 year minor model change cycle, and a 5-7 year major model change cycle.

The reason existing manufacturing changes slowly I believe is the cost to make change is so high. Here we see a door mold being stamped at Tesla's model S factory in California. Unfortunately, they used the traditional manufacturing methods. They have a game-changing product but it is also going to change on multi-year cycles because of this. This door dye, where they're stamping a door for the model S, is milled, engineered, and placed on a multi-ton noematic press and each of the those door molds cost more than 10 million dollars, by the time you factor in the engineering time for that door mold, and then the machining of it. That means if an engineer had a better, safer, more orogenic, less expensive design for that door tomorrow, they would want to wait 10 years to first amortize the cost of the existing door mold, to pay off the existing door mold before making that change. Existing manufacturing changes slowly because they've chosen tools that are expensive to change.

In team Wikispeed we had to try a different approach. I have a software development background, like most of the people in this room. I was used to thinking I can't design a whole solution at once, it's too big to even have in my head at once, and I had to split it up into pieces, into modules. Object oriented programming says, first have a clear interface and then have classes, and then you can change those classes and you have hot, swap-able, loosely coupled modules. That's exactly how we engineer the car. The car is built in 8 parts, or modules, and they switch independently. This means we can roll out the gasoline engine and roll in an electric drivetrain, a bio-diesel drivetrain, a methanol or ethanol drivetrain in about the time it takes to change a tire. This means we change the entire car body from a convertible to a pickup truck. This lets us change quickly and this also gives a level of flexibility to our customers that they've never had in the automotive space before.

The team works using Agile, Lean, Scrum, Con-bon, XP, and what I'll call XM but it's really just exactly the same process, and we've taken the word software and changed it to customer-visible value. Here we see the team doing a swarm. They've just taken the car apart into it's 8 pieces and now they're putting them back together. This picture was taken at the X-prize. The X-prize was a 10 million dollar prize purse to see if it was even possible to build road-legal cars that were safe, that achieved over 100 miles per gallon. Nobody knew if it could even happen. 136 cars entered from all over the world and we tied for 10th in the mainstream class. We didn't win. We didn't get the 10 million dollar prize, but we came in ahead of more than 100 other cars, including cars from companies like Tesla, MIT, and Tata Motors in India.

I think the only reason this was possible is because we used Agile project management and Agile delivery, and we had a modular car. When other teams were figuring out their planning phase and saying, "How much is this going to cost? How long is this going to take? What materials are we going to make it out of? Who's going to do it? Who's our team?" We just built tests, test driven development saying, "We need to pass the side impact test. We need to pass the offset funnel test. It needs to achieve more than 100 miles per gallon on the EPA UDDS city driving cycle." We had failing tests and then said, "All right what's the fastest, leanest thing we can build that will past this test? How about this test?" And never asked ourselves, "How much is this going to take? How much cost will this be? Where will we build it? What materials will we build it out of? Who will do the work?" Instead we just had clear tests to know when we were done and iterated as rapidly as possible on those.

We a Scrum master a servant leader. They are a process steward, but more importantly they're there to do anything they can do to accelerate the speed of the team. They'll hand someone a screw driver if they see they might need it. They'll run and get coffee. They'll run and get lemonade. They'll change the lights. They'll see if they can adjust to temperature. Anything they can do to increase the velocity, the sustainable velocity of the team without being in their way, and they're a process steward. By the time a team has done 10 daily stand-ups, they're calling for the daily stand-ups themselves. It only takes then a very savvy coach, Scrum master, who studied some team psychology to be able to add additional value.

This is what a vertical slice of a car looks like in our world. Thank you guys very much. We had to have something on the road quickly to know if we were on the right track, and so we could iterate. That meant just like in software where we'll have the user interface layer, the business layer, the data layer, our end-tier design if that's how we're doing it, we had to have a complete version of something that's road legal to begin testing. We were able to develop this in three months. When we compare that to the design and development cycles of traditional automotive manufacturing, the difference is two orders of magnitude and time. Two years later we have this. I hope what you're able to see is that these methods not only might apply in broader industry, but that they might be able to accelerate the pace of new product development extremely, and that they might even yield products that people might want to use.

What I hope you guys are starting to get out of this is that everyone in this room is now not just on the avant-garde of the transformation of the software industry. We might be, everyone in this room, on the transformation of what hardware development, manufacturing, entertainment, the financial sector, energy and oil, government might be doing. It's because it's predicated on the speed and quality that happens when we use all these processes together. You've been in sessions on XP and here's your first on XM, if this is XM. You've been in sessions on Scum, you've been in sessions on the Agile umbrella that encompasses some of these methodologies, or most of them depending on how you think about it. You've been in sessions on Lean. Those same tools might apply to everything we do, and we might be seeing if the big shift is correct, the largest change since before the Industrial Revolution. Not everyone here might agree with Steven Denning, I do, when he says, "The Agile transformation is a larger shift than the Industrial Revolution." We'll find out. We're on the cusp of that right now.

Here's one of our Con-bon boards. This is at our Seattle, Washington shop that we've since outgrown. Here we are talking to the team about what we're going to do today. We're going through tasks like sand down car body two, take the Discovery channel for a test drive, swap out engine module B4, reroute exhaust in engine module V2. These are hardware manufacturing tasks. The tools we use to do this are all free and none of them existed 10 years ago. Most of them didn't exist even 5 years ago. Applying these methods with a radically distributed team, like team Wikispeed has to, with volunteers all over the world, would have been difficult or even impossible 5 years ago. We now have 150 team members in 18 countries. You'll see highlighted in red is our newest shop in New Zealand, in Christ Church, New Zealand. Do we have a few folks from New Zealand here today? We do. Everybody please thank the kiwi country for being key Wikispeed. Thanks guys very much for coming down. I'd like to introduce one of our team members who has come in from Turkey to spend the summer with us. He came here on a scholarship for aerospace engineering that he'll talk a little bit more about. While he was here, he discovered team Wikispeed and has spent the last 5 weeks with us. I'd like to introduce Emre Aras.

Emre A.: Thanks Joe. Hi, my name is Emre. I'm from Turkey. I'm a Northwest Community College initiative scholar sponsored by the US Department of States in Washington. Also we are called [inaudible 00:20:12] scholars in my country. My field of study here in United States are aerospace, robotics, and composites as well as in my country, aircraft maintenance and [inaudible 00:20:25]. By the way, [inaudible 00:20:26] is the combination of mechanics, electronics, and computer science. I met with [inaudible 00:20:33]. We are doing a website for him. By the advice of my classmate, Shane [Stambrough 00:20:40]. At first couple weeks, I wasn't really involved in problem solvings, but in those two weeks, I learned a lot and I improved my technical, hands-on skills art. Because you are applying Agile principles in our shop, I was paired with experienced people. It effected my improvement faster.

After those two weeks, I start become involved in problem solvings even though I haven't driven any car in my life. Other than some technical skills, I also gained project management skills. I learned about Agile, I didn't even know what was Agile before. Also Joe cares about the personal development of the team members, so a couple weeks ago Joe sent me to [inaudible 00:21:45] in Seattle to learn about continuous improvement methods. Now I am here in the biggest Agile conference to learn about Agile, thanks Joe. Unfortunately, in two weeks I am going back to my country but it doesn't mean that I won't contribute this awesome project.

I will contribute as a [inaudible 00:22:17] programmer or computer aided design or some advice. You can contribute this awesome project by anything. You don't have to be [expertized 00:22:29] on some special things. I will carry this Agile methods to my country in order to contribute to the development of my country, especially to aviation industry. Now that I am volunteering in team Wikispeed, I believe myself more to build or repair something. I think if you volunteer a couple hours in a week, you will feel a difference in your life. Feel free to contact me. Thank you for listening.

Joe: Thank you Emre. We're going to show you a sneak preview of something a lot like this in just a few minutes, but before that, I'd like to show you what the pace of development can look like in some other industries that we've had the chance to work with since the last time I was able to speak at an Agile or a Scrum gathering. If we look at the anthropological record, and we look at Homo ergaster, which may have been the first great ape to generate fire with fire-making tools, and we look at the tool set that is found associated with those remains and our carbon dated to have been the same data as the fossils next to them, we see that their tool set, although very advanced compared to any of the other creatures on the planet at that time, didn't change fundamentally over 2 million years. Then we see homo neanderthals and homo erectus having a very similar tool rate of change.

About 150,000 years ago, we have, through genetic randomization dating, essentially the same genetic structure as we have today. We have Homo sapians and we also have modern chimpanzees, our closest living relative. At that time, the anthropological record indicates there was about 1 million homo sapians about about 1 million chimpanzees. Homo sapians began to change their tool set within a single generation. Homo sapians began to change their tool set to be able to extract more energy from the world around them every generation, and now every minute. It's been compounding. We have a growth curve in the pace of making change that is standing on it's end. We have the rate of adoption from having a phone in your household to having a cellphone being an order of magnitude less.

It may be that the one thing our species does very differently than any other species on this planet, is increase the rate of change. There are now 7 billion almost homo sapians on this planet and there are 65,000 chimpanzees. You can look to say, "Has our closet living relative changed it's tool set or the way it extracts energy from the environment around it?" No, it hasn't. If you look at homo sapians over the last 150,000 years and say, "Have our life ways changed and the way we gather energy from the world around us?" Well yes. Agile may be a natural expression of the very natural trend to increase the pace of change that our species is so good at it, and might be the single most differentiating factor of our species and anything else on this planet.

John Deere heard a Ted-X talk I gave and saw a magazine that team Wikispeed as in. They sent three managers to our garage in Seattle, Washington to take a look at what we were doing. Then they invited me to their world headquarters in Milan, Illinois to give a talk about what they called frugal engineering and frugal innovation. I'd found this quote ... We talked about modular tractors. We talked about a startup making opensource modular agricultural equipment called Open Source Ecology. They'd already been familiar with Open Source Ecology and with this movement of much less expensive, quicker to make change, agriculture tools, and they were very curious about it and wanted to know about this trend.

Then I gave them this quote. John Deere has been building tractors and their predecessors for 175 years. Their current iteration of the tractor is the 8030, large tractor platform. The head of that team had given us this quote in 2007. "The 8030 tractor development process is quite predictable. We expect to hit the capital plan perfectly and R&D spending within 5%. We know how many resources we need and when we need them." That's from Mr. Wienkes, the large tractor engineering lead at John Deere in 2007. They've been doing this for 175 years. They have a high level of confidence on how long it takes and how much it costs. A Dartmouth study came out that was being studied, actually it was handed to me by John Deere, about the same project. They reported the project ran 6 months over and the engineers were working 12-14 hour days. Even still, they dropped some of the key features. That tractor shipped and made an enormous amount of money. John Deere was very happy but they knew that the pace of development was changing in the whole world around them and it might be time to start evaluating the way they forecast and predict projects.

When I gave them this quote and compared it to this piece of evidence, I thought I'd be thrown out of the building. I was quite scared. Instead, they put me on a boat to give this talk again at their annual budgeting cycle to say maybe our budgeting shouldn't be annual. Thanks guys. I just got a call last week where they were saying, "What would Wiki-Deere look like?" Then Boeing contacted team Wikispeed and they're just up the road. The largest aircraft manufacturer in the world and they're in Mukilteo and Everett, Washington and all over the world, but that's their headquarters. We're in Lynnwood, Washington now, just north of Seattle. We're about 20 minutes away from each other. They said, "We would like to give you a tour of our 787, Triple 7, and 767 manufacturing lines."

We went inside the largest enclosed space in the world. The building is so large they've had clouds form inside and have it rain inside the building. Here we are standing, not even directly in front but near one of the jet engines. You see how massive the scale of things is. It's very easy to lose focus and it all seems small until you look at a person sized door, even just one quarter of the way down the building and someone going in and out and it's astounding. It's like the arch of The Covenant scene from Indiana Jones, but all planes. We talked about maker plane. Maker plane is an Agile aircraft company. They're building 4 and 6 seat light passenger aircraft. They claim to be using the Wikispeed method. Their team lead has emailed me, and I've emailed them back and as far as I can tell, they've absolutely got it. I'm very excited to see what comes out of this group.

Boeing is looking at these groups and saying, "What does that mean in terms of pace of development? How can we accelerate pace of new product development with high quality?" Those are sessions that all of you have been attending all week. After going to their enormous building, we took them to our Lynnwood shop and they hosted a dinner there and sent 15 of their executives over. It's the first time we've ever had a dinner hosted in team Wikispeed with tablecloths and everything. One of their double PhD computational fluid dynamicist said, "You know, the machinery we're using is more advanced than yours but you guys are so far ahead of us culturally that we have so much to learn from you." I was very quick to say, "And vice versa, we're still very small. Let's be good friends." The fact that they're even interested in what a bunch of people are doing in garages and storage units lets me know that maybe we are actually seeing a big shift across all industry.

Then I had the privilege to go to Tait Radio in New Zealand. Tim Meyer went with me, another Solutions IQ employee who also, after work volunteers his time at team Wikispeed. Tim Meyer's expertise is test fixtures and test fixtures now, not just for software and continuous iteration and automated test coverage, but the same for physical manufacturing. He, paired with our electronics team in [Mea 00:31:35] France, to develop and implement an accelerator pedal recorder allowing us to be driving and record accelerator pulses and drive cycles and then play them back for automated testing to see if the changes we made to emissions and fueling were moving us higher or lower with the same recorded test procedures. This type of device is not novel in the automotive industry but it's still fairly new and doesn't have full adoption. Some of the test fixtures we use are wholly new and the only reason they're wholly new is because we design tests before we try to solve any problems, we practice TDD, or maybe it's TDM, manufacturing. It's the same practice. It probably doesn't even need another name. You folks are all experts on this now just as you're familiar with TDD.

In New Zealand, Tait creates hardware goods. They make radio systems. Now they make digital encrypted radio systems for ambulatory, fire fighting, and law enforcement services among others. Here you see one of their P25 base stations. This unit sits in Iraq and receives radio devices, performs digital signal processing, and readmits the signals to transmit them as further distances than a handheld or a mobile can do to each other. This is what the Scrum room for a hardware engineering team can look like. Tim and I landed and we told the team, "We're doing an experiment to see if we can develop products more quickly. Let's have everyone needed to create this product be in one co-located space, a Scrum room, and we had hardware engineers there, they were doing soldering, chip testing, rapid circuit board simulation. We had embedded software engineers and we had application software engineers and we had marketing all in one room. We launched the team on Monday. The product owner, needs sound.

David: As the product owner, manager, I was able to get a very quick estimate of the scope of work and the impact that it might have if we were to choose one option versus another option. The example was that, I asked about the 50, 100 watt. If we were to change from doing 100 to 50, we split the different disciplines in the forum and the stand up, and we were in three minutes able to get a good estimate of impact on each of the disciplines, contrasts. When we're actually doing real work and life is going on can take us weeks to get a feel for the impact of making that choice. That was a real example for me.

Speaker 5: In this case, being able to have the team in a co-located area and simply ask the question to everyone at their work stations but in this co-located area, you were able to get an answer in about three minutes, in fact I believe the decision was able to be made in 10 minutes on a 50 watt amplifier, we ended up choosing a 100 watt amplifier by knowing how will this impact each team member and what risk does that give. That would have taken a week?

David: Perhaps a couple of weeks.

Speaker 5: Maybe a couple of weeks in a non-collaborative work environment.

David: Yes, so it was a big difference.

Speaker 5: Thanks so much David.

Joe: The product owner reported seeing the same type of velocity increases in terms of team decision making, which was a novel concept entirely from a command control culture previously in some of the org, and have a resolution made in three minutes, and a decision ratified amongst the entire team in 10 minutes instead of the team being told of what the answer was, the team came up and then spread consensus in 10 minutes in what would have taken, he said multiple weeks, a small win. Later that same week, David [Genks 00:35:18] again, the product owner, said information bubbled up by having people from different disciplines working together on the same problem saving them more than one person year worth of work across a core team of 7 people and a larger team of about 27 people.

That team launched on Monday and they had a working prototype in a proxy-customer's hands on Friday, making calls through the radio system to test the system. The engineers in the same room had direct feedback from the customer for the first time ever. It normally takes three months, or in some cases I'm told longer, it can be on the order of years to have a protype being interfaced with by a customer, and it was able to be done in one week. We didn't, Tim and I, even tell them what process to use. We walked in and said, "You're self organizing. You can do anything you need to do to deliver quickly. Here's the goal. Let's have a radio in a customer's hands on Friday and have them using it, a prototype of this product. You can use any practice process you'd like to, up to breaking the law, but Tim and I are here to coach you on Agile, Lean, Scrum, Con-bon, XP, XM if you'd like it." We ended up running sessions on all of the above.

Tait was already doing so many things right, it helped. Their manufacturing line right next to it has a rapid prototyping lab to make test fixtures for the automotive line. Their test fixtures are cardboard, just like many parts of the Wikispeed car start out as, as we iterate stubs. They already practice stand-ups in their line manufacturing, in their HR department, and in their marketing and project managing department. While we were there they started using retrospectives in those departments. While we were there we talked about adopting a project owner and a Scrum master role, to have a team steward, a servant leader embedded in the team, and someone with a clear vision of the end state of the product. We saw the result of that with product owners and Scrum masters in HR and the company change management team.

Here we are conducting a cross-discipline retrospective with the C-suite product engineers, two different types of hardware systems engineers, embedded software design engineers, and application software design engineers. There is Tim Meyer on the far right in the blue shirt. Why doesn't every company do this? The number one reason that we hear as we come into companies saying, "I'm not sure that can fit with us," is cultural inertia. Companies have been doing it the same way for up to 175 years, in some cases even a little bit longer than that. Not the exact same way, but some of their processes have been inherited across that time. The resistance we have comes from often middle management. We're saying, "Go back to line facing work. Create customer visible value directly instead of architecture documents that you hand down." Middle managers are typically resistant to this but report higher job satisfaction and engagement when they do. They feel like they're directly expressing themselves through the product that the customer interacts with.

Then, we have enormous resistance from the financial team, the budgeting team. They're saying, "We have these very painful annual budgeting cycles that we prepare reports months in advance and then afterwards we prepare months of reports saying why we went over or under our budgets, and we have to make the best bet we can as to what will be needed one year from now as we apply budget." We say, "No it's much simpler than that. It's actually a short list of KPIs used to incrementally fund budgets every week. We're not asking to do the big bang financial allocation every week. We're asking for a very small piece of it, the most essential piece of it, so that you can more accurately divide funds." Once they do they report more nimble company management and that they're actually able to be financial stewards of the company's resources.

For more information about XM, or any of the other practices I've talked about, please contact my day job, that's how I feed my family, at Solutionsiq.com. Now here's how team Wikispeed applies these principles. Here's a safety iteration of us going through an evolution of our car in 7 days. The first time we did a safety iteration it took us months so we had to divide it into tasks and stories that composed the overall value if we've completely iterated the safety systems of the car. Now we're able to iterate the safety systems of the car in 7 days. Here's how this happens.

First we pick a test. In this case, it's the NHTSA side impact test. Then we simulate that test in CAD. This is the side impact test where the side impact test barrier is colliding with the side of our [chasee 00:40:12] and we see the stress spread across the frame, the [chasee 00:40:16] of the car. Then, to determine the accuracy of that test, we physically conduct crash testing. This test costs us $10,000 every time we run it plus the cost of the car, plus the cost to deliver the car to the crash testing facility. We can't afford to run this test every 7 days. Instead of relying on this test every 7 days, we conduct it whenever we can afford it and use it to make more accurate [arsimulations 00:40:42] which we do run every 7 days.

Then we iterate on that design. In that side impact test, we had four inches of cabin penetration. That is survivable and that is common. There are many new vehicles on the road that have that level of side impact performance. We want to do better. We wanted top tier safety rating. We wanted no side impact penetration. Within hours of that video circulating through the team, this father and some iterated on a new side impact module and attached it to one of our chassis. Because of the modular architecture, it's able to be attached to every car we've ever made.

Here's an aesthetics iteration. First we start with CAD. Someone, somewhere in the world downloads our chassis and our suspension design and they start drawing new parts of the car. In this case, it's a new exterior of the car drawn by Ron [Morbacher 00:41:34] of More Composites in Germantown, Maryland who during the day, he does composites in CAD, and nights and weekends he volunteers his time with team Wikispeed. I'd never met him in person in my life when he drew this CAD. The team decided they liked it, and we voted to make it so we used a computer to control that router, that C&C machine to machine it in foam in one day. Now we have a life-size buck of the car to walk around. Then we lay it up in carbon fiber in one day. Now we have a structural carbon fiber shell that we can use for aerodynamic testing.

Then we go to the largest auto show in the world, Detroit 2011 in January, and we put it on the main floor between Ford and Chevrolet. I was terrified. I had no idea how it would be received and I knew during the first week it's the industry preview, and that's where the executives and board members of every major automotive company and supplier are mixing around, because it's their first time to see the competition's new products. It's their first chance to sit in the new competitor's vehicle. I got to meet many of those people and I thought we would be ignored or that we would be dismissed or we would be talked down to or even made fun of, or that maybe it would even become confrontational. I never expected what happened.

Every single one of them shook my hand and said, "Good job, go get them." Thanks guys. I can tell you're putting yourselves in my shoes. I didn't know what to think. I've had a lot of time to think about it since then and the best idea I have about why that might have happened is I think they know this is what they need to do, or something like it, but they're bored and the rest of the C-suite is saying, "Well cost accounting tells us to make the next version of the Ford F150, not figure out how to rapidly iterate on designs. We need to be not focusing on how to embrace crowd design and crowd engineering, we need to be instead figuring out how to make more or the new version of our existing profit cows."

I think the C-suite and board members that came up and shook my hand were all saying, "Yes this needs to change and we need you to exceed to apply pressure on the financial driven members of our board on the cost accounting members of our board so that we know we can make this change, because it's going to be a long time to steer this big ship and we need to start now so make a big splash so we can okay? That's what I think they're saying to us. I'll never know but that's what I'm reading into it from all of them being so supportive. Then, this is the same aesthetics iteration, be filmed by The Discovery Channel and then launch a crowdfunding campaign to revolutionize the future of automotive manufacturing.

Speaker 6: This car gets 100 miles per gallon. This car is completely modular from the body down to the engine, [transformat 00:45:04] from a two seat convertible to a four seat family car to a pickup truck. We've made the plans to build this car completely free to the public online, and this car is fast.

Speaker 7: 100 per miles of awesome is how it's running.

Speaker 6: Introducing the world's first gas powered, 100 mile per gallon sports car available open source to the public.

Joe: I am Joe Justice, the team lead of team Wikispeed. This carbon fiber, mid-engine, rear-wheel drive, aluminum extruded [chasee 00:45:29], super car is $25,000. It's a race car. It's extremely basic. We're now jumping the gap to bring as much of that technology as responsible, as much of that sports racing performance, and most importantly ultra-efficiency in an even lower cost package that's a comfortable commuter car for people to enjoy every day on their way into work.

Speaker 6: We want to bring this incredibly efficient technology to your driveway. Our goal is to make the next model of the Wikispeed car a realistic option to save you big bucks at the gas pump.

Joe: Team Wikispeed runs on materials, machinery, and person hours. Funding allows us to turn all of those resources up to 11. We want to complete 10 additional crash tests, also additional fuel economy testing that's certified by the EPA.

Speaker 6: Our project is funded for the people and by the people and your support is going to bring the 100 mile per gallon revolution to driveways all over the world. We invite you to be apart of the action. Help make the world completely awesome. Let's drive Wikispeed.

Joe: That crowdfunding campaign recently ended and we raised enough money to perform our next round of crash testing. What that lets us do is continue on as a debt free company, so we have no risk of being liquidated, and keep iterating to make the products we care about with safety as our priority. We were able to successfully fund the next round of crash testing, which is what we're iterating on now. Team Wikispeed is far more than Joe Justice. Some people see me talk about it because I'm very passionate and I want the world to be able to use these practices and processes if they want to, but team Wikispeed is massive. If it were just me, it wouldn't look anything like what it does now. The car would probably still be mostly steel with some cardboard because I wouldn't have learned how to correctly and safety use aluminum composites yet. It would probably be just half a car in my garage, and I'd still be just as passionate, but I wouldn't have any evidence yet that this really works.

With a team of more than 150 people in 18 countries, we have brilliant ideas, hands on work, innovative approaches, appropriate use of practice. I learned so much from team members all over the world. We were lucky enough to have Mary and Tom Poppendieck visit our shop and apply some coaching, thank you very much Mary and Tom. We were lucky enough to have Cory Latis and Jim Benson become team Wikispeed members and apply personal Con-bon and Scrum-bon to our shop and level us up. Because we're open and embracing of the process community, we're able to continue to level up the practice. I know sometimes you hear people say, "Joe says," or, "Joe's project." It's definitely not that. It wouldn't look anything like this and everyone else has just as much to say about the project and I'd encourage you to email info@wikispeed.com and have a wikispeed team member pen pal, or even join the team yourself.

With that said, I would like to invail, and if we can mistro, not many Agile conferences have an automotive unvail but we are at a unique intersection between process and manufacturing right now. I'd like to show you the 2013 Wikispeed Roadster. We're determining it's name. It was created by Rob [Morbacher 00:49:05] in Germantown, Maryland and then collaboratively built by team members all over the world. Here, team Wikispeed members are going to show you the 2013 Wikispeed Roadster, 100 mile per gallon modular commuter car. This car was built by Agile 2012 conference attendees yesterday. This car was built behind that screen by people in two sessions. If you think about all you learned in two sessions here, and then think about how fast that allows you to go in software, we have some evidence that allows you to go that fast in other areas as well, and in one example we have a car.

These groups of people stepped in and we asked, we took a poll, "How many of you have ever built a car before?" One of them said, "Well I rebuilt most of my old Volkswagen." No one else raised their hand. We were from very diverse backgrounds. We created a backlog, a Con-bon board saying this is what needs to be done, and by using pairing we were able to have people engage immediately. Within 25 minutes, we had swarms all over the car. Here you can see, we don't have someone pointing and standing. We don't have a binder, here's how to build a car. We have people that have never built a car before engaged in productive immediately. This is some of the things we see when we use pairing and swarming appropriately with a servant leader or Scrum master who's facilitating as rapidly as possible. The people that built this car were people I've never met before and they have built a car that we're going to take back and perform safety testing on and verify it's exactly what we need to do for correct spec.

If we don't have to do destructive safety testing, this car will go in the Boeing Future of Flight innovation center at Boeing's Paine field. It'll be an exhibit between a cockpit on the Airbus 380, the Rolls Royce trent jet engine, the barrel section of the first all-composite Boeing aircraft in the world, the 787, and then the Wikispeed 100 mile per gallon car. It was built by you guys in one day. That said, I don't mean to take credit away from the Houston shop. They put the [chasee 00:51:58] together and verified the parts were there, and then I can't take credit away from Rob [Morbacher 00:52:03] who made this beautiful body and shipped it in via freight. It arrived on Wednesday and we hid it back stage. I'd never seen it before.

This type of distributed collaborative team allows us to be constantly surprised by successes of each other and help each other. This is a picture of a gorilla high fiving a shark in front of an explosion. The average team Wikispeed member spends between 2 and 4 hours a week rapidly solving problems for social good. We've talked a lot about the cars, because they're visual. It's easy to see the practices applied, but we don't just do cars. My first Agile project outside of software was with Rotary International applying Agile to Polio vaccine deployment to eradicate polio in the developing world.

One of the other Agile projects the team has taken on is remote low cost medical centers to be delivered to developing communities. We have backlog items to develop banking and investment applications for developing communities that don't have access to items in the first world we take as rights, the opportunities and nice-to-haves that just aren't available on an equitable basis. Most of our resources and time are spent on the cars because the car is so easy to be enthusiastic about. Ultra-efficient transportation is something that most of us can clearly imagine. That said, we're actively looking for product owners, people with clear visions of what the world will look like when this social good exists to join the team and accelerate more social good items. We have an entire team to work with you and if you want to add your speed, your velocity in whatever scale you have as a musician, as a seamstress, as a software developer, as a material scientist, as a project engineer, as a product manager, we are looking forward to working with you to make this world that much more awesome. I'd ask you to join team Wikispeed. Email info@wikispeed.com. Sharpen your Agile skills applied to all types of skillsets and make the world a better place.

Even if you don't join Wikispeed, I'd ask that you seriously consider spending two hours a week rapidly solving problems for social good, and I'd ask that you do it with Agile methodologies because it seems to give us the fastest results in the least amount of time. When we're talking about social good, we want to do that as quickly and responsibility as we can, so I'd ask you to use that methodology. If everyone in this room spent even just two hours a week rapidly solving problems for social good, it would be so awesome. It would be like a gorilla high fiving a shark in front of an explosion. Thank you very much.

With that, if there is Q&A, I know most folks have to make flights, and please do. If you have the time to stay, if you have the luxury of a few hours or a few minutes or a few seconds, I'm happy to field questions and they have microphones to run out to the tables in the back or the folks out front. Also, feel free to email me anytime you'd like at info@wikispeed.com with questions or comments or our YouTube channel, youtube.com/wikispeed has about 48 hours of video on it now. Feel free to sift through any part of that that might be interesting, if that's interesting to you. If there's questions and answers for me, our Las Vegas shop leader Tom Taber, our Lynwood shop steward Clayton [Osterman 00:56:13], our intern from Turkey, Emre Amas, or for Deloitte Center for the Edge and the shift index, Christopher Gong, please ask and let us know if it's for anyone or for me. The first hand I saw was here.

Speaker 8: Yes sir, well done. Clearly the financial side is what's ruining or preventing us from really getting to Agile in the industrial scale. We're seeing it in software where software capitalization rules make us do stupid things on purpose. You just said it is the same way at industrial building and stuff. What do we have to do as a community to change the practices, what do they call it, gap, generally accepted accounting practices so that we can amortize things that aren't perfectly built or designed, technically feasible before you start capitalization and amortization?

Joe: Thank you very much. If I understood the question it was, what has to change so that this can be adoptable in industry where they typically have to amortize assets, where they're figuring depreciation in order to cost account their 5 year plan. If I'm close, the session that Walt and Pat put on on Agile accounting, I think is most of the answer. I think they might have a lot of it down. I think they might have a lot of it figured out. There's also the growing, passionate discipline of lean accounting, which I don't know very much about but it seems to be complimentary. Pat and Walt would know. I'd encourage you to ask them. Their session was Wednesday.

It seems that those people being financial stewards of saying, "Yes this can work. Yes this is legal. Yes we can still get up to 10% back from our taxable income by figuring out what's capitalizable versus what's expense per Agile epic, per story item if we have to." It doesn't take anymore overhead than we were already, and it's right more accurate and we're actually more protected from audits. We need to support those people in the accounting discipline. Next time your company or your friend's company is looking for an accountant, inquire them to ask if they have Agile accounting background. I think that's part of it, in helping drive that decision in a responsible way. I guess we should go to mic two.

Speaker 9: Hi. How do you get one of your own?

Joe: How do we-

Speaker 9: Get a car of your own.

Joe: Thank you for asking. Right now, our Wikispeed.com/store is a text page. It's a lean startup saying, "Here's the things we sell but we haven't built an online store yet." You can buy a car now, we've sold three of them. The first one gets delivered in December so we'll be getting our first customer reaction soon. If you were to buy a car tomorrow, you'd probably get it mid spring. You would email info@wikispeed.com or call us, our phone number is also on the website. It's a Google voice number that several team members answer, I'm of them. You might get Tom Taber, you might get Mary Michael.

You'd say, "I'm really interested in buying a car," and we'd say, "Are you sure? They're prototypes. They don't have cup holders yet. They're kind of rough around the edges. They're really efficient and they're safe and that's about it. They're very elemental still. We're iterating on the comfort and convenience." You would say, "I'm an early adopter and I want to see this exist in the world around me. I'm the type of person that wants to show my neighbors and the big 3 automotive manufacturers and the small companies that 100 miles per gallon is available now. Even though the car doesn't even have a roof, I'll drive it on nice days and I know that when you have a roof, sometime around this Christmas, you'll send it to me and I can put it on like a target top and I can feel like I have a Ferrari."

We'll say, "Awesome, thank you so much." What you'd do then is you'd either pay us through PayPal and some people, one of our three customers sends us $1,000 a month on a subscription and when we get the 25th $1,000, sometime I think he's going to give us 20 at once, or 15 at once, and then he gets the car. The other two people wrote us a check and they both came out to look at the shop in person and then handed us a check. Then both of those people then joined the team and they're building their own car that they paid for. That's kind of awesome. That is customer advocacy. You don't even have a proxy customer there. You have direct customer feedback.

What happens with the first 10 cars, because we've just sold three, is that those customers are not only the product owner of their car, but they actually have direct input into the backlog prioritization and can directly add backlog items. If one of them were to say, "For my car," and someone did, Bob who joined our team yesterday and helped build this car. Bob said, "What if I had one seat in the front and two seats behind me like the [Mclaren 01:01:03] F1," this famous super car. We said, "Well in the first 10 cars, we're rapidly iterating to make you happy so sure." He said, "Really? We said, "Sure." You have an opportunity to be defining the backlog and that would then be one of the options going forward for everyone to use if they wanted to. That's a little bit about the car purchasing experience.

Related to that, it's, "Where do I get this thing serviced? You're this tiny little company." We use an American Honda motor company engine that you can have serviced at any shop that's able to service authorized, an authorized service center for Honda goods. Some of the car parts are completely made in house. We package them into modules that are about the size of a shoebox and so if our electronics module goes bad, you'd ship it to us and Netflix style we'd send it back to you immediately and meanwhile we'd get to do root cause analysis on what happened. The service relationship for big things like the engine and transmission is anywhere that can work on Hondas, and the brake system and the steering. The electronics, the braking system, other aspects that are team Wikispeed specific, we mail back and forth Netflix style for service. We can't afford to set up shops all over the world. We had to be a little innovative. Then I think that takes us to mic 4, I guess, oh mic 1, yes sir sorry.

Speaker 10: In order to help fund and promote Wikispeed, can you tell us a little bit more about where we can get a t-shirt that has a gorilla high fiving a shark in front of an explosion on it?

Joe: You are awesome right now. Completely awesome. I found this image by Google, "epic high five." I had no idea who made it or where it came from. Then later I found the artist. He's this guy that does a web comic book called, "Dr. McNinja," and it's totally hilarious. Everything is this crazy. I'm a huge fan. He said, "Well I already sell t-shirts with these." I say, "Hey support the artist." We have these t-shirts being made, because he drew us another one just for us. He said, "What would you want?" I said, "How about science high fiving mother nature in front of a super nova?" We haven't printed them yet but they'll be on our store. In fact, our text store says, PayPal us, I think it's $20 and we'll send you a shirt." We'll do another run of shirts once we have a few orders.

The primary method we're funded, where almost all of our funding comes from is on our website on the right hand side people click to send us $10 a month as a PayPal subscription. That compounds because many people do do it. That way we're able to have ongoing run-rate instead of a big shot at once, which would be the equivalent of big annual budget funding. If I got to ask you guys to do something for Wikispeed I'd say please join the team. If I got to ask you guys to do something to financially support Wikispeed, thank you for asking, I'd say, "PayPal us $10 a month." We do have t-shirts. You can buy the gorilla shark high five t-shirt. It goes to the artist. We don't get funds from that but that's okay by me, he's amazing. We do have our own t-shirts, they're not the gorilla and the shark. I'll ask him. Did that answer your question?

Speaker 10: Terrific, thank you so much.

Joe: Thank you so much. That takes us to 4 I think. Please go ahead.

Speaker 11: First of all, you and the entire Wikispeed are freaking awesome, thank you very much. I'm curious what your longer term vision is for the car manufacturing. Do you actually see this scaling up to be a larger scale manufacturer and would it then turn into a for-profit corporation or do you see volunteer ... I'll let you speak.

Joe: If I understand the question it's, what do we see the impact of this on manufacturing larger scale in existing companies? It was part, and then will we become a for-profit company and what will happen to the volunteers?

Speaker 11: It was more, do you see the Wikispeed manufacturing becoming a large scale manufacturer?

Joe: Do we see Wikispeed becoming a large scale manufacturer, and then do we become a for-profit company, how does that work?

Speaker 11: Yeah.

Joe: When we were founded for liability reasons we were a C-corp, a traditional corporation. We then submitted our application as a not-for-profit and they declined it saying, one it's difficult for us to suspect you're actually not for profit because you manufacture and sale a good, and that's true, it's possible to do but you have to be really on top of your books to continually prove the case that you're a not for profit. They said two, we need two years of tax record history, and we hadn't filed because we hadn't sold anything, we just keep spending money, is how it is in the beginning. This year now we've sold three cars, so this would be our first year where we have taxes, where it says business transaction has occurred. We didn't have a two year history is what they told us.

That said, we now have a bunch of traditional investors coming on and we're saying, "Are you okay with the fact that we're ulturistic and we won't be making decisions to maximize profit for shareholders, we make decisions to maximize social good?" For that, it looks like we're reincorporating as a new structure called a social corporation, that allows just that. Your board can no longer sue you if you made a decision to not maximize shareholder profit, imagine that. We can actually ... Thank you very much. That said, that structure still means that we can issue a return to people that believe in what we're doing if we do well, which is exactly what we care about. We're not against profit, it's just not our goal. We have no profit motive. If we live in the Mayan city of gold because we do it well, that's okay.

Everyone that sends us those $10 a month through PayPal, what we tell them is, "If we ever issue profit, we'll pay you back. If we can afford it, we'll pay you back with interest," so we won't be laughing all the way to the bank for anybody. Then what that means too in terms of us manufacturing, 76 million new cars were built and sold last year. Current analyst predict that about that same number will be made again this year. We think at least 60 million of those should get 100 miles per gallon. That said, I don't want to have to figure out how to do the economies of scale on 60 million cars manufactured in a year. Even worse than that, I don't want to see news that some manufacturing plant was shut down and 4,000 people in a neighborhood were laid off at once because they've just been put out of business by Wikispeed.

I want Wikispeed to succeed and I want it to succeed in hundreds of thousands of cars a year, because that's the number that will make an appreciable difference in the amount of fuel consumed and the amount of emissions emitted. We could sell ten of these at $100,000 each and my pocket book would be pretty happy, or we could sell 100,000 of these at almost cost and make a difference for the environment. That's much more what I'm interested in.

Speaker 11: Thank you.

Joe: The real win is seeing if we can make future partners out of what are thought of as maybe our current competitors. If we can instead help Ford, GM, Crystler, Isuzu, Hyundai, Kia, Mercedes Benz, BMW, Mitsubishi incrementally improve the pace of development of their products to make them more customer relevant, more environmentally sustainable and lower total overall cost of ownership, we've done the right thing. Instead of un-employing that plant that has 4,000 workers, we want to instead have them producing more efficient products. We see all of our future competitors instead as future partners. Team Wikispeed needs to be taken seriously enough by them to see if we can actually make a car that at least 10,000 people will consider driving everyday. That takes us out of being boutique and that takes us to the small mainstream. We'd be bigger than many car companies you know the name of then. That's when I think we can start adding the most value to the world around us, by partnering and helping to accelerate and apply these practices with all of you to all the world around us. That's where I think the manufacturing is going. I think other people will make their products better, but to get there we need to hit at least a threshold of, I believe, around 10,000 units. I think that takes us to mic three.

Speaker 12: Yes I've been coaching so facing the pain of transformation. I view you as more working in disruptive approaches. What do you see the future of these organizations being able to do that versus the just disruptive ones growing up around them and eating their lunch?

Joe: That's Steve Denning's point exactly if I followed you. He's saying it's very painful for an existing organization to change methods. What seems to be happening and what is historically happened in the pace of business turnover that's accelerating is that some other company comes up, is radically disruptive, takes over the space and then they become the complacent one and then they're raided and disrupted and then they're raided and disrupted. My guess at what the answer is, what I've observed and have some evidence of what the answer might be, is that companies need to be good at change and not be good at Agile, not be good at Scrum, not be good at line manufacturing, not be good at lean, although all those things do help them change quickly, but the actual good is not to figure out how to be an awesome scrum master. The actual good is to figure out how to make your team do something different next week that's better than what you're doing now and that's what all these practices are all about and we all know this, but sometimes it's easy to get dogmatic and we know when that happens then the excitement starts to leave the team.

The other part of that is if there's anything team Wikispeed's doing that's actually new, because everything we're doing, well even including this, is common across the Agile space, it's just the Agile space is still booming, it's still flying open and expanding. Is focusing on morale as a multiplier for velocity? That's not very common yet and I've heard a few sessions about it and I didn't come up with it either, but we apply that very seriously and we apply that paired with reduced cost to make change and I bet that that's what might service these companies. If they get good at having highly motivated teams that are making changes quickly, they may be able to stay on top of their markets. That doesn't address how to convince or encourage or support an existing company to try to make change.

There's the thought that you need to give someone at least five compliments before you can ask them to change. It might be making sure we find out what's really good about the companies we're in before we find out what we might want to disrupt and disrupt it very gently and with support, and come at it, I would imagine, from a loving angle of what the company's already good at, and a loving angle for the people in the business and what they're already doing and help them do it better to be higher morale and to be able to make changes quickly and then maybe we will see all companies being continually disruptive and we'll all benefit from having a radically different maybe, pace of new product development that's customer focused. Did that talk to your question at all or did I take it sideways and go on a rant? I probably did.

Speaker 12: No actually that was really good but I think when you were talking there about, some people think I'm a nice guy, I've got them fooled, when you're looking at trying to transform them it seems to take an awful long time so they think, I'm going to get this coach in and oh by the way, I want you to take these 100 teams and get them Agile before the end of the year, I just kind of start to shiver and shake when I hear them talk that way because it's a lot of talking, helping, and when they feel like you're there to help, then you get the ability to influence them, and to me it takes a long time to be able to build that up. That's my fear of them not actually transforming is then it takes a 2x4 to the head and that's a lot more painful for them than a nice transformation.

Joe: I used to feel that level of resistance at the clients I'd go to in my day job. I don't anymore. That example at Tait Radio, they were already doing some strong practices that they had proactively found by working with Mary and Tom Poppendieck and [Henerick 01:13:59]. Then when Tim Meyer and I were able to come in, we were able to set up a team on day one. We were able to have visible, radical progress in that team. The team was, and Tim and I were able to support it. We didn't build those radios, we're not radio engineers, in five days. We're beginning to see the pace of adoption and the pace of culture change go through the roof too. What I see as ... I will get on my high horse for just a minute. I see people come in and talk about organization changes, if it's this roadmap and this cycle. What? We're Agile. I run into a client and say, "You have permission to do what you need to do," they do right?

"Okay, and you won't be fired for at least one week. Now we're going to do something really different and here's the practices that support it. See that cube wall? Just for this week, we're going to move it against the wall okay? Please take these things over here. Who has the clearest vision of what we're doing? Who can imagine a day in the life of the customer and what they're doing that day when they use your product or service and what they ate for breakfast and how it relates to the rest of the things they do that day? Who is that? It's your tester. Oh wow, imagine that, it's not even someone from marketing but they really do, do they? They do, let's talk about how to vote as a team. Okay you're now this thing called a product owner. Who's going to run to hand everybody screwdrivers or get lemonade? Okay for today at least, you're the Scrum master. Do you have a background in team phycology? No? Well maybe go to a coaching clinic next week."

Week one we have results and that starts to have other people from other teams come in and look and say, "What's going on?" We have an all-hands session saying, "Everything you gave this team once a year, you're now going to give them a little piece of it once a week, and everything you used to get from this team once a year, once a quarter, you're going to get a little piece of it once a week. You need to support them by attending their demo of that product every week, okay please, can you do that for a week?" We have radical transformation very, very quickly.

I think it's when people walk in and say, "Let's talk about transformation. Let's talk about your quarterly plan. What's on your five year budget?" And instead saying, "Is your CEO truly the vision holder for the company? If so, can they be the product owner for the company, and be that I mean be here everyday to answer questions for the change management team? No? Well then who actually is driving the vision? Nobody? Surprise. Let's marry that. Let's figure that out on day one," and that can happen and I've been seeing it happen. I don't think change adoption actually has to be a long, slow process. In fact, there's some evidence to say that that might be true.

Speaker 12: Great thanks.

Joe: I did, I'm now off that high horse. I could be completely wrong, but thanks. Your mileage may vary. I need to soften that after getting that excited because we're on the cusp of change and new things are happening right now. None of us are predictive, that's why we're Agile. Instead we're responding with as much information as we're able to gather this week in what we're going to do next week, but I'm glad I got to share some of the things I've seen and some of the things I've tried that seem to be working. Microphone two.

Speaker 13: First of all, great car. Many people have asked some great questions. I would like to add one trivial question being an engineer now, being a Scrum master without Agile practices. The first thing I noticed in this car didn't have doors. That might be simple, it might be something cool, but what struct to me was looking at your design, did that come by design or was that because as a first [inaudible 01:17:41] your value is looking at promoting a car which is more economical, and also by your initial design, your trust system or chassis system are much simpler to design that way? Was that a team's way of selecting saying that that's a good feature but not be needed now, it also helps us to promote what we need to show, was it by design? Trivial feature as a door, which real world I would like to say that some of the things that we do at our work might be nice to have, but we still force it into our releases, we think it is very tough to remove, and you made a very bold decision to take it out but also looks look.

Joe: Let me feedback and see if I caught the essence of the question. First, thanks for saying the car is cool, I agree. Then, you said you have an engineering background and currently you're a Scrum master right?

Speaker 13: Yes.

Joe: Or close to that. If I followed you, you were saying did the design emerge or did we have to do a planning phase?

Speaker 13: Yes because you having the chassis which is like a box start system, it also helps your safety, if you had put a door it would be split in two halves, it increases your stress levels, it's much more complex design to handle.

Joe: Absolutely. Some complexities is this chassis, you still step over the side and then you sit down in like a race car. That door does not open, it is not a door, it is a side of a car. It's like a race car where you step in and sit down. That's why our cars are prototypes. They're not ready yet for my mom.

Speaker 13: It's a open NASCAR.

Joe: Yeah it's like a race car, but we want it to be. We want it to be something that at least 10,000 people will seriously consider driving to work. How did this design emerge and how did you determine the trade-offs that we make?

Speaker 13: Right. I'm just trying to take away an analogy here from your car to our daily lives.

Joe: If I followed you, our design is emergent. There's principles that are not. There's principles that we're standing on the shoulders of giants here. People have figured out object oriented programming interface, first development, contract first development for a long time. I went to college and learned those things right afterwards. [Dotnetone 01:20:02] and web services were the big boom right when I was entering the working world. Contract first development for web services and [wisdols 01:20:09] were small revolution at that time. Those practices have to be met in order for the pace of change to stay high. Now, not necessarily Microsoft's version. That was one implementation where in that case, the loosely coupling of web services worked really well.

The object oriented practices, the modularization of software practices are from all, we are all using those. Those are not tradable. Given those principles, the idea is what's the simplest, leanest, cheapest thing that passes this test? The test is the side impact test. That's where we get emergent design responsibly, because it's still modular, we can change it quickly, it's still cheap to change so it's okay if we go off the rails. We will never go off the rails longer than one sprint because we test and iterate every sprint, so that's the longest we can do something that's irrelevant is our sprint length, in our case it's 7 days.

When we say side impact test and it needs to be modular, we first started ... Well actually let's start with the offset frontal impact test. We first started with the front half of a 2016 Honda Civic because at that time, it was the lightest thing in the world that had gotten a 5 star crash rating all the way around. We bought the front half of one. This is kind of hilarious. General Motors had bought two of them, cut them in half to figure out why they were as safe as they were, and they thought it was able the way the seatbelt [pretensioners 01:21:31] worked, so they tossed the front half of the cars and we picked them up on Ebay, and they kept from the front seat and back to do seatbelt sled testing. They missed the boat. It's actually that there's these [hexigonal 01:21:45] tubes that go from the front crush structure up into the a pilar that holds the windshield on and they're filled with a structure foam partway intervals to then manage the stress and channel it not just into the bumper, but then up and over to the top of the car and actually activate the rear crush structure even in a front collision, which is why it's so light and so safe.

That is known now, but they missed the boat at the time. They sold it to us for nothing on Ebay, because that's the part of the car they didn't need. We attached it to the front of our car. We bolted on the front of this other car because that was the fastest way to comply with the safety reg. We could do that in a week. Then we cut it down more and had just the front crush structure and front bumper beam, and we bolted that on. Then we found out that you could take a 6 inch by 6 inch, 8th inch thick, 50/53 aluminum alloy beam, which is really simple to model because it's just a rectangle that's hollow, and you click the materials property and you say apply force. A geometric shape is one of the quickest things to determine the structural property. We bolt that on and it was just as safe. Then we impact tested it to verify. We rapidly iterated, and that's all the design of all rapid iterations to past tests and so we started with big clunky things and it keeps getting more and more elegant.

That said, there is a decision made that any part of the car can be built with, there's these two machines we use. If I had one here I'd point to it. It's a milling machine which is, it's like a drill that's mounted this way. You pull a lever and you can drill down but it's also really strong this way so you can actually cut sideways with that spinning bit. It's a milling machine. Then a band saw that cuts off metal that way. Those machines together are about $500, and that's part of why we have so many Wikispeed shops because it costs about $500 and then you can build a car. We're very careful to say we only pick designs that are build-able with those two tools which allow us to do a lot of things unless it's absolutely necessary, unless it's absolutely important. We're very resistant to change that increases our cost to make change, that increases our marriage to certain pieces of machinery. Did that talk to your question or did I miss it?

Speaker 13: Absolutely, yep absolutely.

Joe: Thank you very much and please email info@wikispeed.com. A Scrum master and engineer would be a fantastic person to email back and forth to say, "What do you think about this?" Or to maybe even have you get hands on with us some times. Please email us.

Speaker 13: Will do. Sure will do, thank you very much.

Joe: Last question. Email us, info@wikispeed.com. It goes to the whole team.

Speaker 14: Mine's a pretty quick question. First thing's, high five, so high five, good job, yep awesome. Second, thanks for making my job easier. I just happened to work at John Deere and the time you came into John Deere and talked about it I got a zillion emails so thanks for helping John Deere. My third question is, do you want to make a tractor next year for Agile 2013?

Joe: Open source ecology makes a modular open source tractor and they make modular open source bread ovens, circuit mills. They have this concept where there are these 50 machines that they think if they had all of them available in open source, and I think they have 13 now, that you could replicate our current standard of living with all open source machinery. The idea being there that if a rural farmer, if their tractor broke, they wouldn't have to go off and send for abusively priced maintenance parts. They could choose to fabricate their own where it's guaranteed that since it's open source they could have multiple vendors vying to have competition. It removes artificial scarcity. I think that's a pretty cool idea. I don't have the clear vision of it. I'm not [inaudible 01:25:30] who's essentially their product owner, the person with the clear vision. I think it could be amazing. I have a pretty clear vision.

What team Wikispeed did is we took one of the versions of our car and published it all on open source. It's one of those 50 machines. One of their 50 machines was a car, and one of them is now one of the versions of the Wikispeed car. We have other versions of the car that aren't totally open source, but one of them is. Without ever talking to us, you could build your own Wikispeed car. They're using parts of it to talk about how they're going to evolve their tractor. John Deere has all sorts of interesting plans and when they're talking about Wikideere, there's some stuff that could get really exciting. What I can say is, I signed an NDA on that.

What I can say is existing major companies are starting to do really interesting avant garde things that most of us wouldn't have expected from those companies ever, but are becoming the norm to keep up with the rapid pace of evolution from this new global village that we all live in with a lot of it being open source and collaborative. Wikispeed isn't wholly open source but we have a complete open source car. Open source ecology is completely open source and they have created a tractor system with interchangeable modules. Other companies are considering these tactics if it increases their pace to make change and they're finding out that it does. The world is getting more awesome everyday and you can go online right now and look at all the plans, the budgets, the video instructions to build a tractor, and you can add a nuance to it.

Say maybe you don't have the entire project vision of a tractor, but maybe you say, you know my uncle owns a corn farm and when he attaches the corn head implement to harvest corn, it takes him like three tries and he has to climb up into the cab and go down and modify the connection and go up into the cab again and try to do the connection. On this open source tractor, I'm going to put this idea I had down and see if anyone tries it and gives feedback, and you will get feedback from people all over the world saying, "That's a pretty good idea, what if he did this?" It will evolve and that will help everyone because it's in open source. If your question was, are we going to build a tractor next, well our car's modular, we could, but if your question is are we going to build a modular tractor next, there's already a group focused on it that's doing amazing stuff that we're attempting to help in every way we can figure out how to help, so maybe that's happening already. I don't know if we ... Yes, mic, paper, rock, scissors.

Speaker 15: Thanks for sharing your enthusiasm. I have a question as you look back at this journey that you had, this awesome journey. Can you think of the single most important moment where you had an epiphany either to imagine this future, or to scale this future to what it has become now?

Joe: Thank you for asking. I think it was, can you think of the moment, a moment where you had an epiphany about the vision of this project and product.

Speaker 15: Yeah, the most important, what you were doing, what ideas combine together to create this epiphany either to imagine this or to scale it, the most important moment in this journey.

Joe: Luckily there was a clear moment. I think it's talking to your question, I hope so. If it's not, email me. On my honeymoon, my wife is Japanese and I was born in Indiana and then have moved around the United States. When we got married we wanted her family to be able to come and mine too, so we went to Hawaii together and we were able to have the same number from both of our families come, which was fantastic. I love cars and on Maui there's this really twisty road called the Road to Hana. Hana is this little town on the tip and there's this cliff drop off to your left and these white cap waves slapping against the side of the cliff, and to your right it's basically rainforest. It is gorgeous. It's this wonderful driving road in the lush, natural beauty, it's astounding. We rented a turbo charged Mazda speed Miata. We're wagging the tail of the car as we go around, newlyweds, and it's wonderful.

I had this moment where I thought, if it were this hot, dusty day and the air smelled like exhaust, even doing exactly what I'm doing wouldn't be nearly as enjoyable. It's that I'm in this relatively pristine natural setting. If everyone in the world, almost 7 billion of us, got to enjoy the same feeling I'm feeling now, that'd be enough soot out of the tail pipe that those white cap waves would have a brown tint and that rainforest would be more wilted. What I'm doing is really fun, but it's not actually sustainable. Something flipped and it actually kept me up at night and it still does. Each day, for whatever reason, if I haven't done something to make that same feeling, it's very feeling specific. For me it's absolutely in my gut, which I think is what I think actually makes an excellent product owner, if they actually feel it and can taste what the world will look like when it happens.

If I feel like I've made some progress towards people able to have that feeling while driving, which to me I think is one of the peaks of the automotive part of Wikispeed, while being a little bit more or a lot a bit more environmentally sustainable, and at a lower cost of ownership so that's not a privilege just for the ultra-wealthy or elite, then I actually sleep very soundly at night and that's when the bit flipped for me. When I do product owner workshops, I don't call it guided meditation because that's a charged term, but I absolutely have everybody who's going to be a product owner take a deep breath, take an exhale, close their eyes and imagine the day in the life of the customer when they're using that product or service. That seems to make a big difference in actually having them be a vision champion, which is probably the only absolute responsibility to a product owner in my view. I hope I talked close to your question.

Speaker 15: Thank you.

Joe: Please email me, I went long.

Speaker 16: You're going to have to hang on to that one. Unfortunately, we're out of time. We are over and we are supposed to be starting to finish up the room. All of you please join me in thanking Joe for this. This was a really amazing thing to see and to have you tell us all about it. I want to thank you very much. If you do still have questions, I know Joe is still going to be around for a little bit and of course his email address and all that other stuff. Thank you all for a wonderful Agile 2012 conference, safe travels home.

About the Speaker(s)

No bio currently available.