We have now been using Scrum to manage our projects for a couple of months, and my experience is that it has completely transformed the way we work.  It has resulted in more communication and collaboration between team members, and given people the opportunity to do tasks that they wouldn’t normally have selected or been allocated.  It also breaks tasks down into manageable chunks, and makes you feel like you’ve achieved a lot by the end of a sprint.  Which, in fact, you have.

Scrum, by Roy Skeane

To start with, I thought the name was a bit macho, and wondered if team meetings would start to look like a bunch of rugby players arguing over a strange ball, but in the event, they have been very civilised.  Daily meetings are also very focused, as you are only required to say what you did yesterday, what you plan to do today, and anything that stands in your way.

You’re also allowed to move cards across from “In Progress” to “Done” as soon as you have done them, which keeps the sprint board as an accurate representation of the current state of the project, and gives you a tiny buzz as you move your task card across.  It’s kind of like a team version of Getting Things Done (GTD) with the sprint board as a giant Hipster PDA.

I have also found that usability and information architecture are addressed much earlier and more frequently in the product development cycle, which is good.

Planning Poker, by Improve It

The other thing I like about Scrum is the varied format of the meetings.

There’s Planning Poker, where everyone estimates the complexity of tasks using a series of cards with numbers (more-or-less from the Fibonacci sequence) on them.  This makes the estimation easier because it’s about the size and complexity of tasks relative to each other, rather than an absolute measure of the task.  The placing of cards by the team members means that you get individual views of the task size without group dynamics influencing it.  Then these converge towards consensus as the people with the outlying estimates explain their reasons for their estimates and everyone then votes again.  It’s much quicker than discussing it.

Sprint retrospective, by Improve It

Then there’s the retrospective meeting, where we look back at the sprint as a team.  We have found the easiest way to do this is for everyone to write down what they thought were the significant events in the sprint on Post-It Notes.  For our last retrospective, this included one that said “Snow”.  Items can include tasks in the sprint, the way the team worked, or impediments.  Once this phase is done, everyone goes round and marks the Post-It Notes with stickers (blue for what we did well, yellow for what we learnt, red for what we should do differently, and orange for what puzzles us).  We then arrange them with the ones with the most stickers at the top.  This gives us an overall picture of the sprint; there is then a brief discussion of the picture that has emerged from the retrospective.  The whole thing takes about 20 minutes.

Another great feature of Scrum is the clearly-defined channels of communication, as the Product Owner represents the users and the Scrum Master represents the development team.  Also the Product Owner is  involved in several of the meetings, which gives them more opportunity for feedback on the product as it is developed, and makes the development process more agile and responsive to user needs.