Team Lessons Found only in Ensemble (Mob) Programming
Every-day learnings that get lost in solo tasks
Special issue of Crafting Tech Teams today. I joined Coach Bob’s Code Craft Saturdays this weekend. This is a short summary of learnings and the experience overall.
In this issue you’ll find examples and use cases for your team on mob programming. If you have never tried it before and are on the fence, keep reading.
The Structure
Meeting in gather.town we found the active participant groups very quickly and jumped spontaneously on a call. I love Gather for this very reason. It’s so easy to mingle with the group and at the same time being able to leave the conversation to come back later if you need some space.
We set out to practice first using a coding kata. Combining CyberDojo for TDD and mobti.me we had a rotation of roles that allowed everyone to participate. Our kata of choice was Fizz Buzz using python. It was pretty fun!
The rotation for the roles is traditionally:
Navigator — makes decisions on what gets written
Driver — controls the screen and keyboard
Next — the next person in the rotation to become Navigator or Driver
Everyone else — waiting their turn. They are influencing the navigator through conversation
There are stricter versions of the rules, ie. whether a navigator is allowed to be become a driver immediately afterwards or if they need to rotate one turn. These are the ones we used.
In addition to this we decided to stick to an agreed-upon plan per cycle until the tests were all green.
“Rather than writing the code you are thinking about it has to go through another human’s brain first.” —Ensemble Programming
Diversity of Opinion Accelerates Discovery
We had different experience levels in the ensemble ranging from a few years to a few decades. This variety simulates a normal workday well. During the rotation two types of behavior dominated the talking-space:
Disagreements over going down rabbit holes
Misunderstandings in interpretation of requirements and abstractions
Sounds familiar isn’t it? These may come up in a myriad of combinations on any code review. In a way—that’s what ensemble programming is: a live review.
However, there is a difference that highlights its productivity benefit: the review is done on the thinking-level, not on the code. The solutions are being selected and rejected before they are written into the codebase. When that is difficult due to the team’s cognitive load—we can explore it with a micro-step: write a test, explore, revert if needed. CyberDojo is a very good tool for this kind of back and forth.
Hot Seat System—Continuous Development
Alignment of time schedules can be quite irksome for meetings and pairing. An extra layer of activity has to be maintained in order to facilitate the conversations towards being on-agenda. Someone leaves or has a last-minute emergency and you have to reschedule. An ensemble is unique in that regard in that the group can always carry on with their average level of understanding.
It’s okay for someone to leave their camera on and simply leave the rotation for 30minutes or an hour while the group continues. This is extraordinary when developing a feature that has many moving parts and team members require a quick rest or mental reset.
Refactoring the Requirements
One of the things that stuck out to me was that our readme file with instructions was structured in a way that allowed misinterpretation. I noticed 2 navigators stumbled upon this. When it was my turn to navigate I suggested to refactor the readme in such a way that it becomes clearer and without ambiguity.
It might seem trivial to an outside observer at first. But in a professional setting, this is the equivalent of collaborating with the team to reject and groom bad business requirements and confusing instructions.
Without this detour—we would have easily accepted it as “meh okay!” and begrudgingly kept making the mistakes. Usually this creates a bad habit within the team. Expect silly things in business requirements may foster a evasive pattern, rather than an immune-response to correct it at its source.
Discover Gaps of Understanding Early
The Navigator is an interesting role. Rather than writing the code you are thinking about it has to go through another human’s brain first. This creates an incentive for the group to make sure the person with the least amount of context and knowledge is brought up to the level of the group very quickly.
When done well, this creates a nurturing environment that can accelerate someone’s onboarding to a new domain, tech stack or even the company itself.
Overall, I had a lot of fun and met amazing people along the journey. I’m very grateful that a sincere level of human interaction is so easily available nowadays. Especially if you’re isolated in a solo task or long-term project on your own. Coach Bob—Bob Allen—is hosting these weekends regularly for all timezones. Give him a follow
"Diversity of Opinion Accelerates Discovery"
This is overlooked so often - we want differing opinions on a team and differing experience levels (which helps with differing opinions) so we get better thinking and accelerated discovery.