Gil Zilberfeld recounts his experience with collocation during his time at Typemock, and explains how collocation can benefit your team. In modern agile discussions, we struggle with how to work with distributed teams around the globe. The truth is that it’s easy to break stuff just by moving part of the team to the next room.
Since Kent Beck came up with Extreme Programming (XP), agile practitioners have been talking about the advantages of collocation. We know that having people at the same place increases productivity, gets people focused, and breaks down communication barriers. This is not new. In fact, I experienced collocation even before I’d heard about agile.
Ten years ago, my development team kept adding features “creatively” (read: features that were not in the specs), so it made sense to pair them with the testers. While the developers were okay with it, the testers were ecstatic; they finally got features that were actually requested.
“Well, Gil, if you know all this already, why are you writing this?” you might ask.
During the last few years at Typemock, collocation has been second nature for me. Sitting with the dev team with everyone in the same space makes it hard to notice the advantages until you’re hit in the face with them. So, here’s my story.
For the first years, Typemock did not have a dedicated support team. Support was part of the developers’ work. We rotated the duty among us, so every few weeks, developers got a chance to do some support work. This made us better developers on many levels: We understood the customers better, got direct feedback from the field, and turned this feedback into cool features.
Then the team grew, and we wanted to continue improving. One of our goals was to divert more effort to development, which we could achieve by adding support people. We went with this plan knowing that it will not be possible to offload all support operations to the new people. The logical plan was to place the new support people with the developers in our open space.
In the beginning it looked promising. There was a quick ramp-up in the new support team’s learning. If there was a problem, it was easy to pair and resolve it. The new guys took part in standup meetings, and people on both teams knew what was happening “over there,” mainly because “there” was “here.”
We also built a big task board for support tasks, and in time we learned how to manage support tasks that required developer assistance. It wasn’t optimal, but we managed to track handoffs between support and developers, then back again. It was easy because everything was there in front of our eyes.
It was a routine, which made sense. And we didn’t miss it until it was gone.
In addition to diverting more effort to development, there was another goal for the support team. Good support yields more sales. We picked the support people not only for their technical savvy, but also for their people skills. After a few months we wanted to take our collocation effort further.
We moved support staff to the sales area so they could improve their business skills and help the sales team. We’d made the connection earlier: When the customers were happy with the support they got, the support person would talk with the sales person to push deals forward. Like before, it made sense that in order to realize the potential of sales, sales and support should sit together.
The sales area is twenty feet away from the dev area, by the way. We thought the distance was insignificant.
Boy, were we wrong.
The first sign of trouble was the disappearance of the support people from the developer standups. It didn’t happen immediately, and over time we stopped noticing it.
The work didn’t change, though, so we still needed to sync handoffs. Support still needed help from the developers, and when they did, they got it. But the developers were available on request mode only. They were pulled by support. We started seeing the support people less.
Then we started to miss support tickets. A few were lost, and some customers got late replies.
This is where human nature comes in. Before, items were visible on the board, but now the support task board was in the other room. I had to get up and go to that room to see what was happening and to talk with support people.
You’re probably thinking, “How lazy is that guy?”
If I’ve learned something from this experience, it’s never underestimate human laziness. Because I was “so busy,” it was easier to track the status of support tickets through emails rather than walk over to speak to the staff. It was easier to ask a day later, “What’s happening with case X?” rather than go visit their room. It was easier to do it on my terms, without immediate interaction.
And that wasn’t all. We saw a big drop in morale with the support team. Technical people tended to prefer other technical people around them (We have very nice sales people, but still…). Tasks took longer. Effectiveness was lower.
No one was happy. So we changed it back.
Within a few weeks, we’d almost gotten back to normal. When we had the support task board in front of us, we were able to clear it pretty quickly. Support staff pulled developers for help much quicker than before, so we made progress in cases sooner. We stopped losing tickets. And everyone seemed much more cheerful than before.
This was a huge relearning experience for me. I knew collocation worked, but it was only when it went away that I started seeing the effect.
We know collocation improves communication and productivity. But the biggest reveal was how well it works with our nature. Laziness makes us ignore tasks that are not in plain view. It makes us resort to email rather than go to another room. The cool thing is that when people are near us, it’s okay to be lazy. Without even getting up from our desks, we can just ask about case X.
In modern agile discussions, we struggle with how to work with distributed teams around the globe. The truth is that it’s easy to break stuff just by moving part of the team to the next room.
