Scroll Top

Scrum Process With Outsourced Global Development Teams

– By Padma Krishnan, Senior Manager
When potential customers plan to outsource product development or developing a customized piece of software they often embark on an “Agile” or “Scrum” development model. Often outsourced teams are located in different geographies and time zones. The customers’ understanding is that they will get development done faster and better, cutting through a lot of bureaucratic meetings and documentation that are otherwise present in traditional software development models. However they find many issues creep up when they start the engagement. They find that they are not able to get work done as fast as they expected and with the quality and cost they budgeted for. This article highlights some practical approaches to tailor and adopt the scrum model in an outsourced engagement using globally dispersed teams
The Scrum model is considered to be an implementation of the Agile Manifesto which emphasizes communication and collaboration, working software and the flexibility to adapt to changes. It emphasizes individuals and interactions over processes and tools, and values responding to changes over following a plan. While this seems very ideal, there are some aspects that need attention in outsourcing. Firstly, the customer and his team will not have a lot of direct access to the development team and their day to day interactions. This is compounded when the outsourcing vendor has globally dispersed teams. Secondly, traditional outsourced models necessitate basic documentation like a product plan and sufficient engineering documentation. This does not imply that the scrum model cannot be practiced in outsourcing, but it makes it clear that some different techniques and processes need to be adapted to make the model work.

The Discover Phase

A scrum team consist of a Product Owner, Development team and a Scrum Master. The Product Owner has the most important role as s/he is responsible for maximizing the value of the product and the team’s output. The Scrum Master ensures that there are no impediments to the team of developers and acts as a servant-leader of the team. Scrum usually starts with a large backlog of items to be worked and a “Sprint Planning Meeting” between the product owner and the team wherein a list of items to be immediately worked upon is decided. In an outsourced scenario, an initial requirements gathering or “Discover” phase is recommended which is critical for the success of the project. While we do not suggest that all the requirement gathering and design be done upfront, we do need to cover enough breadth and depth so as to sustain several development cycles or Sprints. There is no uniform timeline for these phases as it simply depends on the nature of the project, the stakeholders, the product owner and the level of details known at that point. The Product Owner must be a person from the customer side who can clearly articulate the high level vision as well as all the necessary details of the project. This phase lays the foundation for future development work and therefore this phase should not he hurried or sprinted. In fact, a deliberate execution of this phase, even if takes more time, might save several person days of effort over the life of the entire project.

The Product Owner from the Vendor's side

In a scrum model, usually, the product owner is responsible for creating “user stories” and documenting the requirements. In the outsourced model, we recommend that a Product Owner be nominated from the vendor’s team, usually a Business Analyst. The Product Owner from the customer’s team should explain the requirements to the outsourced team and the designated product owner from the vendor’s team should create user stories. However all features and user stories must be critically reviewed and approved by the product owner from the customer side

High Level Design Phase

Prior to starting development or time boxed sprints, a high level Design phase is needed in outsourced engagements. During this phase, a high level architecture and design document must be prepared and walked through with the customer. Depending on the nature of the project, POCs (proof of concept) may be needed. Technical decisions that impact the overall design must be taken and agreed with the customer. The low level design aspects can be a part of the respective sprint cycles, but the overall project structure, design patterns, high level schema and other technical details must be agreed during this phase. The Discover and this High Level Design phase need to be done collaboratively.

Dependencies, Verification, Performance and Security Aspects during Sprints

After these Discover and high level Design phases, the product owner can prepare a list of backlog items which can be taken up in sprints. It is important to identify dependencies amongst various items while selecting items for a particular sprint. During the initial sprints, we recommend developing the technical framework pieces along with any reusable components which will benefit future sprints. After developing a few features which are critical to the customer, perhaps after three to four sprints, we recommend performing a load test and a penetration test in order to address performance and security issues which will be costly to fix if postponed to a later stage. Best practices for delivering highly performant and scalable solutions cannot be added in the last sprint as an addendum. They must be practiced right from the initial sprints. We also recommend running code analysis tools on the delivered code in order to address best practices in development. Certain customers have specific audit requirements before accepting code, like for example requiring that the code pass the HP Fortify audit tool. It is highly advisable to get these activities going during the early sprints rather than waste time and effort during the later sprints to refactor code.
The regular sprint cycles can continue after load test, penetration test and code analysis. In our experience, we find it very useful to have a specific sprint addressing bugs, UAT issues and for undertaking some refactoring work after every 4-5 sprints. Requirement changes are inevitable and this may involve some refactoring of previously working code. Hence it is practical to acknowledge change and address these activities in a specific sprint. Failure to allocate time to do early load tests and code refactoring delays and amplifies the inevitable problems that will ensue during the later stages of project acceptance.

Demonstration to Stakeholders by Product Owner

After a sprint delivery is performed by the outsourced team, the product owner from the customer side is recommended to demonstrate working application to stakeholders thus facilitating early feedback and correction mechanism. We frequently find this practice compromised. This will merely delay the changes and cause expensive refactoring during later sprints.
A pictorial representation of how scrum can be practiced in an outsourced engagement for new development projects is shown below.
As can be seen from the diagram, the product owner interfaces with stakeholders, customers and users to prepare a product backlog. We recommend that the next steps should be a face to face Discover Phase and high level Design phase in order to agree on the important decisions that will affect all future sprints. This process yields superior results by way of identifying dependencies, complexities & uncertainties amongst items in the product backlog. Successive sprints are better planned as the vendor team feels empowered and has a better sense of what is in store in successive sprints.


Scrum can definitely be practiced in outsourced development and with globally dispersed teams. But it is important to plan for all the potential pitfalls mentioned above. Taking time to conduct an in-person Discover and Design phase, allocating specific sprints for code refactoring, fixing customer issues and making sure that the customer product owner creates or at least critically reviews and approves all the product features will go a long way in ensuring the success of your outsourced scrum engagements.