Fix-Price Projects And Agile

PyCon 7, 2016

live slides @ tinyurl.com/pycon7-fix

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

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)

Who's Guilty?

#1  Incompetent developers

#2  Customer (feature changes)

#3  "Agile" doesn't work

#4  Maybe it has to be that way?

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)

Agenda

• Why fix-price projects?
• 3 dimensions of a project
• (Failing) Classic approach I+II
• (Demanding) Successful approach

A) Sales Process

B) Project Execution

Why Fix-Price Projects?

• 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

Estimated dimensions

3 Dimensions of a Project

1.  Time

2.  Budget

3.  Features

Failing projects nail all 3 of them.

(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.

(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

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!

Successful Approach

• Fix deadline + budget
• Total estimation = non-binding ("plausibility check")
• Explain advantages of 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)

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

Software that "simply works"

– tested!

I got what I need –

awesome!

On time, on budget,

working solutions

Agenda

• (Failing) Traditional setup
• (Successful) Test-driven setup
• Why it makes sense
• What do we need?

A) Sales Process

B) Project Execution

(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

Big bang release.

(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

Building trust. Gaining speed.

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.

What Do We Need?

1.  User stories

2.  Test specifications

Acceptance criteria = Scenarios.

Tools & Resources

• behave, behave-django
• Jira: Behave Pro, PyCharm, ...

https://painless.software/test-driven-project

Wow, isn't that what we were always looking for?

It's awesome, honey.

Buy it?

Buy it!