Integrating Agile Practices With a Global Delivery Model

At the same time, global delivery with offshoring has become a very cost effective approach for many companies to develop software. Enterprises today seek to derive the dual benefit of cost effectiveness of offshoring and high responsiveness of Agile practices at the same time. This requires the offshore services companies to revisit their development approach and integrate some of the Agile approaches to be competitive.

However, while Agile practices deliver significant advantages when applied in the right context, they also add significant risks and challenges when the practices are applied in the wrong context. According to a Gartner's research[1], applying Agile to unsuitable projects has been one of the key reasons for Agile project failures!

So, the key question is, will Agile work in a global delivery model? In this article we share our experience in implementing Agile in a global delivery context for a wide range of engagements.

If the question is "can Agile be applied in an offshore model", the answer is a definite YES! Agile is a concept bound by set of values and principles (Agile Manifesto). Provided you have a suitable environment, Agile practices can be applied irrespective of the location constraints. Offshore is no exception to this.

Integration of best practices requires a business-driven approach including multiple stakeholders.

We adopted a three step approach:

1. Identifying Agile practices that are aligned to business priorities.

2. Analyzing the business context of our organization.

3. Identifying challenges based on the business context and customizing Agile practices to address those challenges.

 

Identifying Agile practices that are aligned to business priorities

Identifying the engineering and business challenges and building a common agreement among the key stakeholders will assist in prioritizing which Agile practices would result in the highest benefits to the organization. For example, if there are challenges around product integration and quality, daily build and automated testing practices will result in better benefits compared to practices around requirements management.

Once the business priorities are defined, choose the Agile practices that are aligned to the priorities. Select few key practices to rollout in phases.

Analyzing business context of our organization

Most of the Agile methodologies like Scrum, XP etc. were born in a context of co-located teams with high degree of business availability, predominantly comprising of internal teams (not contractors), highly experienced and competent domain experts. In direct contrast, the context for a global delivery model has distributed teams with limited business availability and predominantly comprising of contractors.

We analyzed the context differences and derived a best-of-breed methodology instead of adopting an existing methodology or practices as-is. Let's look at each of the context differences and the probable solution for overcoming those. A base framework was defined based on the possible solutions taking corresponding assumptions into consideration.

Distributed vs. co-located teams

The team distribution can have a significant influence on the methodology used for the development. Not having co-located development and business teams is a challenge for any development methodology, but it is crucial for Agile since Agile practices focus more on people than process.

Distributed teams have a direct impact on the communication and collaboration. Practices like daily stand-up, release planning, iteration planning need special adaptation when used in the global delivery context. For example, for daily stand-ups, the teams can have a single stand-up over teleconference at a time that is convenient for all. If there are larger teams distributed, the scope can be logically split for the teams to work independently and a representative from each location can have a daily sync-up (scrum of scrums).

Limited business availability vs. high business availability

Availability of business stakeholders or the product owner as part of the engineering team is one other key assumption in Agile. In an offshore context, this is not possible even if the business is ready to be available 100% primarily due to the time zone differences. Also it becomes difficult for enterprises to dedicate 100% of Business time for a single project. This would mean requirement elaboration cannot be done as and when required and requirement clarifications would require some lead time.

One possible solution is to have a dedicated Business Analyst (BA) located at the client's site playing the role of a client-proxy. The BA will be in regular sync up with the business and act as the client for the development team. This person can also work in a different shift to have more time overlap with the development teams.

Also the requirement elaboration for a particular sprint can be done ahead of the sprint by the BA with inputs from Business. The more clarity of the requirement before the sprint begins, the more effective and productive the team can be.

Since the BA might need some lead time to clarify and confirm certain issues with the business, task allocation are done in such a way that each team member has at least 2-3 features to work on. While they wait on one, they can work on others.

Client and contracts-driven vs. associates and trust-driven[2]

Most of the offshore based projects are contract driven since it is usually executed with external vendors. This results in having equal emphasis on contract negotiation as much as customer collaboration. When contracts are signed for fixed-price fixed-scope development, some of the benefits of Agile cannot be reaped. Agile is most effective when the project run with a fixed price and a variable scope. Also since there could be a low level of trust by the clients of vendors, flexible planning may not be possible.

Probable solution for fixed-scope, fixed-price projects is to do traditional planning and execute the project using Agile practices and validate against the original plan. Actions can be taken for any deviations. Scope creep can be negotiated with the client to see if any scope of equal size can be removed from the original scope.

Skills pyramid-based team vs. all-experienced, competent team members

Offshore teams are usually structured based on teams comprising of varied range of experience and skills with a defined hierarchy. This has an impact on the assumption that team members can work independently and be responsible for their deliverable. The teams cannot anticipate and work due to their level of experience. The teams are usually structured in a hierarchical fashion with 3 - 6 developers reporting to a lead. Every feature is owned by one or a few developers along with the lead. Typically, the leads spend most of their time guiding the developers and sometimes work on the critical features. So, in order to minimize the time spent with developers, the leads will have to ensure the requirements and design are detailed enough for the developers to work as independently as possible. The requirements will have to be very specific and detailed. Also the overhead of reviews cannot be exempted in an offshore scenario.

Probable solution is as mentioned earlier is to have the requirements elaborated in detail ahead of the sprint so that the team is very clear about the scope of work in a sprint. Also the architecture and high-level design with common components need to be developed upfront at the beginning of the project to eliminate ambiguities. Planning should take into consideration the overhead of reviews, independent testing etc. Also detailed progressive documentation of work to be done is necessary to provide the right guidance to the team.

Domain generalists vs. deep domain experts

Typically the offshore development teams are domain generalists who learn just enough domain information required for the project. This would prevent them from working based on anticipation. The client will have to do the due diligence and provide enough information upfront on the overall requirement. Also the requirements will have to be very specific and detailed with assumptions stated explicitly.

Probable solution is same as overcoming the earlier stated challenges like detailed requirements elaboration ahead of the sprint and progressive documentation for the work being done.

The above list is an indicative list of areas. Based on specific organization there may be other context concerns and differences that need to be addressed for successful adoption of Agile practices.

Define an Agile suitability assessment approach

The best of breed Agile approach defined after identifying and analyzing the context differences and arriving at a solution for each of the challenges posed will be a more suitable approach for a given environment than applying a methodology available as-is.

Once a base Agile approach for the organization is developed, it is important to define a way to assess suitability of project context for Agile adoption. The suitability assessment approach is primarily required for assessing if a project satisfies the prerequisite assumptions made for the base Agile approach. The suitability assessment can be done for each of the business context dimensions identified. For example, level of business stakeholder availability, level of distribution of the team etc. A risk/benefit based ranking of each of the dimensions will help decide whether Agile practices would results in benefits or additional risks.

Develop an Agile implementation strategy

Defining a structured Agile implementation approach plays a significant role in Agile success as much as identifying and defining the right Agile practices. We believe that Agile adoption success depends 60% having the right mindset and 40% on actual technicalities of Agile practices. For successful adoption, the organization must embrace an Agile mindset. For example, think of the vendor as a partner not a downstream contractor. It takes both parties to have a mature approach for Agile benefits to be realized.

Since Agile success depends on certain ground conditions and also requires the right mindset in people, a structured approach to Agile adoption along with suitability assessment is required to ensure success!

We follow a structured approach to Agile development in projects using our "Conceive - Transform - Optimize" model. The following chart depicts our six-step methodology for Agile development, including how Agile Suitability Assessment fits into the approach:

We help our clients Conceive the best use of Agile concepts by:

1. Leadership Alignment- Our approach embodies fundamentally different software development methods and also requires the right mindset. Agile means may things to many people, and requires standardization across all stakeholders. Executive understating of Agile concepts is the key for successful organization-wide adoption of Agile practices. This workshop helps in building a common understanding of Agile development among the management team

2. Suitability Assessment - The Agile Suitability Assessment framework is a systematic approach to understanding the "ground" conditions of a project, and to decide whether Agile development is the right approach to use. The tool assesses the risk associated with specific problems on the ground, and identifies ways to tailor Agile processes to address them. But, if the ground conditions are unfavorable, the use of Agile practices can harm both the players and the chances for a successful project. You cannot play ice hockey with bumpy ice!

 

We help the teams Transform their development processes into Agile ones by:

3. Team training- To successfully adopt Agile practices in an engagement, all key stakeholders (users, developers and business sponsors) must have a sound understanding of Agile practices and principles. The Agile Workshop provides an in-depth understanding of Agile practices and principals to build common ground within an engagement team.

4. Process Tailoring - This is one of the most important steps. The base framework is tailored to the project needs based on the team's inputs and the risks identified by the suitability assessment. The team commits to the agreed process approach and agrees to refine it based on retrospective findings.

 

During project execution, we Optimize the Agile approach by:

5. Continuous Coaching- Providing continuous coaching, since practicing Agile techniques requires a major change in team member mindset. During the initial iterations of a new Agile project, teams typically face many challenges adjusting to the new way of working. The support of a hands-on coach is vital to smooth transition to an Agile approach, especially in a distributed team environment. We provide hands-on support and guidance for teams to quickly overcome hurdles and grow competence in Agile practices.

6. Implementation Review - A timely review of how the methodology and practices are helping the project is vital for the success of Agile adoption. We continuously evaluate and refine the approach based on project performance and feedback from the team and client.

 

Conclusion

While Agile practices deliver significant advantages in the right context, they also contribute to project failure when the practices are applied in the wrong context. Successful adoption of Agile practices depends on many factors. Large numbers of these factors are related to the ‘mind set' than specific process. We believe Agile adoption success depends 60% having the right supporting mindset and 40% on actual technicalities of Agile practices. Agile is a not a panacea for all challenges related to modern software delivery.

An organization which is looking to adopt Agile practices in a global delivery model must seriously consider a structured approach to define the Agile framework and adoption along with suitability assessment, which will assist in understanding risks and benefits of adopting Agile practices.

About the Authors

Madu Ratnayake heads Software Engineering Process Quality for Virtusa worldwide, and Virtusa's Advance Technology Center in Colombo, Sri Lanka. Madu has over 14 years of experience in global IT service delivery, quality processes and operations management. He has been a member of Virtusa's management team from its inception.

Madu holds a Bachelors Degree in Software Engineering from City University, London, and a Masters in Business Administration from the Post Graduate Institute of Management in Sri Lanka. While at City University he received the Addison-Wesley Prize in Computer Science in 1996, the Scott Prize in 1993 and the 1992 Robert Kitchin Award for performance. He is also a gold medalist in Management Research from the Post Graduate Institute of Management, Sri Lanka.

Valarmathy Rangasamy is the Lead Agile Champion for Virtusa, and leads the Virtusa Agile practice globally. She has over 11 years experience in the software development industry as a software engineer, analyst and project manager with a broad range of assignments for leading global clients.

Valar has a passion for Agile practices, and her interest lies in consulting for global engagement teams in leveraging Agile practices to improve quality, productivity and collaboration in distributed development settings. She holds a Bachelors Degree in Engineering from Madras University, India. She is a Certified Scrum Master and a Certified Project Management Professional (PMP).

[1] Agile Success Factors, Gartner Research, May 2007

[2] When associates/employees build the software, the level of trust business has of them them is very high when compared to the same of contractors.