Woody Zuill on How Mob Programming Makes the Difference
Mob programming challenges the idea of developer teams as a group of individuals with a common goal yet who do most of the work separately. Hence, mob programming emphasizes the importance of collaboration, having faith that software development can benefit from it just as human enterprises have done throughout history.
To teach us about the benefits of mob programming, we invited Agile coach Woody Zuill.
Woody Zuill is an Agile coach who does workshops, talks, and presentations on the mob programming method, which consists of programming in groups using a single computer. As a developer, he started programming in the early 1980s attempting to create his own programs when he didn’t have access to the software he needed.
As time went by, Woody came across Agile ideas, and by the end of the 2000s, he decided to move forward in his career to mob programming, which he understood was the natural evolution of how to develop software.
According to Woody, the capital asset of mob programming is its capacity to enhance collaboration, a critical aspect of modern workplaces, by allowing team members to share and help each other with their specific skill sets. “ We probably wouldn’t even exist if we didn’t -somewhere along the way- figure out how to collaborate”, he says.
Woody understands that mob programming maximizes instant feedback, advancing little by little yet steadily, and deploying daily or more frequently. To him, mob programming doesn’t replace solo and pair programming, but arises organically as it is required by the circumstances:
“Some people do it [mob programming] like three days a week, three hours each time; some folks do it just when they think they need it.”
Mob programming is the way of collaboration
According to Woody, teams are not defined by how they are arranged to work individually on the same project, but by how they collaborate to do it. He sees working as a group as a way for humans to help each other and bring complex projects to life.
However, this doesn’t mean that collaboration comes naturally to everyone.
In this regard, Woody argues that people should not be forced to mob programming if they want to think alone. Withal, he considers that “ a lot of people who say they need to think alone just means they never even learned or considered how to learn, how to think with other people.”
Woody emphasizes that at least trying mob programming instead of ignoring it is giving a chance to something new that could potentially improve our work. This can also be said for giving a chance to new methods that may arise in the future, so it is crucial to be open to trying new things and give them enough time:
“There was hardly anybody talking, let’s say, 20 years ago about deploying every 10 minutes or deploying at the end of each little thing that we’ve done, and now there are companies that do that automatically all the time.”
The perks of mob programming
Woody has found mob programming to improve four aspects of software development:
Productivity: As in the case of pair programming, teams get more things done in shorter periods.
Knowledge sharing: Team members share their skills, and have a better grasp of how each other works and how their work affects one another.
Engagement: As productivity improves, team members are more engaged with their work and are more focused to resolve potential blockages.
Product quality: Peer pressure makes developers less likely to let deficient code slide or pile up until hindering working with it.
On the other hand, in Woody’s experience, mob programming might be helpful for emergencies, enhancing developers’ focus. However, for Woody, if you only choose mob programming for emergencies you won’t be good at doing it; in turn, if you already work this way, you will become very good at it and will perform better in emergencies.
Onboarding to mob programming
Woody believes that getting into mob programming starts by acknowledging our own limitations: we might not be good at collaboration from the get-go, even though we may be collaborating already without even noticing it.
On this subject, he understands collaboration takes different forms: from communicating with one another using email or messages, to relying on someone else’s knowledge base -including books, videos, etc.-:
“If we’re working in a company where there’s more than one person and we have a customer, then we are collaborating in some form or another; Somebody has to get the software we’ve written and put it on their computer or use it on the web.”
In the case of interns, according to Woody, onboarding to mob programming shouldn’t be hard either. They already have fresh brains, so instead of making them rely on training, with mob programming they can learn by exposing themselves to the actual code from the very beginning.
In Woody’s experience, months of training can alienate newcomers from the actual work, since training materials might be outdated in comparison with the latest code.
Woody is in favor of having someone with little experience in his team interacting with others who are the opposite. To him, developers with little experience “can contribute their technical knowledge or their ability to design or their understanding of the technical stuff we’re trying to do.” More importantly, they have a beginner’s mind, which provides a unique perspective to the team.
In this regard, he considers that having different perspectives is highly important for the work: “A team of people who think the same is not exactly what we want. What we want is a shared understanding of the problems we’re trying to solve […] it’s in the doing of the work that we discover the work we must do. If we can get five different perspectives on that work, we’re going to be a lot better than if we just have the one perspective.”
Beginners are more prone to approach problems from a non-programmer perspective characterized by technical thinking. Woody likes to take advantage of the point of view beginners provide and encourages junior and senior programmers to work together.
An exercise of his consists of making a junior and a senior provide an idea each for resolving a problem, and test out the junior’s first to help him learn from the experience while taking advantage of their fresh pair of eyes:
“Often what happens if we use an idea like an old person like me uses the same idea over and over, that’s one of the patterns that we’re stuck in and that’s not helpful if I can expand my thinking by having a different point of view interjected.”
As such, Woody understands that “ most of our work isn’t really about technical thinking; we’re solving human-level problems. “ In this way, he thinks that developer teams should approach development just as another human activity to avoid limitations:
“The languages we work in software development are extremely limited and we invent parts of those languages ourselves because everything we write is kind of a domain-specific language.”
Aside from the seniority of each developer providing different points of view, Woody also finds that teams possess individuals with different skill sets. These can add a lot of value when dealing with something they master, but also when participating in something out of the scope of their expertise:
“[when] we’re working on some front-end thing, the database person might say, “Wait a second. You’re hard-coding some stuff that should go into a data store somewhere that should be in a config file or maybe actually in the database.”
So we get all those different viewpoints and we resolve problems that therefore never happen to us.”
The bottom line
Learn more about Woody’s work on Agile and programming topics and check out his activities calendar at https://woodyzuill.com. You can reach him as well at his email: firstname.lastname@example.org.
Originally published at https://semaphoreci.com.