The boy looked to be four or five years old. He was laboriously pushing the pedals of his bike, hands gripping the high handlebars. His mom walked slowly beside him.
I bit my tongue as they passed – I wanted to tell the mom that training wheels are so last century! That my grandson is not yet three years old, but he is whizzing around the neighborhood on his balance bike. His dad can barely jog fast enough to keep up.
Once you’ve seen a two-year-old buzzing around on a balance bike, you know the four-year-old struggling with training wheels is using the wrong process to learn to ride a bike. It’s much more important to learn balance, steering and stopping than it is to learn how to pedal.
When I observe teams using Scrum ceremonies that are two decades old, when I see roles that effectively put proxies between the engineering team and the problem to be solved, when I see a company struggling with a scaling process – I see training wheels. It’s time to call out these practices for what they are – processes that focus on the wrong thing, that remove feedback from the system, that distract teams from learning simpler, faster, more relevant ways to develop software.
We are living through a Black Swan event – one that has taught many organizations how to turn on a dime and reconfigure their supply chains, their customer interaction models, their product delivery approaches. Today every store near me offers curbside delivery, supported by a lot of rapid software changes. You can bet these changes were not in the plans a couple of months ago, but they happened, and they happened fast. It feels like a lot of local companies gave their teams balance bikes and let them learn how to scoot, coast, fall down, steer, stop. Whatever it takes – just get curbside pickup working – NOW! Eventually they’ll add the pedals.
2020 has dawned as a decade that will be focused on resilience, adaptability, and rapid response. We need to give our teams balance bikes, not training wheels – but what does a balance bike look like?
First of all, our balance bike operates best without dependencies, and we must acknowledge that dependencies are an architectural problem. Too many companies are trying to solve the dependency problem with process solutions, rather than tackle the real problem – their architecture, both the system architecture and the organizational architecture.
Next, our balance bike riders need to learn to take control of their environment – to balance, to fall, to steer, to brake. We need to stop giving our software teams training wheels: tasks and priorities. Its time for them to tackle real problems, make critical trade-offs, recover from mistakes, make adjustments and keep moving.
Eventually our teams will be ready for pedals – so they can move fast, far, and consistently whenever they want. Software engineers need an execution environment that supports a deployment pipeline, staged releases with automatic rollbacks, and feedback directly to the engineering team so it can figure out what to do next.
The fact is, this kind of balance bike exists in the software world; one example would be Amazon Web Services, and there are many others. We need to get a message through to ‘parents’ that there is a better way to implement software changes than the legacy practices of the 1990’s or the dated practices of the early 2000’s. It’s time to recognize that agile training wheels actually get in the way of the resilience, adaptability, and rapid response demanded by this new era.
________________
Thanks to Joshua Kerievsky, who originated the training wheels analogy.
Thanks to Joshua Kerievsky, who originated the training wheels analogy.