An overview of agile reasoning and agile contracts specifically

1. ©2010TietoCorporation
Devil&details
in Agile Contracts
Cristiano Sadun
Manager
Tieto, Software Solutions
cristiano.sadun@tieto.com

2. Outline
• Agile methods- overview
• Why agile contracts?
• Perspectives
• What do we agree upon?
• Pitfalls
• Standard contracts
• Real world cases
• Q&A

3. ©2010TietoCorporation
Agile methods
Why, and what does it mean?

4. Agile methods – why, and what does it mean?
1994:
16%
of IT projects are
“successful”(*)
(53% challenged, 31% failed)
(*) Chaos report, Standish Group, 1994

5. Agile methods – why, and what does it mean?
Waterfall (Royce, 1970)

6. Agile methods – why, and what does it mean?
0.5+ years
time
is the challenge
t
Requirements Design Implementation Test
Requirements
Design Implementation Test
Requirements
Design Implementation Test
Requirements
Design Implementation Test
Change over
in many modern environments

7. Agile methods – why, and what does it mean?
“An ounce of prevention is worth a pound of cure”

8. Agile methods – why, and what does it mean?
Running a software project:
piloting a plane vs. driving a car

9. Agile methods – why, and what does it mean?
• Agile methods are appropriate for
contexts where external factors or
changes weight more than internal:
• Customer-related projects
• Market-related projects
• Changing or unknown environmental
conditions (laws, regulations, cross country)
• Long-running ( > 6 months)
• The longer the project/effort, the most
likely are changes along the way

10. Agile methods – why, and what does it mean?
Introducing: feedback!
• Projects are run in short iterations,
with frequent re-planning
• Scope is often not pre-fixed:
• Scope changes (and their cost) are agreed
at the start of each iteration..
• ..in collaboration with the customer..
• ..with demonstrations at the end of each
iteration..
• .. and with formalized sign-offs.
• Focus on responding to change
over following a plan.

11. © 2010 Tieto Corporation
Agile methods – SCRUM, a popular method
• Iteration = “Sprint” (4-5 weeks) (is time boxed)
• Each thing to realize = “User Story” (must be simple and testable)
• Difficulty of the thing = “Complexity” (measured in “Story Points”)
• Each thing to realize must have “Test conditions”
• Things we may want to realize = “Product Backlog”
• Things to will realize in the next iteration = “Sprint Backlog”
• Each completed, working story is said to be “Done”
• Every sprint is started with a “Planning meeting”
• Concluded with a “Review meeting”
• Things are supposed to be production ready after every
sprint

12. ©2010TietoCorporation
Agile contracts

13. Why agile contracts?
Agile projects
(and project management)
≠
Agile agreements

14. Why agile contracts?
Traditional agreement
+
Agile project management
=
Disaster

15. • Based on fixed requirements, agreed
project plan
• Expects major, infrequent milestones at
given dates
• Regulates customer interaction limited to
steering groups or PM
• Progress reporting based on completion
percentages
• Separate change management procedure
with change orders
• Consequent payment schedule
• Consequent penalties (or bonuses)
Why agile contracts?
A “traditional” contract supports

16. An agile contract need to support
• Commitment from the customer(s) to actively
steer the project scope via a given process;
• Many, smaller deliveries;
• Mechanisms for agreeing, signing off and
crediting the work done;
• Mechanisms to stop the iterations;
• Commitment to describe the scope in a
testable way
• Commitment to “feed” the delivery machine
with enough scope
• Consequent payment schedules;
• Consequent steering and penalties/bonuses
clauses.
Why agile contracts?

17. © 2010 Tieto Corporation
Why agile contracts?
Lower risk by continuous agreement

18. © 2010 Tieto Corporation
Why agile contracts?
Lower risk by continuous agreement

19. Perspectives
• Agile methods are used by:
• Software Houses
• IT Departments
• IT Services Suppliers
• Agile projects requires agile contracts
mainly in IT Supplier/Buyer context
• ..or in SLA based IT operations.
When independent parties
need to agree on the process
for defining the right scope
along the execution.

20. What do we agree upon?
• Traditionally, scope is given as a set of
requirements + a compliance list
• With agile processes, detailed scope is
subject to continuous adjustment
and re-agreement, starting from an
initial common understanding
• We still need to have a base for
estimations, performance monitoring,
evaluation of results and final
acceptance

21. What do we agree upon?
• Traditionally, scope is given as a set of
requirements + a compliance list
• With agile processes, detailed scope is
subject to continuous adjustment
and re-agreement, starting from an
initial common understanding
• We still need to have a base for
estimations, performance monitoring,
evaluation of results and final
acceptance

22. What do we agree upon?
• An initial scope (or “baseline scope”) provides
basis for estimation and pricing
• Items in the scope must be testable
• The supplier keeps the delivery
responsibility: i.e. there are clear acceptance
criteria and liabilities for not meeting them
• A process to monitor progress and ensure
incremental acceptance is achieved
(i.e. units of work “done”, “in production”, “signed off”)
• There can still be a set of milestones and
delivery dates
• There can be an agreement on the average
rate of delivery

23. Examples
• Fixed price per Story Point
• Fixed price per Story Point +
time&material
• Multimodel: fixed price phases, target
price or time&material phases
• Sequence of Sprints
• Sequence of Sprints, with ramp-up
and ramp-down
• Incremental acceptance with micro-
milestones

24. Pitfalls
• General terms and conditions&templates
• Are usually thought with traditional methods in mind, and so are
“template” contracts in frame agreements: language, wording,
expectations on how the project is run
• Things that traditionally are in a contract, but
shouldn’t
• Commitment to a compliance list
• Commitment to a detailed delivery scope
• A detailed activity plan
• Milestones over more than a month
• Things that traditionally aren’t in a contract, but
should:
• Commitment by the customer to allocate resources to the process
• Agreement to follow a given process,(sign-offs, acceptance
progress)
• Agreement to verify the delivery during the project
• Clear responsibility of the steering group to sign-off progress
• Allocation of responsibility for “feeding” the
agile process
• Commitment to produce testable
requirements/stories

25. Unchanged
• Agreement on a delivery/project closing date
• At the date, the pre-agreed units of work should have
been produced and accepted; errors in the delivery must
stay in the agreed range.
• “Delivery responsibility”/Acceptance matrix
• The delivery must work as a whole.
• Escalation mechanisms
• The process depends on continuous agreement..
which may not always be there
• Anything not impacted from continuous scope
adjustment

26. Standard contracts
• PS 2000 – a mix agile/traditional
• Based on requirement analysis / solution
description / construction / acceptance
• Close customer collaboration (joing goordination
group)
• Uncertainty matrix / uncertainty increment
• Allows partial deliveries
• IDIQ contracts
(Indefinite Delivery/Indefinite Quantity)
• Range based agreements
• Iterations sequence contracts
• Sequence of fixed-capacity iterations
with stop and rampdown triggers
Early years: not many exist, and the ones which do aren’t perfect yet

27. Real world cases (Tieto)
• Software product development
• Tieto Energy Components (Scrum),
2006 - present
• IT Departments
• NetCom (Norway) Teknisk/IT
(Scrum, Lean), 2006-present
• Contracted delivery projects
• Salsa project (Scrum),
2007-2008, (Scrum/Lean) 2010

28. Summary
• Three things to remember:
• Agile projects should not be run under
traditional contracts;
• Agile contract place emphasis on follow up
of a given process (formal signoffs etc) for
frequent mutual agreement between the
parties
• The final delivery can be very different
from the initial scope. Traceability is critical.

29. ©2010TietoCorporation
Q&A

30. ©2010TietoCorporation