We are excited to have Woody Zuill teach a Master Class in this fall’s leading complexity program. The topic is Software Teaming (Mob Programming)—addressing complexity with genuine collaboration.
Woody coined the concept of Mob Programming/ Software Teaming, wrote books on the topic, and traveled the world spreading the ideas.
Recently, we had the opportunity to talk to Woody. We asked him how he got into Software Teaming, why it is more relevant than ever, and what some of the benefits and most common objections are.
Here are some highlights from Woody:
I got a job where I was put on a team, but we never actually worked as a team; we worked alone. This made me question why we called it a team, and I began investigating the idea of working as a team. Most knowledge work requires collaboration, and very little work is done alone. Separating people introduces queuing and inventory problems. Waiting for responses and having multiple tasks in progress create waste.
I had an experience where our team needed to get something critical done but was blocked. I asked the head of the company to send an email requesting immediate help when needed. By the end of the day, we had 17 people working together on one problem. It took us two days to complete work that would have taken weeks in a typical manner. We removed queuing, inventory, and waiting, allowing everything to flow smoothly. Teaming minimizes waiting times and reduces the accumulation of unfinished tasks, leading to smoother workflows.
Check out this short interview below (9 min) to learn why Software Teaming is more critical than ever in today’s complex environment.
Join our Leading Complexity Program to learn more from Woody and the other thought leaders, and sign up to attend Woody´s Master Class, The topic is Software Teaming (Mob Programming)—addressing complexity with genuine collaboration.
Transcript of the interview:
Michael: Hello Woody, great to have you in the program.
Woody: Thank you, Michael.
Michael: You’ve written many books, given talks, and traveled the world around the concept of Software Teaming, also known as Mob Programming. We’re so happy to have you on the program. You’ve talked about it for years, but it’s still relevant, isn’t it? Why is it relevant today?
Woody: That’s a really good point. When I first started programming, I always worked alone as a solo programmer. That was until about 1998 when I heard about pair programming. I learned how to do that and started working with two people. In 1999, I got a job where I was put on a team, but we never actually worked as a team; we worked alone. This made me question why we called it a team, and I began investigating the idea of working as a team. I’d done other kinds of work where we collaborated much more and wondered why we didn’t do the same with software. This was over 20 years ago, and since then, I’ve been exploring different ways to work as a team.
It’s more relevant now because our problems are bigger. Most knowledge work requires collaboration, and very little work is done alone. When we started working this way full-time at Hunter Industries in 2011, we were naturally trying to increase our ability to collaborate. We didn’t know we were starting something others would be interested in, but it grew, and working as a team became critical. Amy Edmondson’s book “Teaming” talks about the importance of teamwork in the modern workplace, making it more relevant than ever.
Michael: Most people talk about teams, but they’re often more like groups of individual contributors rather than real teams.
Woody: That’s a good point. They might have meetings to discuss what they’re going to do, but then they work alone. Although some work has to be done that way, much of it is done better as a group. Research suggests that we can maintain focus longer when working together than when working alone. If true, this explains why teamwork is so beneficial.
Michael: In my experience coaching organizations and teams, the best teams are multidisciplinary and solve complex problems together. Yet, it’s not widely practiced. Why do you think that is?
Woody: With computers, we’re given a keyboard and a screen, creating a personal workspace. It’s not natural to share that work. Pair programming showed that collaboration is possible, but laptops and personal computers are solo tools. Some people prefer to work alone, and while I love programming alone, I believe we can learn to work better with others.
Michael: There are many objections to working together. How do you typically respond to them?
Woody: There are meaningful and not-so-meaningful reasons to work alone. A common objection is that we can’t do mob programming because we have too much work to split up. The assumption is that splitting work gets more done faster, but in reality, that’s not true. Working as a team can get tasks done quickly and move on to the next.
Separating people introduces queuing and inventory problems. Waiting for responses and having multiple tasks in progress create waste. I often hear objections like “I don’t want to pay five people to do the work of one,” but these are based on incorrect assumptions.
Michael: This often leads to poor meeting culture and slow decision-making.
Woody: Exactly. I had an experience where our team needed to get something critical done but was blocked. I asked the head of the company to send an email requesting immediate help when needed. By the end of the day, we had 17 people working together on one problem. It took us two days to complete work that would have taken weeks in a typical manner. We removed queuing, inventory, and waiting, allowing everything to flow smoothly.
Michael: This is so intriguing. I’m looking forward to having you in the program on October 29th for our Leading Complexity program this fall. See you then, and thank you, Woody.
Woody: Thank you. Check out the Leading Complexity Program to learn more from Woody and the other thought leaders, and sign up to attend her Master Class, Thinking with Complexity.
