What The Karate Kid Can Teach Us About Agile and UX

Posted on July 17, 2011.
The Karate Kid was awesome...you know it!

In the Karate Kid (the first one, aka the good one) the seemingly innocuous Mr. Miyagi takes on wayward Daniel-san and teaches him to totally kick-ass in karate. While the movie is a prized trinket of 80’s pop culture, heartwarming and by all measures a classic at this point in time (it came out in 1984!!) there are some terrific lessons to be learned from the way Mr. Miyagi taught Daniel-san how to fight. These lessons translate directly to learning any skill but, for the purposes of this post, I want to apply them to Agile and user experience design.

You want me to paint this fence?

“Show me, paint the fence!”

This is what Daniel-san heard the first day he came to learn karate. He arrived ready to learn how to punch, kick, block and defend himself. Instead he found himself painting a fence. Confused but determined, Daniel painted the fence – day in and day out. It was exhausting, humiliating, and ultimately very frustrating as the weeks went on and it appeared that he was not learning a thing about karate. Instead it seemed to him that he was essentially providing free labor for the old man. Finally, Daniel had enough and complained to Mr. Miyagi who, through a series of task-based commands, illustrated to Daniel how the motions of painting the fence and waxing the car were actually the same motions used in karate. Unbeknownst to Daniel, he was learning the craft all along – initially through ritual – but as he got better the ritual melted away into unconscious practice.


A very powerful lesson

There is strong correlation between rote repetition of exercises and the mastering of a process or skill. In other words, what initially looks simply like “going through the motions” can ultimately translate into process mastery and success. Initially, the calisthenics approach seems meaningless. In Daniel’s case he was painting a fence in a very specific fashion. In a designer’s case, one might take on drawing the same elements every day for a month. In an agile team’s world, this could translate into any one of the standard Scrum practices like the daily stand-up, story gathering or estimating.  But by going through the motions, the ritual becomes inculcated as learned behavior. After enough practice, the purpose of the ritual starts to make sense (even if it didn’t in the beginning and seemed like a waste of time). In the designer’s case, it’s an understanding of how to render a particular form or communication. In the Agile team’s case, it’s an understanding that the daily stand-up not only allows the team to catch up on current events related to their project but also begins the bonding process for the team, which paves the way for greater trust and transparency.


What’s even more amazing is that, as process mastery progresses, again through repetition, it begins to bury itself into the teams collective unconscious to the point where, in essence, there is no explicit process – just visceral reactions to inbound stimuli from the work, the team, and forces beyond the team. Daniel found this level of mastery in the final tournament where he anticipated his opponent’s moves and ultimately defeated him. An Agile team achieves this when they trust each other implicitly, react as a cohesive unit to change and manage that change as well as any conflict with little impact to productivity or quality of work.


This approach is even more impactful when integrating user experience design into an Agile process. Initially, the designer may not understand why they’re going through the rituals of Agile every day. They may seem useless and time-consuming; removing the designer from their element and core competencies. In essence, in the early days, the designer is literally “painting the fence” – she is going through the motions because that’s what’s expected of her. As time wears on, the benefits start to manifest simply from the designer spending time with the team. Camaraderie and joking around are the initial signs of inclusion. That inclusion begins to grow into trust as the rituals force the team to interact regularly. Trust develops into transparency where the designer is now including developers in her process and developers are seeking out the designer as they code the experience. The final step is integration, driven heavily by this trust and transparency. It’s at this point that the “process” has melted away. The designer no longer hides behind their screen incanting secret spells made manifest in documentation. Now, they sketch in the open, pair design with developers, and invite developers into the co-design process itself. The team is working on an unconscious level, reacting to input, solving problems collaboratively without consideration for “what’s next” in the Agile playbook.


It takes time to achieve this stage of process enlightenment. It requires the team spend time together, struggle together, go through conflict together, fail together and ultimately win together. Designing a schedule of ritual practices provides a framework for the team to start working together. Teams that go through this process begin to evolve beyond the textbook practices and evolve into high-functioning teams. By initially “painting the fence,” the team can achieve a level of process mastery that pushes the boundaries of their productivity, quality and responsibility.




6 thoughts on “What The Karate Kid Can Teach Us About Agile and UX

  1. Interesting, I actually start my intro to TDD class with the clip from the karate kid about waxing the cars (it’s the 1st task). I believe fully in a difference between learning concepts (intellectual learning) and learning a skill.

    The key isn’t the ritual so much as the practice. You need to go over the pathways in the brain enough times that new ones form. While this seems obvious it takes practice & time. (on a side note, this doesn’t mean practice makes perfect, it mean practice make permanent which is an important difference)

    Also, notice there is a very big difference between intellectual learning w/out skill and intellectual learning with skill. Take juggling: 

    How to juggle: 
    1) throw the 1st ball to the other hand.
    2) when it’s halfway across throw the ball in the other hand
    3) catch the ball
    4) repeat

    now that i’ve “taught” you to juggle isn’t hard to “convince” you it’s a good process until i’ve “taught you the skill” of juggle. you might nood along, go home and try it and say “well that was crap”. If I’ve got a hour to teach juggling, it doesn’t do any good to now talk about other patterns, even though I could continue at a very rapid pace… (come learn 60 different juggling pattern) … you need to digest the skillset before continuing on. When I process builds on the previous process you need to make sure a certain level of mastery has occurred. (Video games are very skilled at this type of skill building. )

    This creates a very different learning and teaching style.

  2. You bring out a lot of good things I didn’t think about. I never thought of the karate kid being such a good learning analogy. Thanks for sharing such an interesting view.

  3. I don’t think I’ll be clambering around YouTube looking for the ultimate Karate Kid clip for my presentations, I appreciate it’s a decent demo of learning a skill but for me it fits firmly in training an individuals muscle memory.

  4. Wow bro.. I like it.. sweet message ..  It requires the team spend time together, struggle together, go through conflict together, fail together and ultimately win together. 

Comments are closed.