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.