What The Karate Kid Can Teach Us About Agile and UX

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.

“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.

 

[Jeff]