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

1. Fix-Price ProjectsFix-Price Projects
And AgileAnd Agile
PyCon 7, 2016PyCon 7, 2016
live slides @ tinyurl.com/pycon7-fix

2. Peter BittnerPeter 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 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. 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. 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. 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. 3 Dimensions of a Project3 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 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. 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. 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. Software that "simply works"
– tested!
I got what I need –
awesome!
On time, on budget,
working solutions

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. (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. (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. 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. What Do We Need?What Do We Need?
1. User stories
2. Test specifications
“ Acceptance criteria = Scenarios.

19. Tools & ResourcesTools & 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 timefor your precious time
Painless SoftwarePainless Software
Less pain, more fun.