December 3, 2017

Please reload

Recent Posts

Done vs. Acceptance

December 3, 2017

1/10
Please reload

Featured Posts

Models and good practices for resourcing of Agile Projects

September 6, 2017

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.

 

  1. 100% local in-house staff

  2. 100% offshore in-house staff (Captive Development Centres)

  3. A mix of local in-house and offshore in-house staff

  4. A mix of in-house and onsite vendor resources

  5. 100% outsourced to local vendor

  6. Partially outsourced to local vendor

  7. A mix of in-house + offsite vendor resources

  8. A mix of In-house + onsite vendor resources + offshore vendor resources

  9. A mix of In-house + offshore vendor resources

  10. 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;

 

  • One development team

  • 100% In-house development

  • 100% In-house employees

  • 100% onsite

 

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

 

  1. 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.

  2. 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)

  3. It is best if the Product Owner comes from the In-house team (preferably the Business area and understands Scrum processes well)

  4. The Scrum Master may be from the In-house team or sourced externally

  5. The ideal cross-functionality and diversity in the development team is a distribution of 50% from in-house organization and 50% from vendor organizations

  6. Limit the number of offshore or distributed resources to a maximum of 4 (50% of development team size)

  7. Engage all resources on Time and Material basis ($/Day for the duration of the sprint)

  8. Ideally, vendor resources are engaged and paid for a minimum of one day (not on hourly basis)

  9. Engage vendor resources on a full-time basis for the period of the sprint (not shared basis across projects / customers).

  10. Internal resources can also be costed on time and material based on organizational charge out policies

  11. Aim for a fixed cost sprint (# days in a sprint x Number of resources in the sprint x Resource rate $/day)

  12. Schedule daily scrum (stand-up meetings) at the time of the day that is suitable for all team members to attend. Avoid scheduling multiple stand-up meetings in a day to suit time differences.

 

 

 

Share on Facebook
Share on Twitter
Please reload

Follow Us