In roller derby, as in many sports, speed is really important. So much so that as part of the minimum skills (which you have to pass before you can play) you must be able to skate 27 times around a derby track in 5 minutes. Depending on the route you take a round the track, 27 laps is around 1 mile (1.6 km) so the test requires that you skate at an average speed of 12 miles per hour (19 km/hr) for 5 minutes.
At nearly every practice we see how may laps we can do in 5 minutes. When I first started skating I could only do around 10 laps in the time allowed. I had to work on my technique through such things as skating the most efficient route around the track (known as skating the diamond) and also by developing my skating skills, particularly around getting power out of my cross overs (when you cross one foot over the other when going round a corner). I also had to work on my cardiovascular fitness and strength, to give me the endurance which I needed to keep going.
Every time I trained I tried to improve my personal best and over time I was able to skate faster and better. If someone can already skate 27 laps in 5 minutes then they push to go even faster and are always looking for their next personal best. This makes sense for a game like roller derby where being fast can help you to get out of situations and could also increase your scoring.
This push for personal bests also seems to be prevalent in the agile world. I often see managers judging teams on their velocity and expecting them to increase their velocity over time. Rather than velocity simply being a measure of what a team has achieved in the past and using this as a guide to what the team can achieve in the future it is more and more being used as a stick to beat the delivery team with.
One organisation I joined had a team which was failing. Everyone knew it was failing; the managers, the other teams, the team itself. They consistently brought around 45 points worth of stories into the sprint and consistently delivered around 30. The Scrum Master asked me if I’d run the next retrospective to help them find out what was wrong with the team. It turned out that the team brought 45 points into every sprint because the Scrum Master had calculated that in order to meet the delivery dates they would need to achieve a target velocity of 45 points. He had also planned exactly which stories should go into each of the sprints up front. This wasn’t a failing team; it was a failing Scrum Master. It would have been a really useful to have understood early in the project that the team would be likely to take 50% longer than planned to complete the project. It would have enabled conversations around additional staffing, allowing more time, reducing scope or cancelling the project. This is one of the real powers of agile, giving this type of information early in the project when decisions can be made before too much investment has taken place.
A velocity should never have a target or be expected to increase over time. It is a measure of what has been and is the best predictor as to what will be. It has the power to give you information about likely future scenarios which allow you to make more meaningful decisions early. The next time you demand a ‘personal best’ from the team just stand back and ask yourself whether what you are doing helps or hinders the team in their delivery. If the result of your behaviour is that the team doesn’t feel respected then it’s unlikely to result in an increase in productivity.
Louise Elliott (@IvanaTerrorBull) 