These days everyone seems to understand the benefits of a co-located development team. However, there can be some downsides to colocation if it is abused.
Concentration is a limited commodity
One of the first things I hear from most entrepreneurs is how much easier it is to have everyone on site. Frequently this is then followed by “I can just walk over and tap the developers on the shoulder any time I have question.” Try as hard as might, this statement always makes me visibly cringe. Why?
The most precious commodity to a strong developer is concentration. No doubt, coding calls for great requirements, estimates and planning. However, its daily execution relies upon careful concentration. Each time you walk over and tap a developer on the shoulder, you break this concentration and take them out of the flow state. The costs to velocity are massive.
The cost of a 3 minute conversation isn’t 3 minutes, it’s more like 20. You need 3 minutes to have the conversation, then another 15-20 to get focused again and load everything back into mental RAM.
No doubt there are times when this type of disruption is necessary (there is a problem on production) but most often these types of discussions can wait until there’s a natural pause. These tend to come every 45 minutes to two hours - the time period when folks naturally take a break.
Treating your local developers like they are remote, and perhaps using Skype, or email so they don’t need to respond immediately minimizes these needless distractions.
Next time you think about tapping a dev on the shoulder, think: Does this issue need to be attended immediately?
Ad Hoc conversations can mask organizational immaturity
“We’ll just get everyone in a room and sort this out”. The ability to pull everyone into a conference room and chat through any problems is definitely a huge win. However, no one frequently asks why this type of last minute huddle is necessary. Was there a problem earlier in the SDLC?
The answer to this question is usually yes. Stories aren’t fleshed out with appropriate details (or even worse, there are no stories), deployment and testing isn’t done continuously and requires these types of meetings. When teams know they can rely on this last minute huddle, they sometimes fail to develop mature processes that prevent these fire drills.
Remote teams can force some pain earlier in the life of a business. Systems that share information asynchronously need to be in place and requirements often need to be queued and fleshed out earlier. However, as painful as this may seem, it actually may be more efficient than having a developer begin with unclear or poorly thought out requirements, and get off track because everyone knows they can just hop in a room and sort it out later.
As in all things, moderation is key. Remote teams don’t necessitate waterfall specs and local teams don’t require specs at all. Nonetheless, both teams require clear starting points and the understanding of how to get clarity when they need it without involving a fire drill.
In all things, be conscious
Businesses can succeed and fail with any number of cultures. Great development teams can be local, remote, or more commonly, hybrid. However, regardless of the location of your developers, make sure you are conscious of whether you are taking advantage of locality or abusing it.
Are you looking to expand your development team? Click here to see if nearshore software development might be a good fit.
