Working in a distributed team isn’t easy, especially when members are spread across 4 locations. I was recently part of a team that was doing pretty well, but wasn’t functioning as a cohesive unit. There seemed to be hesitance towards pair-programming sessions, even though doing quick Skype calls seemed to be fine. We were relatively open during retrospectives, but were missing out on the deep conversations.
I had a feeling this was a trust issue, and that spending more time together could help. Sitting in an online meeting doing team-building exercises didn’t seem like the best approach, which is when I stumbled over Mob Programming as a way to both get work done, and build up the team’s collective trust and understanding.
The team reluctantly agreed to try it out, but sadly the nature of projects, deadlines and some challenging technical choices ate up our time. I couldn’t justify taking time out of our schedule. So we trudged a long and did a pretty good job of delivering what we had intended.
A few weeks after the team had delivered, and I had taken a planned leave of absence, I received a tweet that blew my mind:
— Tormod Hystad (@TormodHystad) July 13, 2016
I recently had the opportunity to speak in person with some of the team and heard that this one experience stood out as a wonderful experience for them. They learned a lot, and solved the issue together with developers, QA & the delivery manager.
I heard something else as well. There was an openness to the way the conversations flowed. A level of trust that wasn’t there before. This single experience of working through a problem together seemed to have been a defining moment for the team.
Planting a seed
I’m slightly bummed out for missing that session, but it seems that I may just have planted the seed that helped nudge the team in that direction. Or maybe not. Either way, seeing the joy and feeling the candid discussions from the team really lit me up. That team was ready for any challenge now.
Doing it “by the book”
“The book” about Mob Programming talks about a driver / navigators constellation, where all the ideas from the navigators need to go through the hands of the driver. Thus enforcing the shared ownership and understanding.
Was this a Mob Programming session “by the book”? Probably not. But the original definition of Mob Programming seems a lot more important than the driver / navigator approach:
Mob Programming: All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer.
The essence of gathering as a group and solving an issue together was there, trust levels were raised and value was delivered. I hope to bring the value of this experience with me to work I do in the future, and hopefully experience the same building of trust within my next team.
What are your thoughts about Mob Programming? Can it be used in distributed teams? Please feel free to reach out to me directly if you have any thoughts, questions or criticisms. Or leave a comment below.