There is a lot in common between judo and a philosophy of devops, agile development, and continuous integration and deployment.
In judo, you can actually be too defensive. Judo is biased toward action and attacking. If you are too defensive, one of two things will happen. At worst you will get attacked and possibly thrown, and at best you will get penalized. Either way, you have become ineffective, burning lots of energy just to survive, rather than possibly win.
The same is true in development. Companies that do large yearly, quarterly, or even monthly releases are usually leaning toward the defensive side. The thinking is, I cannot release this. It is not ready. I don't want to break anything. Lots of defensive energy is spent keeping the current product running while some bug fixes are held off because others are not ready. Rather than attacking and pushing forward, a defensive stance is taken.
In Judo, you practice the same things over and over, a lot. It takes hundreds of repetitions of a technique, especially a throw, before a base level is attained that would allow somebody to execute that throw in practice. It takes even more practice to be able to pull puff that same throw in a tournament, and perhaps thousands and thousands of repetitions before that throw is truly perfected. To be able to practice this much, Judo practice is structured in such a way to safely allow for this level of repetition.
One of the best indicators of high-performance organizations is how frequently they deploy code to production and how short their cycle time is from idea to running code. Taking the analogy of Judo, committing and attacking frequently, the mental muscles required to pull off frequent deploys are built up and exercised. With each attempt, there is an opportunity for reflection to determine how that attempt can be better than the previous one.
Having some sort of feedback loop to allow reflection is critical. In Judo, the feedback loop is that you succeeded or failed at a throw, or got thrown by someone else. Essentially you do a quick self post-mortem to see what you need to change the next time. In software releases, the feedback loop comes down to testing.
Everybody’s judo is different. Every high-level practitioner of judo has their own style that may differ from the styles of others. They have their favorite throws, favorite attacks, combinations, pins, etc. Two different instructors will teach the same basic throw with slightly different techniques or emphasis on different parts of the throw. This is similar to why DevOps is so hard. There are some common tools, ideologies, and approaches out there, but all of those choices will eventually boil down to something that is unique to each company, and possibly even unique across product teams. This is similar to two students at a judo school favoring different throws, or thowing the same throw in different ways. The DevOps team has to be given the freedom to choose what is going to work well for them.
Judo is freaking hard. It wears you out. You sweat, sometimes bleed, and get hurt. You may get choked unconscious, rolled up into a pretzel and smashed, pull a muscle, have a fat guy fall on you, or get any number of bruises. It’s also a LOT of fun. So is DevOps and more specifically trying to reduce cycle time as much as possible. But we create mats, crash pads, safe environments and testing environments to help us practice over and over. We make a lot of mistakes but learn and improve from each one. And one of these days we become a sort of DevOps judo black belt who can execute on getting software out to the business as fast as possible with minimal mistakes and down-time. It’s a great thing to strive for but a difficult thing to attain.
I’m not there yet (in Judo or in DevOps), and I know when I reach that level, it is just another starting point, and the real journey has truly begun. Now let’s train hard, get stronger, and go ship some code.