In the past year I have played and studied chess more or less active. It has been interesting to see how strategy game chess actually is. As well chess is fun to play I have also found interesting relation to software product development.
In both “games” I have found one of the best approaches first doing strategy, then planning and executing it in small pieces. Let’s take a closer look why I think strategy is important.
Software development and vision
A vision is strategic document in software development. Document usually contains description from the problem and vision from the solution. It also declares in which boundaries solution needs to be implemented.
In other words in the vision you set up strategy how customer problem will be solved.
Based on vision you can start to create more detailed plan like product backlog or functional requirement lists, adjust priorities and then execute it.
Advantages of strategic thinking in chess
In chess strategic thinking means you are building a plan which you can follow and finally win a game. That plan is not step by step moves to the victory. It’s rather vision about which weaknesses and strengths to guide you through the game. The game can be in situation when it’s better to attach, switch pieces or even to sacrifice a piece to get better position as opponent has.
Without a long term plan in chess your chances to win are not good. It’s not possible to count all variations which opponent might play. It’s too complex. And if you just move based on opponent’s last move then he or she controls your game. You need to have long term vision how to win a game.
Software development complexity board
In software development complexity might not be so easy to see, but it’s there. I’ll try to explain complexity with software development board.
Let’s start from the chess:
Your opponent has his or her pieces which have different properties. Your opponent has own mind which you can’t read. So he or she moves pieces more or less unpredictably. This causes most of the complexity.
You have your own pieces which have different properties. You can control your own pieces.
Transforming it to the software development:
LIke in chess I added items which cause complexity to the top of the table. Those are again more or less unpredictable and not fully controlled by you and your team. There is two kind of things. There is items which are related to customer and there is items which are related to environment where you are working.
To the bottom I added items which are solution. These items you can control. There is features delivered and then solutions how features were done.
You win if you can handle complexity and unpredictability and build the solution which satisfies stakeholders.
From theory to the game
As I told in chess it’s impossible to count all moves and win the game. Same applies to software development. It’s not possible to create detailed functional and technical documentation upfront.
Why? Because there is too many factors and you learn those when development goes on. That’s why, as in chess as well, you create first a vision and only then plan next and only next moves.
Now let’s take an example about playing with the vision.
Let’s assume that playing couple moves in the chess game. You find out (or learned) that you opponent is attacking from the left side with his bishop. You need to stop that and you have two options. Which one to choose? The one which aligns with your strategy. This way you improve your whole game and you are just controlled by your opponent.
Same in software development. Let’s assume you created a proto and showed it for the users. You learned that the way they do their things are different that you expected. You need to do something. Way to do things was unknown for you and now it’s attacking you.
With this case you have now possibility add more details to feature which will be implemented in near feature. Like in chess game you had two options to react to opponents move now in software solution you have several ways to fill the need which you learned. You choose one which is aligned with your vision. You are optimizing the whole solution, not just single need. You are going toward your goal, your vision. And the vision declares your strategy. Brilliant.
Vision or strategy is there to help you when you learn more from the vision. Vision is like a compass that guides you to the north pole.
So what I learned?
In chess it is easy to understand game complexity. It’s there front of your eyes. In software development it might not be so obvious. Complexity makes it almost impossible to count all moves upfront. Same applies to software development planning.
When you learn more from the game or from the system then it’s the vision that guides which helps you to do new decisions. With the vision you optimize the whole system, go to the correct direction and not just react to single needs which will pop up.
It’s interesting to think that long term product road maps are strategical documents as well. What could be in the top row when thinking about product road mapping complexity board?