The first and most important proposition in the Agile Manifesto states that individuals and interactions are more highly valued than processes and tools. Why? Because people build software.
There's been a lot of murmuring recently at the failure of Agile to live up to its promise. Hayim Makabee wrote that we are getting close to the ‘trough of disillusionment’ with regards to Agile. He points out how consultants have over-simplified the software development process and focussed not on the original Agile values and principles but on “dogmatic processes with rigid rules and rituals”. As a result we now have The Anti-Agile Manifesto.
In order to climb the ‘slope of enlightenment’ Hayim proposes a “back to basics” approach whereby software developers focus on the SOLID principles of object-oriented design, software reuse, design patterns and component-based software development.
This is true but we must also focus on placing more value on individuals and their interactions. It is people that drive software forward not ritualised processes or sophisticated tools.
People, not tools or processes, write software.
Take this example of where the ‘individuals and interactions over processes and tools’ value is unintentionally overlooked: Scrum of Scrums.
Scrum is the most popular Agile development methodology used today and is implemented in one form or another in many Fortune 500 companies around the world. According to the rules of Scrum, there should be 7 (plus or minus 2) people in an Agile development team. Otherwise daily stand-ups and planning meetings become difficult to manage. In reality, many project teams are much larger than this.
Scrum of Scrums is a technique that is used to overcome the difficulties that arise when applying a Scrum approach to a large project team. It allows Agile to scale. In a nutshell, the team is divided into N sub-teams that respect the person limit of 5 to 9 members. A representative from each team then attends a regular “Scrum of Scrum” meeting to discuss the work of their respective team during a sprint and to address any integration issues.
The problem with this is that dividing people into arbitrary groups, with virtually meaningless distinctions between them, triggers discrimination and a tendency to favour one’s own group at the expense of others. In Social Psychology this bias is referred to as the minimal group paradigm.
This social bias between teams disrupts the ability to deliver a product. Why? Because it creates an 'us and them' mentality and leads to the emergence of a blame culture. Inevitably, this has a negative effect on developers' motivation and makes them less likely to accept responsibility for errors due to fear of criticism from other group members.
In a future post, I'll explore what can be done to avoid and minimise this bias.