The DNA of Agile practices



Some years back, Martin Fowler and Alistar Cockburn adapted the concept of ShuHaRi from Japanese martial arts.

At its core, it’s simply a way to think about learning.

The idea is that a person passes through three stages of gaining knowledge:

  • Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
  • Ha: At this point, the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
  • Ri: Now the student isn’t learning from other people but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.

From this lens, you realize the sacred cows of your own agile practice can be criticized.

Is it really necessary to have a daily standup meeting which is physical every day?

Does your Kanban board really need to have all those lanes?

Must all pairs share a keyboard in your XP practice?

In this entry, we will look past the individual features of the specific agile methods and look more broadly at what unites them, what is their DNA?

Frequent delivery

The idea that final products should well, be final is a pervasive one. It’s one thing to read all about the benefits of iteration and quite another to have your boss or client scream at you for presenting a half-baked product.

Thus we build generous timelines to protect us, to allow to do all the work needed to ensure we present the product that is just right. We know when it’s not. There will be hell to pay.

Agile adopts a more evolutionary mindset, it advocates you ship what works, for now, gain feedback and improve on the product.

This is why Scrum, for example, insists on two-week sprints. There is nothing magical about the number, its simply meant to convey you are supposed to ship something, perfection be damned what we need is working software.


You may have noticed this, the speed by which a project is executed is closely related to how well everyone understands what is to be achieved.

Simon Sinek explains the concept quite well.

If you did manage to forgive the audio quality, you got the vibe, people respond to alignment.

You see communication, especially in software development, goes much deeper than sending and receiving of signals. It took me long enough to realize you can be in a meeting speaking where everyone else is only there physically appearing to be listening to you but lost in their own world.

To properly communicate, you must be able to externalize your mental model and have the other person internalize it. This, in my opinion, is best done when you work together on a physical media, say a whiteboard or a shared doc to express what you perceive. This back and forth helps expose any incoherence in your understanding of the situation.



Thus boards and other interactive information radiators in Kanban help the teams build a shared mental model of the work to be done.

Continuous improvement

The primary school I attended had an interesting motto:

Better your best

It has taken me all this time to finally appreciate what it means.

Continuous improvement is the idea there is always something you can improve. It doesn’t matter if you are a beginner or have thirty years of experience.

Integrating this philosophy into your mindset has two advantages.

First, you never settle, your product is always going to be improving. This is in line with the more general truth of impermanence, no matter how fit the product is to its market today, the market will change tomorrow. Thus you must continue to adapt.

Second, you get the validation to ship your product imperfections and all. After all, there will be a chance to improve on it later.

In agile practices, this principle shows up in retrospectives, where the team stands back at the end of an iteration and reviews its work searching for clues on what they could have done better.

If you learn nothing else about agile, learn this three principles.

What do you think is the unifying theme of agile practices?  Talk to me in the comment section below or on my twitter @jchex



Published by


API Engineer