As with the previous post, this is a verbatim copy of my speech notes, with some mark-up.
It's about the WhyTime 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 StoriesIf 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)
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.
Scary PowerSo 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 ownerHow: add a clause to the contract!
so that: we get answers and resolutions quickly and don't have to guess or debate
As a team we want: a variable backlogHow: add a clause to the contract!
So that: we can do what is actually needed as we discover it
As a team we want: an agile release planHow: add a clause to the contract.
So that: the client can have expectations that match reality
As a team we want: anythingHow: Add a clause to the contract.
Because of this good reason
So, what do these clauses look like? I'll tell you about ours soon.
First off, some more stories:
As a board/person payingHow: make it clear in the contract
I want to know when we will be expected to pay
so that I can budget and do financial calculations
As the end userHow: expose delivery mechanisms in the contract.
I want to play with the software early
so that I can stress less and get what I want
We can really get our teeth into this product: "the contract" if we bring our formiddable armada to bear on it.
Behaviour Driven DevelopmentSo, what's next? BDD... behaviour driven development.
|Crazy Crayon Physics Scenario|
(picture by slopjop)
Given a team working on 2 week sprints[discussion, examples]
When the sprint commitment is not achieved
Then : these are penalties/discounts
Given a team on hourly Time & Materials[discussion, smiles]
When we run a four week month and everything goes well
Then this is the process and financials
Given a team paid on Time and Materials[nervous laughter?, discussion]
When we get to April 2011 and everyone takes the gap and gets 2 weeks leave
Then how does this baby hold up
And what happens to the release plan?
Given a client with cash-flow problems[explain illusion attern of decline, discussion]
When they stop paying
Then what do we do?
TDDThe 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.