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 Unknown

2 comments

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.

Joy.

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 Unknown

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.
[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.

Posted on Thursday, September 15, 2011 by Unknown

2 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 Unknown

No comments