Back in April 2008 I attended the Scotland on Rails 2008 conference in Edinburgh; I literally have the t-shirt to prove it. It was an absolutely fascinating (read: über-geeky) conference let down for me slightly by the fact that I really didn’t have a clue what they were talking about most of the time as I had only just begun to explore Ruby on Rails.
It really was the most hardcore conference that I’ve ever attended. Most of what was said went way over my head as the speakers went into minute details about which new functions were available in Ruby 1.9 (does Ruby even have functions?! See: not a clue!), advanced class design, and there was even a talk called “Bonus Erlang Session”. That could be the name of an experimental band from Germany for all I know.
But there were a couple of things that I really enjoyed, one was the keynote speech by David Black which was just inspirational (check it out on iTunes, it’s called The Flying non-Scotsman: or, My thirty-two year trip from the Borders to Edinburgh), the other was the number of speakers who kept talking about BDD (Behaviour Driven Development), SDD (Story Driven Development) and Agile.
O’Reilly had a book stall at the conference with a 10% discount. So I bought this book: The Art of Agile Development by James Shore and Shane Warden. It’s a great book that gave me a thorough grounding in Agile and XP practices and processes. I thoroughly recommend it.
Fast forward a year and a half to December 2009 and there we were, a rather broken-looking Web team sitting around a table in Web HQ staring at a spreadsheet listing over 120 requested projects.
In The Art of Agile Development the authors write
XP assumes that customers have the most information about value: what best serves the organization. Programmers have the most information about costs: what it will take to implement and maintain those features… A successful plan needs to take into account information from both groups, as every decision to do something is also a decision not to do something else.
Taking that to heart, that we had the most information about costs, we sat down over two days and played planning poker using home-made cards with the list of projects.
Agile planning poker cards (PDF, 24.5 KB)
Planning poker (or the ‘planning game’) is normally used by teams to estimate individual tasks in a larger project, but we used it to estimate the size of projects themselves.
We looked at each project one-by-one on the list. Whoever knew what it was about would explain it to the rest of the group, something like
Okay, so this project is about replacing the virtual tour movies on the website, which are currently QuickTime movies, with the same movies but in Flash format.
Once we had enough detail we would silently vote on the complexity of the project. We used homemade cards (you can download them above) using a sequence that was loosely based on the Fibonacci numbers. Our cards used 0, ½, 1, 2, 3, 5, 8, 13, 20, 40, 100, ? and Break.
Each player would select a card and then at the same time everyone would lay their cards out on the table. We were looking for a consensus of opinion. As I was facilitating the process I would invite whoever laid down both the lowest and the highest values and ask why they scored it that way.
That’s where the real value in the process came in. It gave everyone an opportunity to speak about every project.
Someone who scored it low might say something like:
“Well, I scored it a 2 because I’ve done this before and it was really easy. We just need the source Flash files and then we already have a media template for Flash movies so it’ll take no time at all”
Then the person who scored it more highly might offer something like:
“See, I gave it a 20 because it’s not as straight forward as it initially looks for a couple of reasons. We do have a media template for Flash movies but it doesn’t allow us to embed multiple movies on the page. And then there is the issue about lack of Flash support for iPhones and iPads. Should we be thinking about going down the HTML5 path?”
Having heard the evidence we would vote again until we had a consensus. Sometimes we would end up with three 13s and one 20, for example, in which case I would ask the person who scored it 20 if he was happy for it to be given a score of 13 or if he felt very strongly about the 20.
It was a really useful exercise.
By the end of the two days we still had a list of 120+ projects but each project now had a value indicating how difficult or complicated we reckoned each one was.
We took this list to our boss and she prioritized them, according to the factors that she was aware of and how they fitted in with wider University priorities and projects. P5 was high, P1 was low. Over 20 projects got binned straight away.
By the end of day three we now had a list of just under 100 projects but we now knew the approximate size or complexity and their priority. The project list didn’t feel quite so daunting. We also, crucially, had the commitment from our boss that all new project requests should first go to her.
We then used this list to start disengaging from and postponing half- (or hardly-) completely projects that had a low priority. Most people, to be honest, were very understanding.
Next post I’ll finish this series by explaining how we broke down our projects, what we’re doing now and where we’re hoping to go. I’ll also take a look at Agile tools that we’re using.