Mob Programming
Mob programming is a practice devised by Woody Zuill where the whole team continuously work together over a single product and consider all aspects of the development approach from coding, user experience, testing, deploying and even documenting.
The approach is very simple, in that, there is only one machine, two keyboards, two mice and a huge amount of screen real estate to share between the whole team who sit together and work to refine the product. The story goes that initially a team that Woody was working with experienced a production issue and so like most organisations they got all of the necessary people together in a room and hooked up a machine to try to figure out where the problem was and how to fix it. As the day went on they resolved the problem in their triage or war room, (apparently they had to change rooms every so often when other people had it booked,) and generated a lot of momentum through close collaboration with each other. At the end of the day, one of the participants asked the team if they would like to work this way all of the time, and this then paved the way for Mob Programming.
The person with the keyboard is termed as the Driver and takes direction from the rest of the team who are the Navigators and do the thinking in the group.
Every so often change the driver. A recommendation when first starting out is to set a timer for 5 minutes and switch drivers when the timer alarm sounds.
If using this approach the temptation as a Driver to take control and be the only one doing the thinking, as this excludes the contributions from the rest of the team and also can place some stress on the driver to get the right answer in front of everyone else. To avoid the stress of coding in from of others use the Navigators to collaborate instead and pass instructions to the Driver on what to do. This also has the side benefit that even non coders can get a chance at writing some code with the support from the rest of the team.
As Navigators, try to focus on collaborating and helping the Driver by actively thinking as a group about a high level direction where the product needs to go and also a low level direction on what to do next simultaneously. As the next steps are done, we might learn something from them and so we can adjust the high level direction with the new knowledge. Similarly, having a higher level direction provides context and a way forwards for the next steps. Thinking of both high level and low level at the same time then allows these perspectives to compliment each other.
Multiple Perspectives
It can be easy to think that all the team are doing is just coding the feature and that Mob Programming is just an approach for software developers, but the idea is to have a holistic approach to the product as it is refined, and so incorporating other activities such as writing automated tests, deployment scrips, refining the customer experience, devising the user interface and even documentation should all be done in this way.
It is quite normal to work on a feature at a time and so also work on all of the perspectives of that feature at the same time. This then leads to a holistic understanding in the team about the product and how the new feature fits into it.
No Meetings
The general idea is that all of the team are in the room collaborating at the same time on all perspectives of a new feature, and so with the continuous share knowledge that is being used and extended in the close team, everyone should already know the state of the work and what as a team they need to do next, and so there is no need for a Daily Standup for example.
Also, when working on a feature with multiple perspectives, the team can also be thinking about how the product is shaping from a customers perspective and how the team can improve the way they are doing things, and so rather than have explicit Showcases or Kaizen & Continuous Improvement sessions, the team perform a continuous and analogue appreciation of the product and their processes and continually update their approaches.
Attendees
Ideally we want all of a cross functional team in the room that can contribute to all perspectives of adding in a new feature into the product from concept to production. In addition to the team we might also want the Product Owner or similar who can work continuously with the team to represent the customers' needs and provide information to the team about which features are of higher priority than others, and what level of completion of the feature is appropriate for now.
At Scale
Working with multiple teams at the same time and managing dependencies is much easier when all of the teams are sat near each other and in an open collaborative space. Here teams can simply walk other to each other as dependencies or issues are discovered and begin to resolve them as they happen.
In addition, teams can also coordinate their efforts and high level perspectives continuously in the shared environment.
Equipment Setup
Here is a basic setup for the equipment:
- 1 x computer / laptop
- 2 x keyboard
- 2 x mice
- 3 x large screens e.g. 84" LCD displays
- 1 x hand sanitizer
- 1 x board to host a Card or Task Board
- 1 x board to host a Story Map or Backlog if needed
Getting Started
When using this approach for the first time, it is recommended that teams build up from spending a few hours at first using Mob Programming and then extending the time spent collaborating together. This allows the team to get used to the format and also learn how to actively collaborate, share ideas and create a safe space for each other.
See Also
References
- Mob Programming: A Whole Team Approach, Zuill W, Meadows K, 2016
- A Day of Mob Programming 2016, youtube.com, accessed 22 December 2016