Offers & Pricing

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

Transcript

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 T oo 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 T oC - 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 T oo 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” T urned 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 T eam Day or Sprint Rent T eam 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 T racking 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 T arget 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 T eam Day or Sprint Some people call this T&M OK if you have a single customer and a lot of trust
55. Renting T eam 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 T eam 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 T eam 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/