Roles and Responsibilities in Onsite Off-shore Agile Scrum

Roles and Responsibilities in Onsite Off-shore Agile Scrum Teams

(Joseph Vargheese PMP CISA CSM,

(Currently looking for consulting opportunities within USA.  Please contact

  • Role and responsibilities of offshore and on-site scrum teams are different.
  • Difference is mainly due to time difference and cultural issues.
  • Because of these differences sprint process requires several additional process steps to make off-shore scrum working
  • Proxy Product owner is almost a must for off-shore scrum team success
  • Product owner talents very limited in availability in many of off-shore countries
  • Strong, independent, self-organizing scrum teams will not be reality in the near future (there could be one-off)
  • To some degree, culture differences make it hard in creating self-organizing teams. But help is on the way.

1.     Introduction

Distributed agile teams are always a challenge to work together. Even more so when it comes to 10-12 hours of time difference to off-shore location like India and China. Absence of a product owner in an off-shore location makes very hard for an off-shore team to perform. But it is a reality that, these teams will have to be located different parts of the world due to cost reasons. The successful formula has to take different approach.

2.    Scrum work flow

  • Release planning (onsite)
  • Sprint backlog (combined)
  • Sprint Planning (onsite)
  • Sprint Planning (off-shore)
  • Combined sprint planning (Off-shore and onsite)
  • Daily Stand-up off-shore
  • Daily Stand-up Onsite and off-shore together
  • Sprint Retrospect (Combined)
  • Burn down chart (Combined and/or separated)

3.    What is different and why

Traditional off-shore work culture is very much adapted to water fall process, which includes well documented requirements and very well defined deliverables and contractual obligations controlling delivery components.

Agile comes with exact opposite of these requirements which makes it very hard for the team to operate. Some of the challenges will be as follows

3.1 Undocumented requirements

It will be difficult to conceptualize the business problem on a faraway off-shore location without strong domain knowledge. The presence of strong product owner with lots of domain knowledge can help to bridge the gap.


3.2 Work Culture

Generally off-shore has strong committed work culture.  Most off-shore location like India and china has very young work force with 1-5 years of experience. This young and dynamic workforce can contribute very well if fewer variants are placed on them.  Strong leadership is a necessity in that case.


3.3 Interaction Requirement

Off-shore teams are built mostly not to have many interactions because of time zone difference. Agile enforces that interaction.   This demands requirements of after-hours telephone connectivity as well as equipment to carry-out the work.


3.4 Process Structure

Off-shore teams are very familiar with strong process culture. Agile in essence is very lean on processes. Process ensures the quality even in the absence of strong leadership. Therefore off-shore agile teams require some amount of process.


3.5 Metrics

Off-shore teams are very familiar with performance metrics.  Defining and distributing those metrics can set goals for productivity, performance and thus overall improvement in sprint process.

4.    Off-shore Team structure, Roles and Responsibilities

4.1 Off-shore team structure

Dual-shore Teams Structure:

Dual shore team functions as one team at multiple locations with one scrum master and meetings with all of the members from different parts of the world.

Shared-Shore Teams Structure:

Shared-Shore team will have one scrum master; teams mostly function as multiple teams where daily standup area attended only by core members of team from multiple locations.

4.2 Roles and Responsibilities

Onsite agile catalyst:

This role is very similar to off-shore coordinator role in waterfall except responsibilities are different.  Agile catalyst is a member of off-shore team located onsite. His main responsibility is communication between teams and attending all team meetings from off-shore as well as onsite.  This resource will not have direct sprint task rather works reviewer of deliverables.

Off-shore proxy Product Owner:

This position is very confusing to several of agile teams.  But this is an important position for agile scrum success. This resource works very closely with actual product owner to understand product owner vision and then direct the off-shore team based on the vision.  One of the important point to note here is that this resource will not have any decision making capacity.  Ownership of every decision goes back to actual product owner only.

Off-shore sprint team:

Off-shore sprint team layout is very similar to onsite.

5.    Hand-off between onsite and off-shore teams

Hand-off is an important part of success of teams from multiple locations. Story acceptance to offshore sprint team to be clearly discussed on requirement standpoint as well as on assumptions made. Sprint planning is good place to clear those doubts.  As like in any environment, expectation management is an important part of the hand-off both ways. Daily stand-up is good place to reiterate the decision taken and most importantly assumptions not validated. Impediments and their impact have to be clearly discussed. Expectations on every deliverables have to be discussed.

6.    Cultural difference

Every country has cultural difference of its own.  Education, induction to work force, work culture is very different in many countries.  India and china are prime example of hierarchical work culture to some degree closes opportunity to voice bigger concerns, sometime even opinions.   Scrum requires open and honest opinions and discussions to take advantages of self-organizing team.  To some degree lot of times off-shore sprint teams have to put to test to question solutions and ideas floated by others.

7.     Strong Independent Agile teams, Myth or Reality

Rapid advance in collaboration tools and gaining acquaintance of work culture in different countries will make independent agile teams possible in few years.

8.   Conclusion

This discussion is to communicate that, scrum teams on an off-shore location is still a challenge, but can be done.  It takes lot of effort to make it work.  If not managed properly time in managing an off-shore team will eat into sprint tasks with in onsite team members.  Often some of best talents in the team will be pulled to solve problems from off-shore which also can create a team moral issue and of course productivity.


Performance Metrics for Agile SCRUM Process

Performance Metrics for Agile SCRUM Process

Joseph Vargheese PMP CSM CSP, 

(Currently looking for consulting opportunities within USA.  Please contact

  • The metrics below focus on 5 different areas, Productivity, Quality, Effectiveness of SCRUM, Earned Value and Predictability of the SCRUM.
  • Metrics listed below will help track overall health of agile scrum process on enterprise level.
  • Normal Agile metrics are limited to commitments with in sprint like sprint burn down and stories dropped. Customer satisfaction is an important metrics.
  • Employee satisfaction indexes will help to realize true values of agile process and then work as an enabler for creating high performance sprint teams.
  • Though SCRUM ensure quality and releasable product after every sprint, quality will still be a  concern due to the nature of changes allowed with in a sprint and hence those metrics are very important.


1.     Introduction

A process is an enabler for software development. Process improvement requires quantitative measurements. Following information covers some of measurement techniques effective in agile Scrum process. These metrics can be further subdivided to get more accurate measurements

All of the below information are related to Agile SCRUM process only.

2.     Measurements in any process

  • Productivity
  • Quality
  • Effectiveness of process
  • Earned Value
  • Predictability of the process

3.     Units of Measurements

  • KPI is a metric with strategic objective of performance and should have at least one time bound value
  • Metrics is any measure of a component
  • SLA is a contract on meeting certain KPI between two parties.
  • Metrics will lead to define KPI, and then further lead to define SLA


4.     Productivity

4.1   SCRUM Team Productivity (KPI) respective to peer teams

SCRUM Productivity is relative measurement between teams.  One of the easy measures is number of hours taken  between teams on Small/Medium/Large story types.  Story Points will be better to remove confusion of hours.

Example based on average hours by each story type over 1 year time

Story T-shirt Size # of Stories Analyzed Average Hours/story of 4 Teams Sprint Team 1(hours) Sprint Team 2(hours) Sprint Team 3(hours) Sprint Team 4 (Hours)





















Extra Large







Example based on average Story Points by Sprint team per year

Average Story Points/team/sprint Sprint Team 1(SP) Sprint Team 2(SP) Sprint Team 3(SP) Sprint Team 4 (SP)
Story Points 70 90 65 98 55


4.2 Test case automation velocity within a Sprint (KPI)

It is often referred as number of test cases automated with in a Sprint/per day/per tester

4.3 Test case execution velocity within a Sprint (KPI)

It is often referred as number of test cases executed with in a Sprint/per day/per tester

5.    Quality

5.1  Pre-Release Bugs (KPI)

This is a measure of defects introduced by Sprint development measured by the amount of hours spend to correct the issues tracked by team.

Examples based on Rework hours introduced by each team

Sprint Team 1(hours) Sprint Team 2(hours) Sprint Team 3(hours) Sprint Team 4 (Hours)
Release 1.0 104 140 55 77
Release 1.1 140 154 77 86
Release 1.2 76 175 45 95

5.2 Post-Release Bugs (KPI)

The defects slipped into production from sprint measured by sprint team introduced the defects and hours spend on fixing the defects.

Examples based on Rework hours introduced by each team

Sprint Team 1(hours) Sprint Team 2(hours) Sprint Team 3(hours) Sprint Team 4 (Hours)
Release 1.0 14 23 19 14
Release 2.0 0 14 23 0
Release 3.0 0 19 0 23

5.3  Number of issues found during code review process with in a sprint (KPI)

5.4  Number of defects found with in a story with in a sprint (KPI)

This metrics is an indicator of the clarity of requirement or quality of resources.  Both reasons could result in unexpected defects within a story. Appropriate remediation can be implemented based on metrics


6     Effectiveness of SCRUM

6.1 Capacity available (KPI)

Sum of original capacity available in a Sprint based resource availability and sprint duration

6.2 Velocity (KPI)

Sum of original estimates of all accepted work

6.3 Estimate Expansion (KPI)

Sum of work found during sprint work

6.4 Amount of work dropped out of Sprint (KPI)

6.5 Accuracy of Story Estimation (KPI)

6.6 Capacity utilization (KPI)

This is a very loosely used term with Sprint process.  This forces the team member to report all of the time he worked in a specific project. There is no specific rule of thumb here.  It is very easy to get 85% of time reported in any reporting system.


7    Earned Value

Earned value is an important part of waterfall process.  Earned value is a direct measurement in Waterfall process based on hours worked to date and the features completed.

7.1 Number of features released (KPI)

7.2 Number of Story Points released (KPI)

7.3 Cost incurred per release (KPI)

7.4 Number of Story Points remaining for a release (KPI)

7.5 Money required to complete a release (KPI)

7.6 Number of story points accepted by Product Owner (KPI)



8    Predictability of the SCRUM

8.1 Sprint burned down chart (KPI)

Sprint burn down chart will help to predict health of the sprint as well as the possibility completion of stories committed with in sprint.

8.2 Accuracy of Story Estimation (KPI)

Story estimation expansion is a common problem during the sprint.

8.3 Amount of work dropped out of Sprint (KPI)

8.4 Hours lost because of Impediments with in Sprint (KPI)

8.5 Number of queries originated due to unclear requirements (KPI)

8.6 Estimation expansion due to changing requirements with in sprint (KPI)


9    Customer Satisfaction (KPI)

It is measured using the input from the customer. Usually a set of questions will be answered by the user about both qualitative and quantitative satisfaction of the customer.


10  Employee Satisfaction (KPI)

Similarly for employee satisfaction is measured directly from employee user anonymous surveys, peer reviews or one-on-one sessions.  It is important to understand the employee satisfaction.  It often is a sizeable factor in creating high performance SCRUM team.

11  Conclusion

Above defined KPIs are only few high level KPIs.  These KPIs can be further subdivided into more granular level ones, to make to 1000 KPIs

Author: Joseph Vargheese

Practical Approach in Creating Agile Test Cases

  • Test case discovery happens throughout the sprint process.
  • Exploratory testing will uncover the hidden cases and expand to better coverage.
  • Overall, finding test cases in agile is a challenging process.
  • Definition of “done” of a story/feature is not clearly quantifiable.
  • Start with happy path and take following step by step approach to expand coverage.
  • Full step by step test case documentation is overkill, rather use summary test cases.
  • Most part, acceptance criteria defines the “done” for a Sprint story.


Identifying test cases in Agile is a somewhat difficult task.  In traditional waterfall or RUP, there will always be galore of documents to deduce this information from and in most cases every test case can be traced from some kinds of documented business/ system/ technical/ functional requirements.  Agile by its nature is very lean in documentation. This will create an issue in defining completion point for a feature distributed across several stories. This article defines the process of finding most test cases documented and undocumented with in a feature/story.

Step 1: Input points for test case scenarios

Traditional Agile scrum has following input points where test case scenarios can be uncovered. Every input provides different information. The list below is not conclusive.

  • Story documentation: Generally very slim.  Intention is to start conversation and get confirmation on requirements and definition of “done”.
  • Acceptance criteria for story: Talks about final intent of the story and definition of what makes story “done”.
  • Use cases /Requirement docs (if any)/UI specification (if any): Most cases use cases can be converted to test cases. Well written requirement will be very rare in agile stories.  If it exists, mapping every requirement to test case is an easy task.
  • Sprint planning discussion: Discuss almost all flows including happy path, alternate flows and exceptions flows. Discussion also includes boundary conditions, business rules, existing functionality changes etc.
  • Sprint standup: Discuss daily issues.  Always listen to change in flows as well as corner conditions.
  • Discussion with Developer/Product Owner: Works as a confirmation on numerous information received.
  • Sprint retrospect: Why test coverage is not enough for stories? Test case modification happens after the fact.
  • Exploratory testing: Testing through system without a specific test case.  This is the most effective method to find missing test case. This is method has been very successful with several agile teams.

 Step 2: Collecting Data

  • Tester is involved in all steps of sprint process. Following information should be sourced during all meetings in step 1.
  • Change in any existing functionality: This will results in modification/adding of existing test cases.
  • Happy path:  Tester will hear this several times during the process. Similarly alternate path/flow is also important.  Identify the number of alternate flows and make sure all flows are working.
  • Path of failures: Popularly called exception flow, flow terminated due to errors
  • Guard conditions: Example, login time out
  • Boundary Conditions: Also called as corner conditions. This will make sure that application will work for intended range of input data.
  • Business Rules: Group the business rules and test for one group at a time
  • Event based notifications: Any trigger point for any of the available functionality
  • Non-Functional requirements: Like performance or load of the system
  • Data mapping documents: Test cases can directly be derived from data mapping document.
  • Assumptions
  • Constraints
  • External Dependency: Is this dependent of any external interface for data pull or data push.

Even though all of these conditions (if exits) will result in test cases, every story will not have all of the above scenarios

Step 3:  Organizing the test cases

Since agile input points are many, it is possible that test cases closely related to each other will duplicate across locations.  Always organize test cases by functionality if possible.

Step 4:  Examining coverage

Most testers like to have 100% test coverage. Exploratory testing is the most viable solution to reach 100% test coverage. Since traditional RTM is missing in agile, acceptance criteria will also determine the coverage of test cases required.  Creating an “Acceptance Traceability Matrix” will help to cross check the coverage.

Step 5: Review

After completing test cases, always make sure to be reviewed by product owner or scrum master/developer.  Any coverage miss derived during the review process will be added/updated to test cases.

Step 6: Continuous integration from defects and enhancements

Product defects as well as enhancements will add/modify test cases. Defects generally indicates overlook of test coverage during the sprint testing.

More details contact author: Joseph Vargheese PMP CISA CSM,,

Building an Onsite Off-shore Agile SCRUM Team

Building an Onsite Off-shore Agile SCRUM Team
 (Joseph Vargheese,
  • This article assumes basic knowledge of agile scrum
  • Agile scrum off-shore delivery model is much different than onsite agile model
  • Off-shore teams are also different than onsite team,  role of  product owner in off-shore agile is very different than onsite team
  • Right Off-shore team layout  is an important component for capacity utilization of team and productivity
  • Agile is very lean in processes. But off-shore agile team requires matured processes for predictable delivery
  • Because  of the absence of strong communication and interaction,  in sprint architecture/design  and in sprint test automation have to be scheduled outside the sprint
  • Agile off-shore delivery model requires a dynamic organization culture including alternate  carrier path for technology lovers and lean processes which are uncommon in many off-shore companies
  • Small vendors are more successful in agile off-shore delivery because of dynamic organization culture
  • Strong governance models are a must in agile to set expectation and delivery

1. Introduction

It is difficult to engage agile team from offshore location. Many organizations have tried different models.  This article discusses the steps to create a model close to agile utilizing Agile Scrum process. Agile XP approach is not covered in this article, although these models are very similar. This article also requires basic knowledge of agile process and scrum.

Following intervals on the bottom of the picture are sprint intervals. Below picture shows different milestones. Further process steps are explained below.

2. Planning for an offshore sprint team

There should be some change in the thinking process to get the offshore agile model working. Agile in principle demands close collaboration as well as co-location. If we consider these requirements, off-shore development is not a candidate for agile development process. But all these requirements are possible in some shape and form. Model could be closer to the actual definition of agile to take advantage of the lower cost of development and trained off-shore staff.

Prepping client’s onsite staff with process change is an important part of initial discussion. Since offshore agile scrum process is not same as onsite scrum process, it is important to get training programs organized with experts in this area. Normally vendors will have experts in this area, who can help on educating offshore management on changing expectation from offshore teams, as well as on vendor’s successful agile offshore models. This is very important to avoid some of the surprise during initial phases of sprints. Some of the discussion points will be as follows

  • Work intake process and delivery process.
  • Path of escalating issues
  • Current process structure
  • Offshore delivery model
  • Hierarchical culture in several offshore location and expressing the difference of opinion
  • General resource challenges

3. Offshore and Onsite Collaboration Mechanisms

    1. Video conferencing engines
    2. Instant messenger
    3. Shared WIKI space
    4. Shared Drive Space
    5. Shared artifacts repository (like SVN)

4. Why clients like Agile and vendors don’t

Vendors providing software off-shore services always want to have firm delivery and generally don’t like change. They are more comfortable in traditional waterfall which gives the predictability and stability to deliverables.

5. Overall sprint team roles for offshore

Overall offshore sprint team should include five distinct roles within sprint

  • Onsite Scrum Master
  • Onsite Product Owner
  • Offshore agile catalyst(located onsite and facilitates offshore communication and delivery oversight)
  • Offshore sprint team
  • Offshore proxy Product Owner (Business analyst with strong domain knowledge)

6. Offshore Sprint Team Size

Most efficient offshore agile team in my experience is 5 Resources (3 Developer + 2 QA). Next logical choice will be 7 resources (4 Developer and 3 QA) and further logical choice will be 10 resources (6 Developer and 4 QA). This mix is more dependent of the complexity of application. As complexity increases number of QA should also increase and vice versa.

7. Off-shore sprint process

Off-shore sprint process is not exactly same as onsite sprint process.  Variations are required to suit time difference and often a 24 hours turnaround time.  Let us discuss the individual components in variation

Sprint planning:

Due to time difference, off-shore and onsite sprint planning will be done during two different time zones, though combined sprint planning process is always recommended.  In case of two separate sessions, it is preferable to have off-shore sprint planning process after onsite sprint planning process.  Onsite planning should discuss any impediments team see on implementing these stories, which could be technical, functional or infrastructure.   Off-shore sprint team should discuss and document  any onsite support required for these stories and on importance on timeliness of help.

Off-shore daily scrum:

Apart usual scrum, it is scrum master’s(SM) responsibility to track timely delivery of onsite support (technical, functional or infrastructure) documented during sprint planning and change story status to yellow or red and escalate communication to appropriate stakeholders.

Scrum of Scrum with onsite Scrum master(s):

This is a very important item for success of offshore sprint.  Off-shore SM and onsite SM should talk together about the impediments and supports required for the team and assign the ownership for the delivery of items. This is important decision point for dropping a story from sprint.  Onsite Agile Catalyst will lead effort in getting these items resolved for the off-shore team.

Sprint Retrospect:

Apart from normal sprint retrospect, team should reflect on better ways of getting support from onsite stakeholders clearly document steps worked during current sprint.

8. Agile in captive business units and dual-shore model

Agile dual-shore model with onsite client SM

Captive business units are offshore business units owned and operated by client. Captive business units generally work as an extension of client onsite teams. In that case following model works better. This model is also called as dual-shore model, which is a successful agile model.

  • Most often dual shoring is the common agile practice in this environment. Dual-shore will have a collection of offshore and onsite teams in one agile sprint team.
  • Possible team sizes will be as follows
  1. 5 Onsite resources and 5 offshore resources
  2. 7 Onsite resources and 5 offshore resources
  3. 7 Onsite and 7 offshore will be an overkill
  • In this offshore team, function as an independent sprint team with offshore lead.
  • Offshore lead will be reporting to onsite Scrum Master.
  • Depends on the experience resources, SM could be offshore or onsite.

9. Successful agile models vary with vendor

Agile implementations and vendor knowledge of agile vary with vendors. It is very important for a client organization to understand agile implementation in vendor organization, even before implementing agile in teams for delivery of project. In that case, several of agile skill set in vendor organization can be leveraged to delivery teams.

10 Agile vendor team model

This is not a recommended model. Chance of this model succeeding is very remote. In this model onsite agile catalyst will function as onsite scrum master. Onsite team will include BA and SME from vendor. Vendor sprint development team will be located offshore. Overall delivery responsibility will fall into onsite agile catalyst. Most often this  model  fails because inadequate onsite support system.

11 Agile vendor team model with shared delivery responsibility

This is one of the successful agile model in which delivery responsibility is with onsite scrum master.  In this model onsite agile catalyst report to onsite scrum master who owns overall delivery responsibility

shared agile off-shore team with onsite client SM

12. Agile in T&M model

Agile and T&M model goes hand in hand. But one of the challenges is the quantification of deliverables in this model. There is a clear definition of end product in water fall variations as well as RUP model. In agile, these end products will come as short increments. Though text-book agile talks about releasable product after a sprint, it may be releasable only after few sprints. Quality of deliverables can be determined only at that time. Seemingly well running sprint delivery will expose several quality issues at the time of release and will send several red flags to all parts of organization.

13. Agile in FP model

This is a very challenging model. Since fixed price require locked down requirements and agile allow change, it will be difficult for fixed price model to have agile delivery model. But “fixed” term can be used well in the equation. Instead of holding to fixed price, client can hold fixed SLA, Quality Metrics, productivity.

Following list of items with a target number will have almost same result of fixed price, but with better quality

  • Capacity utilization (How many hours resource worked in all tasks within sprint)
  • Productivity metrics (Sprint resource delivery time against average resource)
  • Defects created during sprint development and found during sprint testing
  • Defects induced to the product during sprint development
  • Code quality measurements using standard tools (for example Sonar for Java, nDepend for C#.)
  • Unit testing coverage

14. Starting an Agile Project

Much the work needs to happen before starting an agile sprint. Following items should be discussed during the kick-off meeting.

  • Offshore resource selection and management process should be in place
  • Offshore resource induction training programs should be in place
  • Should have reasonable idea on quality metrics expected as well as training period
  • Should have fair idea about the progression of velocity of sprint teams
  • Should have defined role of product owner and have identified a person for that role

Following key points need to be finalized before starting an agile engagement

  • Decide agile offshore team model
    • Dual-shore
    • Vendor team model (not recommended)
    • Vendor team model with shared delivery responsibility
    • Decide the team size
      • Based on the discussion above, please determine the appropriate team size
      • Define the role of agile catalyst and proxy product manager
      • Define the flow of feature to sprint and frequency of production release (following section will give pointers)
      • Decide on the quality metrics/SLA/KPI
      • Define governance framework/feedback mechanism

14.1 Flow of offshore agile sprint

As discussed earlier offshore agile sprint needs little more discipline  to be successful. Design and test case automation are the difficult issues within offshore agile sprint.  In the proposed process flow, high level and test automation has been taken out of development sprint.  High level design has been moved prior  to the feature development sprint and test automation has been moved after the development sprint.  This will help to reduce number of queries and decision points with in development sprint and bring better predictability.

Flow of a feature set in off-shore agile sprint

15. Onsite Support System.

Even before starting the sprint, onsite support system has to be defined and agreed upon with offshore teams. Resolving hardware and software issues will be one of the key elements during off hours.

16. Sprint -1 Design

Sprint-1 is defined as the sprint earlier to the development sprint. An offshore team requires little more disciples in terms of receiving work and committing to deliverables. Offshore units are generally several hundred miles away and several time zones apart. Communication will always be a challenge. High level design during the sprint will take lot of back and forth discussion and approval from different teams. Once the high level design is finalized, it is easier to do the rest of the design work within sprint. Otherwise the process normally hampers the delivery process and predictability.

17. Sprint -1 Story creation, review and estimation process

Once design is finished rest of time should be used to create stories and estimation required for the actual development sprint. This will help the teams to prioritize stories within a development sprint reducing the unknowns. Quality will be better as well because clarity of requirements and design is very clear at the point of development.

Estimation is little tricky for scrum process. Many organization use variation FP called story point.  Story point calculates estimate based complexity of the story and comparison similar estimates in the past.  Story points will be translated to hours if sprint burn down is tracked using hours.

18. Continuous integration and Continuous Delivery

Agile normally recommends continuous integration to reduce the unknowns. Even more offshore teams require continuous integration and build process to reduce integration problems in the beginning itself. Continuous delivery will also be recommended for offshore team. This will enable teams to improve productivity.

19. Sprint +1 Automation

Automation within sprint is a way to improve quality and overall ownership of software. Automation will reduce the cost of release and software certification. It will be ideal to do automation after completion of development and verification of software using manual scripts. Automation within development sprint normally creates heavy overhead of reworks down the road.

20. Offshore Scrum (Dos and Don’ts)

Best practices

  • Make sure to filter and select the right talents for the team
  • Create overlapping business hours for the offshore team with onsite resources.
  • Enable close communication between onsite teams using agile catalyst
  • Create measurement metrics for the team (ex: Capacity, productivity, defects created, code rework hours, communication lapse, code quality index)
  • Create continuous improvement for the team based on sprint retrospect
  • Daily progress report and time reporting for status
  • Daily standup meeting with offshore
  • Frequent offshore and onsite travel
  • Daily review of all deliverables and daily feedback mechanisms
  • Tracking offshore created reworks
  • Maintaining WIKI based issue register for all impediments.
  • Selecting a right vendor is the most important one of all

Practices to be discouraged

  • Offshore only team with no onsite oversight
  • Offshore team with no access to domain knowledge
  • Set of offshore hidden factors also need to be avoided

21. Offshore Knowledge Transfer

On periodic basis offshore resources should travel to onsite location for knowledge transfer. It will be a good idea to send a knowledgeable resource to offshore for training. My recommendation will be to have yearly travel of 20% of the resources to onsite for KT for a period of 4-8 weeks.

22. Offshore interaction model

Most important factor in offshore interaction model is to avoid SPOF. Interaction model should be diversified in such a way that offshore failure or rework will not be suppressed.

23. Maintaining Issue Register

It is important to maintain global issue and risk register for offshore engagements. WIKI will be good place to keep track of this register. Key factor is that both offshore and onsite can update this on regular basis.

24. Evolution of Offshore Scrum

Offshore Scrum is still involving. People are experimenting new roles to make it a successful model. Standalone offshore scrum teams are still very far from realty. Though many companies are trying several variations of quasi offshore teams with an oversight from offshore design scrums and onsite requirement/feature creation scrums, net results of these experiments will take time to prove.

25. Agile delivery control (tools and techniques)

There are several tools available for code quality/requirement quality. These tools will help to tune the delivery without much overhead.

Following WIKI has several Code Quality Tools.

26. Creating a compare, contrast and challenge culture

This is one of most challenging task in an offshore environment in general. Even if resource recognizes the request that does not make sense, resource will shy in questioning the validity of the request. Creating such culture requires constant monitoring of communication from all sides. Communication has to be constructive in nature to address these issues and encourage them to challenge and reward the people challenging with right question. This is an important element to be inculcated in the team culture.

27. Switching to agile offshore team

Re-tuning waterfall to agile offshore project is a difficult task. It requires much bigger discussion. I am deferring the discussion for now.

28. Agile Fixed Price vs. SLA based delivery

Sections 9 and 10 have references to this section. Further discussion will be added soon.


29. Resource, Carrier Path and challenge in agile

One of the challenges I faced in the past are related to offshore resource career path. Some of offshore hiring managers will state that, “they could find enough developers with experience more than 5-6 years of experience” and agile teams require strong technical skills in large numbers to be successful. There is a cultural issue. Because of the phenomenal growth in software industry in India and China, it is almost given that after 5-6 years of experience good engineer will be promoted to manager. They manage a set of people and will be less practiced on technical skills.

30. Conclusion

Overall this article is intended to give an overview of offshore agile process in the current form. Since this is brief paper, several of details are not discussed in this article. If any of you are interested we can talk more details.

Qualities of deliverables are based on the quality of vendor providing services. After all quality can be inserted only to certain extend using process.

Thanks to Julie John for reviewing this article.

Hidden facts of an off-shore software vendor

Hidden facts of an offshore software vendor

Dated: 12/28/2011

Joseph Vargheese 

Atlanta GA USA

This article mainly reference operations in India and china, and assumes minimum knowledge of offshore operation in China, India, Brazil, Costa Rica, Russia and Vietnam.

Location of your ODC

Location of youroffshore software development (ODC) environment determines offshore vendor price point as opposed to single rate for a country. Resource cost attributes to biggest expense in an ODC. But those salaries are determined by the location. For example average software engineer salary in major cities is around 14000$ in china and 16000$ in India (as of 2011). As operation move from one city to other cost also changes. For example salary in Dalian (second  tier city in China) is 25% cheaper than Beijing (first  tier city in China) or Shanghai or Shenzhen. There will be another 20% resource cost advantage if company move to a city like Jinan, which happens to be located few hours from Beijing. Similarly in India moving from Bangalore/Chennai/Hyderabad to second tier city like Bhopal/Kochi/Mysore may have 30-40% cost advantage.

Not all cities are same

Not all cities are good for sourcing highly skilled software professionals. Companies outsourcing to second  tier cities have to think about the type of manpower they can source from that city. Generally second  tier cities have lower supply of highly skilled man power compared to first  tier cities. If your operation is a heavy R&D based, it will be advisable to stay within a first  tier city.

Challenge in English

Recognize the fact that English speaking resource is a challenge in many outsourced countries. It is very challenging to recruit English speaking resources in China and Russia. Unfortunately the client will have direct feel of the problem only when contract is done and the staff selection has started. To some degree, vendor could find English speaking resources in India/Vietnam/Brazil/Costa Rica because of the higher supply.

Infrastructure and Operations cost

Infrastructure and Operations cost are not always a component in many countries. It is not the same level playing field between outsourced countries. China has high federal subsidies to operate within a software technology park owned by government, including subsidized tax, electricity, water, rent for several years. Brazil, Vietnam and Russia have some subsidies. But operating cost in these countries is much lower than India and China. India has subsidies for operations mostly driven by state governments to attract companies to that state. It includes subsidized rent, electricity and water. The high federal subsidies make China’s operation cheaper than other countries.

Experience and Salary

Experience determines the salary not the technology. Many  vendors sell CRM and ERP skilled offshore technology worker for a higher price. But for most of these countries, including India/China, resource pricing is driven by YOE. That means SAP professional and QA tester will only have  a small difference in remuneration for same years of experience.

Employee turnover rate

Most of the time, “stated employee turnover rate” does not include first year. Most of the time, vendor will state a yearly attrition rate excluding employees leaving in the first year of their employment, unless specifically asked. That number alone could be an additional 10%.

Overlapping hours

Practically overlapping working hours are hard to realize. Many  vendors provide overlapping hours coverage with their USA counterparts as work from home option or office. Most often employees can’t stay during night time due to family commitment or transport etc. In case of  work from home, most of the Indian or Chinese homes are not equipped with internet and phone facilities. Yet another note is that, in large cities these professionals are staying with an extended family in a 2 or 3 bed room apartment, which will not give them enough privacy required to function.

Many cities in India and china get cold during winter time. Life becomes almost stand still after 8:00 PM. That means transportation is very minimal as well as safety become issue for female employee to travel alone.

One size may not fit all

A high performing vendor in one area may not be suitable for other type of efforts. Vendors like to get every type of business available within a company. Every vendor engagement is a standalone unit. Most people do not understand that it is very challenging to bring another horizontal knowledge base to that engagement. For example you have very successful .NET based engagement and suddenly an SAP requirement comes. Natural choice will be the vendor performing currently. But most often it will be as challenging as starting a new engagement.

Disappearing resources

It is usual to exchange experienced resources for other projects. As engagement gets matured, vendor will start pulling experienced resources stating various reasons. Reason is that they are more valuable somewhere else in their organization. This will reduce the quality of your engagement. Client should consider contractually binding these resources.

Plan for the worst, expect the best

Terminating the contract and knowledge transfer to another source is always a sticky point during the contracting process. As time goes your offshore vendor can grow significantly, which make your current operation very small for them. On the contrary, client could grow fast which warrants a better offshore partner to cover client’s needs. Client’s outsourced contract should be able to terminate any time and always add an option to do a knowledge transfer to another vendor. It should be at the discretion of the client to decide on the notice period and not all resources are required for knowledge transfer.

Bring Competition

Competition brings best out of everyone. Always consider  two vendors for your engagement, because inherent competition always brings better value for the client.

Reverse knowledge transfer

It is a challenging issue to bring back knowledge from outsourced engagement to onsite. The challenge will become very high if the resources can’t speak English. This issue  has to be addressed during vendor goverance process.

My special thanks to Rajesh Philip for reviewing this article