Seven Tenets of Mob Programming
|
On a chance bus ride down MLK to our Jama office a few months ago I happened to share a seat with a colleague in our Engineering Department, Bryant Syme. He had only been working for Jama for a few months and to be perfectly honest I hadn’t spoken to him much yet. We talked a lot about recent events in the office, but also talked about some of his previous work experiences. This is the first time I had ever heard about Mob Programming and the many potential benefits it can bring to a team of engineers. It planted the seed for me to introduce it to my own team and eventually start evangelizing it to the rest of our department.
What is it?
Mob Programming is a style of paired programming, but with the entire team involved instead of two developers. Every person involved in the story should be in the Mob Programming session and actively contributing, including Product Managers, DevOps and QA Engineers.
Think of Mob Programming as a tool for getting through larger, more obtuse stories and epics. The team will crowd around a single screen with one person driving and will talk through everything from acceptance criteria and design decisions, to implementation of the code and even test cases.
Mob Programming has many benefits:
- Shared ownership over decisions.
- Better quality code.
- Ability to break through large tasks easily.
- Team bonding through working together.
- A great way to teach other team members various skills.
This style of work doesn’t need to be limited to programming. It could also be great to work on any project, from writing a document to planning for future work, to doing performance testing.
The tenets of Mob Programming
The main tenets of mob programming that everyone should follow are:
- Use one keyboard and screen
- Use a private room
- Select a time keeper to rotate who is on the keyboard every 15 or 30 minutes.
- Everyone gets time at the keyboard, even non-programmers.
- Take a story from start to finish, or in other words: from planning to coding, to testing, to done.
- Take breaks when you want.
- A session should span an entire workday.
Each of these tenets are flexible and should be discussed with the group before starting. One thing I’ve had a lot of luck with so far is pausing the timer to do whiteboard planning, for instance. We also usually take however much time we need at the beginning of the session to sketch a rough plan of what we are going to do, in order to stay on task as people switch around.
One keyboard and screen
This allows the team to concentrate without the distraction of e-mail, chat applications or other work. Team members may come convinced that they will need to work on other activities since there won’t be enough to help with when they aren’t at the keyboard. I had such an encounter with one of my teammates who was certain that there would not be enough for him to do. You will need to remind them that this is not a normal meeting and that you need their full attention. In the case of my teammate, I conceded that he could bring his PC as long as he kept his attention on the task at hand. He agreed and ended up being so engaged that he rarely, if ever, looked at his own screen.
One rule you can bend here is that research on one screen can be boring for the team to watch and help with. This is an appropriate time for other team members to use their own PCs to help do research (as long as everyone is staying on task).
Use a private room
This moves the team to another space both physically and mentally, and also prevents outside distractions. Other teams should respect that you have shut the doors and should not interrupt you. But if you are interrupted, team members should volunteer to chat with that person outside of the room to allow others to keep working.
Rotate who is on the keyboard every 15 or 30 minutes
Decide on a good time interval at the beginning of the meeting. I recommend 15 or 30 minutes depending on how many people are in the group, but other time increments are also fine. I’ve found that a group of 4 or less people works best with 30 minute intervals, wheras 5 or more works best with 15 minute intervals. Its just enough time to get some work done, but also enough for everyone to rotate through in the large group.
Bring a timer with a loud alarm. I usually use the Clock App on my iPhone and turn the sound way up. When the alarm goes off, whoever is at the keyboard should immediately take their hands off and let the next person rotate in, even if they were in the middle of typing. The thing to remember here is that it’s not about one person working while the others watch, as it is about everyone working on the same thing. Whoever else rotates in should easily be able to pick up where the last one left off.
A clock that resets itself is also ideal, since you don’t want to forget to start the timer.
Everyone gets time at the keyboard, even non-programmers
Whoever is helping should have a chance at the keyboard, even if they are in a QA, PM or DevOps role. Remember that everyone is working on the same task and watching and directing what the driver is doing, and it should not matter much who is on the wheel. It’s ok to be a backseat driver in this situation.
Participation also keeps everyone at full attention! Keeping the same person or only developers will become boring for others in the room if they never get a chance to participate.
Take a story from start to finish
Even when coded, the story isn’t finished, it still needs to be tested! Work on your test cases as a team. Personally, I am a QA engineer and getting other team members to help work on making quality test cases is very validating and helps us be less black box.
Whatever is required to get that story into the “Done” column should be done during this session. In addition to getting higher quality code, test cases and automation, this also tears a lot of walls down between roles. A lot of our developers often don’t have much of an idea for what DevOps or QA engineers “do”. This is a perfect chance to get cross-team collaboration and boost how your team works together!
People are allowed to take breaks when they want
Bathroom breaks, coffee breaks, lunch breaks should not be discouraged, but be warned: people will want to keep working, so mandatory breaks may be needed!
Mob programming can also be exhausting, if someone needs a few minutes to take a breather, they should be allowed to simply leave and come back when needed.
A session should span an entire workday
This one has been difficult to schedule a lot of times. So far we have managed to schedule one full day and several half days of mob programming. Most literature I’ve seen on the topic so far recommends the full day, if possible, though. If individuals need to leave for meetings or other commitments, there should still be enough people left to absorb their absence.
Conclusion
Mob Programming is a great tool that can be used to effectively chop down and complete large stories and epics. Remember if you are trying this, review the tenets with your group, such as sticking to one screen and one keyboard, as much as possible.
This is also great for bringing other team members up-to-speed with certain design patterns or tools. Someone who never uses the command-line or has never dealt with a certain language before will likely get a chance to learn a lot.
Everyone in the room should be involved, don’t limit it to just programmers, or others will get bored and not be as engaged. Remember to invite everyone in your team to the session, including the Product Managers, QA and DevOps Engineers.
And of course remember to have fun! Odds are your team will have a blast and work just a little better together than before the experience.
Subject matter experts from Jama Software provide guidance and best practices on requirements management, test management, compliance and regulation, risk management, and complex product and software development.
Latest posts by Jama Software (see all)