As a past student of the martial arts, I’ve noticed that there are some interesting parallels between Bruce Lee’s Jeet Kune Do –The Way of the Intercepting Fist – and Agile software development.
As I pointed out in a prior post, Bruce Lee on Software Development, Bruce Lee introduced a new system that was highly controversial because Lee challenged the thinking of his peers. Lee was advocating change, but this did not resonate with everyone – for more than one reason.
Jeet Kune Do was difficult for some people to understand because it was a system versus a specific fighting style. In fact, Lee didn’t even name his system at first. Lee was also something of a philosopher, and he referred to his system as, “Having no way as way,” which naturally confused things in people’s minds.
Since people couldn’t figure out what IT was, Lee eventually gave his system a name: Jeet Kune Do (JDK). For Lee, it was all about developing a deep understanding of the martial arts, of acquiring the knowledge, skills, and attributes that went into being a great fighter and helping others to find their own path to their own truth.
The situation with Agile software development is similar to JDK. Agile development at least has a name, but like JDK, people struggle with what Agile development is. Part of the problem is that “Agile development” is really an umbrella term that encompasses a variety of approaches. Another part of the problem is that Agile development is a framework, deliberately avoiding being overly prescriptive.
An all-too familiar dynamic emerges in all of this. While some embrace the notion of a conceptual framework to work from, there are others who desire greater structure, who want a prescriptive, repeatable approach to increase the odds of success in any software project. This is no different from certain styles of martial arts that have a specific area of focus (the kicking and punching of karate or the throwing and grappling of judo, for example) and a definitive, progressive belt-ranking system whereby the practitioner must demonstrate knowledge and proficiency in specific techniques and skills in order to advance to the next belt level.
Bruce Lee, in challenging the thinking of others, didn’t exactly make friends. His intent wasn’t to challenge everything about other styles; his main concern was that other styles had become too rigid in their thinking and unrealistic in their approach to training. His passion and energy about what he felt was wrong became a strong indictment of their approach, striking a nerve (yes, this is a small pun), one involving an investment of years of sweat – and with money on the line.
I had a similar experience when I first encountered Agile development. I was eating lunch with some people at a conference in the 2003 timeframe, and a couple of those at the table were Extreme Programming advocates. I was curious and asked them about it, but they were so arrogant in the way that they talked me – talking down to me – that I was actually very put off. It was a terrible sales job!
My experience over the years is that many of those who embrace Agile development are actually similar in nature to Bruce Lee: he was quite open-minded about what each style had to offer and incorporated techniques from others styles into JKD, if those techniques worked in real situations. With JKD, Lee desired to look deeper; he wanted to zero in on the essentials, refining what works and discarding anything that was inefficient or wasteful.
This sounds like the goals of Agile development to me!
Change is hard, and there will always be resistance to different ways of thinking. With Agile development, we need to guard against how we are presenting ourselves and positioning our message. We don’t want to drive people away from Agile development, we want to help them find a path to what Agile development has to offer. We need to frame Agile development in their context, not ours.