How to Contract for Agile Development

Services
Published: 1 October 2015 ID: G00280983

Analyst(s): Neil Barton, Gilbert van der Heiden, Nathan Wilson

Sourcing managers are challenged to reconcile the collaborative, flexible

culture of agile software development with the more rigid discipline of
managing application outsourcing contracts. Sourcing strategies must be
modified to adopt agile's trust principles while verifying that vendors deliver.

Additional Perspectives
■ Federal Government Context: 'How to Contract for Agile Development Services' (9
February 2016)

Key Challenges
■ Conventional sourcing approaches create long, complex contract negotiations, which are an
obstacle to quick agile delivery.
■ Multiyear contractual commitments can force a client to work with a service provider even
though it has become dissatisfied with the results.
■ Conventional contract change methods are too slow to keep up with the rapid changes
expected in agile development.
■ The flexibility of agile projects makes it difficult to establish conventional service-level
agreements (SLAs) and penalties for underperformance.

Recommendations
Sourcing managers should:

■ Contract with multiple service providers that have depth in agile methodologies.
■ Implement simplified master service agreements (MSAs) in which each sprint is a fixed-price
work order, payable on delivery.
 ■ Use well-established agile metrics to verify the service provider's performance.
■ Review the results after each sprint, and reserve the right to award future sprints to alternative
service providers if serial underperformance should warrant it.

Table of Contents

Introduction............................................................................................................................................ 2
Analysis.................................................................................................................................................. 3
Set an Agile Sourcing Strategy......................................................................................................... 3
Select Multiple Agile-Capable Service Providers............................................................................... 5
Write Agile Framework Contracts......................................................................................................6
Manage Agile Contracts for Quality.................................................................................................10
Colocate, or Distribute With Care..............................................................................................10
Define "Done"........................................................................................................................... 10
Use Quality Metrics...................................................................................................................11
Gartner Recommended Reading.......................................................................................................... 12

List of Tables

Table 1. Sourcing Culture Has More in Common With Waterfall Development Than Agile........................3

List of Figures

Figure 1. Timeline for Contracting Agile Development Services............................................................... 4

Figure 2. Gartner's Recommended Best-Practice Contract Structure..................................................... 7

Introduction
1
Organizations are increasingly adopting agile software development methodologies, driven by the
growth of digital business and the need for innovative projects (Mode 2 efforts) to respond to rapid
business change (see "How to Achieve Enterprise Agility With a Bimodal Capability"). Note 1
provides a definition of agile software development.

As a result, Gartner is receiving an influx of inquiries from sourcing managers who are seeking
2
guidance on how to outsource agile. Many of today's application outsourcing contracts were
3
designed primarily to support waterfall methodologies. The culture of sourcing and vendor
management is to hold service providers accountable for deliverables that were agreed on at the

Page 2 of 14 Gartner, Inc. | G00280983

 start of a contract. This culture has much in common with the "waterfall" style of software
development, as illustrated in Table 1.

Table 1. Sourcing Culture Has More in Common With Waterfall Development Than Agile

Sourcing Waterfall Agile

Fixed statement of requirements Fixed statement of requirements Frequently changing requirements

Statements of work with RACI matrixes Top-down assignment of tasks Highly collaborative

Strict change control Strict change control Acceptance of frequent change

Multiyear contract terms Large but infrequent releases Short sprints, typically two to four weeks

Formal governance Disciplined governance Self-organized governance

Delivery and payment milestones Phase gates Review scope between sprints

RACI = responsible, accountable, consulted and informed

Source: Gartner (October 2015)

Agile principles are opposed to waterfall development's emphasis on control. The Agile Manifesto
states on its first page that agile values "customer collaboration over contract negotiation" and
4
"responding to change over following a plan."

Clients and service providers are now working to bring these incompatible principles together. For
example, legal firms such as Bird & Bird have published papers explaining how the two can work
5 6
together, and the CoActivate project began work on a sample fixed-price agile contract.

Gartner's adaptive sourcing Innovate layer (see "Adaptive Sourcing Innovate Layer: Innovation
Strategies Accelerate Business Growth") establishes the principles for sourcing managers to work in
a fast-moving environment. In this research, Gartner recommends specific best practices for
contracting service providers for agile software development. These best practices are structured
around the four phases defined in the Gartner sourcing life cycle (see "Outsourcing Advisory:
Sourcing Strategy Phase Overview").

Analysis
Set an Agile Sourcing Strategy
Conventional contracts for application services set out an "iron triangle" comprising three elements:
the functionality to be delivered, a deadline and a fixed cost. Sourcing managers expect service

Gartner, Inc. | G00280983 Page 3 of 14

 providers to accept responsibility for delivering all three. They often are concerned that agile will
result in this discipline being abandoned.

It does not have to be this way. Agile methodologies such as Scrum state that, once a sprint goal
has been agreed on and the sprint has started, new functionality should not be added to the current
sprint, but instead added to the product backlog and scheduled for a future sprint.

Therefore, a conventional contract that defines a program of deliverables over many months will be
unsuitable for agile working. Instead, a more flexible contract is needed in which each sprint is
viewed as a separate piece of work. The service provider is made accountable for delivering each
sprint, but the content of a sprint can be set just before the sprint starts, not at the start of the
contract.

It follows from this that, while the client has the intention to purchase a full program of sprints, the
completion of a sprint is an ideal time to review progress and decide how to continue. During the
early iterations (typically the first five or six sprints), underperformance can be discussed with the
service provider and corrective action taken. (This may require behavior changes from the client as
well as the service provider.) After the early iterations, continuous underperformance will require
stronger action. The contract should not oblige the client to continue if it is dissatisfied with the
progress. It costs time and money to change suppliers between sprints, so this should not be done
lightly. On the other hand, if a project is failing, then it is better for everyone to find an alternative
quickly. Additionally, the promise of working on the next sprint is a great incentive for the service
provider to focus on really delivering the current sprint (see Figure 1).

Figure 1. Timeline for Contracting Agile Development Services

Source: Gartner (October 2015)

Page 4 of 14 Gartner, Inc. | G00280983

 A fundamental principle of agile is the close and active involvement of business users in the project.
This is no different when outsourcing agile, and is a principle that must not be compromised. Expect
all business users, service providers and IT personnel to be present at key meetings.

Another important relationship is with the IT operations team. A standard must be established so
that all service providers deliver object code with consistent compiler and runtime library versions,
along with working test scripts, test data and expected results. These should be deployed in a
DevOps-style continuous integration/continuous delivery (CI/CD) system. The DevOps movement
arose from the need to support the frequency of software releases that agile development produces.
It is a fact of life that, in many outsourced environments, IT operations are the responsibility of a
different service provider than application development. This makes it particularly important to
follow the DevOps principle that IT operations should be treated as a development team member,
with its nonfunctional requirements being recognized and met by the agile team.

These relationships create some complications in managing communication. In pure agile, all team
members are in the same room and feel part of the same organization. In outsourced agile, some
team members are employed by a different organization, and also may be in a different location. To
establish the trust within the team that is so important in agile, it is best to keep lines of
communication as simple as possible. Therefore, it is also best to keep the number of service
providers working within an agile team to a minimum — that is, one. In agile development, using
one vendor for project management, another for development and a third for testing is only possible
in a staff augmentation contract. It does not allow clients to share delivery risk with service
providers.

Recommendations:

■ Involve business users and IT operations closely in selecting and working with the service
provider.
■ Don't change the goals of a sprint during the sprint.
■ Accept changes to requirements between sprints (where necessary).
■ Treat each sprint as a fixed piece of work, and review performance on completion.

Select Multiple Agile-Capable Service Providers

Sourcing managers can still encourage competition between service providers, even though, in any
one project, only a single agile supplier will be contracted. The goal should be to keep at least two,
if not three, service providers in play and award different projects to each. If one service provider
should fail, then others that are familiar with your organization will be ready to take its place. Using
more than three service providers dilutes the spending with each company, and, thus, the volume
discounts they offer.

Almost all application outsourcing service providers offer some level of agile or Scrum capability,
but agile is embedded more deeply in the DNA of some providers more than others (see "The
Increasing Number of Mainstream Outsourcers Offering Agile Development Will Require Greater

Gartner, Inc. | G00280983 Page 5 of 14

 End-User Diligence" [Note: This document has been archived; some of its content may not reflect
current conditions]). The selection process should identify which vendors bring actual depth of agile
experience, rather than just "lip service." Sourcing managers can evaluate expertise, to some
extent, by using simple metrics, such as the number of certified ScrumMasters and years of
experience with agile projects. Other clients are being more creative; some have even run
hackathons as part of the supplier selection process.

Recommendations:

■ Within an agile team, engage one supplier only.

■ Maintain multiple suppliers working on different projects.
■ Select suppliers with verifiable depth of experience and skills in agile methodologies.

Write Agile Framework Contracts

Some sourcing teams have developed standard terms and conditions that are suitable for contracts
of all shapes, sizes and scopes. Negotiating these terms and conditions with service providers is
time-consuming and can delay the start of an agile project by months. For the small, innovative
niche service providers emerging in many digital business projects, reviewing and agreeing on such
complex terms can be extremely difficult. A potential solution is for them to adapt the agile concept
of a "minimum viable product," and for sourcing to construct a "minimum viable contract"
containing only the terms that are essential (bearing in mind that each work order within the contract
is of relatively low value). Figure 2 shows Gartner's recommended best-practice contract structure
and the sections that are essential for agile development services.

Page 6 of 14 Gartner, Inc. | G00280983

 Figure 2. Gartner's Recommended Best-Practice Contract Structure

BHD = behavior driver; OLA = operational-level agreement; SOW = statement of work

"Research Index of Gartner's Best Practice Outsourcing Contract Toolkits"

Source: Gartner (October 2015)

Gartner, Inc. | G00280983 Page 7 of 14
 The MSA sets out legal terms and conditions such as intellectual property ownership, liabilities and
payment terms. Each sprint is treated as an individual work order under this contract, using an
attachment to the MSA to document matters that are specific to the sprint. The "statement of work
(SOW)" in the attachment lists the epics and stories to be delivered in the sprint. This does not
impose any additional overhead on an agile project, since documenting the sprint backlog is a
normal task in agile development. The attachment also documents "key personnel" who the service
provider is obliged to retain on the project, responsibilities for providing development and testing
tools, and an "exit plan" to define what the developers should hand over when the application
completes its main development cycle and enters maintenance.

The MSA should not force a client to purchase a full sequence of sprints; rather, it should be flexible
enough that a client commits to completing each sprint, but is not obliged to order the next sprint.
This allows the client to react quickly to changing business circumstances, and also maintains the
service provider's focus on completing each sprint successfully.

Some service providers will be concerned about this provision. The client should reassure them that
it intends to purchase a full program of work, and does not intend to switch service providers
arbitrarily or frivolously. Switching service providers between sprints causes delays and additional
costs, so it is not in the client's interest to do so unless a project is clearly failing.

A service provider may object to the lack of a long-term commitment by saying that it is required to
dedicate resources to the project and should be compensated for the loss of future revenue if the
client changes its mind midproject. Gartner estimates that the structure recommended above
provides a guarantee of at least a month's work, and the likelihood of future work with relatively little
sales effort. As such, it is not very different from time and materials contracts, and service providers
are skilled in pricing their services for such environments.

Some clients negotiate a middle ground. In "Agile Contracts: Money for Nothing and Change for
7
Free," Scrum evangelist Jeff Sutherland proposes that if future sprints are canceled, then the
supplier should receive 20% of the revenue planned for the remainder of the project as a
8
cancellation fee. Even organizations with reputations for inflexibility, such as the U.S. federal
government, are using indefinite delivery, indefinite quantity (IDIQ) contracts to deal with situations
9
like this.

The other important element of the contract is establishing the charging mechanism for each sprint.
The four main options are:

1. Time and materials: This is the path of least resistance for application development projects of
all kinds. However, it is the least satisfactory for sourcing managers, who feel that they bear all
the risk of the project, while the service provider bears none.
2. Size-based pricing: Sourcing managers ideally would like to be able to pay per unit of
application functionality delivered. The challenge is to find a unit measure of functionality:
■ The best size-based methodology is function point counting (see "When to Use Function
Points in Application Development Contracts" [Note: This document has been archived;
some of its content may not reflect current conditions]). Function points provide reliable and

Page 8 of 14 Gartner, Inc. | G00280983

 objective software sizing, are reasonably cost-effective, and can be combined with agile
methodologies. However, they have the limitation of measuring only functional complexity,
not business value. In practice, function points are rarely used on agile projects.
■ Many agile methodologies use story points to estimate effort, and it is tempting to calculate
a "cost per story point." This should be avoided. Story points are relative measures of
complexity, an advanced version of a "small/medium/large" method for classifying
requirement complexity. One team will count story points differently than another, so it will
always be difficult to compare a cost per story point between teams or suppliers. An agile
team's ability to estimate improves over time, so story point estimates for early sprints are
less accurate than later sprints. In any case, business users prefer to think at higher levels,
such as epics or themes, rather than at the level of detail of story points.
3. Fixed pricing: The most common solution is to treat each sprint as a fixed-price project.
Payment is made when working software is delivered, and it is subject to a strict "definition of
done" (see below). The fixed price can be adjusted between sprints, if necessary, using a labor
rate card to calculate the cost of increasing or decreasing the service provider's team for the
next sprint.
4. Outcome-based pricing: In an ideal world, service providers would be paid only when the
client achieves the business value that the new system was intended to deliver. This
arrangement is highly desirable and should always be considered. Service providers from the
digital business and agile worlds are particularly likely to support such an arrangement. In
practice, however, outcome-based pricing is often difficult to implement, and many clients
revert to fixed pricing. There are three difficulties:
■ Defining an outcome is not as easy as it sounds. On an agile project, the definition of
outcomes may change over time.
■ A business outcome for the client may be only partly dependent on the service provider; it
also will depend on the client's ability to execute, or on third parties. Service providers often
are concerned about putting part of their payment at risk based on factors other than their
own performance.
■ Business outcomes may not be achieved until many months after the project is completed,
thereby creating a delay between the service provider's costs and its revenue. Service
providers will not absorb all these costs themselves, so the client may pay a premium for
deferring payments until outcomes are clear.

If outcome-based pricing is not used, then it is wise for a client to retain a percentage of the total
contract value to be paid on completion of the full program of sprints, or on significant milestones
when the new system starts to deliver business value.

Recommendations:

■ Simplify contracts to a minimum in order to enable quick supplier selection and contracting.
■ Construct framework contracts with no long-term commitments.

Gartner, Inc. | G00280983 Page 9 of 14

 ■ Make each sprint a fixed-price work order within the framework contract, payable on delivery.

Manage Agile Contracts for Quality

Colocate, or Distribute With Care

Agile principles normally encourage colocation — that is, for the whole team to be present in one
room throughout the project. This is very difficult to achieve when outsourcing to an offshore service
provider. The most common solution is the "landed" method of working, in which offshore resources
are relocated to the client's onshore premises for the length of the project. This achieves the goal of
having the team colocated, but the additional travel and accommodation costs make it more
expensive than pure offshore. Some clients adopt the reverse principle and move the onshore
business representatives to the offshore work location for the duration of the project.

Distributed agile can be made to work, but it requires close management attention. Business
representatives are likely to be based onshore. Developers and testers often will form the largest
part of the team, and are most commonly located offshore. Product owners are most commonly
based onshore. A proxy product owner working at the offshore site and answering questions on
behalf of the business can work as long as the actual product owner and the proxy have a common
understanding and good lines of communication. ScrumMasters are more commonly located
offshore with the development and test teams. Distributed agile requires a higher on-site to off-site
team ratio. Whereas waterfall can operate with 1-on/6-off or even 1-on/10-off, agile working
requires 1-on/3-off or 1-on/4-off. A single off-site location is optimal, while multiple remote locations
make communication and collaboration harder.

Even when distributed working is necessary, it will always be a challenge to the intense cooperative
communication seen in high-performing agile teams. Some basic guidelines will reduce the
obstacles:

■ The offshore team should preferably be in a time zone with at least a two-hour overlap with the
onshore team. (Less can be made to work, but it is inadvisable. Nearshore solutions have the
advantage of much greater time-zone overlaps.)
■ Where the scale of the project means that multiple Scrum teams are needed in different
locations, methodologies such as Scaled Agile Framework (SAFe) and Large-Scale Scrum
(LeSS) can help to scale up agile principles.
■ Do not economize on bandwidth to the offshore location, travel, or collaboration technologies
such as videoconferencing and telepresence. You will save some money in the short term, but
spend more in the long term by impeding the productivity of the team.

Define "Done"
It is important to establish a definition of "done" to be applied to sprints (see "Avoid Chaos in Agile
Development by Defining 'Done'" [Note: This document has been archived; some of its content may
not reflect current conditions]), and to enforce the team's responsibilities for this. Some of the
responsibilities will fall on the service provider — for example, to ensure that the latest code has

Page 10 of 14 Gartner, Inc. | G00280983

 been checked in and loaded into a continuous integration system, or to update unit test scripts/
automation. Other responsibilities will fall on the business representatives, particularly user
acceptance testing. Ideally, the business should carry out its own testing of deliverables at each
sprint. If this doesn't happen, then future sprints will have to go back and rework code, thereby
reducing the capacity available to implement new functionality. Clients should consider adopting
test-driven development techniques to ensure that the whole team understands the gates for user
acceptance from the start of the sprint, and make maximum use of automated testing (see
"Accelerate Development With Automated Testing" [Note: This document has been archived; some
of its content may not reflect current conditions]).

Use Quality Metrics

Agile development methodologies provide a wealth of metrics for managing a team's performance
(see "Use Metrics to Drive Agile, DevOps and Continuous Delivery" [Note: This document has been
archived; some of its content may not reflect current conditions]). Outsourced agile should make full
use of these, but should treat them as quality metrics triggering remedial actions, not as contractual
SLAs triggering penalties or breaches. The whole team (business representatives, IT management,
sourcing management and service providers) should maintain and review the metrics on the product
backlog, Scrum board, burn-down charts and so on.

Burn-down rates are used to measure the story points delivered in each sprint. It is normal that the
team's ability to estimate its capacity evolves during early sprints. If the first few sprints do not
deliver the story points planned, then this should be used to improve the team's estimating
techniques for future sprints, not treated as a failure of the service provider. By the fifth sprint, a
team normally should be able to estimate its work more accurately. At this point, an inability to
deliver the stories promised is an indicator of more serious problems. It is reasonable to expect
story points per sprint to improve as the team evolves; on the other hand, a decrease in productivity
should trigger a review of how the team is working, and it might be one of the reasons why a client
decides not to commission further sprints from this service provider.

Sourcing managers also must recognize that the responsibility to reduce technical debt is central to
agile working. Agile encourages developers to write code as quickly as they can in order to deliver
the stories allocated to a sprint. The benefit is a tangible working product at the end of each sprint.
The consequence is that future sprints must recognize their responsibility to refactor — that is, to go
back and rewrite sections of code that have become unreliable, unmaintainable or overly complex.
Agile projects should expect to spend 10% to 15% of each sprint refactoring. Code walk-throughs,
static code analysis or automated code analyzers can be used to identify where refactoring is
needed. The need for refactoring does not represent the service provider's failure to do a quality
job; rather, it is a core aspect of agile working and should be accommodated within an agile
outsourcing contract.

Finally, it is worth emphasizing that a strong relationship between senior executives from the client
and the service provider is always an essential element of managing an outsourcing relationship.
This is particularly true when outsourcing agile, where trust is such an important element.

Recommendations:

Gartner, Inc. | G00280983 Page 11 of 14

 ■ Use landed resources to maximize colocation; where distributed agile is unavoidable, centralize
remote teams into as few locations as possible.
■ Enforce a precise definition of "done" (on the business as well as the supplier).
■ Use conventional agile quality metrics not to trigger penalties or breaches, but rather to decide
whether to continue awarding new sprints to the service provider.

Following these recommendations will result in the best of all possible worlds: a rapid time to
market, a trusting collaborative team and verifiable value for money from the service provider.

Gartner Recommended Reading

Some documents may not be available as part of your current Gartner subscription.

"Bimodal IT and Adaptive Sourcing Are Critical to Digital Business Success"

"Business Outcomes, Differentiation and Performance Drive Bimodal Adaptive Sourcing Decisions"

"Create Great Software Using Agile Methodologies"

"Big Change Efforts Need an Agile Business Transformation Approach"

"How to Keep Agile Projects on Time and on Budget"

Evidence
1Gartner's IT Key Metrics data (see "IT Key Metrics Data 2015: Key Applications Measures: Project
Measures: Multiyear") indicates that, in 2010, 14% of development projects were done in an agile
manner, but this grew to 22% by 2014.

2 Over the past 18 months, Gartner analysts have addressed agile sourcing in more than 300
inquiries, with a quarterly growth of between 10% and 20%.

3Gartner's IT Key Metrics data also shows that 48% of all development projects are still done in a
waterfall manner.

4 For more information, see the "Manifesto for Agile Software Development."

5 For example, see "Bird & Bird & Contracting for Agile Software Development Projects."

6 See CoActivate's Agile Contracts page.

7 See J. Sutherland, "Agile Contracts: Money for Nothing and Change for Free."

8See M. Caine, "Money for Nothing & Change for Free," M.C. Partners & Associates, 17 October
2011.

Page 12 of 14 Gartner, Inc. | G00280983

 9See W. Kash, "GSA, 18F Award First Series of Agile Software Contracts," FedScoop, 28 August
2015.

Note 1 Agile Software Development

Gartner defines "agile software development" as an umbrella term for iterative development
methodologies that enable frequent delivery cycles, close business involvement, responsiveness to
change and collaborative team working. Examples include Scrum, Extreme Programming (XP), Agile
Unified Process, feature-driven development, test-driven development, kanban development and
Scaled Agile Framework (SAFe).

More on This Topic

This is part of two in-depth collections of research. See the collections:

■ A Practical Guide to Bimodal Adaptive Sourcing Research

■ Outsourcing Contract Research Index — Contracts Articles and Attachments

Gartner, Inc. | G00280983 Page 13 of 14

 GARTNER HEADQUARTERS

Corporate Headquarters
56 Top Gallant Road
Stamford, CT 06902-7700
USA
+1 203 964 0096

Regional Headquarters
AUSTRALIA
BRAZIL
JAPAN
UNITED KINGDOM

For a complete list of worldwide locations,

visit http://www.gartner.com/technology/about.jsp

© 2015 Gartner, Inc. and/or its affiliates. All rights reserved. Gartner is a registered trademark of Gartner, Inc. or its affiliates. This
publication may not be reproduced or distributed in any form without Gartner’s prior written permission. If you are authorized to access
this publication, your use of it is subject to the Usage Guidelines for Gartner Services posted on gartner.com. The information contained
in this publication has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy,
completeness or adequacy of such information and shall have no liability for errors, omissions or inadequacies in such information. This
publication consists of the opinions of Gartner’s research organization and should not be construed as statements of fact. The opinions
expressed herein are subject to change without notice. Although Gartner research may include a discussion of related legal issues,
Gartner does not provide legal advice or services and its research should not be construed or used as such. Gartner is a public company,
and its shareholders may include firms and funds that have financial interests in entities covered in Gartner research. Gartner’s Board of
Directors may include senior managers of these firms or funds. Gartner research is produced independently by its research organization
without input or influence from these firms, funds or their managers. For further information on the independence and integrity of Gartner
research, see “Guiding Principles on Independence and Objectivity.”

Page 14 of 14 Gartner, Inc. | G00280983