Mob programming – with Woody Zuill

Whenever we have urgent, complex work we sit down and do it together. In our every day work, we make do with occasional meetings. Why do daily scrums when you can do day long scrums? That is how I understand mob programming, but that is not why Woody Zuill and his team started with it.

[bibshow]
I recently had the chance to meet up with Woody Zuill when he was in the area for one of his lecture tours. We had long and interesting discussions about many things. Three of those discussions were recorded on video for Architecture Corner. Go ahead and subscribe if you want a notification when the others are published. Woody is perhaps mostly known for having coined the #noestimates hashtag. Are you tired of the #NoEstimates debate? Don’t worry, this post is not about that, it’s about Mob Programming [bibcite key=”citeulike:13776347″]. If you are curious about my view on #noestimates, read this.

Video about mob programming

The discussion between me and Woody Zuill about mob programming was quite long. The video is almost 20 minutes long. You should watch the video to learn more about mob programming. Below are some highlights with approximate start times in the video. Keep reading for additional comments on these topics.

  • 00:40 How can a whole team of about five people be programming together when there is only one person actually typing? And why isn’t it exhausting to work together like that all day, every day.
  • 04:00 How can mob programming possibly work? Perhaps that is the wrong question to ask, responds Woody. We started with this model because we liked working together. Only later did we realize that we were also more efficient.
  • 09:00 What does a mob programming team look like? It is a mix of roles and competencies and it shifts during the day and the project dependent on needs.
  • 13:00 What is the difference between mob programming and #pairprogramming? Can you get into “the zone” when working together as a team?

What is mob progamming?

Take three minutes to watch the video below. It will give you a great understanding of what mob programming is and what a day in the life of a mob looks like. Woody Zuill is seated on the far right of the video. Notice the white projector on the table? The code being developed is projected on the wall so that everyone can see it.

I like to compare mob programming to the work in a control room. In a control room each user works on their own consoles but they also have a shared context on large screens.

Mob programming is a lot like working in a control room.Source: NASA via Wikimedia Commons | PD

In a control room, the staff has both a local context on their own console and a shared context on the wall screens.

How can mob programming be effective and efficient

When I asked Woody about the efficiency and effectiveness of mob programming I quickly learned that I wasn’t the first person to ask the question. Woody told me that he and his team didn’t start with mob programming to be better or faster but to be able to work together more and better. It was only later that they discovered that, at least for them, it was also a better way of working. Woody quoted Peter Block to illustrate the point.

Transformation comes more from pursuing profound questions than seeking practical answers. - Peter Block

Having noted that mob programming was a better way of working, Woody tried to understand why. He shared two reasons in the interview. Reduced waiting time for answers and reduced cognitive burden.

Reduced waiting times

In software development, we often come across questions which we must answer before we can proceed. How should I call this function? What is the business logic here? Why was it done like this? Until an answer can be obtained, it is impossible to continue work on that particular task. This problem is not limited to the domain of software development, it can also be found in healthcare. [bibcite key=”citeulike:9145602″] When almost everyone you need to talk to find the answers are already in the room, obviously the time spent waiting for answers is reduced. But in mob programming, the team members do not just sit there waiting for a question, they actively search for information so that they can contribute when needed.

The ability to quickly find information, and therefore the ability to quickly find who has the information is critical in any team. The difference between good and bad teams is often in how well this meta information is distributed. It is not a wild guess that having everyone in the same room, focused on the same task reduces the problem.

Reduced cognitive burden

Any design activity, such as “programming” requires that we handle different levels of abstraction. For instance we have to consider the business logic, the algorithm and the actual programming. The programming is often in multiple languages, for instance the front end might use HTML and JavaScript, the middleware might be written in Java and the backend in SQL. Keeping all of these levels in the head at the same time is hard. In mob programming, the burden can be shared between multiple team members.

A mob programming team

A daily sprint meetingSource: Klean Denmark on Wikimedia Commons | CC BY SA 2.0

A daily sprint meeting is far different from mob programming. Team orientation versus task orientation, perhaps.

A mob programming team, like most other teams in agile software development is a mixed team. It has a team lead and several team members. The team members often start out with a background as developers or testers, but remember – in mob programming, the whole team programs together. The supporting cast is equally important. The team needs ready access to technical and business experts. People who can explain what needs to be done and sometimes also how to do it. These persons do not need to work with the mob the whole day. Their contribution will vary over the time of the project. Often they spend a few hours per day with the team.

Teams are not only about skill roles. The interplay between individuals and the teams they form is important to understand. Teams are after all social constructs. [bibcite key=”citeulike:12010180″] In a “team intensive” setting like mob programming it becomes important to understand how efficient self-organizing teams emerge. Who will fill these roles: Mentor, Coordinator, Translator, Champion, Promoter, and Terminator in a mob programming team? [bibcite key=”citeulike:13776423″] An area for future study.

Mob programming versus pair programming

Is mob programming anything other than a “more than two” approach to pair programming? [bibcite key=”citeulike:13776355″] In any programming model, ideas have to be translated through a keyboard to instructions to the computer. (Which of course brings up the old IROP story.) As a solo programmer we strive to enter “the zone”. In mob programming, it is different. We work as a group and share the cognitive burden. We can work with bigger things as teams than as individuals.

The future of mob programming

Mob programming has not had an enormous impact in the scientific literature yet, but some researchers have started looking at it. Alexander Wilson describes what works and what doesn’t in a case study from how it was implemented in his company. [bibcite key=”citeulike:13776350″] I hope we will see more research and more experiences on when and how mob programming should be applied. In the mean time, why not join the #mobprogramming discussion on Twitter?


Credits

Greger Wikstrand and Woody Zuill discuss Mob Programming on Architecture corner.Source: Architecture Corner on Vimeo

Greger Wikstrand and Woody Zuill discuss Mob Programming on Architecture corner.


The video about mob programming with Woody Zuill and me was recorded and edited by Casimir and Lotta Artmann. The video is part of Architecture Corner. You can see all the Architecture Corner videos on YouTube. If you want to see all videos with me, there’s a YouTube playlist available. The episode about mob programming is also available in podcast format.

References

[/bibshow]

Image sources

About Greger Wikstrand

Greger Wikstrand, Ph.D. M.Sc. is a TOGAF 9 certified enterprise architect with an interest in e-heatlh, m-health and all things agile as well as processes, methods and tools. Greger Wikstrand works as a consultant at Capgemini where he alternates between enterprise agile coaching, problem solving and designing large scale e-health services ...

Leave a Reply