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

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

We decided to try it out on a small project to start with before moving on to larger projects. Doing the setup for the alpha project seemed like a great candidate.

Planning

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

Once you’ve laid out each task, you can give it an approximate size. Many SCRUM teams will do it differently, but we currently do it by shirt size (XXS, XS, S, M, L, XL). Once we understand this, we’ll move on to the correct numbers, but we’re currently doing it this way just to differentiate which are small tasks and which are larger ones that may need to be broken down further.

Central 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 do quite a bit, but short enough that we can still gauge how things are going on a regular basis. The important thing to remember is that the tasks you take on in the sprint, you commit to deliver by the end. This presents a number of interesting problems.

1. Estimate how much you can overcome
   Sizing helps with this, but it’s amazing how often things can take longer than you think. The nice thing about SCRUM is that while we do our best to estimate, we know we’re going to get it wrong. However, the more we do this, the more accurate our estimates will become.
2. Taking things that aren’t ready to start
   This is something we are really bad at at the moment. It typically happens with a task locked at the start of a sprint, but we’re « pretty sure » we’ll get unlocked when it comes time to do something. It very rarely happens this way. To help us with this, SCRUM has the idea of ​​a « definition of ready ». If we can’t get started right away or it’s blocked by an external dependency, then we don’t bring it into the sprint.
3. What does it really mean?
   If there is a « definition of ready » which allows us to get started, there is also a « definition of done » which allows us to say that we are finished. What that definition is generally changes depending on who you’re talking to. So identifying that early in the sprint helps us all.

Finish the sprint

If planning is important at the beginning of a sprint, a « review » is just as important at the end. It gives us time to look back on the past two weeks and think about what worked well, what didn’t and what we will improve for the next sprint. Like planning, it is a whole team activity in which everyone has a say.

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

• We all had a better idea of ​​what was going on
  Overall, there was less confusion about the tasks currently going on in the team and how they fit together. This made it easier to fix problems early on than let them lie to the end.
• Correctly define what we mean
  It’s amazing how different people interpret things differently. If we had spent a couple of extra minutes during planning to expand our definition properly, we would have saved ourselves a lot of work this sprint.

The retrospective outputs are then fed into planning for the next sprint. Overall we spent about half a day as a team planning this sprint. While this may seem like overkill, it brought up a lot of things that needed to be discussed that otherwise wouldn’t have been brought up until launch. Had it gotten to that stage, the things raised would have added at least that amount of time to the project before it could be delivered.

It’s always difficult to implement a new methodology, but the only way to do it is to actually do it. So, let’s go!