The Evolution of Cooperation: Why Agile Approaches Will Prevail header background image

Agile testing

The Evolution of Cooperation: Why Agile Approaches Will Prevail

One of my favorite non-fiction books is Robert Axelrod’s The Evolution of Cooperation, published more than 30 years ago. The book compares different strategies to win a game called the Prisoner’s Dilemma, a classic scenario (explained below) used in game theory. Based on Axelrod’s findings, he showed how cooperation can, and most probably will, evolve even if the environment is hostile. Under certain circumstances these findings, prove or at least strongly suggest, that transitions from traditional development methodologies to agile methodologies will succeed even in big organizations, and that agile development approaches will prevail over time.

The Prisoner’s Dilemma

The idea of the Prisoner’s Dilemma centers around two hypothetical criminal friends. The friends are arrested and faced with imprisonment. Authorities can’t present enough evidence to justify a high sentence, so the prosecutor, hungry for success, offers a deal: if one prisoner betrays his friend he will be set free immediately and the other one will be imprisoned for three years. This deal is offered to both friends without giving them a chance to coordinate their actions. If both friends rat out each other, the sentence will be two years for both of them. If none of them speaks, they will both do just a year.

The interesting fact is that, from a game theory point of view, the wisest albeit counter intuitive decision would be to betray your friend. It would guarantee the best possible outcome independent of your friend’s decision. Scientists have a fancy term for that: in game theory it is called a Nash Equilibrium,named after Nobel prize winner John F. Nash whom you may know from the movie “A Beautiful Mind”.

Evolution of Cooperation

In the beginning of the 1980s, Robert Axelrod asked fellow scientists around the world to submit strategies for a contest based on the Prisoner’s Dilemma. He changed one significant parameter though. Instead of just playing just one round of the game, the strategies were compared over the course of a series of rounds. In such an Iterated Prisoner’s Dilemma, a game strategy can benefit from actions taken in previous rounds — e.g. if one opponent started to cooperate in previous rounds the other opponent can choose to reciprocate that behavior.

Everybody taking part in the contest submitted a strategy. Axelrod would then compare each strategy against another strategy in 200 iterations of the Prisoner’s Dilemma. Eventually the scores accumulated by each strategy throughout the tournament led to an overall winner: the best strategy.

It was surprising that despite the rather complex and elaborated strategies (or better, algorithms) used in the tournament, a very simple strategy won in the end. It’s called ‘Tit for Tat’. The strategy is to cooperate (keeps silent) in the first round and mirror the other player’s decision from the previous round for all subsequent moves. After analyzing and publishing the results, Axelrod called for another tournament to see if there was an even better strategy. Again scientists from different disciplines sent in their strategies, knowing well that ‘Tit for Tat’ won the first tournament. Guess what happened? Surprisingly ‘Tit for Tat’ won again.

Based on the findings of these two tournaments, Robert Axelrod derived insights about the nature of cooperation. In addition to three other characteristics (retaliating, forgiving, and simplicity) that will not be discussed further at this point, he found that a successful strategy has to be cooperative in the first place. Axelrod made sure to mention that there are certain criteria to be met to guarantee that such strategies succeed. First and foremost, it’s the iterative nature of his setup — with the likelihood of the opponents ‘meeting again’ — that fosters cooperation.

Axelrod took it a step further, showing that even in a hostile environment, where there is likelihood of opponents “playing dirty” cooperative strategies will not only survive but also succeed.

Small clusters of individuals playing cooperatively will be more successful than opponents playing dirty.

The beautiful thing is that it doesn’t work the other way round — small clusters of individuals playing dirty will not succeed in a cooperative environment. I see this as a very romantic and optimistic (but still mathematically sound) way to look into the future.

Agile Transitions

Coming back to the tester’s world, let’s look at the ongoing changes in the development departments of established enterprises around the world. The last couple of years have seen the rise of agile development methodologies. Organizations have adopted, or plan to adopt, agile methodologies and either struggle to implement it or struggle to scale their agile adoption. While methodologies like Scrum look simple on paper, it quickly becomes difficult when R&D departments realize that the whole organization needs to pull together for a smooth transition towards a real agile behavior — it can’t be done just by the Devs on their own.

Over the last decade(s), a lot of time, effort and money have been invested into building test centers of excellence (TCoEs) to centralize all the testing activities of an organization to use synergies, bundle skills, and provide a single point of contact for anything involving testing. These TCoEs have also often been outsourced, meaning that there are businesses depending on running TCoEs for a large share of their revenue.

As Scrum accounts for 90%+ of the methodologies adopted during agile transitions, it is a reasonable simplification to look at just that methodology. A typical Scrum team consists of three roles: the Product Owner, serving as the voice of the customers, the Scrum Master, helping the team to become more effective and efficient following the Scrum processes in delivering product increments, and finally the Development Team. There is no tester role in a Scrum team (there’s neither a ‘tech writer’ nor a ‘business analyst’ role)! Testers are considered part of the Dev teams, and going forward the line will get continuously blurry. Having testers embedded in development teams is the exact opposite of having testers clustered in a TCoE. All the efforts, time, and money taken to build these TCoEs are not helpful for a smooth agile transition.

In addition, levels of expectations have increased and the tester’s role is constantly evolving. Scrum (and other agile methodologies such as Extreme Programming ) force development teams to work in short iterations. In the past, the R&D departments hacked away for months and months, then tried to put everything together, integrate it, make a product out of their work, and finally handed it over to the test team. At that point time was typically short, deadlines were passing by, and testing had to be cut short and/or release dates postponed. This approach was called ‘waterfall’. The short iterations of Scrum, called sprints, address the shortfalls of the waterfall methodology by its very nature. A product is developed (and even delivered, to stakeholders at least) every two to four weeks. Work that is done in such a sprint is not just coding — remember that the testers are embedded into the team. The product increment delivered at the end is designed, developed, tested, documented, and ready to be delivered. It is this approach that, during a transition, puts a lot of pressure on the testers previously clustered in TCoEs and on the organization as a whole. Suddenly testers are forced into test automation — otherwise the simply can’t keep the pace. The test is ‘shifted left’ — it has to start as early as development. Manual testers without too much technical background are suddenly part of a very technical development environment. Testing tools need to be changed in order to cope with these new challenges. Processes need to be adapted or be removed altogether.

What’s the advantage? Why would any organization accept so many troubles to go through such a transition? Not surprisingly, it’s the usual suspects: shorter time-to-market, higher quality but also quicker feedback from customers, a more flexible reaction to this feedback. In short it is best of both worlds: doing the right things and doing things right. Agile methodologies pay off in many different ways.

Why agile will win

How are the previous two stories, agile transitions and evolution of cooperation connected? Although it may seem to be far fetched, I think the two are closely related. Robert Axelrod’s work shows that such transitions can succeed even if, all things considered, it doesn’t look very promising in the beginning.

Agile methodologies enforce cooperation. One of the key agile principles is ‘Individuals and interactions over processes and tools’ — which very simply means that people talk to each other, work together… they cooperate in order to create a better product for their customers faster. Agile methodologies, and thus cooperation, pay off — they reward their proponents. That is one of the key criteria, discovered by Robert Axelrod, needed for cooperation to succeed. The other very important criteria, the ‘shadow of the future’ as he called it, where you have to meet again for cooperation to evolve (i.e: your actions today will have an impact on how your colleagues treat you in the future) is an intrinsic characteristic of Scrum. A tongue-in-cheek way to look at it is that a string of sprints is nothing more than an Iterated Prisoner’s Dilemma. Sprints guarantee that the ‘opponents’ will meet again and again and their actions will have an impact on future behaviors.

So although maintaining the status quo as a team (e.g. as the TCoE) might appear to be the best solution individually, it is very likely that a solution that is best for the greater good of the whole organization will succeed over time. All it takes is a small group of individuals working together and an environment that fosters cooperation — as Scrum does.

Start the revolution — you will succeed.

*Originally published in Testing Circus magazine. 


What is Agile Methodology?