Setting the context

Having worked in a fairly large team for the last 3 years I have come across different types of problems that occur in software development projects with regards to collaboration, communication, management, etc. While most projects have retrospective meetings where we discuss what went wrong and what can we do better regularly, I find these meetings to be restrictive in terms of the mindset of identifying problems, and therefore innovative solutions don’t seem to emerge from them. Having thought about these problems over a long period, I have condensed my point of view down to 3 key questions that any software team facing such problems must introspect about. Then they can work on coming up with their take on how these questions can be tackled. Why? Because the first step to solving any problem is acknowledging there is one.

Question 1 - Finite vs Infinite games

A concept introduced originally by James Carse, this was expanded upon by Simon Sinek who is a renowned TED speaker, author, and coach. The idea states that there are essentially two types of games, finite games and infinite games. A finite game is one where we have a known set of players, the rules of engagement are predefined and the objective is to win the game. A classic example would be sports such as cricket or football where at the end of the match duration we always have one team which is declared the winner. An infinite game on the other hand has known and unknown players, the rules of the game can evolve and change with time and the objective is not to win but instead to keep the game going as long as possible. An example of an infinite game would be the Vietnam War. The US won a majority of battles and resisted all the Vietnamese offensives. It decimated the North Vietnamese forces disproportionately i.e. while the US lost around 50 thousand people it is estimated that the Vietnamese lost around 1.2 million people including civilians. So why is it widely believed that the US lost the Vietnam War? Simon believes this is the case because while the US was playing a finite game for a short-term victory, the Vietnamese were playing an infinite game for the survival of their people. In the end, the US ran out of resources and the will to fight and hence had to withdraw from Vietnam.

What I have come to realize is that Software development is a mixture of finite and infinite games. The normal change requests and new features being delivered are fixed in terms of scope and deadlines with some flexibility offered to those practicing agile. There are other principles or aspects of a software project namely Quality, Reliability, Performance, and UX all of which cannot be fit in the constraints of a finite game. There is no perfect quality or winning UX. We need to realize that these principles are something we have to aspire to move towards continuously even though we may never achieve 100 percent of our goal. These objectives are part of an infinite game so we keep trying in perpetuity. These principles cannot hence be treated as the latest trend that is prioritized for a couple of sprints and then completely ignored to accommodate for other priorities or tight deadlines.

We are not competing with anyone else when it comes to these principles. We are striving to make our project slightly better every day of every year. The infinite player understands that sometimes you are ahead or sometimes you are behind in terms of your competition. So how do we play an infinite game? Simon Sinek gives a checklist to ensure that we actually are playing infinite games rather than sliding back into a finite game.

The Checklist

  1. A Just Cause - A cause in your project for which people are ready to sacrifice in terms of time, ideas, and even monetary benefits. It’s all about what do you stand for not what you stand against that motivates people to go above and beyond the normal standard.

  2. Trusting teams -

  • Teams need to be empowered to do their best work because they know best when it comes to their work and how to execute on the same.
  • This requires inherent trust to be placed in people.
  • People can do their work and acknowledge and own up to their mistakes without fear of humiliation, retribution, or punishment.
  • The very reason we have teams is because everyone cannot do everything and so we put together complimentary skill sets to build on top of each other. Hence there is no need for competition between team members because everyone brings something different to the table.
  1. Courageous leadership -
  • Leaders who are willing to sacrifice the short term to advance the long term.
  • Leaders who are willing to say NO because it’s the right thing to do.
  • Leadership that profoundly believes in the just cause and would never sacrifice their people to protect their interests.
  • We confuse rank and leadership. Just because someone sits at the highest levels of organizations does not mean they are leaders. They have authority and we do as they tell us but we would NOT follow them.
  • Leadership is not about being in charge but taking care of the people in your charge.
  1. Worthy rival - The only true competitor is yourself. The competitors or other players in the game reveal to us our weaknesses. You should admire others not beat them, and not be number one but if someone is better than you at something that means you have to work harder on yourself.

  2. Flexible playbook - What does it truly mean to be agile? To accommodate changing requirements we should have flexible deadlines, flexible plans, flexible designs, and architectures.

Reference - The Infinite Game by Simon Sinek