One of the principles that is the foundation of the web project is the ability to not only be open in what we do, but also to make things available early and often and continually assess how we’ve performed as a team.

Agile is a project management methodology that allows us to do just that. Just over a month ago the Web Services team went through Agile SCRUM training that gave us the foundation of knowledge we needed to implement it effectively. Knowledge is one thing, but putting it into practice is a whole other thing!

We decided to try it on a small project to start with before ramping it up to larger projects. Doing the setup for the alpha project seemed like a prime candidate.

The planning

At the core of this process is properly planning out each step of what it is we want to do so that we properly understand the problem. We’ve tried lots of tools for this in the past, but by far the most effective way to do it is just a big space on the wall, and lots of post it notes! We tend to think of planning as a waste of time and something that just gets in the way of getting things done. However experience has taught me that the time you spend planning generally saves you time elsewhere.

Once you’ve got each task laid out, you can then give it an indicative size. Lots of SCRUM teams will do this differently, but at the moment we do this based on T-Shirt sizes (XXS, XS, S, M, L, XL). Once we get the hang of this, we’ll change to proper numbers, but at the moment we’re doing it this way just to differentiate what are small tasks, and what are bigger ones that might need to be split up further.

Core to this process is the idea of a sprint. A fixed period of time in which you have to deliver something. For our purposes, we find that a fortnight is long enough to get a fair bit done, but short enough that we can still evaluate how things are going on a regular basis. The important thing to remember is that the tasks you take into the sprint, you’re committed to delivering by the end of it. This presents a number of interesting problems.

  1. Estimating how much you can get through
    The sizing helps with this, but it’s amazing how things can often take longer than you think. The nice thing about SCRUM is that whilst we try our best to estimate, we know we’ll get it wrong. However the more we do it, the more accurate our estimations will get.
  2. Taking things in that are not ready to start
    This is something we’re really bad at currently. It generally happens with a task that is blocked at the start of a sprint, but we’re “fairly sure” we’ll get unblocked by the time comes to do something. It very rarely happens that way. To help us out with this, SCRUM has the idea of a “definition of ready”. If we can’t start on it straight away, or its blocked on an external dependency, then we don’t take it into the sprint.
  3. What does done really mean?
    If there’s a “definition of ready” that allows us to start, there’s also a “definition of done” that allows us to say we’re finished. What that definition is generally changes depending on who you are speaking to. So identifying it at the start of the sprint helps us all out.

Finishing the sprint

If planning is important to the start of a sprint, a “retrospective” is equally as important at the end. It allows us the time to look back on the last two weeks and think about what worked well, what didn’t, and what we’ll improve for the next sprint. Like the planning, it’s a whole team activity where everyone has their say.

It was our first proper sprint, so we didn’t expect to get everything right the first time, but that’s ok! What we’ve identified coming out from this is a list of things that we did well, and things we need to do better. These were

  • We all had a better idea of what was happening
    Overall, there was less confusion about the tasks currently going on in the team, and how they fitted in with each other. That made it easier to solve problems early on rather than letting them lie till the end.
  • Properly defining what we mean
    It’s amazing how different people interpret things differently. Had we taken an extra couple of minutes during planning to properly expand on our definition, we would have saved ourselves a lot of work in this sprint.

The outputs from the retrospective then feed into the next sprint planning. Overall we spent about half a day as a team planning out this sprint. Whilst that may seem excessive, it threw up a lot of things that needed discussed that wouldn’t otherwise have been raised until we had launched. If it had got to that stage, the things raised would have added at least that amount of time back into the project before it was able to be delivered.

It’s always hard implementing a new methodology, but the only way to do it is to actually do it. So, onwards we go!