This white paper is designed to share our knowledge as a provider of distributed Agile software solutions and to help companies get started with distributed Agile, a software development methodology (SDLC) that revolutionizes software release. With the traditional “waterfall” methodology a product is released all at once when the product is completed. In contrast, teams using Agile “time box” software releases, deliver the most important features first in short, regular intervals.

Apparatus

A backlog management tool is important for this model of distributed Agile. Stories need to be clearly written, with acceptance criteria that the team understands. As this model is most suited for situations where the entire development team is co-located, test automation and continuous release cycle tools are less critical.

Advantages

• A quick return on investment for short-term, well-documented projects.

• Team co-location reduces the need to work during non-business hours.

• Locating the Scrum Master with the team improves communication and eases the workload as it allows for frequent check-ins.
• Provides an introduction to Agile methods. Low organizational impact as no new roles are required.

Challenges

• Maintaining infrastructure for daily communication between the product owner and the development team can be a challenge. The offshore team must have access to release management and infrastructure so they do not lose work time in situations such as waiting for a server to be restarted.
• Setting expectations with the product owner if the product owner does not have time allotted to work with the team can be a frustrating experience for the team. A product owner who is too busy with other work demands can become a single point of failure, resulting in a disconnected team and a process that reverts to a waterfall methodology.

Best Practices

• Make the product owner feel like a part of the team. We highly recommend flying him or her out to meet the team on a regular basis.
• Establish clear and concise communication between the product owner and the team. The Scrum Master is a technical resource and serves as a liaison between the product owner and the team.
• Develop good stories and clear acceptance criteria. They are essential for the success of this model and must be produced by the product owner. The Scrum Master should work as a coach for the product owner (in developing and splitting stories) and the team (in reviewing and sizing them).
• In order to ensure the success of this model, practice shorter sprints with demonstrations of functionality completed to date.

Follow the Sun

The name “follow the sun” reflects the fact that in this model team members work during daytime hours—whatever those happen to be, based on their particular time zones—and that the model is designed to take advantage of the work time differences of onsite and offshore team members.

Human Connection

The product owner is co-located onsite with the Scrum Master and product development team, while the quality assurance team is located offshore in a different time zone. In this approach, it is common that quality assurance is completed during onsite non-business hours. Taking this model to the next level, team members can be distributed in more than two time zones, for instance in North America, India, and Europe.

Collaboration Approach

This model takes the company and teams into a more mature relationship between the service provider and the client. It is based on a waterfall SDLC that was primarily used early in the offshore development trend and was aimed at cutting costs and decreasing time to market. The model allows the development team to leverage the time difference between locations to increase productivity.   

For this model to succeed, communication between the offshore team and the onsite developers is key: daily stand-ups and other team meetings must be held during the time overlap window. The core task definition must be kept in mind, while development and quality assurance happen in parallel.

Apparatus

At this stage, introducing testing automation tools is essential as teams expand into more globally dispersed offices. An online tool for backlog management and tracking stories becomes critical along with the ability to share information online, such as in a wiki.

Advantages

• Faster delivery than a hand-off or an onsite model, when well executed.
• Potential for lower cost of delivery, with offshore staffing dispersed in areas with a lower cost of living.
• Easier communication as developers, Scrum Master, and product owner are co-located, which facilitates ad-hoc huddles with developers and product owners.

Challenges

• A short, or nonexistent, time overlap window can lead to problems. In the absence of overlap such as there is between the United States and India, team members may have to work late at night or early in the morning, which can make it hard to recruit and retain staff.
• The short overlap window imposes scheduling constraints for daily stand-ups, retrospectives, and other team meetings. Any difficulty in communication can leave teams without critical information and result in the loss of a day’s work.
• Team collaboration and creating a sense of unity can be more difficult to achieve when developers and testers are not co-located.
• The model may limit the type of testing that can be done. Testers may also find it harder to understand the stories and may feel left out of ad-hoc huddles between developers and product owners.
• The testing environment must be accessible to remote team members; this may require duplication in managing and maintaining physical and virtual environments.

Best Practices

• Bring offshore testers onsite to get to know team members and improve communication and team unity.
• Celebrate success with both onshore and offshore team members: for example, team members can go out for a celebratory lunch and share photos of the event. Human Resource managers can work with the Scrum Master to acknowledge hard work and creative solutions.
• Pair developers and testers for check-ins during any overlapping time.
• The Scrum Master may hold two stand-ups, one for each team, to ensure that information is completed by one team and ready for the next to pick up.

Functional

The Functional Model is a step-up in complexity and often incorporates a mix of distributed and onsite Agile teams. Work is distributed between teams according to functionality. This model balances the two underlying drivers of Agile Methodology: the needs of the project (such as profitability) and the needs of the team (such as communication between team members). The offshore team allows a company to expand into new areas quickly and efficiently, reacting rapidly to emerging markets in order to maintain a competitive edge.

Human Connection

This model has the entire Agile team in one location, except for the product owner. An example of this is with a Distributed Agile Support team or a Distributed Agile Innovation team.

Collaboration Approach

This model is best for companies that already have experience working with an offshore team. Service level agreements (SLAs) and communication methods are in place, and the company has experience working with the service provider through distributed methodologies.   

One function we see often is the transitioning of code operational management to the offshore service providers’ team (the Support function). A long-term team will manage changes, updates, and patches to this codebase. With a fixed team budget, the company can control costs through outsourcing. Another option is piloting new technologies. We can utilize a service provider to test new technology, giving a company a competitive advantage. For example, if your software development team lacks experience with mobile development, you can utilize your offshore service provider to create mobile versions of your website (bypassing the need to train internal staff). SLAs should then be put into place with the service provider to update the site to support new devices as they are released. In this example, the Scrum Master may work as a team representative and stay after hours or come in early to ensure the team has everything it needs to function efficiently. At this point, it is important to look deeper into how testing automation is performed. BDD, behavior-driven development revolutionizes the testing processes as the engineering team focuses on customer-driven behaviors and functions first. These processes will require a mind shift that goes hand in hand with the organizational transformations that distributed teams will have naturally occur with Agile adoption.

Apparatus

The transition to behavioral-driven development can require new tools that empower engineers to think about the design before they code. This is a good point in a company’s growth period to evaluate the development and collaboration tools utilized to see what may be available to assist in the success of your Distributed Agile transformation. Incorporate tools that allow engineers to easily document design and development as part of the implementation process.

Advantages

• With the right service provider, new ideas can be quickly piloted and implemented without hiring or training new staff. The service provider can set up client best practices for development and expand and contract teams as needed.

• Freeing up resources from maintaining legacy code can reduce costs, while the service provider can look for creative methods to refactor and optimize this code with rewards built into SLAs.

Challenges

• As with the hand-off model, this can easily revert to a waterfall approach if the product owner is not fully engaged with the offshore team.

• Knowledge transfer sessions can be costly and are often an inefficient way to get a new team ready to change an existing codebase.

Best Practices

• We recommend starting off with small projects with your service provider and establishing distributed Agile meetings to clarify milestones, lengths of sprints, and communication methods. Once you’ve established functioning teams and developed a “well-oiled machine,” you’ll be ready and able to take on new opportunities as they emerge.

• Utilize technologies within a shared (cloud) infrastructure.

• Prepare clear criteria on what functionality is created onshore and offshore.

Onsite Coordination

The functional model we just described is a strong method for building and testing a company’s relationship with a service provider. Once you’re sure that the provider can meet SLAs and cost-saving goals, you can consider a longer-term model to leverage this relationship and increase communication capabilities between onshore and offshore team members. The Onsite Coordination Model is ideal for a company that has reached this level of maturity.

Human Connection

In this model, one or more technical coordinators are located onsite with the product owner and the Scrum Master, while the rest of the team is offshore.

Collaboration Approach

The product owner aligns the team with business priorities and values. The coordinators work closely with the product owner and the team to relay the priorities and clarifications the team may have. It is important that the stories are well written and have clearly defined acceptance criteria. Test-driven development, or TDD, is another core component of this model. It was developed from basic Agile principles, themselves focused on the art of simplicity and self-organizing design. In TDD, a test case is written from the acceptance criteria as soon as the story is picked up to play from the backlog. The first time the team runs the test case it will fail since the code has yet to be written. Still, this process validates the test case clarity and allows the team to review expectations together. Pairing engineers, a concept introduced by extreme programming principles, can significantly reduce knowledge transfer overhead while increasing team motivation. At this point, it makes sense to look at the guiding principles from Agile-based frameworks and begin incorporating them to increase the model’s success. It is very important here to ensure that teams feel safe and encourage open communication. In doing so, mistakes are exposed early on and become lessons promoting innovation and reducing the fear that can be exaggerated by cultural and geographical disparities.

Apparatus

There are many types of tools on the market now that can be incorporated to assist dispersed teams at this stage. Tools can be beneficial for Agile practices such as pair coding and refactoring, release planning, connecting stories to the test codebase and TDD.

Apparatus

• Onsite coordinators work directly with the product manager for a quick resolution on queries from the team.
• Onsite coordinators can help resolve infrastructure and release issues as they arise. n Onsite coordinators can represent the offshore team and convey information in story huddles.

Challenges

• The offshore team may feel left out. It’s up to the HR manager and the Scrum Master to keep offshore team morale high and to celebrate team success.
• The coordinator’s role must be clearly defined so that a hierarchy is not formed that could inadvertently bypass coaching principles.

Best Practices

• Ensure clear communication and set up processes to avoid creating a hierarchy. For example, coordinators can be offshore team members who visit the client site on rotation.
• Maintain a workstation for visiting team members and remember that they will need housing and other resources.

Agile Next Door©

Agile Next Door© is a proprietary concept developed by Nisum Technologies for identifying the best practices from Agile models currently in use (and described above), and for creating a system that takes full advantage of each team member’s geographical distribution, along with more mature Agile processes. Agile Next Door© is recommended for companies that are using an advanced or mature form of distributed Agile, with teams challenging themselves to reduce sprint cycles to two weeks or less. This increases the team’s ability to think up, prioritize, and release features to the customer in a timely manner, and creates a competitive edge for the business. 

The Human Connection

In this model, all teams and team members can be easily accessed, regardless of their locations. Using technology like video streaming, team members can easily collaborate. They get to know each other personally and professionally, through rotation, and they enjoy the multi-cultural aspect of a global team.

Collaboration Approach

The ability to locate team members in multiple time zones is a key element of Agile Next Door©. Engineer pairs can be scattered around the globe while the team’s clear processes blend daytime and nighttime into seamless 24-hour sessions. Rotating between sites and pairs, team members continually learn from each other, becoming more competent for each project as they go.

Apparatus

This model relies the heaviest on technology and connectivity. There are a significant number of products aimed at facilitating distributed team collaboration. A factor for this model’s success is the reliability of these products. It is recommended that the toolset chosen be consistent for all locations. Communication suites (especially those that facilitate screen sharing, VOIP, and instant messaging) allow team members to work together as if they were sitting next to each other and sharing a screen, regardless of their physical location.

Advantages

• The distribution of team members through multiple time zones, as described in the Follow the Sun model, can increase a team’s productivity while potentially decreasing costs.

• A geographically distributed team allows for increased availability and response times.
• Agile Next Door© allows for the global recruitment of talent, enabling a much larger resource pool.
• The cultural diversity of team members can create motivation and innovation within a team, as they integrate diverse ways of thinking.

Challenges

• Expect a longer ramp-up time for new teams, as cultural and language differences require more time for team members to learn to communicate effectively with each other.
• High speed, reliable connectivity to the virtual team space is a requirement.
• Business hours may need to be adjusted in order to increase the overlap window between team members.

Best Practices

• Online dashboards for collecting metrics are a key factor in implementing Agile Next Door©. Neighborhood Metrics, which measure a team’s progress at facilitating continuous improvement, are important components of these data sets.
• Repeatable processes and supporting infrastructures allow teams to form good work habits. The stability and consistency (of doing the same thing in the same place at the same time) allow the team to measure its velocity.
• Moving away from the concepts of “day” and “night,” Agile Next Door© introduces the concept of “Neighborhood Meets and Greets.” These are important work sessions that can happen at any time, as determined by the team. A Neighborhood Greet is time-boxed to 15-minute sessions. The first 15 minutes resemble a daily stand-up: team members greet each other and exchange news. They tell each other what they’ve completed since the last Neighborhood Greet, and what they plan on doing until the next one. Any items that require deeper discussion are paired for further discussion immediately afterward in the next 15-minute block, the Neighborhood Meet. These sessions take advantage of limited overlap time to ensure the entire team, or “neighborhood,” understands what each other team will focus on until the next session. These sessions are key to the success of this model. The neighborhood metaphor has been a successful tool allowing us to move away from the division of an Agile team into clusters of offshore or onsite members. Instead, all are part of one “local” neighborhood and all team members are just next door.
• In this model, team processes and tools maximize automation. Ensure all team members are comfortable with the selected tools. That will reduce the likelihood of corner-cutting during time crunches and will ultimately increase your success.

Distributed Agile Best Practices

Nisum Technologies has helped numerous companies implement the Agile models that best meet their needs. From our experiences, we’ve put together some recommendations for best practices to help you along your own distributed Agile journey. Before you start that journey, you and your teams should discuss a number of important agreements to establish a clear understanding of Agile, set expectations, and educate team members on the process. We recommend that an Agile Coach work with you to put these practices in place, together with the service provider and product owner, so as to best reflect the company’s needs and overall methodology.

Team Size

Most Agile teams are comprised of six to eight team members—they are similar in size to an average family. A team with more than ten members can become hierarchical and can smother the voices of softer-spoken members. A consistent set of team members enables the team to improve incrementally. Adding or removing a team member always changes the team’s overall velocity. Design patterns recommended by the Extreme Programming framework, such as pairing, are best implemented with an even number of team members. Pairing encourages developers to work side-by-side with a counterpart while teaching each other skills; this doubles the team’s size (and respective costs), but also increases productivity and improves morale. In our experience, teams organized around two to four pairs showed the most consistent overall trend in product delivery.

Team Composition

The stability of an Agile team directly contributes to their ability to “be agile.” Relationships based on trust take time to develop. Agile ceremonies, processes, and interpersonal interactions also take time to develop and are essential for building team cohesion. Companies share members across teams all too often—breaking a distributed Agile team in this way can impair its autonomy, reduce team cohesion, disrupt its rhythm and depress its productivity (as measured by its velocity). It is important that the team is composed of members who feel empowered to make decisions and do not need a “manager” to bless the decisions around technology or estimates. When building an Agile team, it is important to differentiate between roles and members. One team member can play more than one role on the team. For example, hiring and/or training team members to design and write both functional code and testing automation removes the bottleneck that occurred from the hand-off between developers and QA that many teams suffer from. This flexibility allows people to focus on what needs to be done, to “gather around the work,” rather than sheltering behind a role. In using the Scrum framework, most prevalent in the industry at the moment, a distributed team’s Scrum Master is the team’s Agile advocate. This role embodies the concepts, motivation, and energy of “being agile.” Team members’ approach to meeting challenges is vitally important. An effective Scrum Master makes sure the team has what it needs and is not delayed by waiting for blockers to be resolved in another time zone. The Scrum Master keeps a record of team decisions and Agile ceremonies and ignites the team to continuously improve. He or she meets cultural and communication difficulties with more timely team check-ins and ensures that all voices have been heard. The Scrum Master does not play a part in Human Resource Management. Both onsite and offshore team members need to have separate human resources managers who communicate regularly with the Scrum Master.

Team Member Rotation

Offshore team members can be regularly rotated to join the onshore team to improve communication and cohesion and build a more motivated and collaborative environment. Rotation also facilitates a natural “leveling off” of knowledge: a team member coming onsite becomes the spokesperson for his or her entire team while visiting, and in doing so gains business and technical knowledge. Team members can be rotated in pairs or as individuals. In either case, those on rotation are given a specific plan and set of goals to meet. They can be encouraged to begin each work session by describing the differences they see at the new site or the expectations they have for the visit. Our experience and survey results show that team members brought on location become more engaged; they communicate more effectively, become more dedicated, and capable of making stronger decisions. The success of Agile depends on having teams that are both self-empowered and enabled to make collective decisions, resolving issues as they come up. Teams like these will be more productive, will produce higher quality products, and will contribute to increased satisfaction with the service provider (see survey results).

IT Infrastructure

Setting your team’s expectations and building the right technical infrastructure is critical to their success. A clear method for communication (determined, tested, configured, and established with your service provider) can cut down on frustration and costs and will increase a team’s productivity and satisfaction. The Agile process recommends “interactions over documentation.” It is to your benefit to put the tools and processes in place for clear communication and collaboration at the beginning of this engagement.

Behavior, Design, and Test-Driven Development

Behavior, design, and test-driven development frameworks were developed to support Agile principles. These methods build quality into the development process; turning it upside down from the way testing is performed in waterfall methodologies by writing the test cases prior to the functional code. These methods are extremely helpful for distributed teams as they increase quality and decrease the time required for knowledge transfer. When selecting a service provider make sure they utilize these methodologies to ensure that code is more easily maintained and supported. The effort put into establishing these processes ahead of time can make a big difference to your company as it grows.

Conclusion

We began this white paper by presenting the hand-off model for Agile, which does not require the onboarding of new resources. For this reason, it can be adopted quickly by a smaller company. A company wishing to adopt this model can also start by utilizing a service provider’s infrastructure and best development practices. This model is especially useful for companies that do not have their own software development department or would like to pilot a new technology they do not have in-house. In contrast, the Agile Next Door© engagement model utilizes a more integrated approach to working with a service provider. Team members periodically visit their counterparts at the client’s location, making this model best for companies that have long-term, ongoing relations with a service provider. We recommend that companies interested in using Agile methodology start with a low-level maturity engagement model (such as the hand-off model) to establish and test a working relationship with a service provider. Once those processes are in place, and relationships and trust have been created, then the company is better positioned to integrate the service provider into its overall corporate strategy for software development.