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.
In 2001, at a summit of seventeen thought leaders of several programming methodologies, a consensus was reached around four main values captured in the Agile Manifesto. These values serve as the vision for the Agile SDLC. The first value states, “Individuals and interactions over processes and tools”. In the earlier years of Agile adoption, there was a common belief that this required teams to reside in physical proximity of each other. This belief hindered many companies from adopting Agile, finding it not feasible with employees distributed in more than one location and time zone. In this paper, we will describe some ways in which Agile methodology has been successfully used to improve the productivity of teams with globally distributed members. In our preliminary research, we reviewed existing literature and conducted an online survey to identify ways in which teams (especially teams that are distributed) have implemented Agile. We asked: Can it be done? What obstacles have teams faced? How have they overcome these obstacles? In compiling the answers we identified some of the challenges and best practices teams use to implement this “distributed Agile” and the most commonly used models.
Evaluating the results of our research, we found that distributing team members could likely bring participating companies significant advantages—benefits that were not foreseen when the original Agile Manifesto was written. These include the ability to recruit talent from a larger resource pool, increased flexibility to meet the needs of a changing market, and improved team productivity by taking advantage of global time differences. In some cases, distributed Agile can provide a growing business with the edge that will allow it to be more versatile than its competitors. When using Agile with a distributed team, it’s crucial to select the model best suited for a company’s size, structure, and type. Companies also need to review their growth plan carefully and consider how to mature their distributed Agile model as their business grows and their needs change. In this white paper, we present a selection of some of the most commonly used models of distributed Agile methodology. Our goal is to give you a better understanding of not only how to begin using it, but also how to create a vision of team development that will improve your business competitiveness.
The most common challenge faced by teams using distributed Agile is finding an efficient way to communicate. We found that this was often due to differences in both time zones and working hours across the globe, as well as cultural and linguistic barriers. Team members also complained that they spent an average of 35% more time dealing with collaboration issues than they did focusing on the projects at hand. Workers also dealt with a lack of infrastructure. Anyone on a dispersed team has at some point experienced the frustration of wasting a good part of a meeting trying to establish a stable connection. The size of the distributed team was another major concern. As teams grow, it becomes more difficult for all voices to be heard. Inclusion is an important component of the consensus-making process, which is imperative to the agile frameworks.
A lack of clarity in measuring innovation and quality was another common challenge. This can reduce managers’ confidence that a distributed team will be able to deliver a quality product while following a timeline that will provide a competitive market edge.
Nisum has developed a set of distributed Agile engagement models to help you develop your teams and improve your outcomes—we’ll review a few of them here. While they do not represent every team engagement structure available to you through Agile, they do provide sketches of some classic structures to show you how distributed Agile takes shape and drives success for a busy organization. The Agile engagement models described here are three-dimensional:
Here we present five Agile engagement models in order of complexity: the most simple to the most complex ways that teams initiate, implement, and manage their work. The model’s degree of complexity is called its “maturity level,” in reference to the way the company has managed its human connection, collaboration approach, and apparatus to implement Agile methodology. At its most mature, Agile is fully automated and takes little or no time to deploy and scale. As we have listed and described the models from simple to complex, the first will be easiest to implement and maybe the best choice for a company that is just starting to utilize offshore resources. It might also be useful for a company that already has an offshore team and is thinking about changing its SDLC, moving from a waterfall approach to an Agile approach. As company teams become more experienced at utilizing and implementing distributed Agile, they can introduce more advanced techniques from the more complex or mature engagement models, such as continuous delivery and resource rotation. Elements from the models can be combined depending on the team’s functional needs and/or the company’s business requirements.
This is a great choice for a company that wants to begin using Agile; it can be a stepping-stone to further engagement and to the more complex models described below.
The product owner is onsite, while the rest of the team is located offshore in one remote office: including the Scrum Master, the developer, and the quality assurance team.
The product owner works closely with product development staff to create stories and relays this information to the offshore team. Because the product owner plays a key role in this model, it is essential that he or she works closely with the team. Without the product owner’s participation in all Agile ceremonies (especially the daily standups), the model can easily revert to a waterfall SDLC. The Scrum Master is responsible for ensuring that the product owner understands the Agile process, and clarifies the team’s expectations regarding story writing and backlog prioritization.
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.
A quick return on investment for short-term, well-documented projects.
Team co-location reduces the need to work during non-business hours.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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).
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 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.
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.