Or: how we stuff our Sprints
Any player of Dungeons & Dragons (or, for a different flavour of geek, nethack) would love a Bag of Holding. You can put in as much stuff as you like (coins, swords, unconscious friends) and yet it never gets full. No self-respecting adventurer should be without one.
We have a variation within our implementation of Agile Development – it’s the Bag of Stuff To Do. It’s similar to the Bag of Holding in that we can stuff in as much as we like, but like its evil twin the Bag of Tricks, there remains a non-zero chance of being badly bitten.
Stuffing the Bag
In our Sprint planning meetings we decide what to put in the forthcoming sprint. As I’ve blogged before, it’s difficult to plan this bit right. In theory we have a well-groomed backlog of work; we can siphon off the right amount and commit to getting it done.
I’ve also blogged on the potential for our daily Scrums to descend into blandness. This is particularly apparent when we’re working on different projects. One developer is working on the FRAP system; another on file export; two or three more on new measurements capability. There’s three stories here, all of which have been bundled together and put in the Bag of Stuff.
We’ve decided that these three things are our priority for this Sprint. Or rather, we’ve decided that a certain fraction of these are our priority. We’ve broken down larger tasks, packaged them up with User Stories, and are happy (ish) that we can get them done. All very clever, well done us.
Alas, our Bag of Stuff cannot hold anything large – and the larger the contents, the harder it is to squeeze them out. If we put in two ironing boards and a lampshade, chances are at least one of those will get stuck.
What we should really fill the bag with is sand. That way, we can …
No, wait, metaphor fail. Let’s talk actual tasks. What we should fill the sprint with is small tasks, that we can all pick up and complete. We’re quite good at this – we have a good parallel skill set in the team – but still, we’re dishing out big, sprint-long projects to individual developers and letting them get on with it.
What fits the “sand” metaphor? Well, we could do nothing but fix bugs. Bugs are (usually) small, equally hard for everyone and the whole team gets to work from the same pool of tasks. But we don’t have that many bugs.
So instead, we could focus the whole team on only one thing. Pick a task, and ensure everyone is working toward the same goal:
“After this sprint, our software will be able to make tea.”
Then everyone works on this task. No exceptions. If we make the effort to break “Make Tea” up into bite-sized, parallelisable chunks, we can keep our focus, and work as a team.
Even if a sprint is only two weeks long, we can concentrate on one feature and get it nailed.
There’s some problems, of course. Bottleneck tasks, which must be done in a certain order. Hardware – only one person can work on the FRAP system at a time. And bugs must be tackled, a tide of infestation that must be herded and culled each sprint. But bugs can be tackled whilst bottlenecks are squeezed through; and UI design doesn’t require the hardware.
In upcoming sprints, let’s not just stuff the work we’d be doing anyway into an awkwardly-sized bag. Let’s have a clear Primary Goal for the whole team, and write it on the Scrum Board in BIG LETTERS. Then we can tackle the goal as a team, and actually work together towards our product development’s top priority.