I am blessed to live in Northern California, where our relentless commitment to preserving open space means that the San Francisco Bay Area boasts a wide variety of preserves with all levels of single track. Favorite trails reward mountain bikers with forests, meadows, creeks, and fantastic views of the San Francisco Bay and the Pacific Ocean. About two years ago we took a family vacation to Moab, Utah — a mountain biker's paradise — and we were hooked. We invested in the bikes, protective gear, trail maps, and eventually a GPS. I've been practicing Agile in its various forms for about 11 years now, and on a recent ride it dawned on me how similar the two pursuits are.
Bend your knees
If you play any sport where balance is important, the first thing you learn is about your stance. In almost every case, the first thing you learn about your stance is to bend your knees. It helps your body react to the need to change direction, jump, and stop. In the case of mountain biking, bending your knees helps you better cope with the ever-changing terrain beneath you. You're constantly assaulted by rocks, branches, dirt, or whatever else is on the trail. Bending your knees is the best way to cope, so that you "float" over these small obstacles.
In Agile, we embrace change as a fact of life; we even plan on change. Instead of dreading or trying to control change, we "bend our knees" so that the team can more easily float over daily distractions and disruptions.
Lift your gaze
One of my first times out mountain biking, I found myself staring intently at the ground about three to five feet in front of me, trying desperately to steer my front tire around every obstacle. I was constantly nervous and anxious, not wanting to peddle too fast for fear of making a mistake, and I was constantly surprised by the change in elevation, so that every climb up a hill (no matter how small) was a grind. My coach (aka my husband) said, "Lift your chin so your gaze is about 100 feet in front of you. Only glance down as necessary." What a difference that made! I could now plan so much more of the ride, taking into account changes of elevation, technical sections, and even getting a chance to enjoy the scenery. I stopped sweating over all the small stuff under my tires and learned to trust that my bike would ride over all those small rocks and ruts I was so obsessed with.
In Agile, we insist on all layers of planning all the time — product, release, sprint, and daily plans all inform each other, as does real-time feedback from production. As an Agile leadership team, if we make sure we "lift our gaze" ahead to each upcoming release, and even to multiple releases ahead, we can build up enough momentum (think of a runway) for the team so that it can more easily execute on its sprint-level and daily plans without the constant scrutiny (and disruption) of management intervention.
Earn your downhill
We recently rode on a trail at the top of Skyline Ridge called Crazy Pete's Trail. We parked the car at the top and rode Crazy Pete's Trail through some fantastic downhill, descending awesome switchbacks, jumping logs and dodging branches and rock outcroppings. We got to the bottom and celebrated with high-fives and proclamations of "What an epic downhill!" Then it dawned on us. We had to ride back up that trail to get back to the car. We seriously considered abandoning the car, but in fact we spent the next hour-plus climbing slowly back up and bemoaning the effort involved. After that experience, we always planned our rides to front-load big climbs so that we could feel like we'd earned that thrilling downhill.
In software development the equivalent experience is the pilot. All too often we peel off the easiest scope to implement and put it into production, with much fanfare and good feeling, and call it the pilot. Then we turn our attention to the next set of scope priorities and find out that a lot of that work is hard. This often leads to long gaps between the launch of the pilot and the launch of a true Release 1. Agile values insist that we face our fears early and work on the riskiest/most difficult scope items in our first sprints. Agile embraces integrating systems early and often during the development of a release. This way we can enjoy implementing some of the easy scope along the way, knowing that we have indeed "earned" it.
Enjoy the journey
On the first couple of trips I was really busy getting oxygen into my lungs, focused on shifting properly, picking a precise line through technical sections, and trying to bike "perfectly." Then I fell. It hurt. Then I fell again, and again — and, well, you get the idea. Sometimes you fall for really good reasons (for example, learning to lean your bike at just the right angle to descend through a sandy switchback — got that one wrong a lot). Sometimes things just happen, and you fall. We have a saying in in our family: "If you're not bleeding into your shoe, keep peddling." We bike as a team. We encourage each other, celebrate our own mini-accomplishments with shouts of "Cleaned it!" and laugh at ourselves, making sure that everyone in the group has fun. It's not about finishing "first" or "best" but enjoying the journey together.
In software development projects, all too often we bemoan mistakes, sometimes even seeking blame. We try to optimize decisions so much that we're often paralyzed into making late or no decisions (which in itself is a decision). Agile encourages teams to take risks, make mistakes. Embrace your falls and learn from them (maybe even laugh), but then get right back on that bike and peddle. We celebrate the small things in Agile by doing brief retrospectives at the end of every sprint. It's the equivalent of shouting out "Cleaned it!" or voicing an encouraging word to a teammate who accomplished something difficult.
Agile — like mountain biking — is a group project. Enjoy the journey.
Photos from a vacation trip to Stanley, Idaho, in pursuit of single-track mountain biking