👬 Background 👭
In one of the recent retrospective ceremonies in my current company, it was highlighted that our pairing sessions had become a little painful, and that the team felt that we weren't getting the most benefit out of our collaboration sessions as we could.
The company I currently work for is very collaborative in nature, and encourages pairing and mobbing (forms of extreme programming or XP) rather than tackling tasks solo.
This highlighted something that I hadn't thought of before this point: that none of us had been taught how to pair or mob effectively. All of us had at some point been told to work with someone else on writing code, and so we did, without thinking about how this could really work.
None of us had really recognised this as a skill that needs building upon, or improving. Or that this was really more than one person writing code, and the other watching for mistakes.
Therefore I set up a workshop-cum-retro for my team, that I hoped would highlight good practices for pairing and mobbing, identify the pain points of our current methods, and allow the team to think a bit more about how they best work as individuals, and how they can use that to their advantage when working collaboratively.
✨ The Workshop ✨
The workshop and retro were done using Miro, which allowed the team to interact in real-time whilst working remotely, and ensured that everyone was able to be engaged with the process.
The first part of the workshop focused on the definition pairing and mobbing, and highlighting what hasn't been going well so far.
I gave the team two minutes to think about what they have been struggling with, and then facilitated a short discussion about what they had raised.
From here I moved on to how pairing and mobbing is a great way for us to work, but it's important for us to remember that we are people, and not machines. And unfortunately with that, there are great differences in the way each of us would be able to work to their best.
One of these main differences being our individual learning styles. I talked through these and explained how these can have an impact on how each person would best approach collaborative working, and how to maximise what you get out out it.
I then added a section which highlighted 6 ways in which pairing can be most effective.
Then, using all of this information I asked everyone to fill in a small profile, with their preferences/likes, dislikes/weaknesses, and a small personal learning style evaluation, which we then discussed.
And we then moved on to the retro section. For this I prepared two styles of retro, one being a regular retro board that would allow the team to put what has been going well, what hasn't been going well, and what could be improved. And the other was a table which allowed them to each give specific feedback to each other.
As the latter option would be more personal, I made it clear that this would only be used if the full team felt comfortable to do so. As I realise that personal mental health and frame of mind could impact how feedback and criticism is given and received.
Finally the Miro board ends with a section for actions, feedback, and online resources for further reading/proof I researched some of this.
🐁 How did it go? 🐁
Firstly, it was clear that I tried to fit too much into one hour, unfortunately it has had to be split into two, with the team discussing the ferris wheel and actions after Easter. This was then completed on the 13th April, with the team capturing some key actions for improvement.
Thanks to the open discussions in the team I feel as though we have identified our biggest difficulties with pairing, and helpful ways in which we can improve.
Such as:
- Timing how long we have one person driving for, and introducing more frequent switching.
- Planning what to do before trying to do it.
- The team also identified that as we move forward, we may want to do more solo tasks, to reduce social burnout.
- Regular reviewing of XP practices can also prevent the team from falling into old habits.
- And note that some team members can benefit from approaching the task in different ways, so tools like Miro can be used to diagram the solutions, or make a to-do list prior to starting could be very helpful.
🔎 The Resources 🔎
Unfortunately, without paying to upgrade Miro I am unable to share the template for this, so I hope that people who wish to run a similar session can use what I made as a base for their own versions.
However, here are the resources that I link at the end of my template:
- https://duckly.com/blog/7-tips-for-successful-pair-programming/
- https://www.rasmussen.edu/degrees/education/blog/types-of-learning-styles/
- https://www.codecademy.com/resources/blog/what-is-pair-programming/
- https://www.pluralsight.com/blog/software-development/mob-programming-101
- https://martinfowler.com/articles/on-pair-programming.html
And these are resources suggested by other people I have shared this with:
- https://pomofocus.io/
- https://woodyzuill.com/
- https://tidyfirst.substack.com/p/thinking-about-code-review
🤔 Final Thoughts 🤔
I hope that this has been insightful and helpful to teams with similar issues. And that this has helped inspire people who want to improve the pairing and mobbing practices in their own teams.
It may not be a perfect approach, but to re-iterate, collaborative working is a skill that needs to be built over time through practice and conversations, whilst I am still very new to running sessions like these, I hope that this is useful to somebody.
Top comments (0)