DataStax Developer Blog

Distributed development at DataStax

By Mike Bulman -  February 23, 2012 | 1 Comment

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?

People

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.

Process

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.

Bigger Picture

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.



Comments

  1. Burak Say says:

    Very accurate findings, thanks for sharing the experience. Keeping teams as autonomous as possible is one of the key items. Once you have smart people in place that can function without impeding each other on a daily basis thanks to the process, communication and geo-distribution becomes a smaller scale challenge.

    A couple caveats I would add to this would be to related not getting too comfortable with your location. Teams can get gradually morph into habits that promote colocation, which would hinder the communication with remote teams. Things like using hallway chats to make design decisions, moving away from using the common chat rooms etc. Managers should be aware of these risks and try to steer the processes accordingly by raising awareness of the team.

    One last noteworthy practice for running effective distributed agile teams is regular team get-togethers. Regular physical colocation opportunities like hackathons, dev summits, etc. or even just visits for the sake of it will help promote the team perception very effectively. This is something that’s easy to overlook in the name of keeping to budget, but I would recomend considering it as a high ROI activity.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>