Two books that have had a great influence on my productivity over the last six months have been The 12 Week Year and Deep Work.
This week we adopted a new practice: planning poker.
Like many teams starting out with Agile practices we didn’t just jump in feet first and adopt every Agile method going; that would have been too much to take in. So we began with a few methods:
The photograph above, taken a couple of months ago, shows the planning board in our office — an information radiator — that shows us at a glance how many tasks are left to do, what’s currently being worked on, what’s in testing, what’s done and (unlike, I would guess, most other Agile boards) what we’re waiting for.
By definition Agile really should be used by teams working on one project at a time. It’s simply not efficient working on more than one because as soon as you start switching between different projects you lose time. One reason is that it takes time to get back up to speed with project B after working on project A.
However, some of us have no option but to work on more than one project at a time, as well as juggle support emails, telephone calls and the like. In which case you simply have to adapt the principles of Agile to accommodate more than one project, and essentially run them all in tandem as though you were working on multiple threads of a single project.
Karl Scotland, formerly Development Team Leader with BBC Interactive wrote a really useful paper back in 2002 entitled “Agile planning with a multi-customer, multi-project, multi-discipline team” (DOC, 225 KB) in which he explained how he ran things at the BBC where they would regularly work on three projects simultaneously.
We currently have 19 projects on the go at the moment. Which is far, far too many and we need to do something about it. So this week we revisited our project backlog and introduce a new Agile method to the mix: planning poker.
The idea behind planning poker is very simple: “planning poker is a consensus-based estimation technique for estimating, mostly used to estimate effort or relative size of tasks in software development” (Wikipedia).
Each member of the team had a pack of cards (I made our cards using Microsoft Publisher 2007 and a handful of skills) which have a sequence of numbers printed on them. They are quite often close to a Fibonacci sequence to reflect the uncertainty in estimating larger items. Our pack uses the sequence: 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, a ? (unsure) and a coffee cup (I need a break).
We then took each item in our project backlog and after an explanation of what was required we all took a vote on how difficult we thought it would be as a project, placing the cards down on the table at the same time so as not to influence another player’s estimation by laying your card earlier than them.
Once voted, unless the group has a consensus the person who laid the lowest-value card and the person who laid the highest-value card explains why they thought it was easier (they’ve done this before, for example) or harder (what did the others miss?).
Votes are taken again until a consensus has been reached and then the team passes to the next task or project on the list.
We found it a really useful exercise because it actively encourages everyone to speak and gives everyone an equal say in the decision-making processes associated with managing projects. We really quickly got to the core issues related to each project and at times an interesting spectrum of scores (13, 20, 40 and 100 for one project).
Our next stage is to complete the scoring on the remaining <cough> 60+ projects, and work with our boss to prioritise projects. That should give us an overall score (estimate x priority) which will enable us to more accurately plan when we should schedule these projects and in which order. For example, you don’t really want to be tackling three really taxing projects at once.
Oh, and it makes the task of planning much more fun.
If anyone wants a copy of the cards I made (in PDF format) drop me a note in the comments and I’ll upload them for you.
Luis Goncalves, co-author of the excellent book Getting value out of Agile Retrospectives has written a really useful article about planning poker: