In every Scrum.org 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 my 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.
- 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, first thing I would have done was to remove all the code from the previous person”. That’s pretty harsh!
- 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.
- 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.
Recommended for You
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:
- Because the entire team was working on the same code at the same time, no time (zero seconds) was spent on merging code.
- 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.
- 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.
- 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.