Delivering on the Promise – Sourcing Options for Agile Workloads in IT

Agile software development promises faster idea-to-deployment times with continuous improvement in both speed and quality. But, when an organization uses a provider to manage application software maintenance and development and the associated infrastructure, it must make sure its sourcing contracts are structured to achieve those benefits. Key tenets of the Agile Manifesto hold that software developers should value:

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change over following a plan.

Traditional sourcing has been largely a matter of following a plan with detailed statements of work that describe all the functions and activities the service provider will perform and service levels that keep providers on a strict path of deliverables, deadlines and budget. How do organizations shift away from this contracting approach and move toward an approach that supports an Agile development methodology with a less rigid vision of scope, funding and deliverables?

Several pricing constructs in the market today support an Agile approach, but choosing a pricing construct will depend somewhat on the level of the enterprise’s Agile maturity. As the enterprise matures and moves toward a product-aligned operating model, the benefits of increased throughput and declining costs become more readily achievable in an IT sourcing contract.

Contracting for Agile Services

Contracting for Agile services can be complex and typically evolve based on the maturity of the Agile practices in an organization. When an organization is just beginning its Agile software development journey, it will find itself in the bottom left of the graphic below. As it evolves its Agile maturity, it moves along the line toward the right, taking advantage of different pricing structures along the way. 

Figure 1: Agile IT Pricing Maturity

The following pricing constructs mark the path of an enterprise that is evolving its Agile development capabilities:

Staff Augmentation/Hourly: In this scenario, the enterprise buyer sources Agile pod team members on an hourly basis and retains overall responsibility for the day-to-day operations and output of the pod. This approach is largely the same as the legacy staff augmentation approach most enterprises currently use. Key attributes include:

• Ease of contracting with rate card-based pricing by resource type
• Simplicity of invoice validation for time and rates
• Ability to make up pods as needed by “buying” individual resources to fill roles in existing or new pods
• Responsibility to manage each sourced resource like a badged employee
• Ownership of delivery risk (without service levels)
• Lack of guarantee for productivity improvements / efficiency of throughput

Fixed Price for Capacity by Agile Team Size: This pricing construct allows an enterprise to pay a fixed monthly price for pods based on size and location. If all the functions in the pod are sourced, the provider manages the day-to-day activities of the pod members and bears more of the delivery risk. Key attributes include:

• Ease of contracting with rate card-based pricing by pod size and location
• Ability to be structured as fixed price per team per sprint (by size and location)
• Potential for sharing responsibility for productivity improvements / efficiency of throughput risk between the client and provider as the client begins to understand pod productivity
• Restricted to the pods defined in the rate card unless there are contractual mechanisms for exceptions, such as niche skills or occasionally required skills

Velocity by Agile Team: This pricing structure is based on size and location of the pod and guarantees throughput. The provider manages the day-to-day activities of the pod members and bears most of the delivery risk. Key attributes include:

• Contractual guarantee for velocity throughput improvements
• Contractual recourse if providers continually under-deliver on velocity commitments
• Restricted pods as defined in the rate card unless there are contractual mechanisms for exceptions, such as niche skills or occasionally required skills
• Baselining period for each deployed pod to determine pod velocity
• Tracking of velocity improvements by pod

Price Per Story Point: This pricing construct pre-determines price per story point and stipulates pay for each successful story point delivered. The provider manages and provisions teams based on demand. Key attributes of this pricing construct include:

• Reduced risk for undelivered or unacceptable work product
• Alignment of cost to work product at a granular output level
• Dependence on a mature Agile enterprise and a strong provider relationship
• Established and baselined common estimation model(s)

Price Per User Story: This pricing construct pre-determines the price per user story and stipulates pay for successful delivery of each user story. The provider manages and provisions teams based on demand. Other key attributes include:

• Pricing aligned to specific business outcomes
• Unit-price productivity measured over the term of the agreement
• Establishment of pricing after an initial calibration
• Pricing determined by portfolio due to varied sizes and complexities of user stories

The Case for Strong Service Provider Governance

Regardless of whether an organization contracts for services in a more traditional mode or in alignment with the approaches above, one primary principle determines value attainment: service provider governance. Governance is especially critical in determining the success of a sourcing relationship when it comes to building an Agile IT organization. Here’s why:

1. Having a strong governance structure over the demand management process ensures that service providers have enough backlog to keep them busy (and focused) and that the organization does not pay for unutilized capacity.
2. If the contract structure demands productivity improvements in terms of outcomes (i.e., story points), the governance function will provide oversight and ensure the service provider(s) take corrective actions in cases where pods are not achieving the required continuous improvement.
3. The governance role ensures that the business, IT (apps and infrastructure), security, procurement and the larger service provider ecosystem are active participants in the process of software development. Without active, collaborative interaction among all parties, speed and quality gains are unachievable.
4. Governance must play a role in resolving the new challenges that arise in an Agile environment. Those challenges include:
   • Budgeting. In an Agile environment, the business might manage a fluctuating budget as the business needs change, rather than looking to IT to manage according to a set annual budget. Governance needs to work with IT finance and involved providers to ensure that fluctuations are treated according to the contract terms and subsequent invoicing is correct. If the IT organization is more mature in terms of agility than the rest of the enterprise, this could create issues between the IT finance and enterprise finance teams.
   • Capitalization of software development. Governance needs to work with IT finance to develop an approach for determining how much of the provider’s fees are to be capitalized. In a traditional sourcing environment, development work is typically a line item on an invoice. In an Agile environment, fees for a single pod could include pure development and code maintenance or infrastructure support without a break down for the client to determine what is capex and what is OpEx.

ISG Sourcing Solutions helps enterprises source the right talent at the right pricing structure for their specific business and IT needs. Contact us to discuss how we can help you.