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 has 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. I agree 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.
Let me give you an example of where I believe 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. The problem is that 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 usually 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 the team during a sprint and to address any integration issues.
The problem 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.
The presence of this social bias in teams disrupts the ability to deliver a product. It could lead to the emergence of a blame culture which has a negative effect on a developer’s motivation and makes her/him less likely to accept responsibility for errors due to fear of criticism from other group members.
In a future post I will explore what can be done to avoid and minimize this bias. What are your thoughts? Have you ever experienced this situation when working in large project teams?