In the history of crazy ideas in the software industry, XP - with both Pair Programming and Test Driven Development - was a pretty big one when it was first publicized. Mob Programming seems to go a step further: it is a way to develop software where the whole team works in the same place, at the same time on the same computer.
Woody Zuill gave a keynote on Mob Programming during the first Mob Programming Conference, where he goes through the questions everybody keeps asking him after four years of mobbing. The Mob Programming Conference took place in Cambridge, MA, May 1-2, 2016. InfoQ covered the event with Q&A and articles.
This article is a two part review going through the ideas of the keynote and an interview with Zuill on the different ways to introduce Mob Programming, the main problem of the IT industry, the other activities where mobbing can fit, and the purpose of mobbing.
Keynote: What is Mob Programming about?
Regarding the history of XP, and the difficulty of explaining technical practices to C-level and Senior (non-IT) Managers, the obvious question is: "how can a team of five at one computer be productive?" Woody Zuill gave two answers:
- Where is the proof that splitting the work between multiple people is effective at all? This one is very close to Robert C. Martin’s review of the History of IT, and Peter Drucker's work about "knowledge worker": the use of factory metrics to evaluate knowledge work has explanations but no proof-based evidence (that I'm aware of).
- The goal is not to be productive but effective. To draw a line with Lean Practices, being productive and not effective is usually a good way to produce waste quickly.
The main issues a team faces while developing software just fade away with Mobbing. For instance:
- There is no more Communication Problem; the whole team is there, necessarily exposed.
- The Queue Time for (answers to) questions: the problem is not productivity, it is getting answers. In this context, introducing new inventories in the backlog is just waste. Working together all day long evaporates the problem.
- Technical Debt. This is probably the most intangible aspect of software development: in IT, when the team introduces garbage in the product, it will remain. Mobbing allows continuous high quality.
In 2012 Zuill was trying some new practices with his teams at Hunter. After a few discussions over twitter, he started explaining what he was doing in conferences. Over a number of presentations the same questions kept being asked, so he decided to write some slides to answer them, keeping in mind this quote of Peter Block:
"The value of another's experience is to give us hope, not to tell us how or whether to proceed."
Zuill had a tricky question: "Why does the team work this way?". The audience answers were legion, but his was different: the only reason for the team to work as a Mob was because the Team had decided to do so.
This is probably where Mobbing fits the most with an Agile Mindset, and it is maybe more Agile than the Manifesto, much the way Alex Krivitsky had rewritten it in 2011: it's all about "Individuals and Interactions". To get it, the Mob Programming "manifesto" (I'm not sure anyone would call that as such) follows:
All the brillant minds working On the same thing At the same time In the same space On the same computer.
I see two main differences with the first manifesto:
- First, the Mob is focused and aligned through unity of action. The whole Mob is committed to work together on one thing at a time, and not split the work between people. This is mostly what XP should have looked like. This is the guarantee of collective ownership.
- Second, thanks to this alignment, there's no question about collocated vs distributed teams. It's meaningless in the sense that everybody has to work together, and the emergence of effective tools to work virtually helps (joinMe, HangOut, etc). Some teams are known for doing so (Cucumber team, Corgibytes, etc).
To achieve and reinforce this pattern, Zuill explained the introduction of strong pair programming, that Llewellyn Falco defines in the following way:
For an idea to go from your brain to the computer, you have to use others hands.
Woody is very modest regarding Mob Programming: the team he was working with had just been trying some practices; they were just using more the practices they found helpful. Woody just saw code smells and asked the teams to improve some technical skills. As he put it:
The people doing the work can best determine how to do that work
A typical day of such a mob team was one hour of learning sessions every day, without standup. After that, the team works on the product, for no more than 8 hours a day. After a short period of time, the Product Owner became part of the team nearly full-time. Several principles were applied:
- Turning on the good: it's what Kent Beck explains in "XP Explained": if something seems to do well, do more or it.
- Retrospectives: to get better at improving results, the team inspects its own practices at least once a day to adapt and turn up the good.
- Weekly practices: to improve your coding skills, it's mandatory to practice.
Robert Henri summarizes this main point:
The object isn't to make art, it's to be in that wonderful state which makes art inevitable.
As a conclusion, Mob Pogramming is about learning attitudes: * Sharing * Paying attention to beginners ideas
Zuill does not promote Mob Programming as a "must do", rather he encourages more frequent retrospectives, and basic care for the team. Probably just as important as the practices described here, Mobbing, by design, will be different from one team to one other.
Every one in a mob is exposed while Mobbing, which means that you have to ensure psychological safety to make it work. This is very close to the explanation about the Core Protocols, which Richard Kasperowski presented two days before. This is probably why with the Core Protocols, Agile Open Space and Mob Programming define Modern Agile.
Interview with Woody Zuill
InfoQ: Woody, thank you for talking to InfoQ. After your keynote, you explained that the IT industry is broken. Could you share your thoughts on that?
I wouldn’t go so far as to say the industry is broken, but many of the practices that we follow are merely by convention. It’s often as Adm. Grace Hopper has said: “Humans are allergic to change. They love to say, 'We've always done it this way.' I try to fight that." When we do things simply because “that’s how we’ve always done it”, I see that as an opportunity for improvement.
InfoQ: With this perspective, what do you think could be done to improve the situation in our business?
It’s very useful to pay attention to things that are working well, and then do experiments to see if we can find ways to amplify the good. For example, prior to discovering “Mob Programming” we had gathered together for a meeting to take a look at some work that a few developers had been having trouble with. After looking at a few problem areas, we started working on it together during the meeting. That is, rather than suggesting some ideas and then going back to our desks to work on the code, we all started working together identifying problems in the code and fixing them as a team. We noticed how effective this was, and decided to continue working that way for a few days as an experiment to see if we could “turn up the good” on collaborating. It worked out wonderfully, and that is what has lead to us working this way, “Mob Programming”, as a team every day.
InfoQ: As the main agent of Mobbing, how would you introduce the idea of Mob Programming in company?
While I have a lot of confidence that Mob Programming has a lot of benefits, I would not presume that the benefits I have seen and experienced are universally applicable. However, when I’m invited to introduce Mob Programming to teams, I do a workshop where we explore the nature of software development, the benefits of working as a team, and techniques for sharing ideas and respectfully handling conflict.
InfoQ: On the other side, if our readers are convinced by Mob Programming, what advice could you share to introduce Mobbing from the inside?
Take baby steps. If people are interested in experimenting with Mob Programming, I suggest that working together on simple code exercises or Katas is a great way to start. Without the pressure of working on production work we can practice working together and learn how to interact well and meaningfully. That is, Mob Programming is about learning to work well together.
InfoQ: With some perspective, do you think that Mob Programming can be used for something other than coding, like Scrum?
As with Agile and Extreme Programming, Mob Programming is about software development, but similar concepts are beneficial with other types of work, such as design, marketing, hardware engineering, documentation, and just about anything. Working well together is an advantage in many fields.
InfoQ: During one workshop for facilitators, you said, and I quote you: "It's not about Mob Programming". So if mob is not about mob, what is mob about?
It’s about discovering the principles and practices that are important in the context of the work you are doing, and the people you are working with. Mob Programming itself is merely an outgrowth of allowing the people who are doing the work to decide how to go about doing that work. This happened in an environment where we were practicing how to get good results from frequent and regular retrospectives, paying attention to what is working well, and turning up the good. When we do this well we’ll find the right mix of practices for any context.
InfoQ: If our readers want to deepen their understanding of Mob Programming, what do you suggest they can read/watch/listen/do?
There is a 3 minute video on youtube that is a fun starting point – it shows our original team working together “Mob Programming” for an entire 8-hour day.
Also, I’ve written a book with Kevin Meadows which is available.
There are a number of videos of talks we’ve given at conferences, as well as podcasts, and I frequently do free webinars on Mob Programming. And I’m always happy to talk via video conferencing to answer any questions.