Part 1: Speed is a false friend
It’s a chilly spring day and I’m walking around the bend of a country road in the middle of Hertfordshire, England. I’m on a training ride with a volunteer from the Institute of Advanced Motorcycling, an ex-police rider, preparing for my exam. “Any idiot can ride fast in a straight line!” John is showing me how to get the ingredients right to carry speed through a hairpin bend. What line to take, when to break, where to look and when to accelerate. All done safely.
“Don’t ever focus on speed. Get the inputs right and speed will come ”.
Get the ingredients right and riding a powerful motorbike feels amazing. You are in the zone, the right line into the bend for the best view out of it and the perfect timing of opening the throttle as the bend straightens out. Plus looking ahead as far as you can see for turnings, tractors, cyclists, horseriders just about anything which is going to be a ‘hazard’.
Working in agile teams, I see similarities. Like comparing the agility of a car to a motorbike, agile teams can accelerate, change direction and stop more quickly plus have fun while doing all of it!
However, I also see Agile was being used as a way to focus on speed of delivery, often because reduced cost is perceived as the value of delivery speed. However, without due care and attention to getting the ingredients right, just like the motorbike, you can end up careering into the nearest proverbial hedge!
Unlike my car, which has anti-lock brakes, airbags and crash bars, the margin for error on the bike is zero. If I get it wrong, I’m in the ditch or worse.
So here are my top three ingredients to avoid the agile ditch:
- build a deliberate combination of skills of the team members (both soft and hard skills!). You wouldn’t jump on a bike without any training or awareness of strengths and weaknesses right? If you are using Agile as software development methodology, it can realistically take 3 months to get a high performing team working well;
- Look up! Spend time creating a clear, single, shared vision of the goal of the project i.e. which bend you are looking at! Keep that focus on the vision. The best tip I had on the motorbike was:
Look where you want to go, not where you are going
In motorcycling that means actually turning you head to look around the bend and not at the hedge rapidly approaching! In software, that means getting the right shared language, drawing sketches of architectures to make sure everyone understands the same thing and having good conversations. A mantra that stuck with me from Jeff Patton’s book, User Journey Mapping [linked reference] is:
“a shared document is not a shared understanding”
- autonomy i.e. ability and freedom to choose a course to meet the goal. Rather like the pillion rider dictating which line to take just before the bend… sponsors of agile teams need to trust them to deliver. Most common pillion behaviour I’ve experienced in software delivery is someone else suddenly grabbing the brakes! For example, re-deploying one of the key members of the team to another ‘more critical’ project.
Hopefully, thinking of agile like riding a powerful motorbike round twisty roads will stop you fixating on speed alone and be reminded of the value of getting the ingredients right. Focus on building the right culture, mindset and goals and the speed and success should follow.
Happy riding!
