Interview with Woody Zuill who will be teaching a Masterclass Mob programming with Octo Academy on May 28th.
[Original version – traduction en Français ici]
You have practiced Mob Programming and trained development teams in doing Mob Programming for several years. What brought you to this way of working?
Woody Zuill – Mob Programming emerged from a team that was focused on learning to use an Agile approach to software development. Among other things, the team wanted to improve their ability to work together well. Over a six month period we had been studying and practicing Clean Code techniques by using a Coding Dojo style that is sometime called a “Randori”. In this practice we work on a coding exercise and each team member takes a turn at the keyboard (the driver) while another team member guides them (the navigator). Every four minutes we would switch out the Driver and Navigator. We follow a simple guideline: For an idea to go from someone’s head into the computer it must go through someone else’s hands (credit for this guideline goes to Llewellyn Falco).
We liked this way of practice, and were becoming good at the different techniques needed to make this work well such as expressing our ideas, listening, and following the guidance of the navigator.
One day a team member asked the rest of the team to look at some difficult code and perhaps help figure out how to proceed, and we just naturally started working on the code together using the same techniques we had been learning in our Coding Dojo. During this session we all noticed we were learning a lot, getting a lot done, and having fun doing it, so we decided to continue working this way the next day – and we haven’t stopped since. We have literally worked this way everyday over the last six years.
What are the most observable benefits when working as a Mob Programming team?
Woody Zuill – There are a lot of good things happening, but the most obvious is that we are able to work through almost any coding task or story very quickly with everyone was working together. We are rarely blocked from going forward due to unanswered questions or missing skills or knowledge – so we find we get more work done. We also noticed the quality of our work increased dramatically because we have the whole team reviewing the code, and suggesting improvements as we do the work. Additionally Mob Programming provides a rapid learning environment where we learn from each other and all grow our abilities day long.
What are the main obstacles you encounter when a team converts to Mob Programming? And how do you overcome them?
Woody Zuill – To be able to work on a Mob Programming team it’s important to learn how to work well with others. Most developers have been practicing working alone for their entire career, so it can take a lot of effort to learn the skills needed for close, continuous teamwork. We need to become good at listening – and this is difficult for some of us. At the same time we need to develop our ability to communicate and share our ideas while being willing to try other team members ideas.
Lack of these and related skills can be a problem for a team. Paying attention to how we interact with each other, and working at improving our listening and teamwork skills takes time. We’ve used a number of techniques, and perhaps the most helpful has been to follow the guideline that when we are the Driver (the person at the keyboard) we simply follow the instructions of the Navigator. Another technique we use is to be willing to try each other’s ideas. We learn from doing, rather than merely discussing our ideas.
If you wanted to make all the development teams of a company to work in Mob Programming, what would you do ?
Woody Zuill – It is important to me that this way of working be entirely voluntary – so I would avoid dictating that all the teams should work this way. Mob Programming is not a “silver bullet”, and not everyone is suited to working this way. If we can get good at it then it is another option along with solo and pair programming.
For those interested I suggest they gather together regularly and frequently to practice the techniques and skills needed. Practicing first on a few code exercises allows us to learn how to work together without the pressure of work. During these sessions we focus on improving our listening and teamwork skills. After a few practice sessions it might be helpful to work on some simple bug fixes or small stories to get used to the flow of working this way. After each session it is helpful to review how things went, and look for ways to improve.
You want to participate in the masterclass ?
Information and registration on the OCTO Academy website