Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Fix-Price Projects And Agile – PyCon Sette


Published on

You are a digital agency struggling with your Django projects. You’re over budget and you’ve run out of time, that’s the norm not the exception. And of course you promise to deliver all features on time for a fixed budget, don’t you? – And nobody told you this is a problem?

See the original presentation at

Published in: Software
  • Be the first to comment

  • Be the first to like this

Fix-Price Projects And Agile – PyCon Sette

  1. 1. Fix-Price ProjectsFix-Price Projects And AgileAnd Agile PyCon 7, 2016PyCon 7, 2016 live slides @
  2. 2. Peter BittnerPeter Bittner Developer (of people, companies, code) Co-founder Painless Software @peterbittner, behave-django codeship-yaml django-analytical django-apptemplates django-organice
  3. 3. You Know That WellYou Know That Well deadline overtime features still missing deployment big-bang release bugs, bugs, bugs (regression) customer complaints renegotiations (price pressure) unpaid fixes (liability)
  4. 4. Who's Guilty?Who's Guilty? #1 Incompetent developers #2 Customer (feature changes) #3 "Agile" doesn't work #4 Maybe it has to be that way?
  5. 5. “ Agile does not exist.Agile does not exist. -- the infamous Peter Bittner It's really not a method, but just a set of best practices derived from experience (in software development)
  6. 6. AgendaAgenda Why fix-price projects? 3 dimensions of a project (Failing) Classic approach I+II (Demanding) Successful approach A) Sales ProcessA) Sales Process B) Project Execution
  7. 7. It's a planned economy (annual plan) Budget known in advance Target dates depend on goals + budget Revenue expected from new features Sums up to total profit Reliable dimensionsReliable dimensions Estimated dimensionsEstimated dimensions Why Fix-Price Projects?Why Fix-Price Projects?
  8. 8. 3 Dimensions of a Project3 Dimensions of a Project 1. Time 2. Budget 3. Features “ Failing projects nail all 3 of them.
  9. 9. (Failing) Classic Approach(Failing) Classic Approach All features + fixed deadline + fixed budget Must be estimated competitively Buffers are never sufficient Not ready for change = renegotiations “ You try to do the impossible.
  10. 10. (Failing) Classic Approach II(Failing) Classic Approach II They will buy it (low risk) Time to get to know them Place to sell your approach Room to come up with an estimation Offer a workshopOffer a workshop You try to do it allYou try to do it all Your goal: rough estimation Because you want all features (too) And meet budget + time "I told you at the workshop" syndrome “ Good! “ Bad!
  11. 11. Successful ApproachSuccessful Approach Fix deadline + budget Total estimation = non-binding ("plausibility check") Explain advantages of sprint-wise billing Sprint-wise billingSprint-wise billing Reduce risk (always deliver a working product) Freedom to change your mind (change features) Get what you need (not what you ordered)
  12. 12. Critical ElementsCritical Elements Ship early, ship often Build first what creates most value Never ever touch the deadline! Plan a going-live party with customer On timeOn time On budgetOn budget Welcome change: Reprioritise, reorder, redo features (before sprint starts) Stick to the process: No overtime, no changes in a running sprint (full concentration) Bill every sprint ("when time is exhausted") “ Fixed working hours = no renegotiation
  13. 13. Software that "simply works" – tested! I got what I need – awesome! On time, on budget, working solutions
  14. 14. AgendaAgenda (Failing) Traditional setup (Successful) Test-driven setup Why it makes sense What do we need? A) Sales Process B) Project ExecutionB) Project Execution
  15. 15. (Failing) Traditional Setup(Failing) Traditional Setup Long acceptance test phase in the end A lot of manual testing Regression after bug fixes No guarantee of stable implementation Risky defects liability period A closing test phaseA closing test phase “ Big bang release.
  16. 16. (Successful) Test-driven Setup(Successful) Test-driven Setup Acceptance test specification in concept phase Tests implemented by programmers Tests executed automatically Extremely short handover in the end Regression under control Upfront specificationUpfront specification “ Building trust. Gaining speed.
  17. 17. Why It Makes SenseWhy It Makes Sense No additional budget required Product stability Waste less money for bug fixing Cheap repeatability of testing Focus on advanced quality topics “ Make the same things earlier.
  18. 18. What Do We Need?What Do We Need? 1. User stories 2. Test specifications “ Acceptance criteria = Scenarios.
  19. 19. Tools & ResourcesTools & Resources , Jira: , PyCharm, ... behave behave-django Behave Pro
  20. 20. Wow, isn't that what we were always looking for? It's awesome, honey. Buy it? Buy it!
  21. 21. Thank you!Thank you! for your precious timefor your precious time Painless SoftwarePainless Software Less pain, more fun.