Distributed development at DataStax
I started out at DataStax running the OpsCenter team, which is colocated in Austin, TX. A few months ago I took over our DataStax Enterprise (DSE) team, which is completely distributed: from Oklahoma to Poland to Belarus. I was skeptical about how things would work out. Would everyone feel like a team? How would we get things done without in person debates and a whiteboard? Would the team be happy?
The success of any development team starts with the people. Finding smart people is hard. Adding the requirement that they must fit into a distributed team/company compounds that. These are people that prefer to work independently, can learn quickly on their own, and don’t require a lot of hand holding. We’ve hired good developers in the past that just weren’t a good fit for the distributed nature of our teams, so we now know to be very aware of these qualities in future candidates.
At the core of making a dev team run smoothly and efficiently is having a good process (or workflow) in place: we use a hybrid of the Kanban method. Having everything organized in a single location, combined with concrete expectations, allows the team to run as autonomously as needed. Everyone on the team should be able to understand what’s happening within the project without daily meetings or micromanaging. This transparency into what everyone is working on also helps to add trust among the team.
Communication and Collaboration
Because our entire company has always been distributed, using chat rooms (specifically HipChat) for most conversations has always been the norm; including when two people are less than five feet apart. This helps tremendously with ensuring the distributed team members aren’t – and more importantly, don’t feel – left out of day to day conversations.
We also try to keep discussions and decisions regarding a certain feature or task recorded in the ticket itself so that everything can be found in a single place; rather than lost in chat logs or email threads.
While being able to get up and talk with someone or work on a whiteboard in the office is certainly nice, I’ve quickly come to realize through experience that these are more of a convenience than a necessity. Given enough time, smart people will figure out ways around physical limitations: video conferencing, online whiteboards, etc. I’ve even recently witnessed team members using the collaborative nature of Google Docs combined with the shape tool to talk out a design decision via diagrams.
On any distributed team you’re inevitably going to have team members in different timezones. In our case we have team members that are as far apart as 9 hours. This means that people have to be a little bit flexible to allow for some overlap, but because our process is mostly autonomous only a minimal amount of overlap is actually needed.
The dev organization as a whole benefits from using the same processes and ideas among both colocated and distributed teams. Both teams are given the opportunity to focus and work independently as needed, inter-team communication is inherently promoted, and of course the colocated teams can wander over to the water cooler whenever they feel like talking about sports.