Your SlideShare is downloading. ×
Offers & Pricing
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Offers & Pricing

2,268
views

Published on

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

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

0 Comments
4 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,268
On Slideshare
0
From Embeds
0
Number of Embeds
16
Actions
Shares
0
Downloads
12
Comments
0
Likes
4
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

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