At Invotra we have a distributed agile development team spanning five locations, and together we deliver a live release every two weeks. Applying agile development methodologies in a distributed team is subtly different to those of an onsite team. I’ve outlined the key factors which make us an effective distributed development team and help our product and business grow.

Make your agile ceremonies have a meaningful outcome

There are many books and blogs written about running daily scrum meetings, sprint planning meetings and retrospectives. The most important thing for us is to have meaningful, actionable outcomes, without this, agile ceremonies are just a bunch of people talking.

Every team, project, and organisation is different. There is no one-size-fits-all process when it comes to distributed agile software development and blindly applying agile methodologies is not a silver bullet. Adapt how you run daily calls, sprint planning meetings and retrospectives to fit the nature of your project and organisation, make them work for you.

How to run a daily standup with a distributed team.

• Get the basics right. Make your scrum call the same time every day and make sure you have a decent headset, preferably with background noise reduction. If there is background noise, mute yourself if you’re not talking.
• Turn up on time. If it was a real meeting, you’d hope to be there on time. If you are not, contact the organiser to let them know.
• Ensure there is a calendar invite for everyone you want on the call, including a link to the webex. Invite other areas of the business to listen in if they need/want to.
• If you are comfortable to do so, switch your camera on – reducing barriers within a distributed team is important for establishing trust and good working relationships.
• Greet your team as they join the webex.
• Use technology which is right for you, we use google hangouts as it’s ideal for screen sharing, and it’s also free.
• Have your scrum boards in Jira/Trello (or whatever you use) open before the meeting, having reviewed them briefly before the call. Be prepared and share your screen during the meeting.
• Don’t get drawn into ‘solutionising’ during the call. If need be, have people pair up after the call to further discuss the issues that need more attention.
• Decide on a clear format for the call that works for you and stick to it.
• Note actions that come out of the call, who is doing them, and when progress will next be reviewed.
• Share feedback from management with your team If things have been well received, let your dev team know. If something hasn’t gone well, make sure the team know what went wrong so that everyone can learn from any mistakes.

Best day to day practices

During day to day development, there are certain practices which will help progress things and stop issues from falling through the cracks.

• Avoid asking, ‘can someone’ or ‘can anyone’ questions via your Internet Relay Chat (IRC) (Skype, Hipchat, Slack etc), channel. Instead, nominate individuals if something specific needs doing. This way you can be sure that what you want to be done will be actioned, and you’ll know who to ask to check how it’s going.
• If you need to arrange a meeting, always include a link to a webex in your meeting invite. Check others are free to join your meeting and avoid making people have ‘back to back’ meetings.
• During meetings, if actions are required for the future, make a note of them or check someone else has. For your actions, use a format that works for you, a notepad, an app like ‘to-do list’, or maybe you apply the ‘Get Things Done’ method, which involves capturing everything into actionable lists, which then allocate time to process. Whatever your choice, make sure you know what needs doing, and when you’ll action them.
• Make sure development tasks are well-defined and are not lost in translation, give early visibility to developers to feedback to those defining requirements.
• Ensure you involve other teams within the business where appropriate, for example, we give our product team early visibility of significant new functionality to avoid late feedback.
• Encourage pair programming via screen sharing for issues which require a greater level of understanding.
• Sometimes consider team members to be like those running a relay race. Make sure each person passes on the baton to the next person and that they know what the next steps are. When each person in the team is in a different country, this is particularly important so that issues don’t get dropped.
• Get to know your co-workers, the more you can relate to them the easier it is to have conversations. If you can meet in person occasionally, this helps to build relationships.
• Make a note of critical issues that need to be progressed for the day. When your co-workers are in the office, there is a natural tendency to chat with your co-workers and discuss progress. When your team are distributed, that tendency is reduced, so you need a mechanism to check things are progressing as they should.
• Don’t worry about interrupting people via IRC, encourage others to do the same and to discuss issues via webex rather than use a stream of comments on an issue tracker, then make a note of the outcome. If you were in an office and you needed their input, you’d go over and talk to them, it’s important to apply the same habit in a distributed team.
• Help to create a culture where everyone in the organisation considers and includes those working in remote teams.
• If your team is global, be aware that national holidays will differ from country to country, and plan for them.
• If timezones significantly affect when your teams can be together, adapt your processes to work to your advantage and ensure that there is clear direction and no blockers for the times when you are out of communication.

Making the most of retrospectives

Retrospectives, where everyone is in the same room, encourage feedback. In a co-located retrospective you have whiteboards, post-it notes and sharpies! Interaction comes naturally and communication flows freely. Running a retrospective for a distributed team in a webex is different and needs to be led in a slightly different way:

• Have your retrospectives via webex at the same time each week if you can.
• If there are any specific topics or issues which you feel need further discussion, mention them on the meeting invite so that people are prepared.
• Begin by revisiting issues that were agreed to be actioned in the last retrospective. Did you apply the changes agreed upon and what was the impact? If we didn’t action something, why not? Finally, how can it be facilitated and what was the impact of not doing it?
• If something didn’t go to plan, look into why it went wrong. Don’t play the blame game. Instead, take a mature approach. If the code is bad, focus on the code itself, not the developer. Also, be prepared to criticise your own code or mistakes. Without acknowledging problems, you can’t expect to improve. Ask individuals for their feedback as opposed to getting people to volunteer their thoughts.
• Give positive feedback.
• Be clear in the agreed outcomes of your retrospective.
• If you ask open questions to everyone on the call but no one answers, nominate a couple of individuals to get a conversation started.

Too long, didn’t read

• There is no one-size-fits-all solution for distributed agile development teams. Adapt your approach and processes to fit the needs of your project and organisation.
• Use appropriate technologies that fit with your approach and meet your communication requirements.
• Make sure you get actionable results out of your agile ceremonies.
• Maintain good communication habits.
• Use technologies that fit your communication needs.
• Stick to agreed processes as much as you can.
• Encourage a culture of good communication between distributed teams and locations.