As an agile methodologies SCRUM is pretty simple to follow. There are basically 3 roles , 4 ceremonies and small bunch of practices. So why does it work? let me take a game theory perspective to the how, in order the explain the why.
Sprints: Deliver often!
A sprint is a unit of time (in our team is 2 weeks) in which the team plans and delivers an increment of the product that provides value to the customer. Once a sprint finishes a new one starts, the 4 SCRUM ceremonies are held within one sprint.
Classic waterfall projects tend towards a big bang approach to delivery. For the customer and the supplier, it leaves a door open to last minute surprises: “this is not what I ask for, it is going a bit late, I am not paying you, we had to cut that feature…” This might be represented as deflections by both sides (or players in a prisoner’s dilemma).
Tricking the other side into doing their part without you doing yours, (e.g. increasing your margin by cutting test effort and delivering bug-ridden software) can be more appealing if the players are not likely to meet again (or at least not in the near future).
However, if these interactions are more frequent and longer lasting, the benefits of ongoing collaboration become more attractive. This approach to fostering collaboration is well argued by Axelrod and it is implemented by scrum in the ‘sprint’ concept.
Product Owner,Backlogs and Stories
The Product Owner represents the customer needs to the team, and provides clear requirements (Stories) to the team. The Product Owner (PO) interfaces with the multiple customers and it’s the only person providing stories and priorities (backlog) to the team.
In a situation where the customer is not easily accessible or multiple parties are involved, collaboration becomes harder and less explicit (this is well explain by Schelling). The creation of a single and accessible customer makes the game a very straight forward prisoner’s dilemma. The product owner hides these complexities by providing a single and local customer interface to the development team.
Small and Self-organising teams
A scrum is a small group of people 7 +/-2 , that organise and assign tasks to themselves. The team elects a ScrumMaster to facilitate the self-organisation.
There is a second level of games occurring in your average software project: Can a member of the team get away by doing less than expected? Well, there will always be a star performer to pick up the slack, right?
This problem is familiar to all project managers, but may its solution is less obvious… self-organising teams. The issue with an individual defecting in a Project Manager lead team is that the consequences are not so clear… the PM has to judge if the information provided by a developer is accurate, and a developer is always at risk of being used as the scape goat by rogue PMs.
Small and Self-organising teams increases the stakes of deflection, the deflector is no longer judge by a single person but by a small community of peers… nowhere to hide!
Scrum is not optional
Scrum works because set a well balanced framework for human interactions. It creates an environment designed to foster collaboration. But do Scrum projects fail? Yes, and often. May teams take a “pick and choose” approach to Scrum. The bottom line is: You either do Scrum or you don’t – none of the roles, ceremonies or practices are optional.
Victor Tuson Palau 