Joe Justice will be giving a keynote presentation titled For Maximum Awesome at Agile Development Conference & Better Software Conference West 2014, which will take place June 1-6, 2014.

About For Maximum Awesome:

An agile hardware and engineering company of five hundred collaborators in twenty countries, Team WIKISPEED uses test-first development practices, is run by Scrum teams, and produces road-legal cars, microhouses, and social-good projects. Joe Justice shares how their one hundred-miles-per-gallon road car was created in just three months through object-oriented design, iterative development, and agile project management. Joe describes how agile software techniques are applied to physical engineering and manufacturing and how cross-functional team members can eliminate the constraints we imagine around traditional manufacturing. He shares the design and development of their ultra-efficient, modular cars and their clients' projects in satellites, laboratory equipment, missile systems, radio systems, medical devices, software projects, service deliveries, marketing, finance, HR, and other areas. Hear examples of exactly how to launch or relaunch your projects and organization with Joe’s methods. Get inspired to change your world for the better.

 

Cameron Philipp-Edmonds: Today we have Joe Justice. Joe is a consultant at Scrum Inc. and the inventor of the Extreme Manufacturing project management method. He’s also the founder of Team WIKISPEED, an all-Scrum volunteer-based, “green” automotive prototyping company.

Joe Justice: Totally—exactly right.

CP: All right. Joe is a principal thought leader in Scrum. He’s a TEDx speaker and a coach for agile hardware and manufacturing teams worldwide. He consults and coaches teams on implementing Scrum at all organizational levels, both in software and physical manufacturing. He’s been featured in Forbes, CNNMoney, and on the Discovery Channel. Joe has been widely recognized for his work in reducing time to value in organizations globally and within Team WIKISPEED. Did we cover everything?

JJ: Oh, my goodness. Yeah, that’s right, I’m a principal consultant at Scrum Inc.—Scrum Incorporated—based in Boston, but we're global. I just got back from Amsterdam and Munich, Germany, the week before, a few days before that, and head off to India shortly—all from Scrum Incorporated to do that work. Then, I’m next to the WIKISPEED in Lynnwood, Washington, shop right now, and I can look outside the window and I can see car number one. I can see our first micro-house prototype to help make a dent in involuntary homelessness.

CP: OK, awesome. Working at Scrum Incorporated, you also get to work directly with Jeff Sutherland, who is the cocreator of Scrum. What’s it like working with Jeff?

JJ: Oh, my gosh. I imagine it’s, for a lot of folks, getting to work with a guru. I’ll be coaching a team and they’ll have a question about the way they run the daily meeting. Jeff might be involved, and he’ll walk in and say, “Well, when we first started the daily meeting in 1994, this was the research that we based that on. Here is why we kicked that off.” It’s phenomenal. Instead of just getting good practices from Jeff, you get the origin every time. Then you usually get a set of five or more evidence-based studies and academic white papers because he’s a PhD statistician, and that’s exactly how he thinks and how he’s wired. So it’s a deluge of data and of evidence for each and every practice constantly, and also all the background. It’s phenomenal. For a process nerd like me, it’s like working with a rock star.

CP: Awesome, fantastic. You are quite the rock star yourself. In fact, the keynote that you are doing here at Agile Development Conference & Better Software Conference West 2014 is titled For Maximum Awesome. Why is it titled For Maximum Awesome?

JJ: Yeah, what we need to do is go directly to teams' mindsets, to the way people think when they walk in the door at work, or even before they walk in the door. If they are going to deliver "maximum awesome," they’ve got to know it. They’ve got to have stories that are brought to ready before they—the team—even gets them, so they can pull them and run. If we want teams to rock as hard as they can, then they’ve got to be performing like top-level sports teams. That’s absolutely a mindset, a way of thinking. There is a fantastic book, titled Happiness, created by a set of teams at Harvard, on how happiness is causal for team performance.

Well, not just teams—doctors giving more accurate diagnoses and having better outcomes directly related to how happy they were when they got into the hospital that day. So, different than “I’m happy because I’m doing well,” but it’s happiness causing excellent performance. Then Niki Harré, the dean of psychology at the University of Auckland, has done her body of research on happiness in teams creating better outcomes for the companies, for the countries, and for the individuals. For Maximum Awesome is all about the way we’ve got to think to create "maximum awesome."

Then, the idea being that if we all hit double velocity—which is average from when teams start doing Scrum. Some teams hit 10x velocity, the amount they are able to get done in a given increment of time with quality. If they do that, what are they going to do with all that extra time they have? What we propose is that they should do some social-good work, and that’s what Team WIKISPEED is for. It’s a group that people can join from anywhere in the world, where they spend about two hours a week rapidly solving problems for social good. It’s basically that outlet for when teams hit high velocity.

Now they are going twice as fast or faster—they have 50 percent or more extra time, they are going to spend a lot of that time delivering even more, so getting more than double velocity. Well, take two hours out of the week and make the planet completely awesome, and if we do that, we’ll live in the world we want to live in.

CP: Wow, I bet that’s definitely pretty awesome. You were the founder of Team WIKISPEED. What is your current role and what is the current status of Team WIKISPEED?

JJ: Yeah, I’m the team lead, and that often makes me the product owner, but not always. We are one of the few Scrum teams that rotate product owners, and in our case we rotate them based on what’s in the current sprint and who knows the most about it. If we have a whole bunch of aerodynamics tasks coming up, whoever knows the most about aerodynamics in the team will be the product owner role. I’m often the product owner, but not always. Then, in the build parties, which is how we get our work done every Thursday night and most Sundays, I’m a team member.

I’m completing these backlog items as fast as I can—pairing with other team members and helping bringing backlog items to a ready state, where they are clear enough and concise enough. We know we have all the tools where we can grab them and get them done. Also, on paper I’m the CEO, which means I did file the articles of incorporation for the company. I manage the stock disbursements—which, actually, we have none. We reincorporated as a nonprofit. We don’t do stock disbursements anymore.

I also manage the licensing of our open source products. I verify that they are freely available and that the folks that are using our products are adhering to our open source license. I do a lot of the business end of Team WIKISPEED, as well, and manage a lot of the finances for the team. We are primarily supported by people sending us ten dollars a month through PayPal, and that funds shops in twenty countries. We’ve had dramatic success with that. Those funds go into the Team WIKISPEED account, which any team member can manage. A lot of the time that’s left on me, because people want to go build cars, micro-houses, and make the world a better place.

CP: Well, yeah. You sound like you have a lot on your plate with Team WIKISPEED and with Scrum Inc. How did you have time, and can you tell us a little bit about what you have planned for us for the keynote at Agile Development Conference & Better Software Conference West 2014?

JJ: Totally. Well, I can't wait to see you guys in Las Vegas. We are going to have, I hope, the best time possible together. I use personal kanban for my own time. I spend about forty hours a week working with Scrum Incorporated, Scrum Inc., and about forty hours a week working with Team WIKISPEED. Yeah, that’s most of the time. Absolutely sustainable, because it’s mission-driven. Both of those items directly appeal to why I believe I’m on this planet, and it makes it easy to find the energy in that case. It’s not like I can't wait to get out of work after forty hours and go watch baseball or something like that, something that helps me feel free.

I feel that at work, and then I can't wait to feel it even more at Team WIKISPEED. Personal kanban is what lets me keep that sustainable and help me keep my velocity high, because I always know what’s happening next, and when I have a distraction or an interrupt, I always know what’s next again. I’m always able to improve my flow because personal kanban gives me a flow visualization of everything I’m doing.

At the Better Software Conference in 2014 that’s in June in Las Vegas, we get to do something even a little bit more dramatically awesome. We get to build one of the cars that one of our customers has bought.

I’ll be bringing in a set of eight modules that can compose our WIKISPEED cars, our ultra-efficient carbon fiber cars, and anybody who’d like to that’s attending the conference can come and enroll in the sprints. We’ll pull from a backlog, and it won’t be "bolt this to this," it will be test-driven development. People will get hands-on experience with test-first development, test-driven development, contract-first design, modularity, object-oriented architecture, and working in a Scrum team. I’ll be a team member. I’ll also work as a coach when I can. And we’ll have product owners and ScrumMasters solicited from anybody who’d like to show up that’s attending the conference.

It’s great for people that are new to any of this agile stuff as part of their Better Software journey, and people who are deep experts. In both cases they get to have a tremendous amount of fun and we get to actually build a real, road-legal car together. I also get to do a presentation there, and I’m excited that folks get to hear the background of Team WIKISPEED and what to do next if they want to have some of these wins happen in their company.

CP: Yeah, awesome. You talked about how it’s great for beginners and people who are experienced in the industry. What is really the main point or points that you want attendees to walk away from after seeing the car built?

JJ: The biggest win we could possibly have is for people to understand what a high-performing team feels like. That’s difficult to describe in a book, and it’s difficult to create that experience for people to know what it feels like. Lucky for me, these build parties, where we have a total party while we are putting the car together, usually create that feeling. In fact, it has every time so far, and I hope that continues at Better Software. What that should mean is that anybody who attends this build or participates in a part of it should be able to then walk into a Scrum room anywhere in the world and know if that team has it or not.

A common feeling of new teams is they’ve read a good book about it, maybe a few people in the team have received training, and they start and they say, “Well, do we have it? Are we doing it yet? How come we are not going much faster yet?” They’ll be able to feel it right away. That’s the key, and folks who have attended this session will be able to know if a team has it or not just by walking in the room and seeing if it feels this way—that’s the biggest win.

Now, with that said, that’s maybe a little ethereal, even though that’s the strongest win we could have. We should also say that the concrete practices for getting started with agility in software projects and hardware projects will all happen during sprint one of the car build. The concrete practices for maturing and accelerating agile teams—including the architectural component, which is often overlooked by starting teams—will happen throughout all the remaining sprints. Then we’ll get to celebrate pretty hard at the final demo because we just built a car.

CP: Yeah, that’s pretty awesome. Now, in your TEDx talk, you talked about how a lot of work is done in pairs, which helps with sharing of knowledge and eliminates the need for unnecessary training. Are there any other reasons that the pair-off method is very advantageous?

JJ: Yeah, it builds cross-functionality. For example, we have an absolute carbon fiber expert in Team WIKISPEED, Rob Mohrbacher of Mohrcomposites. He lives in Maryland. We rotate pairs through with Rob to propagate carbon fiber knowledge. Now, Rob remains the absolute expert in carbon fiber processes in the team composites. However, by pairing with other folks, he’s learned most of the other skills required to build the car end to end. Also, all those other folks that pair with Rob, their composite skills are dramatically better than they used to be. They are still not as amazing as Rob, but they are able to do all the composite processes, it just might take them a little bit longer.

We are able to propagate skill throughout the team, which reduces our "bus factor"—how many people in the team would it take to get hit by a bus before the project would stop? For most teams, it’s one person. There is one person who knows how to deploy the build. There is one person who knows how to configure the continuous integration server, for example. Pairing helps propagate those skills throughout the team. It also allows swarming. Pairing, I would say, is the prerequisite to swarming.

Swarming, in our case, is when something goes wrong, something is stuck, people aren’t able to move their backlog, and they are done, everyone on the team is able to descend on that backlog item and push it to done. If we haven’t done pairing so people have some level of shared knowledge—shared skills—swarming is ineffective. By doing both, we’ve never hit a problem in Team WIKISPEED we weren’t able to crush by swarming on it.

CP: Fantastic. The thing is, you talk about it and it all sounds so great and so fantastic—really so awesome. Why haven’t other companies done this?

JJ: A lot of them have. A lot of them are now. We are seeing Scrum, agility, Extreme Manufacturing, Extreme Programming, and even now Extreme Innovation deployed in most of the Fortune 50 companies. If we go to the New York Stock Exchanges’s top IPs of all time IPOs, the money generated by their initial public offering—all of the top ten tech companies are Scrum companies. Companies are seeing the advantages of this. What Team WIKISPEED brings that is a little bit new is a clear set of technical practices that allows Scrum and many other agile practices to be used in hardware work—that is pretty new.

Only a few companies are doing that now—less than a hundred—and most of them are doing it because they work with Team WIKISPEED. I’d say most companies haven’t done it already because they haven’t yet become familiar with the technical practices required to use agility in hardware, also in sales, in research and development, in your legal department, in human resources. It turns out by quoting the Extreme Programming practices to manufacturing, we found we were able to generalize them to many other types of work. Now we have a whole bunch of Agile 2.0 companies—by that, companies that use agility across the entire company, from the board of directors to the delivery teams.

Those teams have usually started using Extreme Manufacturing in hardware or Extreme Programming in software. Then, they work with Team WIKISPEED to generalize those practices across their whole org. Those companies are now at the top of their sectors across the board.

CP: You talked about Extreme Programming and all these extremes. And you are the founder of Extreme Manufacturing. Looking now into the future—kind of big picture—how do you think this is going to impact the economy and, really the world as it operates?

JJ: It’s starting to happen. Last year I was invited to the world financial conference on sustainability and I was invited to speak to a number of EU delegates about Scrum being used to stabilize the European economy. That was amazing. I did not have the knowledge to talk about how we would stabilize the European economy, but I did know a lot about Scrum, and I got to share that.

In the EU delegates’ opinions that attended—the European Union delegates—they said, “Yes, absolutely, our job now needs to be passing policy that makes it easier for companies to start with Scrum and for existing companies to convert to Scrum as soon as possible.”

Not that Scrum is the only answer—agility as a whole is—but Scrum is the rightest left way to do it with teams. It has a highly successful track record, which helps these companies. We are seeing it transform at a global political level right now. The EU, in pockets, is adopting Scrum. Also, the United States Department of Defense has mandated agility for all defense deliverables. As a result, I now work with most of the military and defense contractors.

CP: Wow, that's pretty awesome.

JJ: It’s playing out on the international stage right now, where Extreme Manufacturing, agility, 

Extreme Programming, and Scrum are changing the way people work at all levels. The banking sector is booming with it as well: ING, Rabobank, JPMorgan Chase, the Royal Bank of Canada are all Scrum adopters. Some of them had additional agility technical best practices to help them accelerate their work—Scrum patterns, even, in some cases. The world is absolutely changing, and what we expect to see is companies are doubling in velocity. Companies who haven’t figured out how to do that are folding—they are going out of business.

In the TEDx talk I had a chance to give in November 2011, I proposed that all companies are going to have to try to work this way or they’ll become irrelevant or be unable to compete. That trend seems to have accelerated—that’s exactly what we are experiencing. Deloitte Consulting Center for the Edge calls it "the big shift.” It’s a massive die-off for companies that don’t have agility and a massive acceleration and very profitable time for companies who do.

CP: What does that really mean for—kind of from a social perspective—what does that mean for everyone else? You talked about how the price of a car—and you are building the car and whatnot—what does it really mean for some of the underdeveloped countries? Or even the EU, which has its own problems—what does it mean for a society as a whole?

JJ: It looks like goods are coming with an increased pace of innovation, so we think about the time it took for us to get from the iPhone 1 to the iPhone 4, for example. That amount of time should become one-tenth of the time. Not that there is such a meaningful jump between firms or processors or laptops or cars, but that the pace of innovation doubles or more. The Honda Civic Hybrid got an additional two miles per gallon across a six-year span. We’ll expect it to be two miles per gallon a month if they hit Extreme Manufacturing. We should see Moore’s law apply much more broadly than just computer power, but to usability, ergonomics, and user value as well.

That should become less—what can I say—centralized in the most developed countries and much more broadly distributed, where we have very rural, historically poor countries becoming even players in the international commerce battle field. The customers being the winner in every region.

CP: With that being said, what do you think the greatest challenge is for some of these undeveloped countries, or for really even companies here in the United States or anywhere else, to widely adapt that process of Extreme Manufacturing?

JJ: Cultural inertia is the biggest block I’ve hit when I’m working with companies. They say, “Well, this is the way we’ve always done it, why would we change?” Yet they have a mandate saying we have to produce the next tractor or the next software package in half the time and half the price if we are going to remain competitive. Yet they say often, “This is the way we’ve always done it we can't change. Why would we change?” As soon as companies are willing to look precisely at the way they do their work, suddenly they are allowed to make evidence-based decisions on their work, and that’s where these advantages come into play.

The biggest challenge tends to be this sense of "this is the way it’s always been done" or "that’s always the way we do it right here at this company." Maybe that works for so-and-so down the road, but it couldn’t work here. Once folks open their mind to the possibilities, that’s where we start to see big wins.

CP: OK. What is an easy way or an easy couple of ways or to get people started with the Extreme Manufacturing process?

JJ: For a whole company at a time, if they add a process coached to their board of advisors or their board of directors, they’ll be able to start adding agility across the entire company. At the team level, we would expect them to have a process coach or a ScrumMaster always monitoring the value stream map of that team. For a team member, we would expect them to be continually asking their teams’ process coach or ScrumMaster what they can do to increase efficiency across their team. For customers, we would expect them to start demanding much more frequent updates in hardware and software—not tolerating an eighteen-month or a five-year plan, even for massive hardware projects.

CP: OK. You also talked about, in one of your TED Talks, that you like to see visual flow and be able to visually see things. Are there any other tools you think are really important for getting the Extreme Manufacturing process now?

JJ: A visible impediment list—anything that the delivery team thinks is preventing them from accelerating is critical. If that’s not easily visible and anyone can't easily add items to it, it’s going to really slow everybody down. Then, support from the top tier. Usually the investors or the investors' delegates in the company through the board of directors. They directly look at that impediment list and they often need to make managerial decisions to remove those impediments. The impediments are typically organizational structure or the way they work with suppliers.

We have an executive action team who are working on behalf of the shareholders to remove impediments from the delivery team. The delivery team making their impediments extremely visible and thinking really hard about what they are during every sprint—what’s preventing them from accelerating. That entire flow is modeled by a value stream map and making their flow visible to optimize the amount of stuff they can get done with quality. That’s usually catered to by a skilled ScrumMaster who is making a value stream map of that team every sprint. Then we expect the burn-up chart—that gives us every win we would always wish for in traditional management.

We would want to know what’s going to ship, when it’s going to ship, and how much it’s going to cost. All of that is visible from the burn-up chart. We have the scope what is going to ship; we have when it’s going to ship in terms of a timeline with the standard deviation around it. We know what date range of when this thing is going to cross our threshold of becoming a viable product. Then, by knowing the consumption rate of the team, how much money it takes to run that team per sprint—and if it’s a hardware team, that includes hardware consumables—we then can project the end cost. It’s currently the most accurate way we have to predict all of the above.

CP: OK. I have a final question for you now. You’ve done a lot of great things with Scrum Inc. and with Team WIKISPEED and Extreme Manufacturing, everything like that. If you could step in a time machine, go back in time to the very beginning, and tell yourself something that you know now that you wish you knew then, what would that be?

JJ: It would absolutely be the visible impediment list. I would much better track what was preventing me from accelerating, and so I’d be able to get a lot more done every sprint. A little me—back-in-time Joe—would have hit a higher velocity much earlier. Instead of me being thirty-four years old right now running an automotive company and consulting with software and hybrid companies around the world, I might be working from the moon, living in a city of gold, air-dropping vaccines to solve all disease all across the planet.

CP: That’s definitely awesome. Once again, your keynote is For Maximum Awesome, and that’s going to be at the Agile Development Conference & Better Software Conference West of 2014. It will be June 1 through June 6. Is there anything else you want to say to the future delegates?

JJ: Yeah, folks, absolutely enroll in the build parties so we get a chance to rock together, hand-in-hand and shoulder-to-shoulder. And I can't wait to see you guys in Las Vegas.

CP: Once again, that was Joe Justice. Thank you so much, Joe.

 

If you have enjoyed this interview and would like to be a part of the action, you can join Team WIKISPEED at www.WIKISPEED.org, and can reach Joe Justice at [email protected].  You can also see a recent video of Joe Justice bringing awesome to the Netherlands by clicking here.

 

Joe Justice is a consultant at Scrum Inc. and inventor of the Extreme Manufacturing project management method. He also is the founder of Team WIKISPEED, an all-Scrum volunteer-based, “green” automotive prototyping company. Joe is a principal thought leader in Scrum, a TEDx speaker, and coach for agile hardware and manufacturing teams worldwide. He consults and coaches teams on implementing Scrum at all organizational levels, both in software and physical manufacturing. Featured in Forbes, on CNNMoney, and on the Discovery Channel, Joe has been widely recognized for his work in reducing time to value in organizations globally and within Team WIKISPEED.