Agile ContractsGet More Flexibility with Agile Contracts

Agile principles emphasize accommodating change, whereas the underlying tenant of fixed price

contracts is to fix scope. Given this duality, Time and Materials contracts work best for any

Agile implementation. Nevertheless, many clients prefer fixed price contracts in Agile because

of the security it provides them. This eBook highlights the differences between contracting

for traditional and Agile methodologies, highlights the different types of Agile contracts, and

tries to establish a middle ground between the two opposing ideologies of fixed-price-fixed-

scope contracts and Agile contracts. It also throws light on some financial and organizational

implications of scaling Agile across an enterprise.

TABLE OF CONTENTS

OVERVIEW

WHAT IS AN AGILE CONTRACT?

HOW IS AN AGILE CONTRACT DIFFERENT FROM A TRADITIONAL CONTRACT?

EXPECTATIONS FROM AN AGILE CONTRACT

TYPES OF AGILE CONTRACTS

NEED FOR AGILE FIXED PRICE CONTRACTS

WHEN CAN I USE FP CONTRACTS IN AGILE

DIFFICULTY IN IMPLEMENTING AGILE FIXED PRICE CONTRACTS

PREREQUISITES FOR A FP CONTRACT

TYPES OF AGILE FIXED PRICE CONTRACTS

RESEARCH FINDINGS

ADDITIONAL ASPECTS OF AGILE FP CONTRACTS

MANAGED SERVICES IN AGILE

ATOS SYNTEL FIXED PRICE MODELS

GUIDELINES

SCALING AN AGILE CONTRACTING MODEL - THE AGILE FINANCIAL MANAGEMENT MODEL

REFERENCES

© 2 0 1 8 S Y N T E L , I N C .

123456789

1011121314151617

Overview

What is an Agile contract?

An Agile contract is a contractual model which states that customers and suppliers of IT projects need to create software by using different Agile techniques. An Agile contract consists of an initial test phase. After the test phase, the budget, due date, and the manner of navigating the scope within the framework is decided.

How is an Agile contract different from a traditional contract?

• The difference between Agile and traditional methodologies like Waterfall can be explained by the iron triangle, which elucidates thecorrelation between cost, scope, and time. A project has a set of deliverables which need to be delivered within a budget and a specific timeperiod. Project management aims to provide maximum output by optimally utilizing time and cost resources. A change in any of the three(time, cost, and scope) variables forces a change in at least one of the others. Traditional and Agile methodologies vary in the variables theychoose to keep constant. Agile accommodates scope changes while keeping time and cost fixed, whereas, traditional methodologies laysemphasis on fixing the deliverables and adjusting time and cost to meet the scope.

• Using traditional contracts may deprive the company from reaping the benefits of Agile development.• In Agile we need to embrace the idea that estimates are not exactimates.

Conventional contracts Agile contractsFocuses on own interests Focuses on a win-win situation

Encourages loophole finding Focuses on relations

Features are defined upfront Features are committed before a sprint

Assumes that the contract is full proof by virtue of the fixed approach to be followed and blames the vendor for failures

No blame game. Flexibility is incorporated to address failures ef-ficiently and cost-effectively

Does not define how a project should be run on a day-to-day basis Defines roles, communications, and documentation

Focus is on legal remediation after project failure Ensures transparency to avert failures

Goals are technical objectives Goals are business objectives

Challenges in applying traditional contract principles to Agile

Solution

Specifying every functionality of the system and having a fixed budget

1. Good estimations on the price, scope, and deadline2. Just have a basic idea of how the software should work and how

much money you are willing to spend on it3. Exclude something for each added functionality

Lack of customer involvement Customer involvement, roles, and contributions specified in contract.

Bureaucratic change management process If the change is within scope, it should be handled without any further development costs or delays, but if it is not, the contract needs to be revised.

Scope

ScopeIron Triangle

Time

Time

Cost

Cost

(Deliverables, Quality, and Value)

Inverted Iron Triangle

Expectations from an Agile contract

• It should not stifle the ability to collaborate.• Must haves:

• Commitment - In terms of the amount of output and not its details.• Feature change - There should be a provision to change the features without cumbersome change control mechanisms. Features to

be built should only be committed to at the start of each iteration, and no changes in features should be made during a sprint.• Metrics - To track feature cycle time (time from the conception to delivery of a feature).• The contract should clearly state where customer needs to contribute for the success of the Agile approach.• Roles - The key Agile roles should be detailed and terms related to them mentioned.• Product Vision• Sprint duration• Definition of done - The contract should outline responsibility for incomplete items in an iteration.

Types of Agile contracts

• Fixed price • T&M - Time-and-material is favorable in small projects, where the client and vendor have a trusted working relationship.• Target-price contracts - Risk of overruns is shared between client and vendor. The contract outlines an effort target, a negotiated profit, and

a deadline. If the effort exceeds the target, the customer pays an agreed upon percentage of the exceeded cost. If the project is delivered byusing less than the targeted effort, the vendor receives a fixed percentage of the saved costs. This contract can also be set up with minimumand maximum effort hours that can be charged. The scope should be estimated along with some buffer. If scope exceeds the estimated scopedue to clarifications or fixes, it can be charged without increasing the profit. If a new requirement is added the profit needs to be renegotiated.

• Cost plus contracts - The vendor is paid for all the costs plus an additional fee which includes the profit.

Feature Fixed price T&M Target price

Scope Fixed as to the maximum number of story points that will be delivered

Variable Variable

Time Fixed Variable Fixed but can be extended

Quality May be compromised Generally good Generally maintained

Cost Fixed Variable Fixed

Billing cycle Per sprint/iteration/milestone/release Per sprint Per sprint/iteration/milestone/release

Resources At the discretion of the vendor Based on client demand

At the discretion of the vendor

Change control Minimal NA Minimal

Termination clauses Client should be able to exit anytime Client can exit anytime

Provision should be made for anytime exit

Need for Agile Fixed Price (FP) contracts

• In a bidding based vendor selection process, time, scope, and cost help take a decision.• In traditional fixed price contracts, the product might already be obsolete by the time it reaches the market.• Suing the vendor for a botched delivery cannot do any good to the customer, if they really needs the software at that time as the non-

delivery losses might be substantial. Also, the cost assurance and control of a traditional fixed price contract is only a farce as many fixedprice contracts exceed the budgets.

© 2 0 1 8 S Y N T E L , I N C .

When can I use FP contracts in Agile?

• When the domain and technology are known.• When the vendor has experience in handling large projects. Otherwise FP contracts are more suitable for small projects.• When the vendor has experience in handling large teams. Otherwise FP contracts are suitable for small teams.

Difficulty in implementing Agile Fixed price contracts

• The very purpose of Agile is to accommodate changing requirements. The basic rule of FP contracts is to fix price, scope, and time. Thesetwo ideologies are at loggerheads with each other.

• These conflicting ideas may result in poor quality deliverables compromising the very reason of undertaking Agile.• If the team is very efficient, the vendor may make more profits, but if the risks are not factored at the outset, there is a chance that the

vendor may lose money.• To make FP contracts work in Agile, we need to modify the concepts of both to make them meet somewhere in the middle.

Prerequisites for a FP contract

• Have a good idea of the team’s velocity and other unknown dynamics before committing. Initially commit for a few sprints and based onresults commit long term.

• Steps:1. After identifying a broad goal and legal framework for a project, an epic describing the entire project is chosen and broken down into

several varied user stories which can be used as reference user stories.2. Story points are assigned to the user stories and expenses are estimated based on this, taking into consideration business risk. These

estimates are verified empirically, and only then is a legally binding contract implemented.3. The empirical phase can last for 2-5 sprints each of two weeks duration. This phase also helps arrive at the risk sharing agreement.4. An independent IT consultant can be appointed for governance.5. Projects similar to past projects can do away with the empirical assessment phase.

• Definition of done, iterations, and releases should be discussed with the client.

Types of Agile FP contracts

Different approaches have to be adopted for every project based on clients’ understanding of Agile concepts.1. Fixed price, variable scope: We do not need to compromise on product quality but the scope needs to be prioritized. Defines the conditions

under which changes are permissible.2. Fixed price, fixed scope: In this case the only variable to tamper around with is quality; which has also been made full proof by putting in

place a robust definition of done.• Having said that, it is possible to fix price and scope for one sprint and renegotiate scope once the sprint is over and the client has seen

the built software.• When to use

• When the high level requirements are clear and no major changes are expected midway through development.• When there is a fixed time to market.

• The maximum number of story points to be delivered in a fixed number of sprints can be fixed based on estimations.3. Fixed price per story point: Here the client pays only for the story points that meet the acceptance criteria.

• When to use• Requirements are opaque at the beginning of the project and will evolve as project progresses.• Dependency on third party for capturing all requirements, for example, government policies.

• Once we have estimated the total story points, we estimate the velocity of the team. To estimate velocity, we need to consider pastperformances, availability of a client (the lesser the time the client is available, the slower is the velocity), and the number of activities wehave to do in the iteration. We also consider the number of days for sprint planning, retrospective, and demo.

© 2 0 1 8 S Y N T E L , I N C .

• Some formulae:• Total no. of story points/velocity of the team = time to complete. The relation between team size and velocity is not linear.• Velocity * time = No. of story points that can be completed. The client has to prioritize and decide what he wants to forego.

• Money = man hours * per unit man hour cost.• The client can swap stories with equal no. of story points.

4. Incentivized price per story point: Pay a higher per hour rate for accelerated completion of work and a lesser rate for delayed completion.5. Fixed price per iteration: Fixed team to deliver the sprint backlog in a sprint. A drawback is that the project vision may be replaced by

iteration vision and result in technical debt.6. Fixed price per release.

Research findings

adVANTAGE’ contracting model by Matthias Book et al. (2012): An eclectic mix of T&M and fixed price models. It consists of a series of steps. High level requirements in the form of user stories are collected and a budget figure is arrived at in the first step (called Step 0). This is used as a reference figure in all iterations for billing. Three steps to follow are iterated. User stories can be added, eliminated, or prioritized by the customer, considering own budget and vendor’s quotation, in step 1. A decision is then made on which user stories should be implemented in the next sprint. Step 2 is the sprint implementation. The user stories are detailed at the beginning of each sprint. The sprint is billed in step 3. Effort price is equal to the product of effort put in and vendors’ hourly/daily rate. Costs for additional tasks like story grooming and scrummaster’s tasks are also included as a lump sum amount. Example bill (only completed and accepted user stories are considered):

Sr. no. User story Estimated effort in person days Actual effort

1 User Story P 8 8

2 User Story Q 10 8

3 User Story R 5 4

4 User Story S 15 14

Total 38 34

Estimated cost (38 X $1000)Underspend (4 X $1000)Lump sum

$38000$4000$12000

Sprint bill $46000

If the actual effort exceeds estimations (overspend), the additional efforts are paid for at a lower rate. Uncompleted user stories can be moved to subsequent sprints or eliminated. These user stories will be considered as additional efforts and paid for at a lower rate. The customer can exit after any sprint.

Collaborative Agile Contracts by Thorup and Jensen (2009): Milestones are defined based on value and payment is made after completion of a milestone. The payment can be same for all milestones or can be different for each milestone. The following are defined:

• A description of the scope that serves as a vision statement• A 10-50% discounted hourly price than the one in a T&M contract• A milestone list. A milestone is considered completed, when the associated increment of the system is deployed at the customer’s site• A schedule for the project for reference, though this contract has no fixed deadline

The total cost has two components: the completion price (divided among the milestones based on their size) and the price per hour. The rela-tive weightage to the two is based on the intent. In a time pressed delivery, a high completion price is beneficial as it incentivizes the supplier to deliver quickly, to make higher profits. Inefficiency is eliminated by the hourly pay. In projects where delivery of all features is important, or where there is high uncertainty in the initial estimates, it is advisable to go for a high hourly price. This gives more flexibility to the customer because in fixed price contracts additional feature requests from the customer are not very welcomed by the supplier since they require addi-tional effort without extra pay. A high hourly price motivates the vendor to keep an open attitude towards change.

Additional aspects of Agile FP contracts

• A cost range can be provided rather than a single figure.• It is possible to identify the probability and impact of potential risks, and the costs of mitigation.• From 10% (where risk is less) to 30% of the estimates can be considered as buffer to account for seen and unseen risks.• The project scope can be classified into must-haves and nice-to-haves.• Risks and profits are shared (additional expenses are divided).• Voluntary exit by either party at any stage is possible. The terms of exit are addressed in detail. Some of the available options are:

• Payment of a certain percentage of the leftover budget.• Assignment of a new contract equal to the leftover budget.

• Change control management: Should be used sparingly as they can cause the development team to lose focus and rhythm, thereby, increasingthe budget and time of the project producing unhappy customers. It is better to have Exchange requests.

Managed services in Agile

• The key here is to commit velocity increases in the Service Level Agreement (SLA).• The team gets paid for the actual number of user stories delivered and accepted.• There should be a core team and a flex team. The core team should consist of experienced people who do not change, whereas, flex resources

can be roped in whenever required.

Atos Syntel's FP models

• Prerequisite steps for Alternative Agile model:1. Identify technology landscape.2. Baseline effort metrics.3. Based on the project, technology identifies all possible tasks.4. Divide the tasks into HIGH/MEDIUM/LOW levels of complexity.5. Estimate the effort for each task based on its complexity.6. Effort should be estimated in story points for ease of use in sprint development. This will help to determine the number of story points

each user story will need to take. This will also allow the client and vendor teams to be in sync on the estimated time required for anyfunctionality change.

7. Approval of both client and Atos Syntel on the effort metrics.8. Decide estimated sprint velocity.9. Agreement on the story point hours from both parties.10. Define productive and non-productive efforts either within story points (as percentage or hours) or as story points.11. Define the sprint duration.12. Identify total team size.13. Estimate sprint velocity.14. Estimation example:

• Story point = 8 hours effort.• Weeks sprint will be used.• Team size is 8 resources including developers

and testers.• 0.5 story points on the first and 0.5 story points on the last day of sprint will be used in sprint planning and demo.• Assuming separate non-productive story points per sprint for estimating non-productive efforts. Non-productive efforts: Daily

meetings, defect resolution, etc. Out of the total of 72 story points, 64 story points (80%) of effort will be used in productive taskswhereas story points (10%) of effort will be used in non-productive tasks. Rest 10% effort will be in planning and demo efforts.

• Scrum master and business analyst are part of the scrum team, but their efforts are not considered for story points calculations.• Team velocity can be defined as 64 story points per sprint.

NOTE: Productive Efforts: Design, Coding, Documentation, Sprint Testing, etc.

© 2 0 1 8 S Y N T E L , I N C .

15. Atos Syntel currently uses two methods:• Pay per story point: Atos Syntel gets paid on sprint-to-sprint basis, based on total story points completed.

Example:Per story point payment is assumed to be $1000.Estimated velocity (i.e. story points) per sprint: 64Sprint backlog > 64 story points.Case 1: Completed story points: Estimated velocity Total story points delivered: 64 | Payment applicable: $64,000 Case 2: Completed story points > Estimated velocity Total story points delivered: 75 | Payment applicable: $75,000 Case 3: Completed story points < Estimated velocity Total story points delivered: 55 | Payment applicable: $55,000

• Fixed price model: Atos Syntel will be paid at the end of each milestone based on milestone success criteria.

Guidelines

Variable Recommendation

Size/Duration of project In a very big project, due to high initial uncertainty, a two phase contract, with fixed price for initial uncertain phase followed by T&M, should be followed. If scope is well defined, one can opt for fixed price projects.

Customer’s experience with Agile If there is a low customer experience with Agile, the contract should clearly define customer roles and responsibilities.

Trust If trust is established, T&M contracts are best.

Scaling an Agile contracting model - The Agile Financial Management

model

As an organization gets transformed into an Agile factory, the traditional financial model no longer holds good. Agile organizations need an Agile Financial Management model.

Traditional budgeting, cost accounting, and reporting instills counter productivity in an Agile organization.

Consider project which needs a total of 320 story points which needs to be completed in 2.5 months (5 sprints)

Story points : 320 Sprints : 5 Sprint Velocity : 64 Team Size : 8 Cost : Resources * Time

Identify majorfunctionalities or

user stories

Divide the current majorfunctionality into story pointswith appropriate complexityas per complexity guideline

Arrive at the total story pointsfor current scope, based on

estimation metric guideline

Include additional 10-15%story points to the total as bufferfor managing any requirement

changes without the needfor Change Order

Define number of sprintsavailable, based on project period

Identify the expected velocity per sprint(i.e. Total story points / total sprints)

Estimate team sizebased on sprint velocity

Arrive at totalSOW cost

Traditional cost accounting principles Agile principles

Long-term planning with frequent revisions No long-term planning needed

Values planning accuracy Allows for uncertainty

No room for overshooting budget Further investments are encouraged if initial feedback proves successful

Re-approval needed if there are changes due to delay or other causes

New items can be picked from the backlog for development if the time and budget is approved

The following changes may be needed:• Removal of project level cost control and instead budgeting deliverables• Projects should be prioritized and reprioritized in the backlog and the least number of resources should go to the least priority project• Encouraging transparency with planning uncertainties

References

• https://www.scrumalliance.org/community/articles/2014/march/good-bad-and-ugly-of-Agile-fixed-price-contracts• https://en.wikipedia.org/wiki/Agile_contracts• http://www.infoq.com/articles/Agile-team-fixed-price-contract• http://www.timecockpit.com/blog/2014/11/30/How-Fixed-Price-Contracts-and-Agile-Can-Go-Together• http://xpnl.Agilesystems.be/html/fixedpriceprojects.pdf• http://blog.trifork.com/2013/08/22/lessons-learned-how-to-do-scrum-in-a-fixed-price-project/• http://searchsoftwarequality.techtarget.com/tip/Agile-development-practices-Extending-agility-to-contracts• http://www.twobirds.com/~/media/PDFs/Brochures/Contracting%20for%20Agile%20software%20development%20projects.pdf• http://liacs.leidenuniv.nl/assets/Bachelorscripties/2012-2013-05ShiHaoZijdemans.pdf• http://www.leadingAgile.com/2010/01/replacing-the-iron-triangle-of-project-management/• https://www.scrumalliance.org/community/articles/2014/september/Agile-and-managed-services-can-they-co-exist#sthash.ColHJfx6.dpuf• http://www.google.co.in/url?sa=t&rct=j&q=&esrc=s&frm=1&source=web&cd=5&cad=rja&uact=8&ved=0CDYQFjAEahUKEwj99_vIrM

bHAhXHuRQKHdNlAOM&url=http%3A%2F%2Fsaiframeworkbalancer-762644628.us-east-1.elb.amazonaws.com%2F%3Fwpdmact%3Dprocess%26did%3DOTQuaG90bGluaw%3D%3D&ei=M3vdVb0Sx_NS08uBmA4&usg=AFQjCNERkMGSJzGQ7pVOcniTzHnPcYcHNg

Scope which definescustomer value add

This canbe changed

Schedule for arelease train is fixed

Cost for arelease train is fixed

about Us:

For more i n fo rma t ion , v i s i t us a t www.a tos-syn te l . ne t

Atos Syntel is a leading global provider of integrated information

technology and knowledge process services. Atos Syntel helps

global enterprises evolve the core by leveraging automation,

scaled agile and cloud platforms to build efficient application

development and management, testing and infrastructure

solutions. Our digital services enable companies to engage

customers, discover new insights through analytics, and create a

more connected enterprise through the internet of things. Our

"Customer for Life" philosophy builds collaborative partnerships

and creates long-term client value by investing in IP, solutions and

industry-focused delivery teams with deep domain knowledge.

To learn more, visit us at www.atos-syntel.net