Your Federal Quarterly Tax Payments are due April 15th Get Help Now >>

Agile Project Management - Offshore Agile by dag12237




Agile is an iterative and evolutionary approach to software development implemented through a set of practices
and principles. It focuses primarily on developing software with high collaboration between various individuals
and with customer, “just enough” documentation and frequently delivering working software in order to make the
process more responsive to changes.
Off-shoring software development enables organizations to leverage wealth of skill and talent available at a much
lower rate thereby making them more cost effective.
In an attempt to leverage the benefits of off-shoring as well as Agile, we have practiced the hybrid “Offshore
Agile” model yielding good results. This paper describes the challenges faced and best practices established
during software development using offshore Agile.


Implementing Agile in offshore-onshore development model throws up many challenges. This section describes
significant challenges experienced while implementing offshore Agile.

2.1 Cultural Incompatibility
Cultural incompatibility is one of the biggest stumbling blocks one could face while implementing offshore

2.1.1    Inertia from traditional software development methodologies

Traditionally most of the Indian software companies are extremely process oriented and every single work item is
planned well in advance. Development team, Project Managers and Senior Management track progress vis-à-vis
the plan. Deviations are closely monitored and corrective actions are taken to bring the project back on track as
per the plan. Change Control is also an integral process. Changing requirements are tracked using baselined
requirements as reference.

Agile does not advocate use of such traditional procedures. Project planning far in advance is not advisable.
Changing requirements are always welcome and do not need to go through an elaborate change control process.
Making the development team adapt to a complete shift in processes is a big challenge.

2.1.2    Cross Cultural Issues

Most of the Indian software companies operate at a junior programmer level. In such a model, most of the
architectural/design decisions are taken at a senior level. Developers are mainly responsible for developing code
based on the design/architecture laid out. Issues and questions are generally addressed in a hierarchical fashion.

Agile advocates active participation from the entire development team irrespective of their seniority. Queries and
issues are raised and discussed in an open forum. It is a challenge to break the command-control mindset of the
team and have them actively participate in all discussions without any hesitation.

2.2 Communication
Communication is one of the most fundamental principles of Agile development. Any practice that distracts from
effective communication must be removed from the process. On the contrary, any practice that enhances the
process must be embraced.

2.2.1    Absence of enough face-to-face communication
Agile advocates high collaboration between all members of the development team and customer. This includes
face-to-face communication for effective resolution of issues/queries. In an offshore development model, such
high collaboration may not be feasible because the team is spread across various geographies and time zones.
One of the key offshore Agile challenges is to identify alternatives to achieve the same level of effectiveness.

2.2.2    Incorporating Dynamic Requirements
In conventional development methodologies, baselined requirement is the most important artifact to start
development. Its importance is even more pronounced in an offshore development model due to the associated
communication overheads.
Agile methodology embraces changing requirements as it makes the product more acceptable in the market.
Incorporating dynamic requirements in an Offshore Agile model is a challenge.

2.2.3    Always maintain “working software”
Generally, conventional delivery is based on milestones. Working software is delivered at the end of each
One of the Agile principles is to have working software available at any point of time. Development is iterative.
Typically, iteration is 2-3 weeks long. Synchronizing the team to maintain working software is challenging in an
environment where requirements are dynamic, project size is large and iterations are short.

2.2.4    Managing continuous review, feedback and acceptance process
Iteration covers all phases of software development – Analysis, design, coding and testing. In addition to these,
acceptance/review process of previous iteration is also carried out in parallel. Incorporating review/acceptance
comments along with the tasks identified for the current iteration is a challenge.

2.3 Project Management
Irrespective of the methodology being used (Conventional or Agile); effective project management is the key to
success. Managing Agile projects has its own challenges. Some key Agile project management challenges, which
we experienced, are mentioned below.

2.3.1    Project Visibility and Tracking
In conventional methodology, detailed project plan is the most commonly used tool to track project status.
Detailed tasks are outlined and resource allocations are done in the initial phase of the project.

In Agile, project status is tracked by working software rather than tasks accomplished during a specific time
period using a comprehensive project plan.

The major challenge is that there is not much visibility on the low level tasks to be accomplished in the future.
Tracking becomes difficult because different phases are carried out in parallel.

2.3.2    Planning and estimation
In conventional methodology, estimations are done using well-established techniques like Function Point
Analysis, Use Case Points etc. in the beginning of the project.

In Agile, estimates are built by rolling up the aggregate estimates on a set of features. Rough magnitude of
estimation is done in the beginning of each iteration and refined as the iteration progresses. Since estimates
evolve as the work progresses, project planning is a challenge.

2.3.3    Need of highly self motivated technical people
Typically a project team has a mix of people with varying skill sets and competencies. Project Manager
appropriately utilizes all resources based on their competencies.

Agile advocates on executing projects only with highly self-motivated and technically strong people. It is a
challenge to identify and also retain such highly self-motivated and technically strong people.

2.3.4    Aligning with conventional Quality Assurance processes
Most of the Indian software companies are highly process oriented and follow conventional quality assurance
processes and practices.

Agile philosophy is people oriented and gives less emphasis to well defined processes. It believes in “just
enough” documentation and supports only those processes, which helps in doing the tasks faster and more

The challenge is to align the Agile practices with organization’s well-established quality processes and strike a
fine balance between these two to optimize benefits.


Agile methodology is based on the following key principles:
•   Individuals and interactions OVER processes and tools
•   Working software OVER comprehensive documentation
•   Customer collaboration OVER contract negotiation
•   Responding to change OVER following a plan
It advocates continuously applying and evolving best practices around these principles. This section describes
best practices being followed at CSC India for implementing Offshore Agile. These practices have been evolved
based on the challenges posed by Offshore Agile.

3.1 Communication

3.1.1   Knowledge sharing in offshore-onshore work model
Most of the development work is being done from offshore. Only around 15% of resources at onsite ensure that
all the Business/Technical queries are resolved and are turned around quickly to the offshore team. Onshore
Team is involved in resolving high critical issues. Also, they are involved in deployment, representing team in
any meetings with other onshore teams. They basically act as interface with the BA’s and other customers.
Onshore team coordinates with offshore team by having daily knowledge sharing meetings during night times
with some time overlap. Onshore team is homogeneously rotated every three months for effective knowledge
sharing and onshore exposure to all team members. This also provides an equal opportunity for the development
team to personally interact with the customers. People returning from onshore actively share their experiences
and knowledge gained with the offshore team. This also helps in eliminating cross-cultural divides.

3.1.2 Multiple Communication Channels
Seamless communication is critical for the success of Offshore Agile. Personalized communication might not be
possible at all times. Hence it is important to have alternate communication channels including asynchronous
communication. Following communication channels have proved effective: Conference Calls, Instant
Messengers, Web Meetings, Video Conference, White boarding and asynchronous communication – WIKI.

WIKI is an Intranet based central repository to store artifacts, share common information and host forums for
asynchronous discussions. It is cost effective, works well because they are simple to use, can be worked with any
browser, and are simple to set up.

Fig 1: Asynchronous Communication using WIKI

3.2 Planning & Review

3.2.1 Roadmap
As a starting point, feature analysis of the desired system is carried out. All required features are listed,
prioritized and grouped into high-level “User Stories”. User Stories are high level system needs. Based on their
priority, user stories are grouped into iterations and project roadmap is created. Project roadmap acts as a high
level plan to execute the project. In the road map, complex user stories are planned in the initial iterations and
simpler ones later, to minimize risk and maximize reusability.

Fig 2: Product User Story Roadmap

3.2.2    Iterative development model – Two-week iterations
Iterative development attempts to minimize risk by developing software in short iterations.

Fig 3: Agile Methodology Schema

Iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini-
increment of new functionality: planning, requirements analysis, design, coding and testing. At the beginning of
each iteration, its functional requirements in the form of user stories are elaborated using simulation tools like
While iteration may not add enough functionality to warrant releasing the product, an Agile software project
intends to be capable of releasing new software after every iteration. At the end of iteration, the team reevaluates
project priorities. Optimum results were obtained with short iteration spanning for two weeks.

The basic idea behind iterative development is to develop a software system incrementally, allowing the
developer to take advantage of what was being learned during the development of earlier, incremental,
deliverable versions of the system. Learning comes from both the development and use of the system, wherever
possible. At each iteration, design modifications maybe made and new functional capabilities are added.

3.2.3    Iteration Planning Meetings
At the beginning of each Iteration, delivery team meets to identify and plan delivery and support tasks in order to
successfully deliver the planned user stories. Typically, planning meetings are structured to cover the following:

        •   Review goals accomplished from the previous Iteration.
        •   Review goals planned for the current Iteration and slate goals that the delivery team will address.
        •   Identify new delivery tasks that must be accomplished in order to successfully deliver the current
        •   Identify new support tasks that should be accomplished to successfully deliver future Iterations.
        •   Review practices being used and modify based on the lessons learnt during the iteration.
        •   Query resolution (Business/Technical)

3.2.4    Regular Meetings
Regular synch up meetings are held for the entire team where all queries, issues, status of tasks and plans are
discussed. These meetings help in synchronizing various activity groups.

Weekly status review meetings are held between the development team and customer to review task progress,
query resolution and identify/mitigate risks.

3.2.5    Workload Management
Workload Management is carried out by the team and enabled by the project manager. Self-organizing, self-
disciplined teams need to manage their own workload in order to maintain their accountability. Project manager
monitors their effectiveness and assists them by providing resources required to meet the team's assumptions
made while planning iterations.

One task owner and support team member(s) is identified to accomplish each task planned in the iteration. As the
task progresses, owner provides updates on the respective task. Everyone in the delivery team must either own or
support a task.

3.3 Automated Development Process

3.3.1    Test Driven Development
Test-driven development encourages developers to write unit test cases before writing the code. In conventional
software development, people write code and test the application to validate developed code. In test driven
development, test case acts as a specification to write code. The test case is considered to be the acceptance
criteria. This also helps developers understand the specifications or requirements.

3.3.2    Continuous Integration, Test and Build
Delivery team continuously delivers code into the code repository, integrates code and builds the entire system as
and when a logical end is reached. The value of continuous integration is that it brings up integration issues
immediately, instead of deferring them till the end of the project.
Every time a significant code is delivered into repository, build verification tests (unit tests) as well as functional
tests are executed. When a test fails, the build fails. Responsibility of fixing it lies with the developer who broke
it. In this way configuration management of offshore development becomes almost a non-issue and we always
have a “Working Software”.

Fig 4: Iterative Agile Development Model

3.3.3   Automation – Code Generation, Code Quality Review, Build, Deployment &
Code generation scripts are used to generate code skeletons automatically. This helps in adherence to
architectural standards, minimizing the efforts required in coding and allows time to incorporate changing

To automate the code quality review process, tools like Metrics for code complexity, CheckStyle for style
checks and coding standards, PMD for coding practices, Profiler for code profiling, JDepend for code inter-
dependency analysis, Clover to measure test coverage, are integrated with development and build environment.
These tools generate code quality reports so that code quality can be monitored and achieved.

Fig 5: Code Quality Report using Metrics

Open source tools like Maven, Continuum, and Cruise control are used to facilitate automatic build,
deployment and test cases execution on regular intervals. These tools are integrated with configuration
management tool i.e. Subversion. These tools provide web interface to report latest build status, build history,
reasons for failure and code changes etc.

Fig 6: Build Report using Continuum
Integrating test cases with build scripts ensures automated regression testing after each build.

3.4 Continuous Improvement

3.4.1    Regular Practice Review
At the end of each iteration, delivery team reviews the practices identified for that cycle and evaluates whether or
not the practice was applied effectively/efficiently.

All practices are listed and assigned a practice owner. If the practice is a hindrance or the practice has no positive
impact, delivery team should contact the practice owner to have it removed from the list of practices. If the
delivery team identifies improvements to the practice, the practices list is to be updated accordingly.

3.4.2    Opportunistic Refactoring
Refactoring is the process of changing code for increasing flexibility, understandability and reducing
maintenance costs without affecting external behavior. In scenarios where adding new behavior to a program
might be difficult with the program's given structure, developer refactors code to make it flexible and then adds
new behavior.

3.4.3    Knowledge Management using Tools
Knowledge management refers to ways organizations gather, manage, and use the knowledge that they acquire.
Knowledge management plays a key role in information sharing, planning & continuous improvement in
Offshore Agile implementation.

A central repository is maintained to keep all the documents or artifacts related to the project. All the
stakeholders can refer the repository for any document.

Fig 7: Knowledge Management using Protégé

3.5 Project Management
Project Management artifacts (Status report, task list, task assignment etc.) are generated automatically using
project & knowledge management tool – Protégé.

Fig 8: Project Management using Protégé

3.5.1    Quality Metrics
Agile methodology suggests keeping Time (duration of iteration) and Resources (team size) fixed as far as
possible. If required, Scope (tasks to be accomplished) can be adjusted based on team’s ability to deliver working

software. In such a situation, metrics like Schedule Compliance and Schedule Slippage are insignificant. Metrics
based on Scope and Defects (to monitor product quality) provide better visibility.

Based on past iteration data, Agile Process Capability Baseline & Metrics have been developed, to track and
predict scope/defects for future iterations. Control charts using defects and scope as parameters, have been

   5 0 .0 0
   4 0 .0 0                                                                             D e fe c ts
                                                                                        C L + 2 s ig m a
   3 0 .0 0                                                                             C L + 1 s ig m a
   2 0 .0 0                                                                             C L - 2 s ig m a
   1 0 .0 0                                                                             C L - 1 s ig m a
    0 .0 0                                                                              UCL
  -1 0 .0 0     1        2         3             4           5       6    7
                                           Ite r a tio n s

Fig 9: Defect Control Chart – Reducing Defects per Iteration


                                                                                         Work units
   150.00                                                                                CL+1sigma
   100.00                                                                                CL-1sigma

                    1        2         3             4           5   6     7

Fig 10: Scope Control Chart – Scope Management within Control Limits


Our experience on Offshore Agile has been rewarding so far. The key has been to continuously evaluate the
practices being followed, and be open to customize the process, based on the need. We suggest that following
points be evaluated before making a decision on implementing Offshore Agile:
• Is the team mature enough to follow the practices of Agile world?
“People” are a key asset of Agile software development process.
All members of the team should be professionally matured to understand the underlying philosophy of Agile.
Ownership is the key. People should be capable of proactively suggesting and embracing changes for
Building & retaining a team around such motivated and technically able individuals would have a cost associated
with it.
• Is the budget enough to absorb cost of rotating resources between onshore and offshore?
Smaller projects might not be able to recover the expenses associated with rotating resources through cost
savings on offshore development and might have to figure out different ways of collaborating and

• Is the budget enough to absorb cost of infrastructure?
The cost of infrastructure to support onsite-offshore communication should also be factored in the project cost. In
situations where high reliability and speed of communication infrastructure is a priority the cost of such
infrastructure would be significant.

•    Is the environment prone to continuous change?
Offshore Agile development requires significant shift from conventional methodologies. There may be scenarios
where the requirements are well known in advance and any deviation from these requirements is not required or
desired. In such scenarios, established conventional methodologies may prove to be a better fit rather than going
for a relatively newer Offshore Agile development.

• Is it desired to define and maintain the software documentation in fine details?
In case of projects, which are intended to have long maintenance phase, customers may insist on having detailed
Often in conventional projects documents are updated for every little change in software. It may appear
counterintuitive but on a number of occasions discarding old documents and producing fresh ones may prove
more efficient.
Devoting a lot of time in producing very detailed documentation, which is anyways prone to change and getting
attached to the documentation may offset the advantages provided by Agile development.

4.1 Customer Feedback

“I had the opportunity to review some new user acceptance tests for AR this week. I was absolutely thrilled with
what I saw. The graphical user interface on AR is one of the best I have ever seen. The application looked first
                                                                                 - Product Brand Manager
“It would appear as though we have a shining example of Offshore Agile.”
                                                                                 - Communications Director
“One of the Agile principles has been "Become good at delivery by doing it over and over again” The AR team
has taken that to heart. The team has successfully delivered another Iteration on time!!!”
                                                                                 - Senior Business Analyst





    •   AOSD: Agile Offshore by Vincent Massol

    •   Internationally Agile By Matt Simons

    •   Agile Software Development By Robert C. Martin

    •   Refactoring By Martin Fowler

    •   Agile Project Management By Jim Hingsmith


Somesh Chandra has 8 years of work experience in conventional and Agile project management methodologies.
He is a part of the Financial Services Group primarily with Banking and Healthcare. He has an experience of
implementing end-to-end projects using both conventional and Agile project management techniques. He is
currently working as a Project Manager with CSC India Pvt. Ltd., Offshore Agile Practice and is a PMI certified
Project Management Professional.
Before this, he was working with Tata Consultancy Services (TCS) as a Project Lead.
His interest is in finding new ways and applying innovative techniques at offshore using Agile methodology.

Devesh Gupta is a M. Tech. in Computer Science and has over 13 years of work experience in the Financial
Services domain. He is currently working as General Manager with CSC India Pvt. Ltd. He is responsible for
overall delivery and management of all healthcare projects based out of CSC India. Devesh is also actively
involved in business development and in managing CSC’s financial services clients across the globe. He is a
certified CSQA and Project Management Professional.

Before this, he was working with Tata Consultancy Services (TCS) as Senior Consultant and Group Head for a
custody banking product.

To top