For a teams new to mob programming, the post mob retrospective is really important. This is where everyone who participated in mobbing get’s to share how they found it and put forward suggestions on what to change next time.
Your first post mob retro should not take too long - try keep it under 15 minutes.
Start with an easy question
Start the retro with an easy question, something that everyone is comfortable commenting on (often once a person makes an initial contribution, you will see them contributing through out the retro).
I like to start with…
Did the physical layout work for you?
Encourage people to give feedback. Be comfortable with a few moments of awkward silence. As people give feedback, look out for suggestions and ideas on what to change. If you identify one, write a headline for it on a post-it note.
Make suggestions visible to the mob
Once a headline is written, put the post-it note in a place where the entire mob can see it. If you have a whiteboard by the mobbing station, often this is a good place to put them.
Often, you will find that in future mob programming sessions the same area becomes a place for people in the mob to write suggested topics to discuss at the end of mob session.
Try and get to the heat
Asking about physical layouts, while important, is less important than getting to what I like to call the heat.
Usually the heat is around how people communicated and interacted during the session.
- Did everyone feel engaged, what stopped you from feeling engaged?
- Were there situations where you felt there was unnecessary friction, why do you think there was this friction?
- Were there situations where you felt you were talking over someone else, what can you do differently next time?
If there is no real heat, or people aren’t in a good place to go there, don’t push too hard. Mob programming can be extremely tiring. Sometimes people just need some time to recover and think. If your mob is in this state, suggest moving the retro to when the team starts their next mobbing session. If the majority of the mob is happy with this, end the session but make sure you do the retro before you start the next mob programming session.
Handling suggested adjustments
Before you close the retro, go through all the new suggested ideas and changes. You want to frame these suggestions as ‘experiments’ - something the mob can try, and if it doesn’t work relook at.
Be careful not to adopt too many experiements at once. Having too many experiments going on at the same time makes it hard to gauge what experiments are working and what experiments are not. My rule of thumb is 1 to 3 experiments is fine, anything more than that and I want to park some to come back to later.
Whether you decide to get consensus, or whether you will try something if you get a majority depends on the dynamics of the mob. My preference is consensus, this is in line with a core tenant of mob programming which is treat everyone with kindness, consideration and respect. Make a clear distinction between the experiments you want to try, and the other suggestions that are parked. Having a section on you white board titled “current experiments” is often a nice way to distinguish between the two categories.
How often should you have a retro
When trying mob programming for the first time, you usually start off with a one or two hour mob programming session. Do your first retrospective straight after the first session.
As your team adopts mob programming as a daily practice, it may be more natural to have a retrospective at the end of each day after the last mob session.
At some point the mob will begin to flow,
