This is the third in my Agile Contracting series.
As with the previous post, this is a verbatim copy of my speech notes, with some mark-up.
[DL]

It's about the Why

Time for our own medicine [mime spoon] joke about mirroring.

Well, we're working towards alignment, but we also feel the need for a contract.

It's time for some of our own medicine. Bring out the User story.


User Stories

If we were to write the user story for our contract what would it look like?
  • As a software developer, I want a contract, so that...
  • As a team, we want a contract, so that...
  • As a software company, I want a contract so that?
Do we really know?

[ to C]
19th Century Contract
(picture by kladcat)
Okay, no fair. That's not a story, that's an epic.

And we want the things we want in epics because.. well we're playing catch up, everone else has them.

Everyone else has them so that makes it good? *side-eye* That's a discussion better left for later.
[C]

Scary Power

So we know the scary thing about user stories is: like goals, once we define them we set the ball in motion.

We know the why and the what and the how will inevitably follow.

So, let's see what this baby can do.
As a team,
we want this,
so that this great thing happens.

Feel the power

As a team we want: access to a product owner
so that: we get answers and resolutions quickly and don't have to guess or debate
How: add a clause to the contract!

As a team we want: a variable backlog
So that: we can do what is actually needed as we discover it
How: add a clause to the contract!

As a team we want: an agile release plan
So that: the client can have expectations that match reality
How: add a clause to the contract.

As a team we want: anything
Because of this good reason
How: Add a clause to the contract.


So, what do these clauses look like? I'll tell you about ours soon.
First off, some more stories:

As a board/person paying
I want to know when we will be expected to pay
so that I can budget and do financial calculations
How: make it clear in the contract

As the end user
I want to play with the software early
so that I can stress less and get what I want
How: expose delivery mechanisms in the contract.


We can really get our teeth into this product: "the contract" if we bring our formiddable armada to bear on it.

Behaviour Driven Development

So, what's next? BDD... behaviour driven development.

Crazy Crayon Physics Scenario
(picture by slopjop)
Given a team working on 2 week sprints
When the sprint commitment is not achieved
Then : these are penalties/discounts
[discussion, examples]


Given a team on hourly Time & Materials
When we run a four week month and everything goes well
Then this is the process and financials
[discussion, smiles]


Given a team paid on Time and Materials
When we get to April 2011 and everyone takes the gap and gets 2 weeks leave
Then how does this baby hold up
[nervous laughter?, discussion]
And what happens to the release plan?

Given a client with cash-flow problems
When they stop paying
Then what do we do?
[explain illusion attern of decline, discussion]

TDD

The next tool we have is Test Driven Development.

Pure TDD involves only writing a line of code if you can write a test that makes the product fail.

So we use scenarios and more focused tests to actually create a contract from the ground up that is tested, testable and has no cruft.

Then run that by a lawyer with the tests and ask what extra tests you should add.

Back to Agile Contracting series index.