agile contracting in the second decade of agility
TRANSCRIPT
Contracting for Agile Practices Contracting for Agile Benefits
MY BIO
• Practitioner, Consultant, Trainer
• Occasional CTO
• 25+ years in software
• 15+ years in “Agile”
MY HISTORY
• Independent ISV
• Multi-million dollar waterfall projects
• Military Simulations
• Internal Agile Teams
• Outsourced Agile Development
• Training / Coaching / Consulting
TRADITIONAL AGILE
Product Owner
ScrumMaster
Users
Stakeholders The
Team
OUTSOURCED AGILE
Product Owner
Users
Stakeholders
ScrumMaster
The Team
Moral Hazard
we’ve increased our Moral HazardWE CONTRACT BECAUSE
Because we outsourced our Software Development
WE INCREASED OUR MORAL HAZARD
Outsource our Software Development?SO WHY DID WE?
EXPERTISE
COST
RISK
THE TRADITIONAL ALGORITHM
goto Define Solutiongoto Quotegoto Plangoto Executegoto Complain
fork Set Objectives
ASSUMPTIONS & OBJECTIVES
• Objectives are disjoint from Definition
• Expertise in Definition is Separated from Expertise in Execution
• Goal of preparation is Completeness & Correctness of the Definition - creating a fungible commodity
• Goal of the Vendor Selection process is to find the cheapest supplier
• The Biggest Risk is not getting everything we asked for
ECONOMIC DRIVERS
• Time & money is spent on upfront analysis & contract negotiation
• which increases the cost of delay
• Plus transaction costs throughout the project
• Customers have to get a good deal
• Otherwise the Software probably wouldn’t be worth it…
THE FUNDAMENTAL ASSUMPTION
Is that we can describe what needs to be done so completely, that it doesn’t matter who does it
AND THAT BY DOING SOWe’ll get the hoped for outcomes
HOWEVER…
IF YOU DEFINE ONLY ONE WAY TO WIN
You’ve just created an infinite number of ways to fail
WHY THE TRADITIONAL APPROACHIs pre-disposed to failure
MAKING SENSE OF THE WORLD
WITH THE
Simple (The Known)
Complicated (The Knowable)
Ordered Dom
ainsU
nord
ered
Dom
ains
Disorder
Complex
Chaotic
Cause & Effect Obvious, predictable & repeatable
Cause & Effect Separated by space & time and/or requiring analysis or expertise
Cause & Effect Only coherent in retrospect, but not repeatable
Cause & Effect not perceivable
What strategies are effective in each
domain?
•Legitimate “Best Practice” •Standard Operating Procedures
•Analytical / Reductionist •“Current Good Practice(s)”
•Pattern management •Solutions emerge through co-evolution with agents
Simple
ComplicatedComplex
Chaotic
•Stability-focused intervention •Crisis management
Sense ➠ Categorise ➠ Respond
Sense ➠ Analyse ➠ Respond
Probe ➠ Sense ➠ Respond
Simple
ComplicatedComplex
Chaotic
Act ➠ Sense ➠ Respond
Domain Appropriate Command Structures
Simple
ComplicatedComplex
ChaoticStrong Central
Weak Distributed
Strong Central
Strong Distributed
Weak CentralStrong Distributed
Weak Central
Weak Distributed
TO SUM UP
• We can’t describe the solutions to Complex Problems in complete detail ahead of trying to solve them
• Our solutions can only co-evolve with the agents
• Which means it does matter who builds it
• Expertise not cost is the most important in vendor selection
(Stop demanding dumb people who don’t care)
The Analytical Reductionist techniques that create explicitly documented Defined Predictive “Waterfall Plans” work fine for simple
and complicated problems alike
Their “domain inauthenticity” however means that they will begin to fail completely as they encounter problems of increasing complexity
It’s not that we’re failing at Predictive Reductionist Techniques
They’re failing us
AGILE FRAMEWORKS
Produce better results because they implement
“Probe ➠ Sense ➠ Respond” loops.
UNLESSYou wrap your Agile in a domain
inauthentic wrapper
LIKE A TRADITIONAL CONTRACT
SO WHY DO WE CONTINUE TO CONTRACTIn such an inauthentic style?
REASON ONE
THE AWESOME THING ABOUT AGILE
Is that it’s so focused on Software
THE BIGGEST WEAKNESS OF AGILE
Is that it’s so focused on Software
When you say: “9 out of 10 Bushfires are caused by humans”
All I hear is: “There’s a Koala out there who knows how to use matches”
When we said:
“We are uncovering better ways of developing software.”
All they heard was: “I’m glad you admit that it’s all your fault”http://lasting-benefits.com/2014/05/31/a-conversation-with-the-agile-manifesto/
This never happens
This is how they expected Agile to work
THE RESULT• Software Development is treated as construction
• Definable & Predictable
• Much time will elapse before deliverables have value
• Payment cycles should be long
• Interim deliverables are close to irrelevant
• Early termination represents a crisis to be avoided
• Customer involvement is front loaded
REASON TWO
LEGAL REASONING
• Is about following a Causal Chain
• A Contract may not be indeterminate
• Is based on precedent rather than pure logic
• Changes very slowly (Stare Decisis)
• Is always “behind the curve”
Enforceable via
Contract LawWhere the solutions to our problems live
LAWYERS
• Are duty bound to “Obtain for their client the benefit of any and every remedy and defence authorised by law from threats seen & unseen”
• Focus on protection when trust deteriorates
• “Think the unthinkable”
• Are conservative and combative
REASON THREE
LACK OF TRUST
AGILE STRONGLY BENEFITS CUSTOMERS
Far more than it does vendors
SO WHY ARE THEY RELUCTANT?And Vendors so very keen?
SUPPLIER MOTIVATIONS
• A genuine desire for customer success
• Mindlessly jumping on the latest bandwagon
• Seems like a good way to get “off the hook”
A MARKET FOR LEMONS?
• Created after years of disappointing results
• Drives the customers to gain profits from “side effects”
• Based around fear and asymmetric information
THE CONTRACT SERVES AS A REPLACEMENT FOR TRUST
IT ALSO DEFINES THE RULES FOR A GAME
EACH PLAYER HAS A STARTING SET OF DESIRED OUTCOMES
Supplier Outcomes
Customer Outcomes
Legal Outcomes
SOME OF WHICH ARE LEGAL
Supplier Outcomes
Customer Outcomes
Supplier Outcomes
Customer Outcomes
THEN WE NEGOTIATE
Legal Outcomes
UNTIL WE STRIKE A DEAL
SupplierOutcomes
Customer Outcomes
Legal Outcomes
SO FAR SO GOOD...
BUT…
SupplierOutcomes
Customer Outcomes
Legal Outcomes
A GOOD LAWYER WILL GET IT TO LOOK LIKE THIS…
SupplierOutcomes
Customer Outcomes
Legal Outcomes
BUT BE LIKE THIS
I WOULDN’T WANNA DO
BUSINESS WITH
ANYBODY WHO’D HAVE
ME AS A CLIENT
AND THE SUPPLIER?
CUSTOMER COLLABORATION?
WE NEED A NEW GAME
THE AGILE ALGORITHM
Define Objectives
Set Constraints
do { Plan Define Execute} until happy
Enjoy
AGILE WAS RIGHTWe need to remove Hazard rather than manage it
TRUST CREATES AN ECONOMIC SURPLUS
TARGET COST ALIGNS INCENTIVES
BUILDING TRUST BUILDS PROFITS
• The Traditional approach uses Contracts as a replacement for trust
• This however came at the price of increased “Transaction Costs”
• Increasing trust reduces transaction costs – creating a larger “surplus”
Transaction costs make up around 30% of the costs of any given project
SO WHAT IS TRUST?
WHO DO YOU TRUST?
(and why?)
TRUST IS A RESPONSE,NOT A CHOICE
(at least not a rational one)
IS BUILT ON TOP OF TRUSTWORTHINESS
TRUSTWORTHINESS
• Competence
• Honesty
• Reliability
THE FIRST STEP TOWARDS WISDOM
Is to say “I don’t know”
THE FIRST STEP TOWARDS TRUST
Is to say “I don’t trust you”
PROTECT CUSTOMER INTERESTS
• Incremental Delivery
• A Clean Code Base
• A low barrier to exit
PROTECT SUPPLIER INTERESTS
• Share in the reward for early delivery
• Compensated for early termination
VULNERABILITY BUILDS TRUST
BUILD TRUST THROUGH TRANSPARENCY
• Encourage Transparency by increasing Safety
• Create Safety by Protecting Confidentiality
• Sharing Confidential Information builds trust through exposing Vulnerabilities
BUY SOME TRUST
TAKE MULTIPLE TEAMS FOR A TEST DRIVE
AN AGILE PROJECT IS NOT DISTINCT FROM IT’S PEOPLE
You’re renting Individuals to Interact with…
YOU’RE NOT PROVING A CONCEPT
You’re fostering collaboration
MULTI-TRACKING WILL INCREASE THE QUALITY OF
PROJECT DEFINITION
REFLECTDoes your business model really support Agility?
AGILE CONTRACTING HEURISTICS
EDUCATE & INVOLVELawyers in Agile
TELL YOUR LAWYERS
• Early termination is no longer a cause for concern because we keep our code clean and our increments valuable (but contract for that)
• We no longer believe we can completely describe the micro level activities that will result in our desired macro level outcomes
• Not building stuff can be a good thing
• We no longer wish to seek unfair advantage
CREATE AN IPD
REMEMBER THIS?
goto Define Solutiongoto Quotegoto Plangoto Executegoto Complain
fork Set Objectives
A Traditional Contract creates a Prisoner’s Dilemma
THIS CREATES AN IPD
Define Objectives
Set Constraints
do { Plan Define Execute} until happy
EnjoyUnless you know how
many Sprints it’s going to take
Where the dominant strategy is collaboration
MANAGE IN THE TAILS
Probably doesn’t matter
Awesomely EarlyHorrifically late
THINK RESILIENCENOT ROBUSTNESS
Which means you focus the contract on what you’re going to do when things go wrong
CHANGE THE LANGUAGE
• The language we use day to day influences the way we think and act
• Compare:
• “The Current Hypothesised Implementation is” to “The System Shall”
• Talking about “opinions” instead of “bugs”
KEEP THE FOCUS ON THE GOALAnd off the Sprints
(and don’t even mention Velocity)
PROVIDE EXEMPLARSStory Maps and Impact Mapping are your friends
ENCOURAGE OWNERSHIP
• Regular Reviews are not enough
• Clients need to regularly accept as their own the software that the supplier has built
• We value something far more highly when we perceive ownership (Endowment Effect)
FOCUS ON WHAT YOU HAVE NOW
Not just where you’re going
DON’T PUSH IT
• Not everybody is ready or able
• Not every software problem is complex
ITERATE TOWARDS AGILITY
• Get clients used to being more involved
• And you being more involved with them
• Avoid Sprint “Failure” penalties
• Start with the introduction of re-ordering
• Then move to substitution
ASK YOURSELVESAnd your customers
WHEN DO YOU WANT TO BE HAPPIEST?
• At the moment the contract is signed?
OR
• When the Software goes into production?
SUBSTITUTE FEELING IN CONTROL
For being in Control
WHICH REDUCES YOUR FEAR
OTHERWISE…
FEAR LEADS TO ANGER
ANGER LEADS TO HATE
HATE LEADS TO WATERFALL
