Author: Conor Delanbanque

Do Agile and DevOps methodologies apply outside of technology? More specifically, can we apply them to sport? I decided to answer these questions by analyzing the application of Agile and DevOps principles within my road-cycling team.

For those of you who don’t know, cycling is a very data-driven sport. While we are training and racing, we have a live feed showing data on our computers, which are attached to the handlebars. We see 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 we aren’t overloading ourselves while performing to our highest capabilities. We measure our limits through tests over time periods such as 30 seconds, five 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 in 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 toward 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 set up self-repair protocols within our infrastructure if the monitoring tools report any alerts.

We run the cycling 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 which 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 sprints and so on. The important point is that we don’t segment ourselves solely to these responsibilities – the sprinters still have to get themselves over the climbs and the climbers still have to practice sprinting. We never know when one of us will have to try to fill in for a teammate. We understand each other’s roles and the importance of that 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 2km before the finish – what do we do? The lead out train all move one place up the line, so the guy who was supposed to be the last man left to support the sprinter in the final move, will now be the sprinter. We have setup 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 solely rely 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 in 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 with 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.

Bicycles and DevOps Cycles

Essentially, your entire role as someone who practices DevOps is to make everyone else’s life easier through implementing processes and tools that help to increase productivity and reduce errors. In a cycling team, everyone is working 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 the rear wheel of the other rider. We do this because it uses approximately 30 percent 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 this 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.

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 do the same, 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”—we analyze our performance and it’s more than likely there are many things we could have done better, even if we did win the race. Why do we do this? Because on a different day, if minor mistakes are made again, the other teams might get the better of us. In the tech world, we may 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 DevOps environments—we should be constantly 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.

Our processes worked very well, and they continued to improve. This was helped by the implementation of chatOps to develop our culture and 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 were closed off to the idea of change—“Why don’t we just use email? It’s so much easier,” they said. It really wasn’t easier to use email instead of Slack; it’s just that they didn’t want to change and learn to use a new tool, even if it only took a few hours to get comfortable with it.

This is a common problem I see when trying to implement DevOps tools in enterprise organizations. Even if working with Docker or Kubernetes is going to bring huge benefits for people, sometimes they just don’t want to change from what they know. We practiced empathy and explained the benefits, while showing the improvements in a short space of time. Similarly, we do this as DevOps consultants when guiding cultural and procedural transformations at enterprise organizations. Anyway, we 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 others. 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 and we are based in New York, yet we feel as though he is with us on every training ride.

I’ve seen Slack, Trello and other collaboration tools being used to improve collaboration in remotely dispersed teams. So why does improving culture matter? Shouldn’t people just focus on doing their job? Yes, of course they should. I’m not saying that this should be a distraction. But bringing your teams together means that they are more likely to collaborate in times of need. This will help your global teams with communication and collaboration. It will also help with employee satisfaction because people will feel a greater sense of belonging.

Conclusion

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.

— Conor Delanbanque