Fix-Price Projects And Agile – PyCon Sette

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 http://slides.com/bittner/pycon7-fix-price-projects-and-agile and a recording of the talk at PyCon7 at https://www.youtube.com/watch?v=JinKEa1vh_g

Transcript

1. Fix-Price Projects Fix-Price Projects And Agile And Agile PyCon 7, 2016 PyCon 7, 2016 live slides @ tinyurl.com/pycon7-fix
2. Peter Bittner Peter Bittner Developer (of people, companies, code) Co-founder Painless Software @peterbittner, django@bittner.it behave-django codeship-yaml django-analytical django-apptemplates django-organice
3. You Know That Well You 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. 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. “ 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. Agenda Agenda Why fix-price projects? 3 dimensions of a project (Failing) Classic approach I+II (Demanding) Successful approach A) Sales Process A) Sales Process B) Project Execution
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 dimensions Reliable dimensions Estimated dimensions Estimated dimensions Why Fix-Price Projects? Why Fix-Price Projects?
8. 3 Dimensions of a Project 3 Dimensions of a Project 1. Time 2. Budget 3. Features “ Failing projects nail all 3 of them.
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. (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 workshop Offer a workshop You try to do it all You 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. Successful Approach Successful Approach Fix deadline + budget Total estimation = non-binding ("plausibility check") Explain advantages of sprint-wise billing Sprint-wise billing Sprint-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. Critical Elements Critical Elements Ship early, ship often Build first what creates most value Never ever touch the deadline! Plan a going-live party with customer On time On time On budget On 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. Software that "simply works" – tested! I got what I need – awesome! On time, on budget, working solutions
14. Agenda Agenda (Failing) Traditional setup (Successful) Test-driven setup Why it makes sense What do we need? A) Sales Process B) Project Execution B) Project Execution
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 phase A closing test phase “ Big bang release.
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 specification Upfront specification “ Building trust. Gaining speed.
17. Why It Makes Sense Why 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. What Do We Need? What Do We Need? 1. User stories 2. Test specifications “ Acceptance criteria = Scenarios.
19. Tools & Resources Tools & Resources , Jira: , PyCharm, ... behave behave-django Behave Pro https://painless.software/test-driven-project
20. Wow, isn't that what we were always looking for? It's awesome, honey. Buy it? Buy it!
21. Thank you! Thank you! for your precious time for your precious time Painless Software Painless Software Less pain, more fun.