A while ago I read "Technical Agile Coaching with the Samman method" from Emily Bache which has changed a little bit how I understand what I previously had known as Mob programming sessions. So... yes, here's the first change: Emily favours the term ensemble, which refers to a group of people performing together, over Mob because it doesn't have any destructive connotations.
What is ensemble programming
Is a programming session where the whole team works together in one single task.Mandatory roles
Typist
The person who is typing on the computer what the rest of the colleagues are saying. Important to realize that the typist doesn't have its own ideas, funnels navigator's and the rest of the ensemble ideas into the computer.I find the name interesting in contraposition to driver which is used a lot in the context of pair programming (where the driver has an active voice). The way I understand it, the typist is not driving the session, just the opposite, is being driven.
Navigator
There must be only one single navigator with the responsibility of explaining what should be done... and there's an important nuance: The explanation should be done with the highest possible abstraction level.Emily talks about 3 levels of communication that can be used:
- Intention - Express what you pretend to do. If the driver knows how would she accomplish that, she's good to go.
- Location - If after expressing the intent, the driver still doesn't know where to start acting, add information of where you would do it: "Go to class X".
- Details - After intention and location have been expressed, if the driver still frozen, it's time to be very explicit on the how: "Introduce line 45 and a half and type..."
Supporters
Unless there are people acting with other roles, this would be everyone else in the ensemble. The supporters should be actively listening and helping both the driver and the navigator measuring their contributions. In their case, silence is very valuable, as sometimes waiting a couple of extra seconds to say something can really spare that comment, it's important not to disrupt the flow and avoid context switching when possible.Flow should be interrupted whenever a team member is not following the current work to ask for explanations or clarifications.
Optional roles
Facilitator
Used by teams who are learning to ensemble, the person with this role ensures the guidelines to do it properly are being followed (rotations on time, roles are respected, breaks are taken, ...)Researcher
Whenever a very specific information is needed, the researcher is entitled to use a second computer and search for that information. Once is found, then the researcher goes back to its original role of supporter (I've done this in a more wacky way, were almost everyone was googling in parallel whenever we got stuck somewhere 😅)Archivist
This person is kinda writing the diary of the session: which alternatives were dismissed and why, steps done, tried things... whatever you feel it's worth recording.Coach
The last optional role in an ensemble is the coach (not surprisingly, considering the book). The ensemble is an excellent forum for a coach, the whole team is there and working on a specific task (hopefully related to their real goals). The coach can benefit from the occasion to do multiple activities:- Teach - If there's a knowledge gap in the team, the coach may teach them some focused content that can be immediately used. This teaching mini-session will probably disrupt the flow of the session for a moment.
- Mentor - Use the coach experience to lead the team to a better solution, by facilitating the adoption of new techniques or the application of concepts the team is aware of but not fully proficient with.
- Facilitate - Help the team have a smooth ensemble, ensure every voice is heard and respected and ensemble good practices are followed (this would be putting the coach in facilitator role)
- Coach - Ask questions that help the team to find better solutions (answers should come from the team itself).
- Observe - Follow with attention how the team works together and identify patterns and ways of improving they would appreciate but fail to identify. Since the goal of the coach is to make him/herself disposable for the team, it's interesting to take a step back every once in a while and observe how does the team collaborate without the coach's influence.
- Take breaks - The coach should lead by example and take reasonable breaks too. These breaks will leave the team on its own... so it's a good opportunity for the team and the coach to see how they manage by themselves.
- Retrospect - After an ensemble session, make sure the improvements and learnings are shared and collected. If the coach took an observer role, it's a good moment to share its findings.
Ensemble good manners
Navigator should tell before typist writes
If a typist starts to write before the navigator has explained its intention it should stop.Write first, argue afterwards
The driver should write the code and argue afterwards. Conversation is easier in front of a living example that you can toy around with.Yes, and
I've been multiple times in an ensemble session with the feeling that we were running in circles, doing and undoing code. Emily suggests a simple rule that hopefully alleviates these situations, the "Yes, and" rule. Inspired by improvisational theater, the rule states that you should also follow up the conversation with a "yes, and". Translated to the ensemble context, this means you should not negate (delete) what has been done before you get the navigator or typist role, you should build on top of it and refactor if you consider that appropriate.In my case, we sometimes used an alternative to this rule that we called the "3 minutes rule", where someone in the ensemble was allowed to work alone for 3 minutes and then we all discussed the outcome. It helped us move forward when we where blocked, but I see these rules targeting different problems.