What I learned from falling off my bike and how these learnings apply in a Scrum context.
The Setup
Last week I got an invitation from my friend to go on an offroad motorcycle trip. He had two bikes – a BMW and a KTM – that we could take turns riding so that we could feel the difference and get the experience of riding both.
We were planning a one-day trip leaving in the morning and getting back before dark. I was surprised when I saw my friend come packed as if we were going away for a week. He had his bike loaded with tools, spare parts, etc. When I asked why he said that you never know what you’re gonna need and that it’s easier for him to pack the same way regardless of how long the trip will be.
So, off we went on a sunny morning, leaving the city and heading towards the mountains. We were avoiding highways and following smaller local roads which are winding and more fun to drive on a motorbike. It was still early in the morning with few cars on the road. We were driving peacefully and chatting with each other over the intercom (two-way communication between the bikes).
The Accident
As I leaned the bike into the next curve, I understood that the turning radius was not enough and I was departing from the middle of the road towards the shoulder. I tried leaning the bike a little more but realized too late that I was still going wide. My front wheel hit the unpaved shoulder and lost its grip. I slid and continued sliding with the bike towards the guardrail installed along the swing. In that split second, I thought, “How stupid! We haven’t even reached the mountains and the hard part of our trip, and I am already falling.”
In the next second, my bike slid under the mid-rail, and broke three wooden posts of the guardrail before coming to a full stop. I was caught between the bike and the guardrail and could not get out.
My friend stopped his bike and came over. He asked if I was ok and I replied that I was fine but that I was stuck under the bike and could not get out. We tried to lift the rail but it was not moving.
Another guy pulled his car over and offered help. Together, the three of us pushed the guardrail up, using the tools from my friend’s toolbox as a lever. We finally managed to lift the rail half an inch which was enough for me to finally pull my feet out.
The Aftermath
I was able to stand up and do some damage assessment: scratches on my left side, both shins were bleeding and both of my feet were compressed (left one stuck between the bike and asphalt, right one between bike and guardrail), but otherwise I was in one piece with nothing broken.
In the next half hour, we managed to get the bike out and were surprised that the bike, just like me, merely had some scratches on its plastic parts with no major damage. It was unbelievable! If you take a look at the side of the wooden posts that I broke with the bike, I still can’t believe how lucky I was.
The Learnings
Now its time to extract all the learning:
- Remember that my friend packed his bike as if he was going on a long trip? Having tools and spare parts with us really saved our day. You never know what you might need so pack conservatively, thinking about all possible options.
- This was my first time on this bike. I should have been much more defensive with my driving. Never project your experience into a situation with new equipment.
- At the moment I fell I was talking over the intercom with my friend. Who knows, maybe those few instants of focus and attention that went towards talking could have made the difference of me staying on the road.
- As an afterthought, I feel that I might have driven even slower if I was leading and not following my friend on the road. Remember, put your weakest drivers (those with new equipment, not in the mood, less experienced, etc) forward and let them set the pace.
And finally, we can convert these learning points from biking into the world of work:
- Preparation. When your Team prepares for a sprint, think about all the things that might go wrong during the Sprint. Do you need to do anything special in the Sprint planning when you still have time? Can you make some arrangements and agreements with external parties that might help, if something goes wrong?
- All things new. Do you have a new Teammate? Will you be using some new technology? New software? New procedure? Something that your team never used before or used little? Plan defensively. You might need more time than usual so make sure to set it aside.
- Focus. Doing one thing at a time – focusing all the attention of your Team on one item – reduces the likelihood of failure. That’s why one-piece flow approach is popular among hyper-achievers.
- Let the weakest/least experienced people on your team set the pace of work. Don’t plan based on your optimistic estimations and not even on averages. Nothing happens if the team under-commits and over-delivers, but I guarantee you big drama if you do otherwise.
Most importantly, stay safe, Stay Agile!
– Sergey
