Feedback-feedback on Mobbing
We’ve gotten some great feedback on our recent article on Mobbing! Thank you for that; please keep it coming!
The feedback boiled down to three topics (and two bonus ones!), which we will address in this follow-up:
- Team performance
- Individual performance
- Project ownership
- Optimizations
- How we work
Let’s start with the Team Performance. The feedback boiled down to this: “How do you know that a mobbing team will perform better than a non-mobbing team?”
It is hard to compare two distinct teams from one another — especially if the teams are working on completely different things. So instead of trying, we tried to introspect how our own team performed before/after we started practice mobbing. What we have found, is that our team does not perform worse / are lacking in perceived velocity after we transitioned to mobbing. Or, put in other words, management and external parties are not lamenting the lack of features and fixes we output, but instead are working to keep up.
When bringing the question up in the mob, we started talking about how we are less concerned with performance as such and instead choose to focus on the knowledge sharing that naturally occurs. This means that a task is never stalled because a key member is busy or away for whatever reason. The work flows along anyway because a large part of the team is completely up to speed. There’s built-in redundancy in the process.
By mobbing extensively, we make great strides towards eliminating knowledge silos. Yes, we have engineers who are particularly good at certain products, but through mobbing, everyone can pull their weight.
I’ve tried to illustrate the Team > Individual below approach through a diagram that shows that, expertise comes in different flavours — you can be really good at e.g. “Machine learning”, but have very rudimentary knowledge of “React & Redux”. As a part of a mob, however, the shared knowledge covers both areas, enabling the mob to continually produce high quality software.
Reteaming
At Redgate, we conduct an annual reteaming. When it comes to a team’s performance; because we do mobbing, we naturally bring new team members up to speed quickly, empowering them to output high quality code — that fits in with our existing patterns and practices. The new team member needs to spend less grumbling over why this decision or that pattern was used, as it is explained to them (and they are encouraged to ask/question) as they start. This has been useful “especially now when we are all working remotely” and helps as it “gives us an in-office feel”.
Individual performance
On the note of individual performance, we were asked how management “can calibrate people in a team that exclusively mob”?
We achieve this by actively rotating the navigator and driver roles throughout the day and through a process whereby we give open and honest feedback. To put it simply, our team lead asks us individually how we are getting along, if we have any feedback for one another and is then able to act on that. Adding to this, we have a daily retrospective at the end of the day, where we focus on things that has gone well, and things we can do better the following day. We end this retrospective with some fun time, where we play games together, which helps us bond and delineate between work and our family lives.
If any of this sounds good (and we hope it does!), this is a good time to point out that we are currently hiring!
Ownership
“When everybody owns something, nobody owns it”. To mitigate this, we take turns in leading pieces of work and to lead stand-up (where we ask the team to clarify to our stakeholders what we are doing). Each task/issue is owned by default by the person who initiated it (which could be any member of the team that found/received/noticed an issue), followed naturally by the last person who navigated the issue in the mob. Where there have been issues that had been getting stale on the issue board, we have questioned whether or not it should still be there, prompting someone to either take ownership of it, or discard it as no longer important.
Optimizations
This section is not a direct answer to feedback, but instead serves as a clarification on how we justify “spending so much time” by having multiple engineers working together instead of individually:
- Because we work together, features and fixes gets merged into the main branch and delivered as soon as they are done, instead of having to mature on a board, waiting for someone else to review them.
- Because we work on one thing at a time, we have to spend very little time trying to resolve merge conflicts.
- Because we have our new starters as a part the mob as soon as possible, we get to identify problems that they experience first-hand, which lets us continually improve both our onboarding experience, lets us simplify concepts and make our products easier to use.
- Because we work together, we always have someone to bounce ideas on, without having to spend a lot of time introducing them to the problem space.
How we work
We default to mobbing. When we cannot join an existing mob, we work out loud, by telling the team what we’re doing instead.
Sometimes, individual contributors choose to work on their own (e.g. to prepare a presentation, to prepare/conduct an interview, …). In these cases, when they later rejoin the mob, they tell the mob what they’ve been up to and demonstrate their work to get feedback and to debrief. If it’s code that’s been written, the merging is done in the mob.
Summary
I hope these points above clarify how we look at team performance, individual performance and ownership. I realize that there are no numbers attached, which is a shame, but I do invite other teams with an established velocity metric to compare their pre- and post mobbing velocities and compare for themselves. Please note, however, that mobbing is a practice that takes time to shape why results will lag initially.
