Use Mob Programming to maximize your learning

14 Dec, 2018

In every Professional Scrum Development class, we touch upon both technical and collaboration practices to help improve the development teams explore new options. In a recent class, we had two teams that, after two sprints, hadn’t been able to deliver any "Done" increment to show at the Sprint Review. They were plagued by all kinds of issues, merge conflicts, refactoring gone bad, lack of automated tests and everything else that happens in real life. I decided to introduce Mob Programming to see whether that could help them.
The first experience with Mob Programming is usually total chaos and I tried to prepare the team accordingly. Trying out any new technique – anything that’s out of your comfort zone – can result in initial chaos, it requires a bit of courage to move onward. For those of you that don’t have any idea what Mob Programming is, I recommend reading our recent article in XPRT magazine which gives an overview of it or watching a recent recording of Woody Zuill’s presentation.

The first attempt of these teams didn’t feel successful to them. In a retrospective setting, we dug a little into the issues that they encountered. It’s good to know that these people had already been working together for a longer period of time, some of the issues that surfaced were pretty surprising.

  1. Disagreement on which coding style/standards to follow. Up to the point where one of the developers said: “I wanted to be the next person to take the driver seat, the first thing I would have done was to remove all the code from the previous person”. That’s pretty harsh!
  2. They didn’t like getting immediate feedback from team members. Normally they would request a code review when the work was done. That review would only critique the current end-state. Not how you got there, which decisions you had taken along the way, what “stupid” alternatives you’d tried. When working behind the same screen with the whole team, everyone sees it, and many people have an opinion about it. Pair Programming works similarly, but then with 4 eyes on the code. With Mob Programming the number of eyes multiplies and so does the feedback.
  3. It felt in-productive to the people not doing the coding. They hadn’t figured out how to be most effective in helping to solve the problem at hand while not directly being able to change the code.

We introduced the Mob Programming Role Playing Game roles to the teams, just the role cards, not the whole game. And had them talk about each role end whether some of these contained contributions they could have made to the development process. This led to an interesting discussion and the desire to try anew.

Roles in the Mob Programming RPG. Game icons CC-BY their respective authors. CC-BY-SA-NC 2015 Willem Larsen

The second time the teams took on a sprint, they were finally successful. Not only did they try Mob Programming, but they decided to approach this sprint Test Driven as well. It was the first time they were able to live up to their self-imposed Definition of "Done" and they had a lot of fun doing it.
The team identified a number of positive things about the whole experience they hadn’t imagined before we started:

  1. Because the entire team was working on the same code at the same time, no time (zero seconds) was spent on merging code.
  2. The team had exchanged a long list of tips, tricks, keyboard shortcuts, alternative approaches to coding etc. Everyone felt they had not only delivered code, but learned from each other while doing it.
  3. Every team member felt comfortable having to maintain the code or having to do an emergency bugfix in the middle of the night. Partially due to the unit tests providing a safety net and automatically validated documentation, but also because they had been part of the creation of the code. Truly working together greatly improved the sense of shared ownership.
  4. There was very little time spent on “overhead”, coordination, meeting, status sharing. The teams still practised their daily scrum, but the focus shifted from “what we’ve done and what’s blocking us” to the impact in the goal and higher level concerns. Not one developer felt the need to explain exactly what they did and why. So the time-box got a lot shorter, but the value went up considerably.

The final conclusion of the team: They’d probably be 6 times more productive, but would all be dead tired by lunchtime. Not bad actually for one and a half hours of really trying to collaborate.
Have you tried Pair Programming or even Mob Programming? I’d love to hear your thoughts, frustrations and successes.
This blog is based on an excerpt of the article I wrote together with Martijn van der Sijde. You can read the whole article as well as other interesting articles in XPRT Magazine #6.

Jesse is a passionate trainer and coach, helping teams improve their productivity and quality all the while trying to keep work fun. He is a Professional Scrum Trainer (PST) through for the Professional Scrum Foundations (PSF), Professional Scrum Master (PSM) and Developer (PSD .NET) programs. With a strong background in the .NET platform and C#, Jesse is able to translate the needs of development teams when it comes to tools to manage work, build the code and keep quality up. He has contributed to a number of open source products that extend – as well as supported commercial tools like NDepend in their integration into – Team Foundation Server. Jesse regularly blogs and contributes to numerous communities on StackExchange and MSDN networks, he has received the Microsoft Community Contributor Award three years in a row and has been recently been awarded the Microsoft Most Valuable Professional award. He’s spoken at conferences and user groups, including the Microsoft TechDays and the Scrum Day Europe. Trainer certifications: Professional Scrum Foundations Professional Scrum Master Professional Scrum Developer (.NET) Scaled Professional Scrum (SPS) Scaled Agile Program Consultant In past years Jesse has delivered ALM, Test Automation and Scrum training all over the world, most recently in Sydney, Milan and Bangalore. He has redelivered materials from industry leading partners as well as developed his own. In addition to the previously mentioned subjects Jesse has taught courses on Visual Studio, Object Oriented Analysis and Design, Design Patterns for C# developers, Unified Modelling languages and Regular Expressions. Jesse is married with Charlotte, recently became father of his first daughter and lives in a house that’s more than a century old in the beautiful city of Utrecht. He loves espresso and dark chocolate, travels a lot and takes photos everywhere he goes.

Explore related posts