Global Sourcing and Agile Adoption


Global Sourcing and Agile adoption – What you need to know when your teams are split across country borders

Originally, since when I started working on s/w product development, it was done mostly based on the sequential ‘Waterfall model’ where Requirements, Design, Coding and Testing were planned and executed for the whole product at a stretch in a sequential way one after the other. The consumers of the product had to wait for a long time to experience the product (partially or wholly) and see if it meets their requirements/ expectations or not. The product development history data have proved that this model is not a recommendable one for complex product developments with unclear requirements at the onset. In such a scenario, defining the product requirements as ‘features’ and developing each of them in an iterative manner (Agile) was proved to be very effective.

As you know, Scrum is the most popular way of introducing Agility in product development. Scrum uses fixed-length iterations, called Sprints, which are typically two to three weeks long. The scrum teams will be usually 7 to 10 people strong and they must be capable of self-organising, highly collaborative and easily adaptive supported by a product owner and a Scrum master. Scrum teams will attempt to build a potentially shippable (properly tested) product in every sprint. Scrum is very effective only if the teams are co-located and if possible work from the same room. A large product shall be developed by multiple scrums situated at the same site or building. In this case, the best approach would be to split the teams into multiple feature teams and take up a scrum of scrums approach that can stich all the tested features coming from each scrum together in every sprint.

Since the application of ‘Agile methodology’ in product development, it has been found very effective in terms of time to market, product acceptability, budget management etc. Now, almost all product development companies follow this methodology extensively.

At this juncture, it is also worthwhile to have a look at the trend in product R&D outsourcing. Because of the extreme care on IP protection, product R&D was confined mostly in-house. This closed approach slowly got relaxed and in the last 30 years of the history of R&D outsourcing, global sourcing/ offshoring for product R&D got adopted on a large scale because of the unprecedented benefits it yields. Now, many product companies do their product R&D by teams constituted by their in-house teams and teams sourced from third party outsourcing companies located in different time zones. At present, when the license based product selling is almost vanishing because of the proliferation of usage based charging, product companies can survive only if they can reduce the development cost to the maximum extent without losing agility in newer releases.

Having understood the significance of Agile based development and the global sourcing for project teams, the challenge that comes to our mind is how do we marry both without diluting the basic traits of both? The benefits of global sourcing cannot be neglected just to follow the agile rules/ recommendations strictly. We should exploit both to the maximum extent and marry both appropriately without degrading the effectiveness and efficiency.

In my product R&D career, I have applied both concepts effectively (with some customisations) in multiple programs and have gained some insights on how they can be applied effectively in Agile programs split across country borders. Sometimes, some minor deviations were taken (with approval) to accommodate some of the challenges associated with distributed teams.

  • Since team interaction is very crucial in Agile teams, follow the below guidelines strictly as much as possible while forming the development teams.
  1. If required, split the development teams only based on features. Each feature team can have one or more scrums. All team members of a feature team should be co-located in one building. There could be more than one feature teams at a location.
  2. There could be such multiple locations / development sites holding responsibilities for one or more product features. However, the distribution of features should be done judiciously so that the features which are more coupled are done at the same location.
  3. Since the teams are distributed, in order to make sure maximum team communications, collaboration tools could be used. There are many such tools available today to practice this effectively (e.g. Enterprise social collaboration tools, Instant messaging etc). Leverage video & audio conference facilities extensively to keep the team interactive across locations.
  • Apart from the product owner and the scrum master in each scrum, there has to be a ‘Scrum of scrums’ at one of the locations (most suitable) which will have an overall product owner, scrum master and an integration team. This is very essential because
  1. In a distributed team environment, when individual teams are more focused on their assigned delivery commitments, someone has to keep up the overall product vision and monitor accordingly.
  2. This team will also take the responsibility of stitching the sprint outputs coming from the various feature teams.
  3. Resolve issues that may crop up during feature integrations.
  • Based on the locations involved and the features assigned to each of them, an umbrella document should be written in advance to describe the rules and guideline that the teams should follow strictly. This document must lay down processes and methods to be followed for design, interface definitions, coding style, automation frameworks, defect tracking, source control, change management etc. This has to be understood by each of the team members thoroughly and the overall product owner and scrum master should get a sign off on this from all the members of the program. If written carefully and followed strictly, such a document can remove unwanted communications across sites.
  • Apart from the usual scrum meetings that happens in every scrums, the following meetings also to be planned and scheduled. They should synchronise at least once in two days at a suitable time.
  1. The overall product owner with all product owners of the individual scrums
  2. The master of the scrum of scrums with all scrum masters

These sessions help to make sure that the feature scrums are co-ordinated, synchronised and collaborated well for the completion of the larger objective. They help to take decision on priority changes.

  • To make multisite agile successful, the required h/w set up, development platforms and the continuous integration / build mechanisms should be in place very much in advance and the environments should be tested thoroughly along with the communication links connecting the locations. The same is applicable for test environments as well. This robust set up can increase the number of successful daily builds of the product across locations.
  • All applicable tools should be procured and leveraged to the maximum extent at every location and test automations should be planned and taken up strictly in every sprint. Conscious planning on test automation is very essential across locations which enable continuous regression viable.

The above guidelines have been followed in multiple product R&D programs successfully. Though all may not go through smooth execution at every stage because of various reasons, timely identification of risks and mitigating them as a collaborative team (very important) would be very essential to reap the maximum benefits.