Can agile and DevOps methodologies be applied outside of technology? More specifically, can we apply them to a sport? I decided to answer these questions by analyzing the application of agile and DevOps principles within my road cycling team.
Cycling is a data-driven sport. While training and racing, we have a live feed showing data on our computer attached to the bike's handlebars. This shows data such as power (watts), heart rate (bpm), cadence (rpm), and much more.
Monitoring and analyzing this data allows us to work within our limits to ensure that we aren’t overloading ourselves while performing to our highest capabilities. We measure our limits through tests over time periods such as 30 seconds, 5 minutes, and 20 minutes. The results of these tests form specific thresholds that we work within to maximize the benefits of training and racing. We can set up automated alerts on our bike computer to warn us if we are overexerting ourselves, or we can keep an eye on the screen to measure this ourselves.
In a mature DevOps environment, we work towards monitoring at the service level to understand usage, performance, environment, and application health and more. This doesn’t just help us to find the problem; it allows us to setup self-repair protocols within our infrastructure if the monitoring tools report any alerts.
We run the team like a startup where everyone wears many hats. We operate in small loosely coupled units; everyone rides together without silos, but then we also have specialties that come out during the sessions. For example, the climbers are better at riding fast uphill, so they work together at times, as do the powerful sprinters with the sprinters, and so on. The point is that we don’t segment ourselves solely to these responsibilities—the sprinters still need to get themselves over the climbs, and the climbers still need to practice sprinting. We never know when one of us will need to fill in for a teammate. We understand each other’s roles and the importance of each person within the team.
We learn as we go. We can’t rely solely on one person in the team, even if they are the strongest. Let’s say the A rider has a crash 2 km before the finish—what do we do? The lead-out train all move one place up the line, so the rider who was supposed to be the last one left to support the sprinter in the final move will now be the sprinter. We have set up a self-healing system with very low mean time to repair.
Flip back to DevOps: Some bad code has made it through your pipeline. You can’t rely solely on the person who wrote the code to solve this problem. In the ideal world, we use version control to assist other people within the team to figure out exactly how to repair the issue. We can design the system to self-heal by automatically reversing the failed change to an earlier state.
Everyone on the team understands that they have a cross-functional role. This doesn’t mean that we don’t have specialisms or areas that we like more than others; it just means we are a team of doers. This compares to a team working effectively using DevOps principles. It doesn’t matter if you started your career as an applications developer or systems administrator—you must get the work done and solve problems for the greater good of the organization.
Essentially, your entire role as someone who practices DevOps is to make everyone else’s lives easier by implementing processes and tools that help to increase productivity and reduce errors. In a cycling team, everyone works for the success of the entire organization, not just for themselves.
The DevOps role can compare to that of a domestique in cycling. For context, in cycling, we ride directly behind the wheel of the person in front, with maybe an inch between our front wheel and their rear wheel. We do this because it uses approximately 30% less power for the person behind. The domestique is responsible for making the other person's job easier. They don’t work for individual glory but sacrifice themselves for the greater good of the team.
The DevOps architect or engineer in your organization (Disclaimer: Yes, I believe that it’s everyone’s responsibility to practice DevOps methodologies, but often there is a person who has the strongest knowledge of DevOps and how to implement it across the organization) does not spend their day thinking about how to show off about some awesome code they wrote or the system they built. They are thinking about how to make your day-to-day processes easier and solve problems for the good of the team.
Image by: Victor Chan, oneimagingphotography.smugmug.com
We train, fail fast, continuously learn, and succeed together. In the words of Kiichiro Toyoda, founder of Toyota Motor Corporation: “They do not have the expertise gained from the failures it took to produce the original…The thieves may be able to follow the design plans and produce a loom, but we are modifying and improving every day.” So you can steal their plans, but without knowing their failures and ongoing development, you won’t create the same product.
In comparison, another cycling team could find the blueprints of how we train and try to emulate them, but they won’t understand how we operate as a unit. They won’t understand our failures and what we have learned to advance to where we are now. We practice continuous improvement and continuous learning. We constantly try to better our previous performances. If we win a bike race, we don’t go home, put our feet up, and say, “We are the best team, nobody else will beat us.” Instead, we analyze our performance, and it’s more than likely that there are many things we could have done better, even if we won the race. Why do we do this? Because we make minor mistakes on a different day, the other teams might get the better of us.
In the tech world, we might have achieved our fastest, most secure deployments to date, with very few failures, but are we going to rest on our laurels and cease to improve? This is the antithesis of what we should be doing in a DevOps environment. We should constantly be looking to better our previous work. At the organizational level, the business itself needs to stay competitive and ensure that customer demands are being met; technology allows the business to stay on track with these targets.
For the cycling team, these processes worked very well, and they continued to improve. The implementation of ChatOps helped us develop our culture and boost collaboration. When I joined the squad, we communicated via email. This was slow, clunky, and generally not the best way for a team of 16 people to communicate. Our inboxes were constantly full, and we sometimes missed messages.
Enter Slack. At first, some of the guys resisted the idea of change: “Why don’t we just use email? It’s so much easier.” It wasn’t easier to use email than Slack; they just didn’t want to change and learn to use a new tool, even if it would take only a few hours.
This is a common problem I see when trying to implement DevOps tools in enterprise organizations. Even if working with Docker or Kubernetes will bring huge benefits, people often don't want to change what they know. As DevOps consultants, we practice empathy and explain the benefits while showing the improvements in a short space of time to guide cultural and procedural transformations.
The cycling team ended up using Slack, and before I knew it, the entire team culture had changed for the better. We used the various channels to keep things organized, such as "racing," "team rides," "ICE" (in case of emergency), "coaching," "random," and more. The culture improved because we were able to bond, have fun, and joke with each other without fear of disrupting important conversations in other channels. Our coach is based in Santa Monica while we are in New York, yet we feel like he is with us on every training ride.
I’ve seen collaboration tools such as Slack, Trello, and others used to improve collaboration in many remotely dispersed teams. But why does improving culture matter—shouldn’t people just focus on doing their job?
Of course, they should. I'm not suggesting that these tools should be a distraction. But bringing teams together means that they are more likely to collaborate in times of need. This will help global teams communicate and collaborate more effectively, and it will also boost employee satisfaction because people will feel a greater sense of belonging.
To summarize, agile and DevOps methodologies can be applied outside of technology. These principles and practices can be implemented across entire organizations. They can help manage change and transformation while increasing productivity through automation and the adoption of modern technologies for cloud computing. Don’t get caught up in the DevOps tools.
Image by: bicycleracingpictures.com
[See our related story, How to apply a DevOps culture beyond IT]
Comments are closed.