Agile on the beach 2014: Contracted to deliver outcomes

Contracted to deliver

outcomesAgile on the Beach - September 2014

Kris Lander / @EnergizedKris

www.energizedwork.com / @energizedwork

ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

Introduction

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


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: Agile Warriors


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)ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

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.)

Our Agile Journey


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.ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

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/

But we had some way to go…


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)ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

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

17%

go so badly they can threaten the existence of the company. McKinsey & Company

50%

fail to achieve what they set out to achieve. KPMG

60%

do not meet schedule, budget or quality goals. IBM

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


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: some examples


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.ENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

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

YoskovitzENERGIZED WORK / HMS President Victoria Embankment London EC4Y 0HJ / www.energizedwork.com

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


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.

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: Legacy Replacement


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 stakeholdermanagement)Investors are satisfied with the Investment Service providedGoal: avg. Acceptable – 15thOct 2014Goal: avg. Good – 15th Dec 2014Goal: 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 20142-4 by Q4 20145 - 20 by Q2 2015

Reduce Opex Hosting Costs:50K/month - Q1 201310K/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.


Feedback !

Questions ?

Agile on the beach 2014: Contracted to deliver outcomes

Technology

Transcript of Agile on the beach 2014: Contracted to deliver outcomes