2019 Integrity Inspired Solutions, LLC. All rights reserved.

  • Black Facebook Icon
  • LinkedIn Basic Black
  • Twitter Basic Black
  • Black RSS Icon
  • Phil Ledgerwood

Agile Lessons from Martial Arts

Almost all my life, I've been into martial arts in some form or fashion. Part of it is that I was never very strong or athletic and martial arts helped me in those areas. Part of it is that I'm a huge nerd and martial arts are cool.


These experiences as well as experiences from teaching a martial arts class have given me a rich variety of stories and analogies that I pull from when I'm doing consulting, and I thought I'd share a few of them.


Fight One Person at a Time

Do not fight these guys by yourself

The arts that I currently train in and teach - kali and silat - are both family/tribal arts. They're village arts. They arose from the realities of hostile wildlife, fending off raiders, and (sadly) family vendettas. As such, there's a lot of structure around fighting multiple opponents.


This is a tricky proposition, though. There's a reason why, in martial arts movies, the big gang of thugs attacks the hero one at a time instead of all rushing in. The reason is: one person fighting a bunch of people simultaneously is about to get waxed no matter how good they are.


So, is the situation hopeless? Well, as one of my silat teachers says, "The best way to fight more than one guy is to fight one guy at a time."


Although it doesn't make for a very exciting movie scene, we use our footwork to stay mobile so that we position an opponent between us and all the others. We also use techniques that don't lock us up with one person (which is a different agile principle - don't let blocked items linger).


The execution might be tricky, but the principle is simple: focus on one thing, take care of it, and move on to the next thing. You don't want to lose sight of the other things, but you can only effectively deal with one at a time. You don't want to charge four guys at once; you will lose that fight, despite what the movies might lead you to think.


When it comes to workflow, we follow the same strategy. We don't work on five user stories at once. We take the most important one and put the most people on it that we can without getting in each others' way. The person/people working on that item stay on it until it's done, and only then do they consider starting another item.


This is how you get the highest value items out the door in the most efficient manner. Don't charge four user stories at once. Keep in mind that they're out there needing to be dealt with, but structure things so that you're only working on one at a time.


Don't Fall Back on Bad Patterns in the Heat of Combat

Not an actual martial arts photo (but pretty close)

Any practitioner will tell you there is a big difference between doing drills or forms and sparring. It's not that drills or forms don't have value; they are quite valuable. But they are also usually predictable. When you spar someone, the heat is on! You don't know what they're going to do.


It's interesting to me to watch someone spar for the first time. They may have done the drills perfectly, but once they get into the ring and the pressure's on, they fall back into playground fighting tactics: wild haymakers, windmilling, and glomming on to the other person with no particular plan in mind for that.


There's something about anxiety and fear that causes people to fall back into patterns that are comfortable whether those patterns are healthy or not. This is true in most areas of life, actually.


Part of dealing with this is, of course, getting used to the anxiety of unpredictability. I've been at this a long time, and I always feel a little anxiety when sparring no matter how good I am or how bad the other person is. You just never know what's going to happen. But I'm used to it.


But the other part is being committed to doing the things I know are healthy and best even when I'm afraid.


In the agile working world, this thing crops up all the time. Teams spin up ready to self-organize and work differently. Management is ready to give them autonomy in doing the actual work. Everyone always starts out so excited and hopeful.


But then the unpredictability of the work kicks in.


Work items start coming in and coming fast. Deadlines look like they might not get met. Quality issues start rearing their head. The heat turns on. Everyone feels stressed and pressured. And what do you think happens in this state?


If you guessed, "Management falls back to a Command/Control model and teams quit doing their agile practices to save time," you guessed right! You might consider a career in agile coaching.


The irony of all this is, when teams are really in the thick of a bad situation, those agile principles and practices are more vital than ever, because that's what'll get you out the situation, just like good fighting principles get you through fights. If you've ever thought, "We need to skip the retrospective this week because we don't have time," that's your red flag. If you don't have time for a retrospective, then YOU NEED A RETROSPECTIVE.


Don't Ditch a Technique Too Soon

"We're too busy! Let's stop having retrospectives!"

Back when I was teaching in a backyard, I had a new student show up one day who quit practicing the drill we were working on. When I asked him why, he said, "This technique isn't really working, and Bruce Lee said we should only keep what works and let go of the rest."


I explained to him that I agreed with that principle. I pointed out, however, that Bruce Lee was a very experienced and capable martial artist and kind of a savant. This student, by contrast, had been to two classes.


Bruce Lee was probably in a position to quickly evaluate the value of a technique because he had very deep insight and proficiency. If Bruce Lee can't make the technique effective, it's bad.


But the reason the technique wasn't working for this student was because he was terrible at doing it. If the student would continue to practice it and get good at it, I explained, he might discover that it was actually a very effective technique. Worst case scenario: he would understand the technique well enough to make an educated decision about it.


In the agile world, I am a big advocate of ditching or modifying practices that don't add value. I don't really care what "true Scrum" is supposed to look like or what this or that author says is or isn't Kanban. The only meaningful criterion for whether or not you should be doing an agile practice is if it enhances your agility. If it doesn't, get rid of it, replace it, change it, whatever.


However, people who are just starting out are not in the best position to evaluate whether a practice is helpful after a couple of weeks.


I hear this sort of thing a lot. "We quit doing daily standups because we weren't really getting anything out of them," or, "We don't use WIP limits because we can't just stop working," or, "I know a sprint should only be 2-4 weeks, but ours are 8 weeks."


It's possible those kinds of things don't fit your workflow. What is probably more likely is that these practices are revealing dysfunction in your system, and you're mistaking that pain for the practice not working. Or, maybe you're just doing the practice badly.


Maybe your standups aren't valuable because you've got the wrong people talking together, or you silo your work so no one's update affects anyone else, or you use your standups as a project management report.


Maybe your WIP limits stop you from working because you let blocked items hang out for weeks, or you've got too many developers and not enough testers, or your limits are wrong.


Maybe the conventional sprint boundaries are too short for you because your user stories are the size of War and Peace.


In any of those cases, the problem isn't that the practice doesn't work. It's not even that the practice doesn't work for you. It's that you've got some issues in your execution, and if you ironed those out, you might discover that those practices that "don't work" are actually gems.


In Closing...

First off, everyone should take my martial arts class. Just imagine the agile insights that could be yours! We're a very beginner-friendly, nerd-friendly, physically-awkward-friendly group. We're about as nurturing as you can be with a pair of rattan sticks in your hands.


Second, I hope these lessons and stories were helpful. Good principles work wherever you find them. I'm a software developer, and most of our practices are modified forms of manufacturing practices. Keep your eyes open for principles of efficiency and effectiveness in all kinds of areas. Cooking. Driving. Golfing.


The next big leap forward in your agile transformation could be made clear by experiencing it in an entirely different category.