Best Practices for Distributed Agile Development:

Introduction:

Software development in a distributed environment is not new and has been in practice in the IT industry since the 80’s and 90’s when IT offshoring became prevalent. Due to global market competition and realization of economical workforce offshore resulted in enormous cost arbitration to global IT companies.

Traditional approaches to offshore development are based on plan-driven methodologies with big-bang deliveries. In Agile development, this needs to be adjusted to support faster delivery cycles and enable highly collaborative environment for multi-site, multi-vendor development teams.

This article analyses and recommends best practices for globally distributed agile teams based on Brillio’s experience of working with large financial, Products and Technology companies in implementing their business critical projects through distributed teams working from multiple time zones and locations.

Distributed Scrum Teams:

In The 2013 State of Agile Development survey, conducted by VersionOne, 76% of respondents stated that their teams were distributed. This being the state of the industry, distributed agile software development is here to stay.

Distributed scrum teams go through the following stages of evolution:

1. Isolated Scrum TeamsTeams are isolated across geographies. Distributed teams may not be using common processes or tools

2. Distributed Scrum of ScrumsScrum teams are isolated across geographies and are integrated by a scrum of scrum which meets regularly or has conference calls regularly

3. Totally Integrated ScrumsScrum teams are cross-functional with members distributed across geographies and there is common processes and tools usage. Frequently there is rotation of team members across the teams

Challenges in Creating Integrated Scrums:

Following are the challenges our teams implementing distributed development have experienced during their implementation and the resolution techniques they have adopted.

Customer Collaboration and understanding business priorities

When development teams are collocated with the customer, it is easier to participate with the customer in backlog grooming and understand the business priorities. When the teams are distributed understanding the business priorities of the customer and ensuring that the teams pick up the right stories for development and synchronizing the dependencies among multiple teams is a big challenge. In one of our projects for a large financial industry customer we mitigated this challenge through having a technical architect and business analyst at each location to understand the requirements and priorities from customer and represent and translate the same to local teams through discussions. Having this proxy team represent as local Product Owner helped clarifications to teams and enhancing the bandwidth of customer Product owner.

Organization of the teams

While organizing teams and distributing work, it is important to form teams based on functionality and not as component teams. Forming component based teams leads to isolated teams and brings in localization of skills. This builds a dependency bottleneck sometimes.

For example, in a project for developing a health information system for a global medical company, we had segregated the teams based on components/modules. This was leading to delay of releases as all the teams had to wait for one of the teams which worked on the server side business objects to complete their implementation to be even able to make a meaningful release. This created a bottleneck. Later, we reorganized the team to be structured based on functionality and this helped building cross functional skills and alleviating this dependency. If any one of the team was delayed, other teams could

help in completion of the work as skills required were now not localized and multiple teams were having these skills.

Cultural differences

It is very important to understand difference in behavior of team members belonging to different cultures when we are working in a distributed agile environment. Some cultures are inherently adapted to hierarchy and command control environments where people are often discouraged from asking questions or bringing out issues, talking about impossible deadlines or saying “No” when something cannot be done. To effectively be agile, this kind of attitude should be overcome and a culture of openness, and trust needs to be built. This needs a good amount of team building and travel to be planned. We have been able to address this through rotation of team members through various locations and teams. This helps them become ambassadors of teams and helps in developing working relations across geographies and building cohesive teams

Communication across Distributed teams:

In a distributed environment, importance of constant communication and collaboration cannot be underestimated. Sufficient budget need to be invested in building the backbone for communication and usage of wiki, group chats, frequent calls, desktop sharing and application lifecycle management tools like TFS, JIRA, VersionOne should be encouraged.

In one of our engagements, we co-invested with customer in setting up a state-of-the-art Video conferencing environment dedicated in their ODC (Offshore development center). This helped the team in getting a virtual feel of collocation to discusses issues face to face and deliver faster

Knowledge Sharing and collaboration:

In agile development, in the rigor of sprints and work completion, knowledge sharing across teams sometimes suffers. To ensure this does not happen, daily synchronization calls between the teams need to be religiously followed. Daily scrum of scrums should become a constant practice, this helps in working around dependencies and ensuring that the teams are not blocked. A blocker tracker needs to be maintained which daily gets discussed during the scrum of scrum meeting and resolved.

Integration of work done (Continuous Integration)

As multiple teams are working sometimes on the same code base it is imperative that a version control system and continuous integration environment be set up for the teams before the start of development sprints. Continuous integration is not only about setting up an environment for continuous integration but also to cultivate the sense of urgency to resolve issues on build failures. Many times we have seen that teams set up a continuous integration environment but do not really give the necessary focus to fix build issues on priority. This attitude needs to be changed by constant tracking of the cycle time for build issue resolution and reporting it back to the team. Continuous integration is the discipline of ensuring that all the teams are working on a deployable codebase every day. This helps moving towards continuous deployment and devops best practices.

Best Practice Lessons Learned:

Conduct proper due-diligence to understand the overall scope, domain and product Plan for a Sprint-0 (Preparation sprint) before the delivery sprints start. Separate teams by functionality and not on activity or components. This helps

creating self-organizing and self-sustaining teams in case of attrition and other team organization changes

Ensure Development and System testing environment are setup and ready for use before start of delivery sprints

Develop anchor stories and categories to classify High, Medium and Low complexity stories to have a rigorous size estimation practice in the team

Use continuous integration practices to minimize integration issues later in the project lifecycle

Project manager and Scrum master to work with Product owner to crystallize release plans for at least two cycles before the commencement of sprint-1

Plan travel for teams to send ambassadors from each team on rotation across to all geographic locations. This helps in understanding problems/issues first hand at each site and in building trust and collaboration among teams

Use regular builds to get feedback and integrate work among multiple teams if a continuous delivery strategy cannot be worked out

Use test cases to understand the requirements upfront. Bring in a Test driven development culture

Ensure transparency to customer through periodic reporting and monthly governance calls

Strengthen retrospective, continuous learning and innovation

Summary:

Distributed Agile Development is here to stay. Organizations have to develop capabilities in effectively leveraging this model for effective Software delivery. There are challenges in creating integrated scrum teams and the root cause for all these challenges point towards the basic tenets of strengthening the Communication, Knowledge sharing, understanding the culture differences and building cohesive High Performance Teams which are key to success in the continuously evolving technology and software engineering world.