Loading deck

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

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

It's awesome, honey.

Buy it?

Buy it!

Thank you!

for your precious time

Painless Software

Less pain, more fun.