12 Best Practices for Distributed Development Teams Using Agile Methodologies

12 Best Practices for Distributed Development Using Agile and Scrum Methodologies - AIM Consulting -

With today’s technologies and collaboration tools, software development projects are no longer impeded by distance between team members. In the past, businesses sought offshore development solutions strictly for cost savings, as companies with limited IT budgets could build applications for less using resources in locations with a lower cost of living. Today, they are starting to realize the true value of being able to assemble teams of experts anywhere in the world.

Distributed Development, a project delivery model in which work is done across multiple worksites, is rapidly becoming a common approach. Within a distributed development model, team members physically located in different places—buildings, cities, countries, or continents—work collaboratively to complete project deliverables. With the right approach, a distributed development team can avoid or overcome common challenges and become a high performing team that enjoys working together to deliver business value.

However, the distributed development team model can still be challenging if the right people, processes, and tools are not in place. Additionally, distributed development teams will struggle to produce results if they are not operating from the same set of principles or have a shared understanding of project goals.  Based on my experience, the following are best practices for distributed development teams, particularly those utilizing agile and scrum methodologies. Some of the success criteria can also be relevant to teams that work in the same location, but play a bigger role in distributed teams.

1) Adopt a hybrid approach with local and remote team members

When possible, the project manager, architect, and other lead roles should be onsite or local to the client so they can interface directly with key stakeholders. Not only does this reduce the risk of misunderstanding business needs and technical requirements, but it also provides project owners and stakeholders the convenience of local contacts combined with lower cost resources.

2) Designate a leader at each worksite

At any worksite with a team of three or more members, someone should serve as the lead. This person could be a lead developer, project manager, scrum master, or any other team member who demonstrates leadership abilities. The onsite lead will provide the team with direction and support through face-to-face interaction. They will also serve as a single point of contact and represent the needs of the local team so that the entire team doesn’t get pulled into every meeting, email thread, or instant message conversation. In this way, the lead will streamline communication and ensure the team has the support and guidance they need to keep focused and stay on track.

3) Distribute work equally and assign ownership to every individual

Work should be assigned based on skill, capacity, and overall release or sprint goals. Work assignments should not be based on location. Ideally, all team members are able to perform a variety of tasks (analysis, design, development, and test) so that work can be re-distributed if needed to complete all items in the sprint backlog. It is also important to make sure each team member is given ownership of a feature or component of the solution so everyone on the team feels accountable for the success of the project regardless of their location.

4) Adhere to engineering best practices and development standards

The team should have a common understanding and agreement on the best practices and standards they will adopt and follow. This includes development procedures, code standards and styles, patterns, and other best practices that result in an extensible, quality product. These best practices and standards may be at the industry-level or ones that the team defines for themselves. When everyone is operating under the same standards, there is a better chance that code merges and integrations will be successful and have fewer defects.

5) Respect time zone and cultural differences

When team members are spread across time zones, everyone will need to compromise on when daily standups and other team meetings are held. The times should be as consistent as possible. This will allow team members to plan family obligations and other non-work commitments and have a sense of consistency in their schedule.

Additionally, when team members come from different cultural backgrounds, it is important to respect each other’s holidays. Everyone on the team should not have to follow the holiday schedule of the corporate headquarters or primary office team. Schedules and resource availability should take into account the ‘global’ holiday schedule.

6) Use of online tools for agile artifacts

The use of online tools is very important for keeping a distributed team informed and organized. There are many good tools out there for creating and maintaining product backlogs, organizing and planning sprints, managing task boards, monitoring burn-down, and tracking bugs and other work items. The use of common productivity apps (Excel, OneNote) in a shared environment, such as SharePoint, can do the job too.

While not an agile-specific tool, Microsoft OneNote is a great application for sharing information amongst a distributed team. When a OneNote file is posted to a shared location, all team members can access and contribute to it. My teams use OneNote to document development standards, project procedures, best practices, and other helpful information. The project notebook evolves as team members add new content or augment existing content to keep it useful and relevant.

7) Adapt communication methods to remote teams

Real-time communication between distributed team members is critical to getting work done and building relationships. Many online meeting and instant messaging tools have video and voice features that allow distributed team members to hear and see each other. During standups and other team meetings, my team uses web cams and the video capability in our online meeting tool. We also use the voice feature in Skype to talk to each other at various times during the day when we have questions or ideas to share with one another. Email should not be a distributed team’s primary communication channel as intent can be lost and those involved in the discussion cannot ask clarifying questions or confirm their understanding without having to wait for a response. However, email is good for recapping discussions and sharing decisions with all who need to be informed.  Whatever tools you choose, the team should not only have access to them; they should use them frequently throughout the day.

8) Arrange face-to-face interaction

Distributed development teams should plan get-togethers in person 1-2 times per year at minimum. Project kick-off and on-boarding phases are a good time for in-person gatherings, as well as key milestone planning events. The team should also plan non-work related social activities to get to know each other personally. When team members are working, use web cams and the video capability in online communication tools to bring the team together.

9) Cultivate commitment to product and delivery quality

Creating a set of shared goals at both the milestone and iteration level can drive buy-in and commitment from the team. I recommend no more than four goals; any more can cause the team to be overwhelmed and unfocused. I also believe it is important to have a mix of product-related (“what” the team is delivering) and delivery-related (“how” the team delivers) goals. During release and sprint planning events, the team should identify action items aligned to each goal to ensure the goal is met. Everyone on the team should be assigned at least one of those action items to foster equal commitment toward the goals. The scrum master or team lead should then hold regular checkpoints to see where the team is at with the action items and gauge overall progress toward the goals.

10) Allow for proper on-boarding and training

If travel to the corporate headquarters or some other primary facility for training and other ramp-up activities is not feasible for new team members, then a structured on-boarding and training plan will help ensure they are properly set-up and trained. Create an on-boarding plan outlining exactly what training they need to complete, what tools they need, and what resources they need to access. Distributed teams should also institute on-going coaching and mentoring between senior resources and the junior or mid-level resources. This ensures the less experienced team members are getting the support and guidance they need, and development standards and best practices are consistently adopted across the team.

11) Frequent demos and retrospectives

Distributed team members should share progress and showcase their work on a regular basis to build trust and confidence with their stakeholders and others within the distributed team. For example, they can build working prototypes to supplement design plans, conduct frequent code reviews with peers and other subject matter experts, and facilitate live demos during the sprint review. Distributed development teams should also carve out time after each sprint or some other consistent cadence to review communication practices, tool usage, and other project protocol. It is important that all teams do this, but even more so for distributed teams.

12) Put it in writing

Project documents and written forms of communication are necessary for distributed teams to effectively communicate with other team members and stakeholders. Simply designed docs, brief meeting notes, and other forms of documentation help ensure intent is understood, decisions are clear and not forgotten, and information is shared and accessible to all team members. Establishing good documentation practices in a distributed team helps to prevent delays and missteps during the implementation, fostering alignment around what the team is doing.

The list of success factors for distributed teams runs longer than what has been covered here. By having the right processes and tools, mutually agreed upon standards and practices, and commitment from all team members to follow them, distributed teams can be just as cohesive and collaborative as teams that work under the same roof. Personally, I find working in a distributed software development team model even more rewarding due to the additional challenges that come with being in different geographical locations. When a distributed team is able to achieve their goals and delivery business value on a regular basis, it reinforces best practices and keys to success.