distributedlife

Part three of my agile presentation is about co-location.

The parts so far: Part One, Part Two

Co-location is the grouping together of the team into a single physical area. The reasons being that when one person in the team needs information from another person from the team, they can turn around and as for it.

Personally I like co-location but its not all peaches and cream. I’ll discuss the negatives first before thrilling you all with the positives.

My main negatives of co-location are:

• potentially noisy / distracting environment
• team members become reliant on asking and not learning for themselves
• Doesn’t work in a virtual teaming environment
• Doesn’t scale if you can’t break a large team up into smaller sub-teams

Potentially noisy / distracting environment

Normally when teams are arranged, it is by discipline. The developers in one building, the analysts in another city and the testers in a back alley somewhere. If you group a team together that is design to work together for an extended period of time. Friendships form, people start getting along and the next thing you know they are discussing the weather. Obviously, this dog won’t hunt.

None of this is bad, however, there are opportunities for distractions. Developers and testers (I assume analysts too) like getting into a groove. You start working, get a good rhythm going. Everything starts making sense and before you know it you’ve tested half the system or you’ve coded a killer app. If you get distracted or need to continually offer assistance then it becomes hard to get a good work groove and your productivity falls.

This is why I like to work after everyone has left for the day. Its not because I don’t like my team, but I need to break part of my day into performing testing and the other half towards managing testers, working with the analysts and developers, providing feedback, clarify defects, etc. Often the ratio of developers to testers is greater than one which can mean a steady stream of questions.

This isn’t bad either and it all helps the project. But so does my other responsibility, testing. Everyone goes home and I can then bash out another two to three hours of work in the comfort of my own headphones.

Team members become reliant on asking and not learning for themselves

This was best covered by Joel Spolsky in this post on Joel on Software. Read his post, I’ll summarise with this excerpt.

…it’s so easy to get knocked out of the zone. Noise, phone calls, going out for lunch, having to drive 5 minutes to Starbucks for coffee, and interruptions by coworkers — especially interruptions by coworkers — all knock you out of the zone. If a coworker asks you a question, causing a 1 minute interruption, but this knocks you out of the zone badly enough that it takes you half an hour to get productive again, your overall productivity is in serious trouble. If you’re in a noisy bullpen environment like the type that caffeinated dotcoms love to create, with marketing guys screaming on the phone next to programmers, your productivity will plunge as knowledge workers get interrupted time after time and never get into the zone.

Doesn’t work in a virtual teaming environment

This is pretty obvious. Co-location and virtual teaming don’t mix. Virtual teaming has its advantages. Your employees get to work from home or whatever city they are based in. You can have round the clock development teams where one team hands over to the next team at the end of the day. The next team based in a separate time zone is just starting the day.

The potential cost savings can be extraordinary. It’s not all sugar and sweets however. Managing a virtual team is difficult. I’ve managed four virtual teams so far and none of them were easy projects. Communication is the most important aspect, having your team be in regular contact can be painful. Conflicts are difficult to manage as avoiding one another is easy. Written communication doesn’t convey tone which can lead to misinterpretation. The bond that bind the team doesn’t get created without alot of upfront team building.

This is what co-location is about. Forming a bond between team members to create a more productive team unit.

Semi Instance Messaging tools like twitter may help (twitter didn’t exist the last time I tried to manage a virtual team). Wikis and forums are also useful. Your team will spend time joking and carrying on in the forums. This is not a bad thing. A team that has no rapport lacks the trust required to pull together during the crunch. There always is a crunch.

Doesn’t scale if you can’t break a large team into smaller sub-teams

If you have a large project team then you are not going to be able to get them all in one location working together, communicating. Too many people and potentially too much noise. Break the teams up into smaller sub teams, each team with its own analysts, coders and testers. Keep the teams small and the bonds tight.

Peaches and Cream

So what is so good about co-location? As a tester the ease at which I can get clarification on business requirements or a bit of implementation knowledge is phenomenal. In return the developers and analysts wander past my desk asking what they can do to provide me with more useful content.

Developers start to want to know what testing is going on, how the build quality is, what am I looking for. This opens up the ability to do odd couple testing (which I’ll get to in a later post). Its basically one big fuzzy ball of good feeling.

The shorter the build cycle the more important co-location is. You need to constantly liaise with the developers, provide feedback and clarify requirements. If the teams are separated and it takes 5 minutes to walk to your team mates, its 5 minutes back. At that point you start collecting questions to ask all at once. As soon as that happens the communication cycle breaks down.

Co-location isn’t easy and it doesn’t come right away. Regardless of team geography you need good people. When you have good people it can help to put them together. With anything there are pros and cons. Weight them up, make a decision, then make it work. Unlike software team dynamics do not happen automagically.

Note: The positives probably weren’t thrilling.

2nd Note: Not every day is filled with pesky developers asking me questions. I never know until I get there so I plan ahead and come in late.