Joe Justice: Managing a Collaborative Multi-National Team in Real ...

Joe Justice: Managing a Collaborative Multi-National Team in Real Time – Transcript of 52-92 min video
Agile2012 Dallas, TX 13-17Aug2012, www.agilealliance.org/resources/learning-center/agile2012-keynote-joe-justice
00:00 – [Joe Justice introduces himself and then introduces Christopher Gong from Deloitte’s Center for the Edge. Not
transcribed]
00:29 – [Christopher Gong, Deloitte Center for the Edge, makes the general argument for agility by reviewing the
2011 Shift Index material. Not transcribed.]
04:15 – [Gong then moves to cars and Team WikiSpeed. Low value, not transcribed].
07:03 – [Gong still] The more time you spend with the team you realize it’s not so much about the tools that they
use, but the better practices and the better cultures they’ve created around these tools. It’s not that WikiSpeed uses a
KanBan 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. And it’s not that they
have a CNC machine, but that they are committed to rapidly iterating on their vehicle, which they do every seven
days. So it’s the combination of these tools and these practices that has created the results that Team WikiSpeed has
been able to achieve. Now seeing the way these tools have been applied in the auto industry begs the question, how
much better would the world be if we were 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 are facing as a society today. Now as
Joe walks you more through his methodology, and how that applies to different clients and different situations that
he’s worked in, I want you to think about that, just that. I would invite you to think about where we can apply these
methodologies and these tools to make society a better place.
08:25 – [Return to Joe] Thanks so much Christopher. Now Christopher’s day job at Deloitte’s 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. And if I look at the tech companies where agile already has a strong foothold, all of the top ten
have agile teams or are 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.
09:34 If we look at manufacturing and hardware development today, we see
it looks almost identical to the waterfall model software teams 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 ten 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 3 years.
Parts of that car were designed over the last ten 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.
10:25: New software teams, agile software teams, lean software teams, kanban
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 Beedle, Ken
Schwaber, and Jeff Southerland’s business in 2003, Agile Project Management with
Scrum, we saw recommendations of 3-month sprints or faster, with 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. Tem WikiSpeed to my knowledge is the first
automotive company, registered automotive manufacturing company, to have 7-day iterations. That’s very different
that a 2-1/2 year minor-model-change cycle, and a 5-7 year major-model-change cycle.
11:25 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 use 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 die, where
they’re stamping a door for the model S, is milled, engineered, and placed on
a multi-ton pneumatic press, and each of those door molds costs more than
$10 million, 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 ergonomic, less expensive design for that door tomorrow, they
would want to wait ten years to first amortize, pay off, the cost of the
existing door mold before making that change. So existing manufacturing
changes slowing because they’ve chosen tools that are expensive to change.

12:29 In Team WikiSpeed we had to try a different approach, and I have a
software development background as do most of the people in this room. I
was used to thinking I can’t design a whole solution at once, it was to big to
even have in my head at once. I had to split it up into pieces, modules.
Object Oriented Programming says: first have a clear interface, and then
have classes, then you can change those classes, and you have hotswappable
loosely-coupled modules. That’s exactly how we engineered the
car. The car’s built in eight parts, or modules, and they switch independently.
This means we can roll out the gasoline engine and roll in an electric drive
train, a bio-diesel drive train, a methanol or ethanol drive train, in about the
time it takes to change a tire. This means we can change the entire car body
from a convertible to a pick-up truck. This lets us change quickly, and this
also gives a level of flexibility for our customers that they’ve never had in the
automotive space before.
13:29 The team works using agile, lean, scrum, kanban, XP, and what I’ll call
XM, but its really just exactly the same processes, 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 its eight 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 cares 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 10 th place in the mainstream class.
We didn’t win. We didn’t get the $10 million prize. but we cam in ahead of
over 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.
14:33 When other teams were figuring out their planning phase, 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 frontal test,
we need to achieve more than 100 miles per gallon on the EPA UDDS city driving cycle. And we had failing tests, and
said all right what’s the fastest leanest thing we can build that will pass this test, how about this test? And never
asked ourselves 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.
And we had a Scrum master as 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 screwdriver 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 the temperature. Anything they can do to increase the velocity, they sustainable velocity of the team, without
being in their way. And they’re a process steward. But by the time a team has done 10 daily stand-ups they’re calling
for the daily stand-ups themselves. And it only takes then a very savvy coach, scrum master, who studied some team
psychology to be able to add additional value.
15:56 – This is what a vertical slice of a car looks like in our
world. 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 n-tier
design if that’s how we’re doin’ 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 with the design and development cycles of traditional
automotive manufacturing the difference is two orders of
magnitude in time.
15:45 – Two years later we have this. I hope what you’re able
to see is that these methods might not only 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 hop
you guys are starting to get out of this is that everyone in this
room is now not just on the avant guard 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.
17:40 – You’ve been in sessions on XP and here’s your first on XM, if this is XM. You’ve been in sessions on scrum.
You’ve been in sessions on the agile umbrella that encompasses some or most of these methodologies 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 (Deloitte start-of-presentation segment) is correct, the largest change since before
the industrial revolution. Nor everyone here might agree with Stephen Denning. I do, when he says the agile
transformation is a larger shift then the industrial revolution. We’ll find out, we’re on the cusp of that right now.
18:20 – Here’s one of our kanban 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, swar out engine module V4,
reroute exhaust in engine module V2. These are
hardware manufacturing tasks.
18:43 – The tools we use to do this are all free, and
none of them existed ten years ago. Most of them
didn’t even exist five 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 five years
ago.
19:05 – We now have 150 team members in 18 countries.
You’ll see highlighted in red is our newest shop in New
Zealand in Christchurch, New Zealand. Do we have a few
folks from New Zealand here today? We do. Everybody
please thank the Kiwi country for being KiWikiSpeed. Thanks
guys very much for coming down.
19:28 – [Joe Justice introduces a team member from Turkey, Emre Aras, who speaks about his newbie insertion-inthe-team
experience. Not transcribed]
23:10 – [Joe’s back] 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 too show you
what the pace of development can look like in some other
industries we’ve had a chance to work with since the last
time I was able to speak at an agile or a scrum gathering.
23:36 – 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 are carbon dated to have been the same date as the fossils next to them, we see that their tool set was
very advanced compared to any of the other creatures on the planet at that time, and didn’t change fundamentally for
over 2 million years. And then we see Homo neanderthalis and Homo erectus having a very similar tool rate of
change. And about 150 thousand years ago, we have through genetic randomization dating, essentially the same
genetic structure as we have today. And we have Homo sapiens. And we also have modern chimpanzees, our closest
living relative. At that time the anthropological record indicates there was about one million Homo sapiens and about
one million chimpanzees. Homo sapiens began to change their toll set within a single generation. Homo sapiens 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 its
end. And we have the rate of adoption from having a phone in your household to having a cell phone 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 seven billon now, almost, Home sapiens on this planet, and
there are 65,000 chimpanzees. You can look to ask, has our closest living relative changed its tool set or the way it
extracts energy from the environment around it? No. It hasn’t. And if you look at Homo sapiens over the last 150
thousand years and ask 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 from anything else on this planet.
26:01 – John Deere heard a TedX talk I gave and saw a magazine that Team WikiSpeed was in. They sent three

managers our garage in Seattle, Washington, to take a look at what we
were doing. And then they invited me to their world headquarters at
Moline, Illinois, to give a talk about what they called “frugal engineering”
and “frugal innovation”, and I had found this quote. And we talked about modular tractors. We talked about a start-up
making open-source 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, agricultural tools. They
were very curious about it, and wanted to know about this trend.
26:52 – And then, I gave them this quote. John Deere and their
predecessors have been building tractors 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 percent. 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.
27:32 – A Dartmouth study cam out that was handed to me by someone
at John Deere about the same project, and they reported the project ran
6 months over, and the engineers were working 12 to 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 know that the pace of development was changing in the whole world
around them. And it might be time to evaluate 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.
28:24 – And I just got a call last week where they were saying “what would Wiki-Deere look like?”
28:42 – Then, Boeing contacted Team WikiSpeed, and their just up
the road, the largest aircraft manufacturer in the world, and they’re
in Mulkiteo and Everett, Washington, and all over the world, but
that’s their headquarters. We’re in Linwood, Washington now, just
north of Seattle. So were about 20 minutes away from each other.
They said “we would like to give you a tour of our 787, 777, 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 had 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 loose 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, it’s astounding. It’s like the Arc of the Covenant scene from
Indiana Jones, but all planes.
29:40 – Then we talked about MakerPlane. MakerPlane is an agile
aircraft company. They’re building four and size 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. And so Boeing is looking at these groups and saying
“What does that mean in terms of pace of development? How can
we accelerate the pace of development with high quality?” And those
are sessions that all of you have been attending all week.

30:16 – So after going to their enormous building, we took them to
our Lynnwood shop. They hosted a diner there and sent fifteen of
the executives over. That’s the first time we’ve ever had a diner
hosted in Team WikiSpeed with table cloths and everything. One of
their double PhD computational fluid dynamacists 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 “Vice versa. We’re still very small.
Let’s be good friends”. But 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.
31:09 – Then I had the privilege to go to Tait Radio in New
Zealand. Tim Myer went with me, another Solutions IQ
employee, who also after work volunteer’s his time at Team WikiSpeed. Tim Myer’s expertise is test fixtures, and test
fixtures now not just for software and continuous iterations and automated test coverage, but the same for physical
manufacturing. He paired with our electronics team in Mea, France, to develop and implements an accelerator pedal
recorder, allowing us to be driving and record accelerator pedal pulses and drive cycles, and play them back for
automated testing to see if the changes we’d 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.
32:18 – 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 a rack and receives radio signals
form other devices, performs digital signal processing, and reemits the
signals to transmit them at further distances than a hand-held or a mobile
can do to each other.
32:46 – 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, And 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.
33:31 – And the product owner [video of Tait employee David Jenks begins]: “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 vs
another option. So the example was that I asked about the 50 100 Watt change
doing a 100 to 50 with respect to the different disciplines in the stand-up and
were in three minutes able to get a good estimate of the impact on each of the
disciplines. That contrasts I think with weeks to get a feel for making that choice.
That was a real example for me.
[Tim Meyer behind camera repeats for David’s confirmation]: “So in this case, being able to have the team in a colocated
area, and simply ask the question of everyone at their workstations in this co-located area, you were able to
get an answer in about three minutes. In fact I think the decision was made in ten minutes on a 50 Watt amplifier,
and we ended up choosing a 100 Watt amplifier, by knowing how this would impact each team member and what risk
that would give. And it would have taken a couple of weeks in a non-collaborative work model.
34:49 – [Joe Justice] The product owner reported see the same type of velocity increases in terms of team decision
making, which was a novel concept entirely for a command/control culture previously in some of the organization. A
decision/resolution made in three minutes, and a decision ratified among the entire team in ten minutes. Instead of
the team being told what the answer was, the team came up and then spread consensus in ten minutes, in what
would have taken, he said, multiple weeks. A small win. Later that same week, David Jenks again, the product owner,
said information bubbled up by having people from different disciplines working together on this same problem,
saving them more than one person year of work across a core team of seven people and a lot larger team of about 27
people.

35:35 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 prototype being interfaced with by a customer. It was
able to be done in one week. And we didn’t, Tim and I, 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 hand by 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, Kanban, XP, XM if you’d like it. We ended up running
sessions on all of the above.
36:33 – 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 automated line. Their test fixtures are cardboard, just like many of the
parts that WikiSpeed cars start out as, as we iterate “stubs”. They already practices stand-ups in their line
manufacturing, in their HR department, and in their marketing and project management department. While we were
there they started using retrospectives in those departments. While we were their we talked about adopting a product
owner and a scrum master role to have a team steward servant-leader embedded in the team, and someone with a
clear vision of the end-state of the product. And we saw the result of that with product owners and scrum masters in
HR and in the company change-management team.
37:24 – 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’s Tim Meyer on the far right in the blue
shirt.
37:42 – Why doesn’t every company do this? The number one reason that we
hear as we come into companies is: “I’m not sure that can fit with us”, and
that’s cultural inertia. Companies have been doing it the same way for up to 175
years. In some case 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 in 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, and
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. And we say no, it’s much
simpler than that. It’s actually a short list of KPIs (key performance indicators) used to incrementally fund budgets
every week. Were 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. And once they do, they report more
nimble company management. And that they’re actually able to be financial stewards of the companies resources.
39:18 – 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.
39:30 – Now here’s how Team WikiSpeed applies these principles. Here’s a safety
iteration of us going through an evolution of our car in seven 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 completely iterated the safety
systems of the car. Now we are able to iterate the safety systems of the car in seven days. Here’s how this happens.
First we pick a test. In this case it’s the NHTSA Side Impact Test.

14:03 – Then we simulate that test in CAD. This is the side
impact test where the the side impact barrier is colliding
with our chassis, and we see the stress spread across the
frame, the chassis of the car. Then, to determine the
accuracy of that test, we physically conduct crash testing.
14:17 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 affors to run this
test every seven days. So instead of relying on this
test every seven days, we conduct it whenever we can
afford it it, and use it to make more accurate our
simulations, which we do run every seven days. Then
we iterate on that design.
40:47 – 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 wanted to do better. We wanted top tier
safety rating. We wanted no side impact penetration.
41:03 - Within hours of that video circulating through the
team, this father and son team iterated on a new side
impact module and attached it to one of our chasses, and
because of the modular architecture it’s able to be attached
to every car we’ve ever made.
41: 19 – 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 for the car. In this case it’s a new exterior of the
car drawn by Rob Mohrbacher of Mohr Composites in
Germantown, Maryland, who during the day 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.
41:46 – The team decided they liked it, and we voted to
make it. So we used a computer to control that router, that
CNC machine, to machine it in foam in one day. So now we
have a life-size buck of the car to walk around.
41:56 – And then we lay it up in carbon fiber, in one day. So
now we have a structural carbon fiber shell that we can use
for aerodynamic testing.

42:10 – Then we go to the largest auto show in the world, Detroit 2011 in January, and we put it on the mail floor
between Ford and Chevrolet.
I was terrified. I had no idea how it’d be received. I knew during the first week, it’s the industry preview, where the
executives and board members of every major automotive company and supplier are mixing around because it’s the
first time to see the competition’s new products. It’s their first chance to sit in the competitor’s vehicle. I got to meet
many of those people. I thought we would be ignored, or that we would be dismissed, or 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 gettem. … I’ve had a lot of time to think about it since then, and the
best idea I have about why that might of happened, is, I think, they know this is something they need to do, or
something like it. But their board and the rest of the C-suite is saying “well cost accounting tells us to make the next
version of the Ford F-150, 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 where our existing profits count.” So I think the C-suite and board members that came up and shook my hand
were thinking “Yes, this needs to change and we need you to succeed 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 its going to take 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.
44:38 – Then, in the same aesthetics iteration, to be filmed
by the discovery channel. And then launch a crowd-funding
campaign to revolutionize the future of automotive
manufacturing.
44:53 – [very well done crowd-funding campaign video – ignored here]
46:40 – That crowd funding 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
we can keep on iterating on the products we care about with safety as our priority. So 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. people see me talk about it because I’m very passionate and I want to worl to see and use these practices if
they want to. but Tem WikiSpeed is massive. If it were just me it wouldn’t look anything like it does now. The car
would probably still be mostly steel with some cardboard because I wouldn’t have learned how to correctly and safely
use aluminum and composites yet. It would probably be just half a car in my garage. 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 come visit our shop and apply
some coaching. Thanks very much Mary and Tom. We were lucky enough to have Cory Ladas and Jim Benson become
Team WikiSpeed members, and apply Personal Kanban and Scrumban 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 encourage you to email info@wikispeed.com and have a
WikiSpeed member pan pal. Or even join the team yourself. With that said

48:39 – With that said I would like to unveil Mystro. Not many agile conferences have an automotive unveil, bet we’re
at a unique intersection between process and manufacturing right now. I’d like to show you the 2013 WikiSpeed
roadster. We’re determining its name. It was created by Rob Mohrbacher in Germantown, Maryland, and then
collaboratively built by team members all over the world, And here team WikiSpeed members are going to show you
the 2013 WikiSpeed Roadster 120 mile-per-gallon modular commuter car. […fan fare…]
50:00 – This car was built by agile 2012 conference attendees
yesterday. This car was built behind that screen by people in two
sessions. So 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 that allows us 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 “how many of you have ever built a car
before”. One of them said “I’ve rebuilt most of my old Volkswagen.
And no one else raised their hand. We were from very diverse
backgrounds. We created a backlog, a kanban 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 of here’s how to
build a car. We have people that have never built a car before engaged productively 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.
51:11 – The people who built this car I’ve never met before. The built a car 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 will be an exhibit
between the cockpit of 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 the WikiSpeed 100 mile-per-gallon car. … And it was built by you guys, in
one day. Now that said I don’t want to take credit away from the Houston shop. The put the chassis together and
verified the parts were there. And I can’t take credit away from Rob Mohrbacher who made the beautiful body and
shipped it in via freight. It arrived on Wednesday and we hid it backstage. I’d never seen it before. This type of
distributed collaborative team allows us to be constantly surprised by the successes of each other and help each
other. … This is a picture of a gorilla high-fiving a shark in front of an explosion.
52:30 – [Joe switches from cars to other social-good problem-solving also done by Team WikiSpeed – not transcribed]
55:00 End of talk
55:30 Q&A begins
56:25 Q: What’s really standing in the way is the financial system that stops us from getting to agile in the industrial
scale. Software capitalization rules make us do stupid things. You’ve just said it’s the same thing in the industrial
activities. What do we have to do as a community to change the generally accepted accounting practices that we can
amortize things that aren’t perfectly built, designed, and technically feasible before we start capitalization and
amortization. A: (Pat and Walt’s session on Wednesday has a good start on agile accounting) ….
58:26 Q: How do we get a car of our own. A: …

62:15 Q: To help fund WikiSpeed, where can e get a T-shirt with the Gorilla high fiving the shark. A: ….
64:30 Q: What is your longer term vision for the care manufacturers. Do you see this scaling up to a larger car
manufacturer. Would it then turn into a for-profit car operation. A: …Were not against profit but that’s not what we do
…….we want to make a difference for the environment … more customer relevant, more environmentally sustainable,
and lower overall cost of ownership, we’ve done the right thing. We see all of our current competitors as future
partners.
69:43 Q: I’ve been coaching, so facing the pain of transformation, and view this work as disruptive. What do you see
of current manufactures succeeding with this instead of new disruptive manufacturers growing up around them and
eating their lunch? A: 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, and so what seems to be happening, and what has 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. Then they’re raided and disrupted, and 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. 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. That’s what all these practices are all about.
We all know this. But sometimes it’s easy to get dogmatic, and we know when that happens, the excitement starts to
leave the team. The other part of that is, if there’s anything Team WikiSpeed is doing that’s actually new – because
everything we’re doing 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 moral as a multiplier for velocity. That’s not very common yet. I’ve heard a few
sessions about it [here at the conference], 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. I bet that that’s what might serve these companies, being
good at having highly motivated teams that are making changes quickly. They may be able to stay on top of their
markets. But that doesn’t address how to convince or encourage or support an existing company try to make change.
There’s the thought that you have to give someone at least five compliments before you can ask them to change. It
might be finding 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 amagine, from a loving angle at 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. 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 is customer focused. Did that talk to your question at all or did I go sideways and talk in a
rant?
72:42 Q quy responds: No, actually that was really good. But I think when you were talking there about, um, 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 hundred
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. When they feel like you’re there to help, then you get the ability to
influence them. And that, to me, takes a long time to be able to build that up. That’s my fear, of them not actually
transforming. Then it takes a 2x4 to the head and that’s a lot more painful for them then a nice transformation.
73:39 A: I used to feel that level of resistance at the clients I’d go to in my day job. I don’t any more. That example
at Tait radio – they were already doing some strong practices that they had found by working with Mary and Tom
Poppendieck, and Henrick [Kniberg] . 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, the pace of culture change, go through the roof too. What I see as a – I will get on my high horse for a just
a minute – is I see people come in and talk about organizational change as if it’s this road map in this cycle. What?
We’re agile.
[excitedly] I run into a client and say “You have permission to do what you need to do. They do, right? [said
sideways, to management presumably]. 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 Q ball, 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,a nd what they’re doing that day when they’re
using your product or service, and what they ate for breakfast, and how it relates to the rest of the tings 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. You’re now this thing called the product
owner. Who’s going to run get everybody screwdrivers and lemonade? Okay, for today at least you’re the scrum
master. Do you have a background in team psychology? No. Well maybe go to a coaching clinic next week.
Week one we have results. That starts to have people from other teams come in and look, saying “what’s going
on.” And we have an all hands session saying everything you gave this team once a year, you’re no 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? And we have radical transformation very very
quickly. And 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 really the vision holder for the
company? If so, can they be the product owner for the company? By that I mean, can they be here every day to
answer questions for the change management team?” No? Well then who is actually driving the vision? Nobody?
Surprise! Okay, let’s marry that. let’s figure that out, on day one.
And that can happen. I’ve been seeing it happen. So I don’t think change adoption has to be a long, slow process. In
fact there’s some evidence that says that might be true. I’m now off that high horse. I could be completely wrong.
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. And 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 for 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.
77:11 Q: I have an engineering background and now I’m a scrum master. Your car doesn’t have doors. Is that by
design or expediency, or how was that decision reached? A: …[Good discussion on iterating for crash test success
starting with a Honda front end. … we only pick designs that can be built with our cheap milling machine and metal
band saw - $500 total – unless something else is absolutely necessary.]
84:15 Q: Will you make a tractor for next year’s Agile 2013 (I work for Deere). A:…somebody else is already working
down that path …
88:00 Q: Can you think of a moment in your journey when you had an epiphany about his project. A: …
91:00 END