Offers & Pricing


Published on

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

Published in: Business, Technology
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Offers & Pricing

  1. 1. Offers & Pricing for agile & lean software development Photo: Wikimedia Commons
  2. 2. About Me Kurt Häusler (@kurt_haeusler) Practitioner (not trying to sell anything) Recovering victim of prevailing management
  3. 3. About Me BSc CSM CSP MSc PSM I KCP PMI-ACP
  4. 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. 5. What Not to Expect Not about contracts I am not a lawyer Too country specific anyway
  6. 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. 7. Central Themes What not to do Offers Pricing models
  8. 8. Offers & Pricing There are many options available Might be more important what we don’t do
  9. 9. “Unlearning - the deconstruction of old assumptions - has to precede the learning of new norms.” - John Seddon
  10. 10. Sources of these Ideas ToC - Throughput Accounting Kanban Community Lean Startup #NoEstimates
  11. 11. Background Scrum and Kanban at a Product Company Scrum and Kanban at a Software Development Service Provider
  12. 12. Sources of these Ideas Resolving impediments Inspecting and adapting Applying Kanban to provide visibility, and change, outside the walled garden
  13. 13. Impediments Time & Materials Billing “Projects” as the negotiable entity Fixed Price / Fixed Scope Requirements negotiation outside “agile” process Misuse of estimation
  14. 14. Impediments (cont.) Basing prices on guessing Hourly/Daily Ratecards Time-tracking Accounting, controlling and targets based on percentage billable hours
  15. 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. 16. The 2 Dimensions of a System Lead Time - Property of Item Throughput: Property of System
  17. 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. 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. 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. 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. 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. 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. 23. A Solved Problem? Agile fixed price / variable scope Money for nothing, change for free Never seen either in the wild
  24. 24. Offers
  25. 25. Negotiating Projects Ignores reality that requirements change Excludes true agility Extremely high risk Too much WIP in the system
  26. 26. Negotiating Requirements Outside Agile Process Extremely high lead times Extremely wasteful
  27. 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. 28. Kanban @ Bewotec Lead Times were around 3 years
  29. 29. CFD New Development
  30. 30. CFD for Maintenance
  31. 31. MVPs The lean startup community are the experts when it comes to developing products like this
  32. 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. 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. 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. 35. Action Plan No requirements General pricing only No signatures No commitments Can change Details are context specific
  36. 36. Requirement Negotiation Occurs regularly within the agile process Kanban Queue Replenishment Represents commitment, may not be changeable
  37. 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. 38. Pricing Models Creative Commons SA-BY: Empty Homes
  39. 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. 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. 41. Time & Materials Wikimedia Commons
  42. 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. 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. 44. Misuse of Estimation OK for sprint planning Rather unprofessional tool to use for an offer or a price
  45. 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. 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. 47. Ratecards Role Rate Senior Management 250 PM/Architect 190 PO/SM/Senior Dev 110 Backend Dev 90 Frontend Dev 75
  48. 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. 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. 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. 51. Another Little Story One department has two projects running One is fixed everything The other is T&M
  52. 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. 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. 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. 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. 56. Price per Item Based on throughput and average total costs Should be recalculated frequently Margin can be smaller than usual
  57. 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. 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. 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. 60. But... Don’t all items have to be the same size? How to explain that every thing costs the same?
  61. 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. 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. 63. Value Based Pricing For more info see Alan Weiss Especially good for consultants
  64. 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. 65. Conclusion & More Info More options than just fixed everything and T&M Value-based best but hard Price per item my current favorite 2013/05/20/pricing-and-a-little-bit- about-estimation/
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.