Mar 172013

Even if you don’t play chess, you are likely to enjoy Gary Kasparov’s recent article The Chess Master and the Computer. Gary writes on the complicated subject of  intelligence  and the human mind in a clear, jargon free language. I would dare say his article is as incisive as the way he plays chess.

For the Agilist, (and for anyone who takes interest in knowledge work), Gary cuts to the heart of the matter recounting the following episode:

In 2005, the online chess-playing site hosted what it called a “freestyle” chess tournament in which anyone could compete in teams with other players or computers. Normally, “anti-cheating” algorithms are employed by online sites to prevent, or at least discourage, players from cheating with computer assistance. (I wonder if these detection algorithms, which employ diagnostic analysis of moves and calculate probabilities, are any less “intelligent” than the playing programs they detect.)

Lured by the substantial prize money, several groups of strong grandmasters working with several computers at the same time entered the competition. At first, the results seemed predictable. The teams of human plus machine dominated even the strongest computers. The chess machine Hydra, which is a chess-specific supercomputer like Deep Blue, was no match for a strong human player using a relatively weak laptop. Human strategic guidance combined with the tactical acuity of a computer was overwhelming.

The surprise came at the conclusion of the event. The winner was revealed to be not a grandmaster with a state-of-the-art PC but a pair of amateur American chess players using three computers at the same time. Their skill at manipulating and “coaching” their computers to look very deeply into positions effectively counteracted the superior chess understanding of their grandmaster opponents and the greater computational power of other participants. Weak human + machine + better process was superior to a strong computer alone and, more remarkably, superior to a strong human + machine + inferior process. [Highlighted by IG].

I might be a little biased as I consider chess and programming to cognitively be twin brothers. Orchestrating a game, if you ask me, is not really different from architecting an application; mastering the intricacies of the Sicilian Defense is similar to getting deep into Java;  recovering from an error is quite similar to fixing a bug; the dreaded time pressure toward the end of the game always evokes in me the dreadful feeling of a (software development) death march; and, of course, chess is incremental – one move at a time. If you asked me whether I am a stronger chess player than developer, or vice versa, I would probably shrug my shoulders and say something like: “I think I am about the same strength in both; as far as I know the two are merely two different applications of the same brain cells of mine.”

If you accept this premise (that playing chess is akin to programming), the aforelisted 2005 tournament, and the conclusions Gary draws with respect to the role of the process in chess playing, are particularly intriguing. Unlike basketball or soccer, Chess had never been considered a team sport. Even in matches between two countries in the Chess Olympics, each game is independent of all other games. The player on the first board will be of the same nationality that the player on the second board is, but other than being played on an adjacent table at precisely the same time, his/her game bears no relationship whatsoever to the game on the second board. To the best of my knowledge, until Gary published his article, the term “process” in chess was always limited to administrative  trivia like determining whether a player in the N-th round will play the white pieces or the black pieces.

Naturally enough, in software development we always aspire to have talented programmers in our product teams. Gary’s analysis indicates that this aspect of team formation might be less important than the process the team uses, its ability to continuously improve,  and the strength of the Scrum Master (or equivalent role).


  3 Responses to “A Lesson for the Agilist by Maestro Gary Kasparov”

  1. Great post, Israel. If I read it right, what Gary and you are saying is, intuition (out of experience) and expertise can only go so far. If the continuous learning component is missing, then winning is not possible.

    There is an application for this discussion in corporate settings. I think of “experienced” executives. Often they come into organizations and claim their 20-30 years of experience somehow gives them the wisdom to create something new. On the other side of this spectrum is the “expert” who is trained on the subject and by virtue of it claims he knows exactly what to do. Which one should I choose? The experienced person or the expert person? The answer depends on if either is open to learn continuously even at their experienced or expert stage. The lack of this learning is what plagues corporate settings.

    Good chess players are constantly trying to improve. They are curious about the next move, and when they don’t find one, they go back to the board, do the homework, come prepared next time.

    Speaking of chess, we should resume our blitz games next time we meet!

    • Thanks for the kind words, Prabhakar!

      I believe a Context over Content phenomenon is of paramount importance to the learning you highlight. The key,
      no matter what your experience and/or expertise might be, is figuring out how to apply them in the specific context.
      I would go as far as saying no two Agile roll-outs are the same. They, of course, have many similarities, but the key is
      fit to the specific needs of each client. As an Agile consultant, my ability to learn the context is pivotal.

      With respect to resuming our blitz chess games, I have lamentably “deteriorated” to the point of putting work before play… my travel
      “diet” right now is Chicago, Durham and Boston. Let’s get together in April once I concluded this trip.



 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>