Daniel and Martin have been in the same team since the beginning of summer and they’ve been collaborating in an unconventional way. Yassal interviews them to understand what’s been going on.
You’ve been successfully using mob programming with your team at Expressen for the past 6 months. How did you get started?
Daniel: The project started without any tech solutions in mind. We decided as a team that mob programming was a good way to figure out what tech stack to use. We had no backlog, but we sort of knew what we needed to do
Martin: I remember proposing this as the best way to do discovery work from a tech perspective. We didn’t know what language or tech platform we were aiming for, and this way we would learn more quickly as a team and could come to a decision.
So, what is mob programming anyway?
Daniel: I don’t really care about the formal definition, to me it’s group programming rather than pair programming. One person is at the keyboard and the others act as support, coming up with suggestions, or researching potential solutions. This helps the whole team stay on the same page, and makes sure that we’re all learning at the same pace.
Have either of you used mob programming before?
D: No, I’m a hesitant pair programmer at best, this wasn’t something that came naturally to me.
M: I haven’t done any real life mob programming before, but I’ve read a lot about it, and I have friends who have recommended it. This was my first time trying it out in a team.
How many people are in the team? Are you collocated?
M: We are 2 developers in Russia and 3 developers plus a few UXers and POs in Stockholm.
I’ve seen your setup, you have a super sized screen right where you sit in an open landscape. Does it disturb the other teams when you mob program?
M: They’re envious of our 60” HDTV.
D: The other teams come over to check out the screen. It looks strange when we’re sitting with our arms crossed not doing anything when one of the guys in Russia is programming, we use earphones with a splitter to improve audio. We’ve considered using some kind of indicator to show that we’re in session, so that they don’t come by and disturb us.
People say that mob programming does not work with an avid VIM user and I know you have one of those in your team…
D: Well, since we each use our own computer and use ScreenHero to share the desktop, each person can use their favorite editor. The driver’s screen is the one on the big screen, this works especially well since we’re not collocated. So having a programmer who’s an avid VIM user hasn’t been a problem at all.
What do you feel has been the best about working this way?
M: For me it’s the shared understanding that the team gets. I can always turn to anyone and ask a question, and anyone can answer because everyone is on the same page.
D: The knowledge gap disappears, there’s always someone who has the answer, or who is looking it up. It’s rare that we’re all stuck at the same time, although sometimes you’ll see us all googling on all screens simultaneously 😉
M: We may not be the quickest all the time but we’re the best we can be all the time
D: Actually, I don’t think we are slower.
M: That is probably true. When we started out people around us were amused and sceptical, especially when we got the big TV. But 2 months later when we released the new version, our manager really shifted and stopped asking “Is this really the best way to allocate resources?”
D: Yeah, on paper this looks like it doesn’t add up.. but it really does.
M: Absolutely, management thought we’d be really late in delivering, and were pleasantly surprised when we delivered as early as we did, and they credit that to mob programming.
Are there things that you don’t like, or have had to adjust with this way of working?
M: The distributed part of our mob programming is a hassle.
D: Yes, it works better when everybody is at the office. But our space is crowded, we have two desks facing the big monitor, so when everybody’s in the office we’re uncomfortably squeezed in. It’s also somewhat mentally draining. You have to be focused the whole time. When you’re mob programming you don’t have any down time, especially when you’re driving.
M: A lot of other teams that I’ve heard of limit the time when they do mob programming to a few hours per day, then split up, to “conserve energy”. Here we try to do it as much as possible.
D: Yes, especially since we’re in different time zones. We try to mob program as much as possible when everybody is there. It ends up being about 5 hours a day. We’ve talked about not mobbing all the time, but that hasn’t materialized. Since the project we work on is brand new, there’s always new ground to cover and we think that important architectural decisions should be taken together, so we end up with mobbing pretty much all the time.
M: So, basically we think of mob programming as the standard, but why did we stick with it?
D: I think we stuck to it because there was no obvious better candidate. This was the most effective and efficient way to work on the project.
You’ve recently started a new project, are you still mob programming?
D: Yes we are, but it’s something between pair programming and mob programming, since we’re only three people working on the new project, and we’re not always all at the office.
Would you use mob programming again?
D: It’s all about the people, given the right circumstances, absolutely.
M: Same for me. I’ve started mobbing with other things, like mob designing interfaces, and that worked out really well. But it’s definitely about the people. Mobbing makes it more obvious when we have team chemistry problems.
Have other people in the organization started using it?
M: Yeah, actually one of the other teams has also started mob programming. So we’ve definitely inspired the teams that sit close to us.
Anything you’d like to add?
D: Yes, we all got closer as a team than if we had not done this. It got us to performing faster, you know, Tuckman’s stages of group development: forming, storming, norming, performing.
M: This is the reason why I like mob programming, it is a real Agile method that gives good synergies. This is not just cooperation, it’s true collaboration!
Thank you for sharing your experiences! It sounds like it was a success overall. It’s also great to see that mob programming can work with a distributed team.
Get in touch via my homepage if you have questions or comments!
This rhymes well with my own experience of mob programming. Our team could see a definite increase in sprint velocity when we mob programmed. But it is mentally exhaustive.
Great idea! Thanks for sharing this interview. I like how this massively shortens the feedback loop from the group having an idea to being able to check it out. So far I’ve only been privy to teams’ having discussions at a whiteboard, and plenty of pair programming.
Thanks for translating it’s a great interview.
Actually my team was doing this quite often(2-4 local developers) and I was quite happy on the results that they where obtaining on self organization and performance.
Sadly, top management of the organization was not able to understand this way of work and their benefits. They requested to share the tasks among all the developers of the team to increase the velocity of the team.
I did explain multiple times that this is going back to the old planning styles and we should help the self organization to flourish as the team must know better than management what they need to do to increase their velocity. But so far no change on management and they’re increasing the micro management of the team that is decreasing quality and velocity.
What would you do if you’re in this situation?
Hi Oscar,
I’ll try to answer the question with the information you’ve provided. It sounds like management is concerned about increasing velocity, and that you’ve noticed that quality and velocity are actually decreasing. How do you measure velocity and quality? If these are things that you can objectively measure then maybe that would help in this discussion. Also, try to find out why top management feels that micromanagement is the best way to go. Are they not getting the results that they expect? What are their expectations? Is what they want more transparency/information?
Good luck!