Agile Contracting in the Second Decade of Agility

Post on 28-Jul-2015

224 views 0 download

Tags:

Transcript of Agile Contracting in the Second Decade of Agility

AGILE CONTRACTINGIn the Second Decade of Agility

@cgosimoninfo@lasting-benefits.com

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

info@lasting-benefits.com