This presentation criticises many common practices in agile and lean software development and presents some alternatives like a "price per item" model.

1. Offers & Pricing
for agile & lean software development
Photo: Wikimedia Commons

2. About Me
Kurt Häusler
(@kurt_haeusler)
Practitioner (not trying
to sell anything)
Recovering victim of
prevailing management

3. About Me
BSc
CSM
CSP
MSc
PSM I
KCP
PMI-ACP

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

5. What Not to Expect
Not about contracts
I am not a lawyer
Too country specific anyway

6. 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”

7. Central Themes
What not to do
Offers
Pricing models

8. Offers & Pricing
There are many
options available
Might be more
important what we
don’t do

9. “Unlearning - the
deconstruction of old
assumptions - has to
precede the learning of
new norms.” - John
Seddon

10. Sources of these Ideas
ToC - Throughput Accounting
Kanban Community
Lean Startup
#NoEstimates

11. Background
Scrum and Kanban at a Product
Company
Scrum and Kanban at a Software
Development Service Provider

12. Sources of these Ideas
Resolving impediments
Inspecting and adapting
Applying Kanban to provide visibility,
and change, outside the walled garden

13. Impediments
Time & Materials Billing
“Projects” as the negotiable entity
Fixed Price / Fixed Scope
Requirements negotiation outside
“agile” process
Misuse of estimation

14. Impediments (cont.)
Basing prices on guessing
Hourly/Daily Ratecards
Time-tracking
Accounting, controlling and targets
based on percentage billable hours

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

16. The 2 Dimensions of a System
Lead Time - Property of Item
Throughput:
Property
of
System

17. 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?

18. Size is Meaningless
The process itself
Who performs the work
All the other process steps up and
downstream from development
Randomness
Delays / Queues
Customer upgrade / versioning cycles

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

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

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

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

23. A Solved Problem?
Agile fixed price / variable scope
Money for nothing, change for free
Never seen either in the wild

24. Offers

25. Negotiating Projects
Ignores reality that requirements change
Excludes true agility
Extremely high risk
Too much WIP in the system

26. Negotiating Requirements Outside
Agile Process
Extremely high lead times
Extremely wasteful

27. Kanban @ Bewotec
About 15 columns
Initial 5 columns all tracking “project”
sized items
The rest were all “features” of around
20-30 stories.

28. Kanban @ Bewotec
Lead Times were around 3 years

29. CFD New Development

30. CFD for Maintenance

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

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

33. 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”

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

35. Action Plan
No requirements
General pricing only
No signatures
No commitments
Can change
Details are context specific

36. Requirement Negotiation
Occurs regularly within the agile
process
Kanban Queue Replenishment
Represents commitment, may not be
changeable

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

38. Pricing Models
Creative Commons SA-BY: Empty Homes

39. Pricing Models
From worst to best
Specific attention paid to the problems
of the worst and the second best which
is my favorite

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

41. Time & Materials
Wikimedia Commons

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

43. 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!

44. Misuse of Estimation
OK for sprint planning
Rather unprofessional tool to use for an offer
or a price

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

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

47. Ratecards
Role Rate
Senior Management 250
PM/Architect 190
PO/SM/Senior Dev 110
Backend Dev 90
Frontend Dev 75

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

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

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

51. Another Little Story
One department has two projects running
One is fixed everything
The other is T&M

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

53. 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?

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

55. 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!

56. Price per Item
Based on throughput and average total
costs
Should be recalculated frequently
Margin can be smaller than usual

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

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

59. A Good Ratecard
Team Standard Intangible
Fixed Delivery
Date
Expedite
X
Y
Z
670 605 910 1210
400 350 1100 1500
710 700 770 850

60. But...
Don’t all items have to be the same size?
How to explain that every thing costs
the same?

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

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

63. Value Based Pricing
For more info see Alan Weiss
Especially good for consultants

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

65. 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/