How to Make Collocation Work for You

[article]
Summary:
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.

Tags: 

About the author

Gil Zilberfeld's picture Gil Zilberfeld

Gil Zilberfeld has been in software since childhood, writing BASIC programs on his trusty Sinclair ZX81. With more than twenty years of developing commercial software, he has vast experience in software methodology and practices.

Gil is an agile consultant, applying agile principles over the last decade. From automated testing to exploratory testing, design practices to team collaboration, scrum to kanban, and lean startup methods – he’s done it all. He is still learning from his successes and failures.

 Gil speaks frequently in international conferences about unit testing, TDD, agile practices and communication. He is the author of "Everyday Unit Testing", blogs at http://www.gilzilberfeld.com and in his spare time he shoots zombies, for fun.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!