en
de

Distributed Development: Collaboration (Part 2)

6 March 2015
| |
Reading time: 6 minutes

Good teamwork and well-defined communication channels represent the foundation for any successful project. As much as it is true for both collocated and distributed teams, there are problems that the team members working in the same office don’t have to face. No special setup is required to start a meeting, information is spread quickly in the team and it is easy to ask for someone’s help when the person you are looking for is sitting next to you. Whether it is an occasional discussion in the room or a short talk during the coffee break, these small get-togethers are an excellent way of getting to know your teammates better and share the knowledge.

In the distributed setups, lack of face-to-face communication can be compensated (at least to some extent) with the usage of proper tools. In the previous part of the post we covered the required infrastructure, while in this part we will focus on the collaboration tools.

Tools used for Scrum meetings

For the teams involved in distributed development, traditional physical product/sprint backlog boards need to be replaced with the appropriate virtual versions accessible to all members of the team. This usually involves choosing among one of the available online tools such as Jira or Trello. Although you can easily setup these tools, the problems arise when you need to tailor them to your specific needs or processes.

In one of our projects the product/sprint backlog was maintained in Team Foundation Server (TFS) and the team, which was in the beginning collocated, used the physical board to visualize the sprint progress. Once the team went distributed this way of tracking progress became an issue for the off-site team members. We turned again to the tracking tool (TFS) but the usability and visualization features of provided electronic boards weren’t enough. In the end we decided to use a TFS extension called Urban Turtle which gave us more flexibility in visualizing the product and sprint backlog. After a few tweak/test iterations the electronic boards became our common (and only) way of tracking progress.

In case none of the existing solutions fits your needs, building a custom tool is a valid alternative.

In one of the projects we were involved, a custom made board was developed and improved by the team members. It integrated nicely with the story tracking software, and, as a bonus, the team also got a tool which distributed backlog stories quite nicely in stacks so backlog refinement sessions actually became more efficient and pleasant to attend.

Sprint planning sessions usually involve lot of discussions around the sprint backlog. The team needs to understand the business value of the backlog items, resolve remaining technical concerns and breakdown the required work into tasks. Any conference tool with desktop sharing can be used
for sprint planning sessions with one person guiding through the sprint backlog and adding tasks.

If you are unable to use tools like Microsoft Lync or TeamViewer for collaboration with people without access to your company’s infrastructure, you can go with a classic conference tool like GoToMeeting or Cisco WebEx.

486140535-web

Daily stand-up meetings are important part of distributed development. They are the perfect place to sync with the rest of the team and talk about any blockers/impediments. Sharing the video and standing in front of a TV with a camera will make the experience feel closer to the face-to-face meetings. Usually someone is required to share the sprint backlog so that entire team can have an overview of the sprint. Video calls and desktop sharing are the prime requirements for the tools used for the dailies.

Instead of standard Lync calls, one project uses an interesting combination of Google Hangouts (audio/video call) integrated into Slack (message sharing) for the daily meetings. Messages were used for announcements (leaves, guests, etc.) and note taking, and could be accessed by all team members at any point in time later.

Estimation sessions include discussions about the backlog items and estimation of the effort needed for their implementation, usually in a form of a vote. Both of these tasks can be done in a distributed fashion using standard (video meeting with team members showing their votes in front of a camera or typing them in chat window) or specialized (online voting) tools.

For estimation sessions we use Microsoft Lync for discussing and presenting the backlog items that need to be estimated. In the end we vote using an online estimation tool – www.pointingpoker.com. The tool is very simple to use, estimation points are configurable and creating and sharing an estimation session is done very quickly.

As a meeting which usually takes place at the very end of the sprint and where the possible improvements are discussed, Sprint retrospectives are also a perfect place to talk about the tools and infrastructure involved. The feedback and new ideas from all team members should be taken very seriously and the appropriate actions should be taken.

Because it requires input from all team members, retrospective usually implies some sort of online collaborative note-taking tool which is used for gathering this input. You can even use the Lync Whiteboard utility or Google Docs but Trello has proven to be the best player in this field – intuitive and fast interface, as well as plenty of options it offers are the main reason for its popularity. Good thing about the online retro boards is that you can set up the board early so the team members do not have to wait for the sprint end in order to add cards.

Tools used for informal meetings

Nevertheless, the distributed team communication should not be limited only to scrum meetings. Ad-hoc meetings are the place where a lot of ideas are born. It’s much easier to have ad-hoc meetings when the team is collocated. Even the coffee break can be used for tech discussions. When team is distributed, it could happen that part of the team just “forgets” the other side when discussing some decisions. So, when you do have some idea, you should always share it with your remote peers.

In one of our projects, we used to schedule a “virtual coffee breaks” right after the daily meetings at least once a week. This proved to be very effective way of sharing the information and knowledge not just about the project in question, but also about general, often personal topics.

One of the biggest pain points for the off-site part of the team is contact with on-site business analysts (BAs), getting requirements and their context.

In a project our BAs are working with customer’s BAs on customer site. While on-site team member can make few steps and clarify any questions with a BA, it’s not that easy for an off-site member:  BAs are working on a customer’s infrastructure and it is not that easy to get in touch with them, except via email.

E-mail is not an ideal communication channel, especially if it is a lot easier to share a screen and say a few words that would give far better context for your questions than a lot of text and images in an email.

For general questions, announcements or as a way for finding a peer for code reviews, you can use HipChat, which can also serve as message board for the team. Basically, instead of shouting through the office for some info, you can just type it in really fast, and you are assured that everybody got the message (as a bonus option, it can be configured to use any proxy settings so you should not have that many issues with your VPN).

For reviews, pair programming sessions or any kind of screen sharing, TeamViewer is an excellent choice. It is very responsive, works on most VPNs and even comes with the option of recording the meetings. On the other hand, its audio component, at least in our experience, is not so great, so in most of our projects we substituted it with parallel Lync or Hangouts calls.

Tools used in our distributed development projects

Tools used in our distributed development projects

Conclusion

In distributed setups, it is crucial to choose the right tools for the tasks you are trying to accomplish. The easier the tools are to use, the faster the team will adopt and use them for their everyday work. One of the most important things to keep in mind is the sound quality. It usually depends on the ability of the tool to cope with high data transfer levels. If the sound quality is not satisfying, you should find an alternatives because otherwise, the team will avoid using the available infrastructure which can hurt the overall productivity and team spirit.

Sometimes the limited infrastructure (including specific network configuration, admin rights etc.) doesn’t allow the usage of the best tool for the job. In these cases, finding a viable alternative shouldn’t be a problem because new tools with strong emphasis on sharing content are constantly emerging (for example Screenhero, Slack…). With this in mind, it is good idea to revisit the current setup from time to time thus allowing both the team and process to evolve and improve.

Comments (0)

×

Sign up for our Updates

Sign up now for our updates.

This field is required
This field is required
This field is required

I'm interested in:

Select at least one category
You were signed up successfully.

Receive regular updates from our blog

Subscribe

Or would you like to discuss a potential project with us? Contact us »