This document provides guidance on building agile contracts. It emphasizes focusing on problems rather than past practices, designing contracts that encourage cooperation between parties, and prioritizing early learning through an experimental process. The key principles are to exploit early information by getting started quickly, minimize the costs of learning so rational decisions can be made, and use an iterative learning cycle of discovery, conceptualization, execution, and assessment to progressively build understanding through experiments and adapt as needed. The overall goal is for contracts to support agile approaches that can evolve based on new information rather than trying to predict and design for all eventualities up front.

1. How to build an
agile contract
some steps to get you thinking in
the right way
• Martin Kearns
• 25th Apr 2016

2. What
problem
do
you
want
to
focus
on

3. Incremental
change
will
not
be
enough
as
we
enter
this
new
era
of
agile
and
scrum
in
the
corporate
world.

4. Complete
Exercise
ASAP
What
does
vendor
management
/
your
business
want
from
a
contractual
engagement?
What
is
preven:ng
them
and
you
from
achieving
their
goal?
•
•
•
•
•
•
•
•
•
•

5. It
is
hard
or
maybe
even
impossible
to
extract,
codify
and
transfer
past
knowledge
in
a
way
that
makes
sense
outside
it’s
original
seCng
The
only
way
to
gain
such
knowledge
is
via
an
incremental
process
of
learning
by
pracEce
Projects
have
to
discover
their
own
way
Place
less
emphasis
on
best
pracEce

6. You
can
never
direct
a
living
system,
you
can
only
disturb
it
Maturana
+
Varela
“
The
Tree
of
Knowledge:
The
Biological
Roots
of
Human
Understanding
1992”
A
system
will
only
be
disturbed
by
informaEon
based
on
what
is
going
on
inside
the
organisaEon

7. We
really
need
to
shake
this
place
up!
Order
(Date,
Cost,
Time)
is
be[er
than
deep
complexity
regardless
of
informaEon
lost
It’s
MarEn
Time
NOT
!!!!!!!!!!!!!!!
Our
minds
incline
toward
the
instant
and
the
obvious
(Habit)
under
a
false
pretense
that
it
will
help
in
our
own
survival

8. Be
wary
of
well-­‐walked
paths
Once
we
know
something,
that
knowledge
makes
it
nearly
impossible
to
remember
not
knowing.
We
become
a
prisoner
to
our
tacit
experience.
Agile
contracts
are
less
about
designing
to
get
it
right
first
Eme
and
more
on
learning
and
responding
to
new
informaEon
as
it
emerges
within
the
lifecycle
of
a
project
/
engagement

9. Name
the
enemy
Meaning
of
so<ware
So`ware
means
a
right,
including
a
licence,
to
use
so`ware.
Expenditure
on
so`ware
includes
expenditure
you
incur
on
acquiring
or
developing
so`ware
or
in
having
another
person
develop
so`ware
principally
for
you
to
use
to
perform
the
funcEons
for
which
you
acquired
or
developed
the
so`ware.
Expenditure
in
relaEon
to
so`ware
projects
is
capitalised
and
depreciated
from
the
:me
you
use
the
so<ware
or
install
it
ready
for
use.
You
can’t
capitalise
a
fic::ous
Business
Case
and/or
a
Business
Requirements
Document
and/or
the
effort
you
place
into
wri:ng
a
crap
contract.
…..
End
of
story
h[ps://www.ato.gov.au/Forms/Guide-­‐to-­‐
depreciaEon-­‐2001/?page=24

10. Construct
co-­‐opera:on
into
the
contract
The
more
important
thing
is
that
the
contract
represents
the
intenEon,
expected
behaviours
and
accountability
to
the
approach.
The
trick
is
to
encourage
co-­‐
operaEon,
by
making
sure
there
is
the
right
pressure
to
encourage
parEes
to
reciprocate.

11. Principle
1.
Exploit
early
informaEon
by
front-­‐loading
the
process
The
pebbles
of
past
failures
grows
heavier
the
longer
you
keep
carrying
them
on
your
shoulders

12. Design
in
the
price-­‐point
for
learning
Time
Minimise
the
cost
of
learning
so
that
emoEons
can
be
controlled
and
raEonal
decision
making
is
the
norm
Value / $
cost
Pay to learn
The
ability
to
iterate
is
an
economical
decision.
Where
feedback
is
seen
to
shape
an
outcome
through
a)
Re-­‐enforcing
b)
AdapEng
c)
Serendipity
d)
Failing
e)
PivoEng
Iterate
Acquisition of
knowledge
Prioritize on
early value
Re-purpose
Funding
learning
demonstrable
value
Incremental
Min. viable
project

13. An
Experimental
–
Learning
Cycle
STEP
4
–
Assess
Carefully
assess
the
tangible
evidence
of
the
sprint
and
determine
whether
to
Pivot
/
Fail
/
Persevere
/
Pause
Develop
understanding
of
cause
and
effect
STEP
1
-­‐
Discover
Run
workshops
where
focus
is
on
refining
concepts
through
idenEfying
new
informaEon
/
causaEon
Observe
risk
profile
STEP
2
-­‐
Conceptualise
Build
the
hypothesis
on
what
knowledge
is
required
to
assess
confidence
and
the
desire
to
proceed
Prepare
test
environment
STEP
3
-­‐
Execute
Use
sprints
to
prove
/
disprove
project
assumpEons
and
the
cohesiveness
of
the
team
Work
purposefully
Learning
by
Experimenta:on
Via
a
cross-­‐func:onal
team

14. Step
1
–
Designing
your
process
of
discovery
STEP
1
-­‐
Discover
Run
workshops
where
focus
is
on
refining
concepts
through
idenEfying
new
InformaEon
/
causaEon
Observe
risk
profile
Discovery
requires
a
willingness
to
risk,
or
admit,
not
knowing
when
we
confront
directly
the
full
weight
our
confusion
or
dilemma
we
are
facing.

15. We
need
to
broaden
our
perspecEve
Early
sprints
encompass
project
experimentaEon,
where
understanding
what
works
and
does
not
work
are
of
equal
importance
for
learning.

16. Principle
2:
The
definiEon
of
done
is
a
strategic
decision
Roles / Functions
Infrastructure
Continuous
Integration
Dev P.C.
Continuous
Delivery
Predictive
Analytics
Iterative
Development
Digital
Enabled
SME in team
no automation
TDD/Build
server
We
must
engineer
the
removal
of
interfaces
between
funcEonal
groups
in
order
to
speed
up
the
process
of
team
learning.

17. TesEng
the
landscape
©
SQS
So`ware
Quality
Systems
Ireland
|
Title
of
the
PresentaEon
|
February
2013
|
Business
Shared Services
IT
Shared
Understanding
Incremental
Value
Demonstrable
Value
Empirical
Evidence
By
working
to
a
shared
“definiEon
of
done”
we
have
the
ability
to
test
the
beliefs
around
collecEve
responsibility,
culture
and
required
behaviors
to
achieve
success.
Learning increases linked cause and effect without
the normal organisation factors that obscure our
ability to commit to an outcome.
Done

18. Outline
a
definiEon
of
done
for
your
scenario
Roles / Functions
Infrastructure

19. Step
2
–
Engineer
rapid
feedback
to
shape
ideas
by
re-­‐
inforcing,
modifying
or
complemenEng
exisEng
knowledge
Retaining
cogniEve
diversity
is
a
required
capability
within
teams
to
allow
differenEaEon,
permiCng
the
emergence
of
new
thinking
and
new
realisaEons
of
what
is
possible.
STEP
2
-­‐
Conceptualise
Build
the
hypothesis
on
what
knowledge
is
required
to
assess
confidence
and
the
desire
to
proceed.
Prepare
test
environment.

20. Principle
3:
Create
a
hypothesis
to
generate
variables
of
interest

21. Steer
the
direcEon
to
what
and
where
you
wish
to
learn
Regardless of what backlog items
are delivered the culture and
capability of the team will be
demonstrated.
Experimentation
Degree of
intervention
Activity
Description
High
Some
Low
Exploration
Observation
A focus on interface and technical
functionality to assess feasibility of
the intended solution exceeds
behavioral concerns.
Regardless on what backlog items
are delivered the culture and
capability of the team will be
demonstrated.

23. Set
your
hypothesis
NOW!
No
I
won’t
bring
back
that
other
slide.
The
learning
objecEve
is
for
you
to
create
the
focused
language
required
to
get
the
desired
behavior
and
purpose
across
to
others.

25. Step
3
–
Test
intent
against
the
behaviours
and
velocity
achieved
via
MVP
Sprints
Provide
the
rapid
feedback
necessary
to
shape
behavior,
process
and
soluEons
by
reinforcing,
modifying
or
complemenEng
exisEng
knowledge.
STEP
3
-­‐
Execute
Use
sprints
to
prove
/
disprove
project
assumpEons
and
the
cohesiveness
of
the
team.
Work
Purposefully.

26. Process
and
roles
limit
the
impact
that
technology
advancement
can
provide
through
excessive
organisaEon
interfaces
(gates)
and
normalised
behaviors
(roles)
Principle
4:
Enable
the
viability
and
resilience
of
systems
to
become
purposeful

27. The
intent
of
M.V.P.
informaEon
is
to
off-­‐balance
norms
between
two
parEes
and
open
itself
to
new
and
more
meaningful
conversaEon
“Stretch
to
fit
“

29. By
moving
away
from
command
and
control
to
one
of
“autonomy
to
outcome”
you
create
a
self-­‐
determinisEc
system.
The
gap
between
raEonal
and
behavioral
viewpoints
can
spell
the
difference
between
project
success
and
failure.
Focus
on
the
individual
integrity

30. OrganisaEonal
norm
can
impede
adapEon
&
arEculate
principles
as
a
form
of
control
Compliance
Externalisa:on
Internalisa:on
Conformance
to
principle
Explicit
Prac:ces
Educa:on
Collec:vely
responsible
Self
determined
Behavioral
norm
Create
an
agreed
set
of
fundamental
truths
around
a
project
that
are
the
foundaEons
for
system
belief,
individual
intuiEon
and
decision
making.

31. Values Principles Practices Methods
• New information will be identified and valued when change is seen
as a necessity for preservation and/or creativity
• Maintain a higher sense of purpose within the team
• People must be empowered to make their own decision as to “How”
they can achieve a goal
• A team must consist of all the skills needed to achieve the
“Definition of Done”
• Team takes collective responsibility for their processes and outcomes
My
Scrum
Principles

32. Define
some
control/common
principles
for
the
engagement
you
have
defined
You
have
guessed
it,
I
am
not
going
to
share
the
previous
slide
-­‐
work
on
your
own
language.
Try
to
see
how
you
can
explicitly
state
the
expected
behavior
of
two
parEes
into
a
common/shared
understanding
of
how
value
is
created.

33. STEP
4
–
Assess
Carefully
assess
the
tangible
evidence
of
the
sprint
and
determine
whether
to
Pivot
/
Fail
/
Persevere
/
Pause
Develop
understanding
of
cause
and
effect
Provide
the
rapid
feedback
necessary
to
shape
behavior,
process
and
soluEons
by
reinforcing,
modifying
or
complemenEng
exisEng
Knowledge.
Step
4
–
test
intent
against
the
behaviours
and
velocity
achieved
via
MVP
sprints

34. The
iteraEon
allows
for
any
system
variable
to
be
created,
disrupted,
corrected
&
destroyed
by
creaEng
pa[erns
at
scale
that
make
contract
levers
tangible
and
used.
Principle
5:
You
must
prepare
and
sustain
the
required
energy
to
observe
and
measure
To see patterns, we
need to step back
from the problem and
gain perspective
System fractals are
created as individuals
exercise both
freedom and
responsibility towards
some simple rules.

35. Create
guiding
values
to
outcome
What
we
don’t
want
in
a
contract:
People
use
their
shared
sense
of
idenEty
to
maximise
their
unique
contribuEon
to
project
success.
Your
responsible
for
How
I
will
decide
to
punish
-­‐-­‐-­‐-­‐-­‐
-­‐-­‐-­‐-­‐-­‐
-­‐-­‐-­‐-­‐-­‐
Deliverables
Output
Input
We
focus
on
achieving
a
shared
outcome
CollecEve
Responsibility

36. IteraEons
help
small
differences
amplify
into
powerful
and
unpredicted
system
variables
in
non-­‐linear
systems
that
no
model
or
methodology
could
achieve
-­‐
the
system
feeds
back
onto
itself
through
the
learning
cycle.
Don‘t
ever
forget
what
an
iteraEon
is
for

37. Some
simple
but
powerful
stories
Assessing
the
levels
of
maturity
being
achieve
with
the
backlog
over
Eme
and
a
commitment
to
a
fixed
deliverable.
Visualizing
the
movements
within
a
product
backlog
with
velocity
and
a
predicted
trajectory
of
progress
/
compleEon.

38. Making
contract
deviaEons
visible
!

39. Produce
some
visualisaEons
of
a
known
problem
Feel
free
to
reuse
some
of
what
you
have
learnt
today.
However,
if
you
want
to
really
impress
me,
come
up
with
some
new
ideas
on
how
you
can
influence
your
systems
through
new
forms
of
measurement
and
visualisaEon.

40. Individual
raEonality
leads
to
a
worse
outcome
for
both
than
what
is
possible
Project
variation
Change
request
Over
spend
Leads to
Best price
Recover
Unhappy
customers
Prisoners
Dilemma
–
players
cannot
get
out
of
the
dilemma
by
taking
turns
exploiEng
one
another.
The
struggle
to
establish
one’s
reputaEon
can
be
a
major
feature
of
intense
conflicts.

41. Shared
Experience
Hands
On
ConstrucEve
Feedback
Transparency
Shared
Success
Stories
Strong
Metric
Legal
Contract
Co-­‐created
AdapEng
to
Change
Embedded
Team
Evidence
Based
CollaboraEve
Framework
CollecEve
Responsibility
Partnership
In
any
partnership,
we
recognise
that
we
all
have
know-­‐how,
skills
and
insights
to
offer,
and
we
all
have
the
opportunity
to
learn
and
grow
from
one
another.
This
is
why
we
know
that
we
will
be
co-­‐creaEng
with
you
the
approaches
that
work
for
the
ATO
Enlarge
the
shadow
of
the
future
via
Partnering
When
the
probability
to
work
with
one
another
is
high,
co-­‐
operaEon
based
on
reciprocity
is
high
bringing
stability
to
future
delivery.

42. An
effecEve
strategy
must
be
able
to
take
into
account
the
history
of
iteraEon
/
interacEon
to
far
MVP
Discount
parameter
MMF
W
Enable multiple exit
clauses
With
the
opportunity
for
future
sprints
/
interacEons
co-­‐operaEon
can
emerge
from
a
system.
Mutual
co-­‐operaEon
depends
on
their
being
a
good
chance
of
a
conEnuing
relaEonship,
as
measured
my
the
size
of
w.
Co-­‐operaEon
can
be
accelerated
by
making
interacEons
more
frequent
and
the
ability
to
recognise
defecEon
more
readily.

45. Dialogue
Real
dialogue
is
where
two
or
more
parEes
become
willing
to
suspend
their
certainty
in
each
others
presence.
David
Bohm
My
hope
is
that
I
have
opened
a
door
through
which
you
can
walk
into
a
greater
understanding
how
contracts
can
be
framed.