Agile Software Outsourcing - Distributed SCRUM cycle
As many companies find out, agile development and software outsourcing are two concepts which do not automatically go hand in hand, and require careful adaptations of both the agile development processes and communication channels between the outsourcing supplier and the customer in order to work successfully together.
As many companies find out, agile development and software outsourcing are two concepts which do not automatically go hand in hand, and require careful adaptations of both the agile development processes and communication channels between the outsourcing supplier and the customer in order to work successfully together.
Distributed agile development with an outsourcing supplier can be successful, and TechTeam Akela has a proven track record of delivering projects run jointly by an onsite and a nearshore team of developers following Agile principles and practices. We are able to achieve these results following our own adaptation of the SCRUM cycle for agile project management, which is described below.
This variation of the Scrum process is used as a baseline in TechTeam Akela for handling Scrum teams in distributed development (onsite and nearshore / offshore) where the Product Owner is located remotely.
There is also the assumption that agile outsourcing project is performed on behalf of a client who has some software development knowledge, rather than being an end-user.

The Scrum Cycle
Roles and responsibilities
In classic Scrum only three roles are clearly defined:
- The ScrumMaster
- The Product Owner
- The Team (Members)
- The ScrumMaster is responsible for ensuring that everyone related to a project follows the rules of Scrum. These rules hold the Scrum process together so that everyone knows how to play. If the rules are not enforced, people waste time figuring out what to do. If the rules are disputed, time is lost while everyone waits for a resolution. Rule changes originate from the Team, not management. Rule changes should be entertained if and only if the ScrumMaster is convinced that the Team and everyone involved understands how Scrum works in enough depth that they will be skillful and mindful in changing the rules. No rules can be changed until the ScrumMaster has determined that this state has been reached.
- The Product Owner (typically someone from a Marketing or Product Management role within the client organization) prioritizes and maintains the Product Backlog.
In our distributed agile approach, we introduce two new roles:
- The deputy product owner
- The client project manager
- The Deputy Product Owner is the representative of the client product owner with the nearshore / offshore team. He/she keeps a continuous communication channel with the product owner, thus establishing shared vision beyond the information available in the time-boxed sprint planning meeting. Also this role doubles as an analyst. This role ensures that the many small decisions the outsourced team makes everyday are being checked for consistency, product-wise. Also it is the responsibility of the deputy PO to escalate any substantial product decisions to the client product owner.
The ScrumMaster and the client project manager are facilitators for the team and project needs (on their respective sides – onsite or nearshore) providing resources and routing information to the appropriate persons. Also they are responsible for managing the team in the organizational sense and provide accurate progress reporting, time tracking etc. to the respective organizations.
In typical projects, these roles can be aggregated. The typical aggregation is for the ScrumMaster, and Deputy Product Owner to be the same person however variations might apply. For instance, if business domain knowledge is only through another member of the team and the required analysis is substantial, the deputy product owner could be a separate job. Also if administrative tasks require the presence of a project manager separated from the Scrum Master, that separation can be also achieved, although there is quite a substantial overlap between the two's typical responsibilities.

