Joe Justice: Managing a Collaborative Multi-National Team in Real Time Transcript of 22

Joe Justice: Managing a Collaborative Multi-National Team in Real Time
Transcript of 22 min video edited out of original 55-92 minute video

Agile2012 Dallas, TX 13-17Aug2012, original version:

Edited version: xxxxxxxxxxxxxx

We Built a fast, affordable, safe, ultra-efficient fun-to-drive car, and the first working prototype to achieve 100 miles per gallon was built in just 3 months. 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.
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. /
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.
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 toolsthat are expensive to change. /
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 hot-swappable 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. /
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 10th 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. /
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.
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. /
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. /
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.
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. /
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. /
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.
11:03 – 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.
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. /
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. /
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 co-located 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.
[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.
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.
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.