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.

Made with Slides.com