Offers & Pricing

Offers & Pricing

for agile & lean software development

Photo: Wikimedia Commons

About Me

Kurt Häusler (@kurt_haeusler)

Practitioner (not trying to sell anything)

Recovering victim of prevailing management

About MeBSc

CSM

CSP

MSc

PSM I

KCP

PMI-ACP

Offers & Pricing

Ask questions any time

Details mostly relevant for service providers, and some product companies

May be less relevant for internal IT and other product companies

What Not to Expect

Not about contracts

I am not a lawyer

Too country specific anyway

Contracts

Standard contracts or templates not that useful

Focus on reducing risk so that people don’t worry about them as much

My focus is much more on “customer collaboration”

Central Themes

What not to do

Offers

Pricing models

Offers & Pricing

There are many options available

Might be more important what we don’t do

“Unlearning - the deconstruction of old assumptions - has to

precede the learning of new norms.” - John

Seddon

Sources of these Ideas

ToC - Throughput Accounting

Kanban Community

Lean Startup

#NoEstimates

Background

Scrum and Kanban at a Product Company

Scrum and Kanban at a Software Development Service Provider

Sources of these Ideas

Resolving impediments

Inspecting and adapting

Applying Kanban to provide visibility, and change, outside the walled garden

Impediments

Time & Materials Billing

“Projects” as the negotiable entity

Fixed Price / Fixed Scope

Requirements negotiation outside “agile” process

Misuse of estimation

Impediments (cont.)

Basing prices on guessing

Hourly/Daily Ratecards

Time-tracking

Accounting, controlling and targets based on percentage billable hours

All Symptoms of the Same Problem

Knowledge work can NOT be measured in hours (unless we are bodyleasing)

Time spent typing in source code is NOT the most significant factor influencing costs or total lead time

Even educated guesses are an unprofessional tool when spending other peoples money (compared to concrete measurements)

The 2 Dimensions of a System

Lead Time - Property of Item

Throughput:Property

ofSystem

What is the Customer Paying for?

Someone to sit and type in source code for a certain amount of time?

More time spent working = more value?

Or software features?

Size is MeaninglessThe process itself

Who performs the work

All the other process steps up and downstream from development

Randomness

Delays / Queues

Customer upgrade / versioning cycles

Size is Meaningless

After experimenting with t-shirt sizes, we observed no correlation with lead time, and only a small correlation across the development stage

The Current Situation

Fixed price is bad

Therefore T&M must be the right way to do it

This way of thinking seems to dominate

The Current Situation

Offers and pricing usually occurs outside the “walled garden”

“That’s business, not IT”

Basic approach is classic agile - reduce the batch size

The Current Situation

Current approach dooms us to “Scrummerfall”

Slogging through a predefined, contractually committed backlog in sprints is not agile.

It’s a death march

A Solved Problem?

Agile fixed price / variable scope

Money for nothing, change for free

Never seen either in the wild

Offers

Negotiating Projects

Ignores reality that requirements change

Excludes true agility

Extremely high risk

Too much WIP in the system

Negotiating Requirements Outside Agile Process

Extremely high lead times

Extremely wasteful

Kanban @ Bewotec

About 15 columns

Initial 5 columns all tracking “project” sized items

The rest were all “features” of around 20-30 stories.

Kanban @ Bewotec

Lead Times were around 3 years

CFD New Development

CFD for Maintenance

MVPs

The lean startup community are the experts when it comes to developing products like this

Lead Times

Story splitting or expand/collapse don’t make your lead times any shorter

Lead time starts when the “deal is made” with the customer

You don’t get to restart the clock by switching batch-sizes

Story about Workshops

I was once invited to take part in an “initial customer workshop”

Turned out to be detailed requirement analysis

“But we have a column on the board for that, and it isn’t the backlog”

In Short

Split the current BCUF into two levels

Small initial “action plan with general pricing”

Small regular agreements about what to do and how much it costs

Action Plan

No requirements

General pricing only

No signatures

No commitments

Can change

Details are context specific

Requirement Negotiation

Occurs regularly within the agile process

Kanban Queue Replenishment

Represents commitment, may not be changeable

2-Stage Commitment

Kanban community are extremely advanced here

1st commitment to begin but not to finish

2nd commitment to deliver

Removes the need to say anything concrete about requirements up front

Pricing Models

Creative Commons SA-BY: Empty Homes

Pricing Models

From worst to best

Specific attention paid to the problems of the worst and the second best which is my favorite

Pricing Models

Time & Materials

Fixed Price / Fixed Scope

Fixed Price / Variable Scope

Fixed Price per Team Day or Sprint

Rent Team Capacity

Price per Feature

Value Based

Time & Materials

Wikimedia Commons

T&M

Punishes innovation

Requires time tracking

If combined with estimate-based promise, has all disadvantages of fixed price

High risk of damaging customer relations

Estimation

Lots of discussion about estimation as a planning tool

But everywhere I have seen it being used it was for offers and pricing

No one talks about money!

Misuse of Estimation

OK for sprint planning

Rather unprofessional tool to use for an offer or a price

Kurt’s Estimation Rules

Only relative units (SPs), never hours or days

Only good for a non-binding, rough idea of duration (sprint or release plan)

Don’t give it to the customer if they treat it like a promise

Never use them for pricing

Process should not depend on accuracy of estimates

As soon as someone thinks about “improving accuracy” of estimates, that is a smell of misuse

Guess-based Pricing

Estimates are usually supposed to relate to “size”

Size is I believe supposed to correlate to development time

Development time (and size) is one of the least significant factors influencing an items lead time, and its impact on our throughput

Ratecards

Role Rate

Senior Management 250

PM/Architect 190

PO/SM/Senior Dev 110

Backend Dev 90

Frontend Dev 75

Ratecards

Obviously offensive

Require not only hourly estimation in advance but categorizing work according to role

I have seen architects sitting idle because we only offered the work at a lower rate

Time Tracking

Time spent recording hours is the least of it

What about work that advantages several customers?

I have seen people do the poor time consuming solution, because the quick clever one leaves us out of pocket

Assumes we want to maximize effort

Billable Hours Target

e.g. 80% of booked hours must be billable

20% time not on customer projects? Just like Google!

If customer doesn’t want to see pairing, training, non-project meetings or refactoring in the bill, they come out of the 20%

Doesn’t suit many roles

Another Little Story

One department has two projects running

One is fixed everything

The other is T&M

Fixed Price / Fixed Scope

Second worse model

Only really bad because of risk

Not a problem as long as price large enough, scope small enough and delivery date far out enough

T&M significantly worse

Fixed Price / Variable Scope

I think this is the same as “agile fixed price”

Why should the price be fixed if the scope is variable?

Fixed Price per Team Day or Sprint

Some people call this T&M

OK if you have a single customer and a lot of trust

Renting Team Capacity

As a percentage of WIP or throughput for an agreed duration

NOT as a percentage of employee hours

A little bit more financial risk in exchange for “locking in” capacity especially when maintenance is involved

MVP for 50k special offer!

Price per Item

Based on throughput and average total costs

Should be recalculated frequently

Margin can be smaller than usual

Price per Item

Team costs €100,000 per month

Delivers on average 175 items per month

Cost is €575 per item

Plus 5% margin for €605 price per item

Price per Item

I use 12 month moving average for both costs and throughput

Can add on extras for other costs of service: e.g. fixed delivery date and expedite

Deal is made and price is fixed at queue replenishment

A Good RatecardTeam Standard Intangible

Fixed Delivery Date

Expedite

X

Y

Z

670 605 910 1210

400 350 1100 1500

710 700 770 850

But...

Don’t all items have to be the same size?

How to explain that every thing costs the same?

Value Based Pricing

The holy grail of pricing models

Hard for a service provider to use

Customer often doesn’t know what it is worth or is willing to share it

Could be good for product companies IF we don’t use imaginary numbers or guesses

Value Based Pricing

Most of the previous models do actually have a value based component

The customer does it for us

Main thing for a service provider is covering costs

Value Based Pricing

For more info see Alan Weiss

Especially good for consultants

Other Pricing Models

Price per story point

Auctioning free slots in the input-queue

Incremental Funding Method

Utilizing asymmetry of payoff-functions

Monte Carlo simulations

Conclusion & More Info

More options than just fixed everything and T&M

Value-based best but hard

Price per item my current favorite

http://kurthaeusler.wordpress.com/2013/05/20/pricing-and-a-little-bit-about-estimation/