Agile on the beach 2014: Contracted to deliver outcomes

Contracted to
deliver outcomes
Agile on the Beach - September 2014

Introduction
Kris Lander / @EnergizedKris
www.energizedwork.com / @energizedwork
ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

Outcomes for this presentation
● An understanding of how and why Energized Work’s approach to
creating value for our clients has evolved over its history.
● An understanding of how Energized Work is trying to create a contract
model that aligns with its current outcomes-based approach.
● An understanding of commercial contracts and typical contract models
for software procurement
● An understanding of the clash between an agile software delivery and
traditional software contract models
● An understanding of the most common agile contract model approaches

A teaser: What we do today
We help companies design, manage and deliver programs of work which
revolve around technology.
We focus on aligning our engagements with the business strategy of our
clients to achieve positive outcomes.
Realising outcomes forms the basis of our contractual obligation to our clients
and part of our payment is determined by measuring our impact on business
outcomes.
We are contracted to deliver outcomes. Let’s explore how we got there.

A brief history
of
Energized Work
2006 - 2009

History of EW: Agile Warriors
Problem: Repeatable, predictable delivery
Early 2000s
● Professional software development wasn’t much fun. At least for me.
● Began adoption of agile practices and methods. Learning and
increasingly competent in applying process and technical practices.
2006: In the right place, at the right time with the right people.
● Step change in terms of speed, predictability and quality.
● Success of team led Simon and Gus to found Energized Work.

History of EW: Got ROI?
Problem: Understanding the value delivered by teams
2007: Project rescue
● Macro measures of value/effectiveness became focused on £ invested
vs user growth.
● Adoption of Lean and ToC methods to focus on managing/measuring
WIP, cycle time, queues, etc which made case for delivering more value
over time.
2008: Governance / PMO
● Business and product strategy across portfolio lived outside of agile
delivery and carried unvalidated assumptions about market and
customer needs which was a far bigger risk to ROI.

History of EW: Making hard
choices
Problem: Successful business strategy is more than just following the money.
2009: Evaluation of IT strategy
● Assessment of IT delivery capability and existing trading platform
● Difficult to quantify return on investment in simple £
● Big gap in terms of expressing value to board led to realisation that there
was a gap in our ability to express the value we were delivering
(Irony: Financial industry has great tools for pricing information and risk management)

Our Agile Journey
Picking on a few of principles from the agile manifesto:
“Our highest priority is to satisfy the customer through
early and continuous delivery of valuable software.”
“Working software is the primary measure of progress.”
“Continuous attention to technical excellence and good design
enhances agility.”
(We had tended to do better with the terms on the left, as opposed to the
terms on the right.)

We’d come along way…
Technical excellence to achieve early and continuous delivery of working
software.
More responsive and predictable:
● Just enough, just in time: small stories, short iterations and constraining
work in process
● Reduced cycle time/lead times, shipping regularly.
Disciplined techniques produced working, maintainable software:
● Test and deployment automation (CI/CD)
● BDD/TDD
Self organising teams have promoted collaboration, transparency and
visibility.

But we had some way to go…
Measuring progress
● Being judged/focused on output (Velocity, Features, etc) as a proxy for
productivity.
Good design
● Agile methods have never explicitly addressed design, be it user
experience design or technical design.
Valuable work/software
● Value needs to be based on more than subjective judgments and is
more complicated than simple ROI (e.g. balancing multiple stakeholder
needs)
See Simon Baker’s paper No Bull. http://nobull.energizedwork.com/

Making a sale.

A Request for Proposal
Client makes a request for proposal:
● Provides a brief: requirement spec (stories), wireframes, etc.
● Client RFP covers wide area of ground.
Client wants the supplier to demonstrate that they can deliver everything
they want within their budget.

“Requirements”
“As a user, I am able to login to the application using the email/password
credentials with which I registered with, so that I can access my account
details.”
We have 50 requirements like these.
Performance requirements:
The website must have an availability of 99.999%

How much and how long?
The supplier knows that unless they have built something very similar before:
● estimation of cost and time is very difficult with sparse information
● performance requirements and dependencies are potential icebergs.
● they don’t have a good understanding of what is more or less valuable to the
client’s customers and other stakeholders
So the supplier makes other promises as an alternative to committing to the
unknown:
● Early delivery of working software into production first week, every week.
● Short statements of work (investment cycle), start and stop when it suits you.
● Pay us for Time and Materials and take a leap of faith.
But the client needs to know: How much and how long?!

Time to get on with it…
Client and supplier attempt to improve the existing requirements, clarify the
unknowns and agree to cut down the scope in the hope that an agreement can
be reached.
Time is against both parties. The client has deadlines and the supplier’s cost of
sales is spiraling out of control.
Luckily, the client and supplier have developed a good relationship. The supplier
has impressed with their expertise and insights and the client has been pragmatic
and accommodating.
It doesn't always work out that way.

Bounded by the contract
The supplier wants to iterate in partnership with the client to discover and deliver
what is valuable, but they know it’s very risky to deviate from the features
specified in the contract.
The client appreciates the focus on value the supplier brings, but they have to hit
their deadlines and can’t go over budget.
When things get tough will contract help or hinder?

Contracts

Contracts - Definition
What is a contract?
“a written or spoken agreement, especially one concerning employment, sales, or tenancy,
that is intended to be enforceable by law.”
“an agreement with specific terms between two or more persons or entities in which there is a
promise to do something in return for a valuable benefit known as consideration.”
The elements:
● Offer and acceptance (meeting of minds)
● Promise to perform (with commitments e.g. by date)
● Consideration (payment)

Contracts - The basic types
Performance: But typical a definition of what is to be done.
Pricing Models
● Fixed Price variants
● Cost Reimbursement variants
● Time (Labour) and materials

Contract model FAIL
Why it doesn’t work: Traditional contracts, especially fixed price, fixed scope
create many if the same problems as waterfall software development.
● Specification of what is to be done, by when and makes the assumption
that we know everything.
● Risk for client isn’t just getting what they want done, but what they need
(ROI)
● Contract makes responding to change undesirable and expensive
● Fixed scope, fixed cost, fixed time (we know what happens to quality)

Fixed Price, Fixed Scope for Software
We asked a 100 agile practitioners name reasons that fixed price, fixed scope
contracts continue to be the most common form of contract for software
procurement.
● Easy to understand, I will get X for £Y by date
● Prevailing belief that building software is like other construction industries.
● Easiest to align with traditional business planning and budgeting
● Constrained by policies of legal and procurement dept.
● Client believes definition of what is to be done, is what they need, and this can
be made transferrable & understandable in contract
● Client feels that they are safely offloading responsibility and risk to supplier
● Client gets to beat down supplier on price, supplier gets to claw back in
changes

IT Programmes
60% do not meet schedule, budget or quality goals.
IBM
50% fail to achieve what they set out to achieve.
KPMG
17% go so badly they can threaten the existence of the
company.
McKinsey & Company

The clash: Agile vs Contracts
Evolutionary vs. Big Bang: One single contract for the expected lifetime of the project
where delivery is only contractually enforceable at the end.
Value vs. Scope: Contract typically specify a set of features without describing how
they create value for the client.
Initiative vs. Control: Business/product owner relationship is client/supplier and
promote top-down management rather than collaboration.
Satisfaction vs. Compliance: Supplier is incentivised to optimise for contractual
compliance over customer satisfaction.
Solutions vs. Retribution : Implicit design of solutions are legally bound into contract.
Alternatives could be considered non-compliance and potentially punished.

Agile contracts
Attempt to align better around agile methods:
● Fixed price or time & materials as typical pricing model
● Iterative/incremental statements of work define shorter chucks of scope
● Provisions for scope of work to change or finish early

Agile contracts: some examples
Optional Scope Contracts
(Short fixed price iterations, with fixed “quality”, time but variable scope)
Money For Nothing, Change For Free
(scope/priorty can change each iteration, client get to cut project short if there
is no further ROI)
Fixed Price per Story Point

Agile contracts...
Focus on what we’ve been good at doing:
● Iterative, incremental delivery of working software
● Responding to change
Still a leap (albeit smaller) of faith for the client and failing to make explicit:
● Delivery of business value
● Means to measure progress in terms of business value
● Providing context for design performance requirements and constraints
(e.g. usability, security, reliability) connected to business value.

A brief history
of
Energized Work
(part 2)
2009 - 2013

Inspirations
Customer Development /Lean Startup - Steve Blank/Eric Reis
● Clear goal: Discover and execute a viable product/business
● Puts the entire business in the PDCA cycle
● Forces us to confront business assumptions and risk
● Focuses on key business/product metrics (innovation accounting)
● Optimized for learning/discovery
Book recommendation: Lean Analytics by Alistair Croll & Benjamin Yoskovitz

Inspirations
Lean Product Development, Cost of Delay, CD3 - Don Reinertsen
● Economic re-evaluation of lean principles taken from manufacturing
● Insights into the effects of uncertainty, variability and risk.
● Powerful prioritisation tool, CD3, that optimises for value over time.
● value has to be quantified (avoid/reduce costs, increase/protect revenue)
Book recommendation: The Principles of Product Development Flow by Don
Reinertsen

Inspirations
Tom Gilb – EVO
● Approach and method optimised for stakeholder outcomes/value
● Numeric, quantified outcomes
● Separation of requirements (ends) and designs (means)
● Powerful design engineering methods
● 12 Tough Questions
● No Cure, No Pay
Book recommendation: Competitive Engineering by Tom Gilb

History of EW: Strategy Discovery
Defining a strategy was the outcome required by the client. Strategy in the
time horizon of 2-5 years could only be defined in terms of business
outcomes.
This time the supporters and dissenters roles were reversed:
● Brought clarity to the function of the business and could understand what
they needed to do in terms of outcomes.
● Rejection by IT management who wanted a plan of what to do, as they
feared leaving design of solutions in the hands of the masses.
This raised a big question - how do we design/engineer, particularly at scale.

History of EW: Legacy
Replacement
Discovery engagement to define strategy to replace legacy system.
This time we applied EVO methods to:
● Define and quantify stakeholder goals
● Evaluate design options for discovery of information
● Evaluate best technical approach to replace the legacy system
Providing frame for legacy replacement in terms of outcomes for the
business.

History of EW: Lean Startups
Delivery an MVP of a mobile POS iPad app.
We help define business and product goals to bring their product to market
successfully.
e.g. Number of sales, NPS score and merchants ability to complete biz
functions (e.g. how well a merchant could complete a transaction with their
customers)
This allowed us to then quantify our contribution as their technology partner.
We tied part of our payment to meeting those goals!

Outcome-based approach: Why
● Shared, defined understanding of what is valuable (and to who) that
focuses the everyone on realising positive outcomes for the business
● Reduce the risk of subjective and emotive stakeholder judgment by
providing a more factual basis for analysing progress.
● Allows us to measure progress in terms realising outcomes/biz value
● Good outcomes change far less than good feature specifications.
● More design freedom with feedback loop so we can learn what will
produce the biggest impact.

Outcome-based approach: Why not
● You can fail and you can't hide it (but everyone can learn from it)
● It’s hard (but very valuable) to reduce an engagement down to a set of
outcomes that can be clearly understood by stakeholders.
● It can surface conflicts between stakeholders that result in paralysis and
politicking.
● Some clients find more value in seeing people busy rather than
delivering value - the "activity trap"

If outcomes are the deliverable…
Then we should attempt to put them in the contract.
Our Strategy:
● Every engagement must have engagement goals defined as outcomes
for the client.
● Client outcomes will be part of our contractual agreements.
And we are trying to go a step further:
● We will try sell risk and reward-based engagements and not just our
time.

An example of what’s in our contract
Investor outcome: (external
stakeholder
management)
Investors are satisfied with the
Investment Service provided
Goal: avg. Acceptable – 15thOct 2014
Goal: avg. Good – 15th Dec 2014
Goal: avg. Excellent – 15th Feb 2015
Process outcome: (capability)
1. Quantify Risk per
Investment
● Goal: First Product
Set – 15th Sept 2014
● Goal: All
Investments – 1st
Jan 2015
Product uptake outcome:
Onboard Partners:
1 Partner by Q2 2014
2-4 by Q4 2014
5 - 20 by Q2 2015
Reduce Opex Hosting Costs:
50K/month - Q1 2013
10K/month - Q4 2013
Scale:
<150 (<800 peak) requests/sec
- Q2 2014
<300 (<1400 peak)
requests/sec - Q4 2014
Reduce the Average Length of
Stay:
● Medical
○ Complexity < 3: 1.6
days
● Surgical
○ Gastro: 2.2days
○ Neuro: 6 days
Outcomes are a) a future state and b) measurable and independently verifiable by some means. They
can vary wildly with context (product, usage, performance, efficiency, capability etc.)

An idea worth spreading?
We believe that we are reaching a critical mass as people reach similar conclusions.
(Some people reached them many years ago!)
Agile has been mainstream for some time and we see that many people are
experiencing a disconnect between “building all the things” faster and the meaning in
their work – i.e. how it creates value.
We believe that having well defined outcomes are the foundation of success which
promote trust and collaboration and freeing us all to creatively design better solutions
to realise them. Outcomes can also be the bedrock of better commercial relationships.

Agile on the beach 2014: Contracted to deliver outcomes

Recommended

Recommended

More Related Content

Viewers also liked

Viewers also liked (20)

Similar to Agile on the beach 2014: Contracted to deliver outcomes

Similar to Agile on the beach 2014: Contracted to deliver outcomes (20)

Recently uploaded

Recently uploaded (20)

Agile on the beach 2014: Contracted to deliver outcomes