Teamwork, mob programming, and working well together

A few weeks ago, Co-Op Digital hosted an evening meetup with Woody Zuill. Woody is credited with creating (or maybe stumbling upon) the idea of mob programming. I wanted to learn more, so I hopped on a train and headed to Federation House in Manchester, home of Co-Op Digital and just across the road from Co-Op’s impressive HQ, Angel Square.

The event was small and intimate with around two-dozen attendees. We were welcomed into Co-Op Digital’s modern loft space, and ushered round to a small presentation area with stepped seating. After a friendly welcome from our host Gemma Cameron, @ruby_gem, we got started.

"If you’re not good at software development, someone that is will take your business" - Woody Zuill

Woody was laid back and relaxed. His easy style of story-telling was highly engaging. He talked about how the whole-team approach to programming just "kind of happened" organically as his team tackled a large piece of legacy code.

Although not working for a software development company at the time (Hunter Industries describe themselves as "Residential and Commercial Irrigation and Lighting"), he was clear in his belief that “if you’re not good at software development, someone that is will take your business”.

Soon, people heard about his approach. got interested, and the word spread about how his team was working. Mob programming was born.

The concept

Mob programming is a whole-team endeavour. Think of it as "all the brilliant people working on the same thing, at the same time, in the same space, and on the same computer". Yup; at the same computer.

One person is the nominated driver, and sits at the keyboard. The rest of the team, the navigators, gather round a (very) large view of the screen and work together - thinking ahead about the direction of the task, working the solution out loud and in the open.

"All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer" - Woody Zuill

The driver listens to the team, trusts their decisions, and translates them into code. At regular intervals the driver is swapped out - just like a court stenographer the driver fatigues quickly so cycles of around 10 minutes are typical.

The driver is thinking about the present. The navigators are thinking ahead about the solution.

The result

Every member of the team is present - including product manager, researcher, designer, DBA, and customer/business experts. Specialist skills and knowledge are on hand immediately, moreover are actively involved in creating the solution. Time spent “waiting for…” is virtually eliminated with no need for costly context switching to fill down time with other work. In principle, the whole team works as a single thread, flowing without friction and in complete synchronicity.

"For an idea to go from someone's head into the computer it must go through someone else's hands" - Llewellyn Falco

The navigators need to articulate in a way that the driver will understand. A clarity of thought and articulation is required. Could consider the driver as a smart input device, interpreting the will of the navigators and committing it to code. Anyone can be a navigator; so now anyone can be a programmer! With a more diversely skilled team solving problems, better solutions will be designed.

Such obvious collective responsibility means mob programming is a genuine team effort. Expertise is shared and the team is resilient - as individuals join and leave no induction or handover is required. The continual nature of working - with course correction, code review, and improvements all happening in real-time - means the risk of error due to the silo'd knowledge or limitations of an individual’s skills is mitigated.

The whole-team discourages reliance on a “rockstars” who become quickly burned out. There is no place for lone star heroes here. Everyone is prepared to contribute the right thing at the right time, and in the right way.

Team are focussed, but relaxed. The set-up of the environment is very important and should encourage the right degree of focus: enough space to think, but with a big enough screen so that the view is unobstructed and clear.

Stronger together

By starting together as a team in the morning, enjoying a nice lunch, and working until a conventional finish time - and somehow being more effective than ever before - Woody found that the team actually want to come to work promptly in the mornings, and even started coming in early. As he remarked, "it’s after 5 o’clock that we start writing tomorrow’s bugs”.

Importantly, the mob programming way of working wasn’t dreamed up round a whiteboard and then tested on a guinea-pig team; rather it was the way the team naturally formed and worked in response to a particular challenge. It was their decision - they noticed what was good and did more of it. No one asked for permission.

"Retrospectives are a graveyard of good intentions” - Woody Zuill

Woody found that he and his team were benefiting from more frequent retrospectives, at first holding them weekly, then multiple times per week, and eventually daily. "Retrospectives are a graveyard of good intentions”, he said, but pay attention to things daily and you can fix problems and bad habits immediately.

Solving the right problem

How many times have you seen a developer or team pulled off the project they’re working on and reassigned as their progress is blocked awaiting a decision or for some new information? I’ve seen countless examples - I've surely been responsible for a few too!

By starting something new while waiting for an answer, it makes it OK not to have information when and where it's needed. Other tasks are found to fill the dead time - thereby solving the visible problem of “not being busy enough” by finding other work masks the real problem which is “access to information when it's needed”. Other team members will wander off and everyone gets generally annoyed and frustrated. Progress is halted, momentum lost. There’s a productivity cost to context switching - and it's an expensive one.

"Solving the visible problem of “not being busy enough” by finding other work masks the real problem which is “access to information when it's needed" - Woody Zuill

"When the whole team is slowed down by a problem, that problem becomes really important. When an individual is slowed down, they have to beg help from someone who is similarly busy”. Mob programming appears to be less about getting the most done, but rather about getting more of the right things done.

Does it work for you?

I haven’t experimented with the method myself - but I’d love to hear some of your experiences in the comments below.

Has your team tried something like this? Did it work for small projects? Does it work when things need to get done very quickly? How does it scale to the very large and complex pieces of work? Let me know.