19 December 2011

On day 2 of the Cape Town Scrum Gathering (a.k.a. Scrum Safari) there were a few lightning talks in the afternoon. I was lucky enough to nab the last slot.

Patrick Vine was at hand to capture the talks and they were posted on vimeo by the sugsa committee.

I've collated links to the talks on vimeo with my (somewhat terse) notes from the gathering.

Annu Augustine: Saying No

Step 1: Don't say the word no!
Instead: not now, let's explore, what if?
Listen, understand context, then use the same language
To motivate prioritization, show lack of connection to the goal
Watch Saying No on vimeo

Cara Turner: Achievable Goals

Maybe we achieved it?
Cara took us through how to frame a goal to assist success.
Watch Achievable Goals on vimeo

Brent: Agile Success

How to tame the dragon: we can't tame a two headed dragon
Client induction is important to get on the same page
Working software is different: "We don't build ships like this" -- indeed.
Agile Success

Pat Vine: Fixed Price Scrum

Why? The customer wants:

  • to know cost
  • to reduce risk
  • requirement for tender
Fixed cost helps some things: scope, date.
Backlog management? + on the end
Watch Fixed Price Scrum on vimeo

Carlo Kruger: Your sprint review sux

15 minute tester demo of the sprint!
Ken: no applause please, we're just doing our job. If we pattern praise, bad things won't come out.
Purpose of the review is to inspect and adapt the product, we need to be exposed to failure to expose learning.
If we raise the stakes, we remove space. Rather remove untrusted people.
We are inspecting the work of the whole team in a facilitated conversation.
Format: Set stage, gather data, generate insight, choose focus.
Watch Your sprint review sux on vimeo

David Campey: Agile Contracting

Check-in: who has seen their contract?
There is a tension between customer collaboration and contract negotiation.
We do team weeks with money for nothing, unboxed does pay for points, Gabby Benefield is suggesting a series of fixed price projects.
Some inspection of our contract.
This talk relates to my agile contracting series.
Watch Agile Contracting on vimeo

All in all a great storm of lightning to spark off new ideas. See you at the next gathering?

Posted on Monday, December 19, 2011 by David Campey

1 comment

18 September 2011

All of us at Information Logistics took the break from routine to take part in the Scrum Safari. My mind's still processing the influx of conversations from last week's gathering in Somerset West.

Excellent event as usual, well done to the committee and everyone else who helped out in some way. And thanks to all who came along and made this event great.

Outline of my experience (speaker details):

Day 1

  1. Welcome with Austin / Mitch
  2. Boris Gloger's keynote on Agile and Management
  3. Sigi's Leadership talk
  4. Manoj: "It's about the culture, stupid"
  5. Serious Play with Thorsten
  6. Evening chat
Day 2
  1. Scrum clinic - was both doctor and patient
  2. Lightning talks (with a pop-in at the Agile Jazz and Games sessions)
  3. Lean vs Agile keynote with [x]
  4. Team game of pool to wrap up

This little red scrum user group book is already sporting twenty-five pages of notes to process, so I'll be attempting to linkify the above list with posts over the next few weeks at some point.

Posted on Sunday, September 18, 2011 by David Campey


16 September 2011

For the last while we've been building and putting the finishing touches on our new offices at the Gatehouse in Century City.

The main event is three 20 square metre team rooms. The rooms are visually connected with big glass windows but have closing doors for when things get rowdy (or sensitive).

It's all shiny and new-smelling, the aircon/heating works wonderfully (how often do workspaces miss out on that crucial detail?!) and we have our foosball table plonked in the middle of the common area.

Building has beautiful internal spaces, (scary) talking elevator, wheelchair accessibility, smart lighting, across the road from the Colosseum mini-mall and is a brief walk away from Canal Walk.


Today was officially my first full day at the new offices. I spent today pairing with Luke on some enhancements to his project. We set up a mini task-board and happily hacked the day away.

Looking forward to growing our company in the new space.

Posted on Friday, September 16, 2011 by David Campey

No comments

15 September 2011

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.

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.

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]


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.

Posted on Thursday, September 15, 2011 by David Campey

No comments

In the past we've had the problem of "zoodling" at stand-up ("What to do when scrum doesn't work" Henrik Kniberg SG Cape Town 2010) because you're not quite sure which tasks you've done in the last 24 hours.

One suggestion is only moving tasks in standup; I find this most unsatisfying. It's great to be able to move that damn task in the heady joy of your victory dance.

A small innovation that has made a big difference on our task boards is adding a "Done since last stand-up" column. Move your item there on completion, and it sits there, glowing with goodness for all to see, until the next stand-up.

Done since last stand-up in action

At the next stand-up you just hunt for your initials in that column and you know what you've been doing.

That is if you were actually working on tasks on the board, if not, well it helps to bring people back onto the board, we like our work to be visible.

It also helps to make it visible when people have "gone dark" or their task is taking too long.

And immediately after stand-up the tasks can all move into the Done column.

Posted on Thursday, September 15, 2011 by David Campey

No comments

17 July 2011

This post is still in progress, at the moment it's a lightly marked up copy of my full form speech draft of this section. I'll edit it at some point, but for now at least it's up :)

Series intro

The House of Pain?

The first time I read the manifesto, well... [reverie]...

Who here has read the manifesto? Can you remember the first time you read it?

"we are uncovering better ways of developing software by doing it and helping others do it."

"Through this work we have come to value:"

Did you laugh when you read "working software over comprehensive documentation"?

Did you take a hopeful breath when you read "individuals and interactions over processes and tools"?

Did you shake your head ruefully at: "customer collaboration at contract negotiation"?

Or feel frustrated and trapped at "responding to change over following a plan"?

Maybe you felt exactly the opposite?

Why is this first encounter with the manifesto such an emotional one?

Each of these statements contains within it a tension, between open and free on the the one hand and shut and trapped on the other.


Four Walls

We can view these things on the right as walls drawn in on a floorplan for an engagement. We have a choice how we build those walls.

There are two extremes:

If we choose to build rigid solid, safe, fear-based, spike encrusted walls... we can build ourselves an amazing safe impenetrable, protected ... prison. And live in that prison for months, or years, walking around in the prison yard, feeling frustrated everytime the walls get in the way. But not really knowing what is wrong [ like neo in the matrix]

If we choose to eschew, to disregard, walls entirely, we stand naked in the elements, without a roof over our heads and can end up wandering aimlessly in the wilderness. Like .. hippies flolloping on the hills of woodstock, hey it's fun, it's like cool, um, like what now? Of course, some well knit teams of marines can roam this wilderness, but even they long to have a roof over their heads every now and then.

As neither of these is too attractive, what do we do?

The Buddhists have a concept of right view: "to recognise our ignorance and humbly seek the middle path."

Walking through walls


Very philosophical, Lets make that more real: Riaan goes to visit his friend Lenny at work and starts to notice all the same patterns, but then... someone walks through a wall!

What? You can't just change the scope? You fixed a bug without logging it? That guy just walked through a wall! [gropes around] "Hey, you have doors"

Lenny looks at Riaan long and hard and says, "Uh, yeah, we can walk through walls here." Then to rub it in: "Sometimes we don't get to actually walk through the wall, but at least we can see through it.. we call this a window."

A False Dichotomy


So, these walls can work for us how..

If we look back at the manifesto:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over sticking to a plan

A conclusion it that it is left or right. Or that we have to tread some sort of compromise between the two.

This is a false dichotomy.

[long pause]

Door and Window Makers


The two don't necessarily contradict. The things on the right are walls, and if built correctly can support, facilitate and improve the flow of things on the left.

The problem is the things on the right are often more tangible, sellable, productisable. We can really get lost in processes, tools, contract negotiation, plans, and documentation when dealing with customer. And we can build walls that disregard and limit the things on the left.

This is why we have to keep these values in mind at every turn while designing and improving our houses.

Scrum, xp and friends contain frameworks, patterns and methodologies of getting through or over walls, And sometimes.. a wrecking ball, sometimes an idea, and sometimes designs for doors and windows that we can build into these walls.

History Lesson

[UR, sit] [history lesson] snowbird, light, xp scrum, fowler on head, cockburn: lightweight lightweight.

Here I related the history of the manifesto, particularly that the manifesto is the meeting of the minds of the door and window makers, who sought to share and find the essence of their door and window patterns.


The key to achieving success in all of this is recognising our values, recognising that we share those values [look SR] with the client, and making sure that our decisions to build are informed by our shared values.


This is known as alignment. Long term relationships are built on alignment.

In the words of Seth Godin:

"Alignment isn't something you say. It's something you do. Alignment is demonstrated when you make the tough calls, when you see if the thing that matters the most to you is also the thing that matters the most to the other person."

It's a search engine wanting to give you search results as much as you want to get them.

Or a holistic market that wants to give you healthy food as much as you want to buy it.

Or a software company that wants to give you great product as much as you want to buy it.

And so?


So how does this relate to contracting? We now have some background to how I think about these agile values and can now use this foundation to deliver some of our own medicine to the values. Then I'll show you what we do at IL and the financial bits.

Posted on Sunday, July 17, 2011 by David Campey

No comments

10 June 2011

In this series of blog posts I'll be posting the content of my recent talk at SUGSA Cape Town. Read Cara Turner's Event Report for a good overview.

These posts will be mainly based on my original speech notes; the video with actual content will be up at some point soon.


My fellow software developers.
It gives me great joy to be looking out at people who care about getting better at creating software.

Tonight I'll be talking about contracts. Huh? Has this guy not read the manifesto for agile software development? we should be talking about customer collaboration, not contract negotiation, right?
Maybe. Just maybe I'll show you how our contracts can facilitate customer collaboration.

Tonight I will share with you
  • some of my insights into the manifesto for agile software development,
  • then give our contracts some of our own medicine, to see how we can get them to jump through hoops
  • how this works at Information Logistics and
  • then finally present a few financial models that support agile contracting.


These will be linkified as soon as they're written, for now they're promises.
  1. House of agile
  2. Our own medicine
  3. Information Logistics — company
  4. Financial Models — graphs based on Peter Stevens' 10 Contracts

More talks

I've subsequently presented some of this material as a lightning talk at Scrum Safari 2011. It's also been proposed as a topic at Agile Africa 2012

Posted on Friday, June 10, 2011 by David Campey

No comments

02 May 2011

This post details getting Hudson to automatically poll a bitbucket mercurial repository and deploy the google app engine python hello world project.

Debian install

Just installed hudson on our Debian Lenny box using these useful aptitude instructions.

hg plugin

To get the plugin to install, go to the Hudson admin page, and manage plugins, then select available plugins. You should see ... nothing!

A careful reading of installing plugins hints that this is expected behaviour, since hitting this page starts the download and a restart is required to see the plugins.

In my case a reload of the page was sufficient and, then I had the long, long, list of plugins available.

Tick box, click install, see the above success screen.

Click button, restart hudson, ready to go.


This required some playing about, I was trying to do as little as possible; as it turns out I haven't needed the jdk or any of the other config paths, just click create new job.

After entering the details of my bitbucket repo (and turning off private, have to figure out login), setting it to poll the repo, and figuring out an appropriate shell command, e.g.

/home/campey/google_appengine/appcfg.py update $WORKSPACE --email=dev.campey@gmail.com --passin < /home/campey/dev.campey.password

the build runs on save! And fails — red globe!

First run failed because I hadn't changed the app name. So back to app.yaml, edit, hg commit, wait, ... and blue globe!


Next steps: getting the dev server to daemonize for local/grid testing.

Posted on Monday, May 02, 2011 by David Campey

No comments