Mob programming is emerging as a technique well-suited for solving complex problems that require diverse ideas and skills to be combined as well as exploring and understanding a complicated domain — such as learning a new programming language or a technical discipline.
Can this technique help a scrum team get better at Test-Driven Development ? Or even learn how to do TDD ? In this post I want to focus on just that question.
I had an opportunity to support several scrum teams get comfortable with using TDD in their day-2-day work and decided to try out using mobbing as a technique for the team to practice TDD. The teams had a wide range of experience with TDD and almost none of them had any experience with mobbing. What they did have, however, was a strong need to learn and apply test-driven development and a very open mind. The teams started with code katas and, since the sessions were rather short (90–120 mins) we were mostly using the strong-style mobbing technique. Over time the team gradually moved to less stricter styles of mobbing.
The approach turned out much better than I had hoped.
- Learning TDD is initially a lot about behaviour and mindset. It is about learning how to drive development through tests, about taking baby steps etc., and doing this in a mob gave room for immediate feedback and practice.
- There were certainly moments of frustration and bafflement as the team went through the learning process. Having well-defined problems and keeping a time-boxed session helped to keep focus and patience through this phase.
- Using these learning sessions as a “sandbox”, teams were able to try out and settle on norms and methods they are comfortable with (e.g., size of the baby-steps, up-front design vs emergent design, trying out ideas vs debating/ discussing).
- Practising TDD together helped the team become better at working as a team. Whether at asking for ideas/ help from team members, calling out someone speaking out of turn, or settling on a method for making decisions, the team was getting more functional in the area that really mattered — writing functional, well-tested, clean code.
This last benefit is probably also the most profound. From seeing wild ideas work wonderfully unexpectedly, to seeing the quite genius in the team for the first time in her entirety, there were quite a few startling discoveries.
I personally feel that mobbing for a TDD code kata could be a good exercise for any team to better understand each other and collaborate better even if the normal work doesn’t require mobbing/ TDD. Below are some resources that I found very useful in this exercise:
- Cyber-dojo is a great place to practice mob programming Code Katas.
- The Mobretreat.org site has resources with detailed information about the roles in strong-style mobbing along with other mobbing styles.
- If you like to learn by watching videos, then the Mob mentality show episodes are a great source.
- If you would like to experience a mobbing session for yourself, I’d highly recommend attending one of the “Code Craft Saturdays / Sundays” sessions conducted by Coach Bob Allen. Bob does a fantastic job of making key insights from TDD and Mob programming available when it’s most meaningful and I’ve learnt a lot whenever I mobbed with him.
I’m eager to know how you have experimented with making TDD and other agile practices more accessible to development teams ? What resources have helped you and your teams ? Feel free to share in a comment.