Product development is like chess! You can't plan too far out, but you can't just move the pieces around on whim, & there are no guarantees.
— Rob Myers (@agilecoach) May 4, 2014
I don’t usually like any comparisons to chess, the beautiful game I have spent years mastering. Don’t get me wrong, I’m at most a solid amateur player, holding no FIDE titles and hopelessly losing even to my own phone nowadays. But I like the game and the knowledge and experience gained during training helped me multiple times in general life.
Saying that product development is like chess made me think about what useful things I know about chess that can be applied to product development. Similar things should be governed by similar rules and it’s great when you can see how this knowledge is transferable.
Naturally, this is somewhat metaphorical: obviously, moving your knights closer to the center or respecting the bishops won’t make your software product an overnight success. However, in this post I’d like to share some advice that IMHO unites the two seemingly separate things and makes me believe that, yes, software product development is like chess.
You might disagree, and actually are welcomed to do so, but please don’t be blunt about it. If you think chess is just a game, then here’s an XKCD comic strip for you, what we do every day is not that much more interesting than moving wooden bits around the board.
But product development is not a perfect information game!
That’s right. One obvious distinction between a game of chess and developing a product is that chess is a perfect information game, where you can potentially figure out the best move every single time. In practice, however, that is rarely happening.
The current world champion, the vaguely boy-bandish, 24-year-old Magnus Carlsen, is said to be able to get into “Houdini” mode (this particular Houdini being a state-of-the-art computer chess engine) to produce a perfect game, meaning that in every position he does the best possible move that current computers can find.
In the development world, we don’t get the luck of quick verification of our efforts. The result of every choice and action is visible much later, so the price of every decision is much higher. Though, the same general principles apply and mental activity and decision making are somewhat similar.
Lesson #1: Try not to let a bad start break your spirits
Even if you have no experience playing chess, you’ve probably seen how a game is organised and set up, right? Every game starts from the same position. Players make moves, pawn are usually thrown first into the battle and, by the rules of the game, they cannot move back. This sad fact makes for an interesting phenomenon: a horrendous pawn structure can easily determine what you can or cannot do with future moves and strategies. Your choices early in the game have now become a limitation to your position.
The point is that the choices you make when starting off often determine your result, and by that I mean that it’s easy to undermine your position and ruin everything with a couple of dubious decisions. There’s an immense corpus of theoretical history both on playing chess and laying down an architecture for your project, and I suggest you use it.
Unless it’s an experimental fun project, don’t dive head first into the wonderful world of hipster frameworks, web-scale NoSQL and brand new JVM languages. Make sure that your openings are solid and won’t prevent you from delivering value later.
Lesson #2: Don’t dwell on mistakes that everybody makes
You will make mistakes. We’re all human after all and, just like everyone else, we do stupid things, especially when we’re tired. There’s a natural reaction of human’s brain to the mistakes you think you’re responsible for. You start thinking about them and what would happen otherwise. What if we went with a different pricing strategy? How about another architecture? Don’t stall out in this unfriendly state of mind. There will always be critical situations and you’ll always wish that you’d done something differently.
Don’t allow yourself to dive into this downward spiral and prevent you from thinking clearly. Thinking about alternative futures won’t give you any solace or strength to deal with the current situation. Wondering why your bishop got suddenly trapped behind a wall of pawns doesn’t help you move forward or salvage the chess game.
In a bad position all moves look bad, it’s because we’re human not because it’s hopeless. If your project’s backlog consists of over 9000 tasks and is growing, you team will lose focus. Contemplating the situation and wondering if there’s something wrong with the approach you took doesn’t help. Unless you pull yourself together and take a conscious action the problem won’t solve itself.
Lesson #3: Feedback is the King
There’s a common trait of top performers both in chess world and in software development is that they always critically analyze their results. Retrospectives and analysis phase is the only time you can actually grow your skill and verify how did you and your team performed.
Chess games are easier to analyse because of their discrete nature. A game ends and you look back on mistakes you made and how you could improve.
Product development is a continuous activity and it seems that it’s never a good time to step back and reflect. However, find the time for it and find emotional resource to accept the result you’ve received.
Take your time from playing chess to study chess. Take your time from developing a product to learn how to do it.
Lesson #4: The errors you make are rarely fatal
There’s a saying in chess: whoever makes the last error, loses the game. This means that you always have a chance to turn the tables on your opponent. An opportunity can wait just behind a corner and show itself only when you get to that point (remember that bishop trapped behind all those pawns?)
Projects die often because their leaders get tired of dragging along, being emotionally drained and seeing perhaps poor results. A game is not done until you surrender. Are competitors killing your project? Is the market favoring other solutions? Keep making progress and improve: unless you make an error AND give up, there’s always some possible future for your project.
Lesson #5: There is more than one way to do it all!
I’ve talked quite a bit about how hard and sorrowful product development can be, but I want to share one positive bit as well. There are two essential components to a game of chess: planning and tactics.
They say it’s better to play with a bad plan than with no plan at all. Since a plan specifies your goals, such as what you aim for and what you want to get out of your position on the board. It can be as simple as “hold the fourth horizontal with a rook”, or it could be much more complicated.
Like a game of chess, your project must have a vision. You need to realize not only what you do, but for whom, when and with what personal goals in mind.
At the same time, you need to zoom in to ground level and figure out all the implementation details, every single move, every single integration and the smallest domain model detail. Another important aspect is to follow through with your plans. Unless something has changed dramatically, don’t jump from an idea to an idea. Follow through.
You can judge your decisions against this and you communicate it to your team so that everyone is on the same page. For every iteration, for every release, have a 2 sentence description of what’s going to be done in it – although preparing your chess opponent in this way for your next move might have unintended consequences :-)
There are others sayings that relate well to both chess and software development. Fake it till you make it and look confident, know your strength and play to the weaknesses of the opponent. Disregard competition and play to the board aka. your issue tracker. I don’t think chess as a game is similar to many things, but the best ideas often come while gaining experience in several disciplines at once. So the comparison is useful as long as it is thought-provoking.
I hope this blogpost will help you maintain your sanity and rationality on the path to promoting your product to the powerful status of a Queen in chess. It won’t be easy, but I’d love to hear your story and what way of thinking empowers your development process. Just leave me comments below, or catch me on Twitter @shelajev.