The Bystander Effect in Scrum Teams

Monday, 9 May, 2011

This is a social psychological phenomenon that refers to situations where individuals do not offer any assistance in an emergency situation when others are present. In fact, the probability of help is thought to be inversely proportional to the number of bystanders – so the greater the number of bystanders, the less likely they are to help.

This is a social psychological phenomenon that refers to situations where individuals do not offer any assistance in an emergency situation when others are present. In fact, the probability of help is thought to be inversely proportional to the number of bystanders – so the greater the number of bystanders, the less likely they are to help.

I first heard of this experiment from Derren Brown’s “Hero at 30,000 feet” where Derren simulates the experiment by blowing ‘fake’ smoke underneath a door in a crowded room filled with people (http://bit.ly/4G907w). The video shows that an individual takes action when left in the room alone, but given the same situation an individual chooses to ignore the smoke in the hope that someone else notices. Children watching another child being bullied in the playground are another example of the Bystander Effect.

This struck a chord with me as I related this phenomenon to many situations I have found myself in when I first starting out with Scrum. (And no, I didn’t deliberately start fires in the filing cabinets to see who panicked first) From reading “The Five Dysfunctions of a Team” (Patrick Lencioni, J-B Lencioni Series) this gave me some theory on which to justify this type of behaviour in a software development team environment.

An example…

I remember back to a sprint planning meeting I was facilitating and two team members began to raise voices, point fingers, thump tables and generally become more “animated” around a particular design decision for the upcoming sprint. My first reaction as a facilitator (which may be the wrong one) was to do nothing. I took the opportunity to observe the other team members to gauge their reaction to the change in dynamic. Not one of the other team members spoke out. Nor did they wish to make eye contact with either aggressor.

Some of them surreptitiously rotated their chair away from the conflict. The twitches in body language made it obvious to me that the rest of the team were uncomfortable with this conversation. I choose to diffuse the situation with a well-timed bad joke and called a 5-minute time-out while the two parties cooled down.

Even with the increased anxiety within the room, all individuals failed to respond and were happy to play the ‘bystander’ role. Research also shows that if just one individual chooses to respond to that situation then other quickly follow as ‘helping’ becomes more socially accepted within the group.

Being comfortable with conflict

More recently as a coach, I occasionally observe this type of behaviour when conflict occurs, a team fails to deal with it, and even harness it. And the mistake I made in the above example is that this was a great opportunity for the team. “Healthy conflict” is a well-lectured phrase when it comes to team development but sometimes we can feel unprepared and shocked into silence when conflict arises.

Some facilitators who suffer from the same fear of conflict will look to flatten turbulent discussions too quickly and miss the potential benefits. Conflict stems from passion. Passion is something that can cook up some of the best ideas as well as being the greatest motivator a team can have.

Where new Scrum teams are “formed” we often fail to establish basic working agreements. But we also fail to understand and relate to each other as human beings. Most organisations push through the team formation process to quickly and don’t give individuals bandwidth to gain trust and form solid relationships. The team’s “trust” is the foundation on which all can be achieved or lost. Team’s who skip this opportunity are much less likely to challenge and conflict with each other at critical points on the team’s future journey.

It is true that trust can form naturally over time (a long time) but few projects and teams will be stable enough, for long enough to allow that trust to form slowly. As ScrumMasters we may have to inject some trust-building exercises to catalyse that process and create some ‘difficult’ situations to encourage the team to build strong bonds earlier than they might expect. Try to encourage an environment were conflict is not something to be feared and stimulate passionate discussion around team decisions.

Less is more

A debate that will run and run forever is what is the best Scrum team size. “What is the perfect team size?” is a question that always brings a wry smile to my face in a training course. My inner consultant would answer, “It depends”. In my opinion of the two words, “team” trumps “size”. The size of the team is right where the sense of team is strongest. In my experience, I had had better experiences and seen the perception of ‘stronger teams’ where the team number is around 7 or less. Fewer team members will find it easier and maybe quicker to establish trust amongst the group and become comfortable with conflict sooner. Larger teams are more susceptible to the ‘bystander effect’ as individuals find it easier to conform to the social standard.

“Calling out” team performance

If a team becomes comfortable with conflict as a means to driving towards a better decision or goal, this increases the level of accountability each team member has to each other. Teams who have found this will have no problem in ‘calling out’ another team member on their performance or non-conformity to their team goals or principles. I have read some great examples of this even happening in sports teams, where NBA players have substituted one of their own peers for arguing with the coach.

As a ScrumMaster condone these events as positive steps, however tempting it might be to diffuse them. Examples of this could be a team member interjecting with “cut the crap Simon, did you finish the task or not?” during a Daily Scrum. Or during a retrospective, “Lisa, you spent too much time updating those test cases in this sprint” is a very direct statement to make. But if the team respect each other for that level of feedback they will learn and improve on it quicker than most other teams.