The adoption of agile software development by large corporations has been a thing in the last decade or so. It has been so common that even banks, the least nimble of organizations has gone into it hook, line and sinker. Banks and other slow moving industries are intentionally methodical and deliberate in their approach to building anything. There is a high price to pay in risky behavior in these types of industries. Being agile to save on cost is not very a intuitive concept for them. I once had to explain to a group of people what agile software development really is and why we should do it the right way. So instead of using a boring presentation from the internet, I decided to make a more interesting and entertaining version.
What does being agile really mean? I put together a short list of phrases that describes it:
- Research your own experiences for the truth
- Absorb what is useful
- Reject what is useless
- Add specifically what is your own
- It is not fixed or patterned and is a philosophy with guiding thoughts
- It is easier to avoid resistance than to push against it
- Minimal movements with maximum effects and extreme speed
These ideas are actually not written in the agile manifesto. I got them from this guy.
Given Bruce Lee’s personality it is not a surprise that he had issues with traditional teachings and styles of Chinese martial arts. His adaptation of a different way of practicing his martial art is very similar to how the concept of an agile software development methodology was born.
It is pretty obvious that an agile way of developing software is not for everyone or every team. The same way Bruce Lee’s practices his martial art is not for everyone. Being agile is born out of the need to be able to deliver high quality software that has quantifiably valuable to the end user. This is achieved by focusing the effort to only the most crucial activities. Why wouldn’t anyone want all that? Managers all over the world shout out in unison: “That’s just awesome. I now decree that my development team is now Agile and we should be able to deliver better software faster with less people!”.
Bruce Lee rejected traditional teachings and styles of Chinese martial arts. There are some parallels in the story of Bruce Lee and the emergence of his approach to Kung Fu to how and why agile emerged as an alternative approach to software development. He rejected the idea of following a particular style of Chinese Martial Arts.
Simplicity
Kung Fu Panda simplified the art to only four styles.
There are in fact very many styles.
Simplicity is one of the main principles of being agile. Enterprises build complex software but that does not mean we need to design for every single possible use case. Starting with a simple solution is much more desirable than taking a long time to plan out a complex one. Simple solutions let you start faster and fail faster. Over time solutions will become complex. There is no way to fully escape software entropy but going for a simple solution allows developers to deliver more functionality, faster. There are 3 certainties in life: Death, Taxes and Software Entropy. Do not let the third one slow you down.
There are 3 certainties in life: Death, Taxes and Software Entropy. Do not let the third one slow you down.
Mad Computer Scientist Ninja
Feedback and Communication
Bruce Lee was very much against training using “katas”. Katas are a series of steps and movements learned by martial arts practitioners to master their physical form and mental mind. It required that the martial artist be able to perform katas in the perfect order and timing so that they can be promoted to the next belt level. Bruce Lee derogatorily called this “dry land swimming” as students would perform the steps by count like they were robotically swimming outside of water.
Bruce Lee strongly believed that the only way to truly learn is to train with a live opponent. He rejected the many styles of martial arts for various reasons, mainly that they gave the practitioners a false sense of capability, putting them at risk in real combat situations. Lee pursued ever more elaborate approaches to protected real combat training to enable the closed loop learning that was core to the evolutionary nature of JKD
If you had done all the planning, estimation, user studies, logistics and tons of meetings ahead of the actual development, would that ensure success? It will definitely help but it will not guarantee a home run. All the preparation in the world will not save you from the only thing that is assured to happen: CHANGE. I am not proposing that caution be thrown to the wind and start writing code now and not worry about requirements. I am not proposing that we guess what the user wants and not bother to ask them. I am not even proposing that we not have meetings and just write code (although that would be a great way to motivate developers). I propose that we learn by training with a live opponent. We should ask users what they want, come up with the simplest solution possible, build it with the least amount of effort then show it to the users. All the while being mindful of the technical debt that we are accruing and making sure that the refactoring effort is part of the immediate next book of work. This way of working is what it means to be agile. Prioritizing valued delivery while at the same time committing to quality work and getting better at it by learning from the good and bad.
Technical Insanities of a Mad Computer Scientist 