Introduction and Context
In the present day and age, hardly any company develops software using only internal staff. Most organizations rely on vendor organizations or free-lance consultants to varying extent in the development process. Some organizations completely outsource their software development process. Other organizations manage the development process In-house (within their company) but engage vendor resources alongside their staff. Some companies have also set up captive offshore development centres that are an extension of their operations. Many vendor organizations have local and offshore operations and engage resources from multiple geographical locations for software development.
All these combinations can be captured by the following 10 resources engagement variations.
100% local in-house staff
100% offshore in-house staff (Captive Development Centres)
A mix of local in-house and offshore in-house staff
A mix of in-house and onsite vendor resources
100% outsourced to local vendor
Partially outsourced to local vendor
A mix of in-house + offsite vendor resources
A mix of In-house + onsite vendor resources + offshore vendor resources
A mix of In-house + offshore vendor resources
100% outsourced to offshore vendor
The most common arrangements are a mix of in-house, onsite and offshore resourcing arrangements for software development. The degree of mix is determined by the company’s circumstances and needs.
These models can be illustrated graphically along two spectrums based on the extent of In-house vs. Outsourced development and the extent of Onsite vs. Offshore development.
Resourcing models for Software development
Objectives for engaging vendor resources in projects
Companies engage vendors in their software development projects for a variety of reasons;
To lower the cost of development
To have flexibility in scaling up and down team sizes as and when required
To address shortfall or scarcity in resources needed for the project
To acquire technological skills not currently available in their organization
To enhance cross-functional skills and diversity deployed on the project through outside resources
Commercial options for engaging vendor resources in projects
Vendor resources are usually engaged in one of the following three commercial approaches;
Fixed price (usually for outsourced projects, typically an agreed fixed cost of development for the whole project or stages)
Time and Material (for the number and type of individual resources and the length of engagement, typically $/resource/day)
Capped Time and Material (Time and Material based on number and type of individual resources and the length of engagement but with an upper ceiling for spend)
The Agile (Scrum) context
The nature of Agile projects is very different to Waterfall projects as we know. Scrum (a flavour of Agile) is based on small team sizes of a maximum of 11 members. The concept of Scope is different in Agile projects and Scrum is not organized along software development functions of Requirements, Design, Development, Testing, etc. More importantly, Scrum emphasis face-to-face form of collaboration which implies that collocated and cross-functional teams perform the best. Agile projects should never be outsourced. They should be executed in-house and may include team members from outside.
In this context, the ideal resourcing model for Agile (Scrum) projects is;
A more common and practical, but less than ideal resourcing model for Scrum is;
One development team
100% In-house development
In-house employees + Free-lance or Vendor developers
Onsite + Offsite + Offshore locations (Distributed Scrum)
Challenges in engaging vendors in Agile projects
Lack of Agile know-how and mind-set in vendor organizations
Vendor’s fear of being commercially disadvantaged
Losing control over resources means vendor cannot maximise resources billing / utilizations through multiple concurrent projects (common practice among offshore vendors)
Geographically distributed locations leading to collaboration issues
Good practices and suggestions for resourcing Agile teams
There should be only one common development team. That team may have resources from multiple organizations but they should never be separated on organizational lines.
Limit Sprint team size to 11 (9 developers + 1 Product Owner + 1 Scrum Master). If necessary set up more than one sprint team (One set of Product Backlog with clear distribution based on components or features and no inter-team dependencies)
It is best if the Product Owner comes from the In-house team (preferably the Business area and understands Scrum processes well)
The Scrum Master may be from the In-house team or sourced externally