Scrum Process With Outsourced Global Development Teams
– By Padma Krishnan, Senior Manager
ISV
Agile/Scrum
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.
Summary
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.