The effect of Bystander Syndrome on an Agile team

For those unfamiliar with the term, Bystander Syndrome is a condition where responsibility is diffused as a group becomes larger.

From Wikipedia:

The bystander effect, or bystander apathy, is a social psychological phenomenon that refers to cases in which individuals do not offer any means of help to a victim when other people are present. The probability of help is inversely related to the number of bystanders. In other words, the greater the number of bystanders, the less likely it is that any one of them will help. Several variables help to explain why the bystander effect occurs. These variables include: ambiguity, cohesiveness and diffusion of responsibility.

The larger the team the lower the sense of responsibility.

I have noticed a similar trend with self-organizing Agile teams, as the team becomes larger the individuals on the team appear to show signs of becoming less accountable and have less of a sense of responsibility for issues on the team.  Dull or unpleasant tasks get ignored and deferred, whole team action items get ignored with the defense that they expected someone else to take it.    With self-organizing teams there is no single person that is accountable for this and the accountability is so diffused that there is no sense of responsibility. Accountability is reduced proportionally to the size of the team.

But even when there are just two in the team there can be issues. I am sure every other married couple is perfect and this doesn’t apply to you, but there are many occasions where my wife and I each assume another will do a job, only to discover that neither of us has done it.  “Did you pay the gas bill?”  Some jobs have a tendency to fall between our fields of responsibility and get missed. As a result of this we now have a whiteboard in the kitchen and on a daily basis I can see the jobs I have been avoiding and hoping someone else will do.

My observations

Behavior changes depending on the circumstances and how clear the expectation of responsibility is. For example:  If there was a system where the team needs to go and look at a queue of service issues they would be far less likely to look and take up the task, than if the issue was emailed to the entire team.  And the larger the team, the less likely any one individual was to look.

What is particularly noticeable was when a single person was specifically named in an email and asked to look, the response rate would be much higher, and if someone came in person to ask a particular person the rate would be higher still.   In essence the harder it becomes to avoid acceptance of responsibility the more responsibility we seem to accept. But it all seems to be subconscious. I would hazard a guess that the team were not overtly aware that they were dodging responsibility. In most cases each individually felt what they were doing was the most important task for them.

I am not a psychologist and these are just observations of a few teams in action, but much to my disappointment it appears to conflict with my notion that self-organized teams are the ideal.

Where no leader is assigned a hero emerges (or a martyr).

An exception to bystander syndrome seems to be an emergent hero, someone who sees the lack of responsibility and begins to fill the void. Often one member of the team would end up taking the defacto responsibility upon themselves, even though it should be a shared responsibility, this sometimes results in a variation of siloing. The consequence of this is that a hidden dependency occurs, and as there is no formal responsibility when that person is on leave the task gets forgotten or ignored. This may also result in negative behaviors such as informal internal hierarchies or power plays.

This situation also builds resentment, if the self anointed person is making decisions for the team the others may resent this “decision making without authority”, if the tasks are dull or menial then the self anointed martyr may resent feeling obliged to pick up the slack. Neither outcome is healthy and may require an outside impartial person to see and help overcome the resulting dysfunctions.

The value of visualizing your work

In Scrum we ‘forecast’ the work at the start of the Sprint and the tasks are added to the ToDo column on the board, with KanBan we have a prioritized backlog of ready items to take and we take the items from the ready queue (ideally in order).  In both cases similar behaviours occur. Some team members have a greater sense of responsibility than others and so unpleasant work is not evenly distributed, the enthusiasts or martyrs take undesirable jobs. And if any work doesn’t get put on the board the team feels free to ignore it entirely.  Which is why it is so crucial to create cards for all work needing to done by the team and clearly prioritize them, and why the use of a board becomes so valuable for self-organizing teams. It is a way to visualize our work, and by doing so we visualize and reinforce our responsibility.  The board is pretty hard to ignore. In many respects the board become the boss. It tells you what to do, what is most important and which things need help.

 

Action Items from meetings

Ever noticed how in a meeting the whole room can agree that something needs to be done but when asked who will do it, the whole room goes silent. We suddenly become bystanders hoping that it is someone else’s problem, that someone else will volunteer. But as a self-organising team we are all equally responsible aren’t we?

This is a point of internal conflict for me, if an action item does not have an owner it often doesn’t get done, so it is normal practice to assign an owner. We make someone accountable before we leave the room, but by doing so we immediately absolve everyone else of responsibility. We create a silo, maybe it is just for that action item, but it is still a single point of failure. The creation of unnecessary silos is something that I don’t like on principle, but at the same time I am well aware that silos are the best way to get something done. When responsibility is clear the task is far more likely to get done.

My ideal would be to defer the decision on who will do a task until the task is started. When Fred – the team martyr – volunteers to take every action item, because the rest of the team suddenly find something fascinating on their phones or on the ceiling when it comes time to ask for a volunteer, we create a situation where he becomes a bottleneck,  others could do the task, but feel they are unable to because it has been assigned. If the task does not make it to the board we may not even realize he is a bottleneck.

But deferring deciding who brings us back to a situation of a task falling through the gap. My preference is to assign a task for someone to create a card to put on the board for any action item. (I’m always looking for a better way.) It feels like the right sort of compromise, someone takes responsibility for getting the card to the board, so we can be confident it will get there, and once on the board and prioritized the teams understand the need to pull tasks in priority order. Leaving the decision of who will do it until the last responsible moment.

Team size

Independently and for reasons other than diffusion of responsibility, Parkinson (as in Parkinson’s Law), concluded mathematically that groups larger than 20 were ineffective and that the optimal max size for an effective group was 8 or less, which by happy coincidence is pretty close to the Scrum guide of a max of 9.

He was studying governments and leadership groups but the same principles apply to any group asked to make independent decisions and has shared responsibility and accountability.  He found that the communication overhead of larger groups made decision making hard. He also noticed a tendency for the groups to focus time and energy on topics the whole team could understand. Which resulted in a bias towards triviality, the less complicated the topic the more you could become involved.

Smaller groups were generally more effective and better able to make decisions.

What exactly does a manager do?

Most of us have had managers at some point, and in business they are widely accepted as a necessary overhead.  Mostly management is about organisation and communication. A manager is a single point for communicating downwards, they are a focal point for communicating upwards. They can be a decision maker, they can set priorities, they can remind us of responsibilities. They can remove obstacles. They can guide and support and resolve disagreements. Often they also do administration, and reporting. Set goals and ensure you are working on the right thing, are getting the training and support needed, and perhaps even ensuring you are happy in your work. Not much of that requires authority, it is mostly support.

For some of us we have been lucky. Occasionally I have had a boss that I have hardly noticed, he has given me space to do many of these responsibilities myself, only being there when absolutely needed. A boss can do this when he is confident that he can trust you, and that you are able to perform the role independently.

So if sometimes bosses can do this, why not all the time? Is the need for a manager a reflection that the team cannot function without her, or is it because she doesn’t trust the team?  My guess is that sometimes it is one; sometimes the other and sometimes a bit of both.

How does it help us?

This is all very interesting but how does it help us?  I think  there are a few things we can learn. The first is that we are asking people to be both independent self-starters and great team players in the same breath. I am not sure those of us that have been in this space for a while can remember how tough these two skills are to learn and how often at first they feel like they conflict with each other.

Most people grow up with parents setting boundaries and stepping in when needed, or teachers setting clear guidelines.  Most jobs have someone checking to ensure you are clear what you need to do and to ensure you are following through on your responsibilities. So taking that away with no support mechanism is risky. Even people used to making suggestions still expect someone else to decide. And worst of all most people grow up believing that making mistakes is a bad thing. You cannot expect people to unlearn these behaviours over night simply because we believe self-organised teams are great.

Ask someone if they would rather not have a boss and they will jump at the chance, that is until they realize that not having a boss means accepting all their boss’s responsibilities.

What we can learn from this?

1. If you can avoid it do not have teams greater that 8 people.  Communication and decision making are significantly improved. Bystander syndrome is reduced and responsibility increased.
2. Ask yourself – do you really need a Manager, or a Team Lead or a Project Manager for this team?  What role do they provide that the team alone cannot?  If the reason is a question of trust or the skill level of the team, what can be done to resolve that? If a team ‘needs’ someone to manage them, I’d suggest this is a sign of other deeper issues.
3. Self-organizing teams require new and different skills, these are learnt skills and will take time to master. Provide support and guidance and let the team learn them. Be on the look out for emergent leaders or martyrs and help the team become aware of them too.
4. Visualizing work is one of the most powerful ways I have encountered for reinforcing awareness and acceptance of responsibilities. A kanban board is far more effective than any status report or project plan.
5. Mistakes are powerful learning tools. Help the team learn to fail safely. Hold regular retrospectives and celebrate the mistakes, find new and better ways to work as a team.

My final thought is that there are many things a team can do on their own, I believe that with the right support, training and experience a team can function almost independently. Certainly without the need for middle management or project management. But that doesn’t mean it will be easy, or that you can simply pull the manager and step back.

Scrum introduces a Scrum Master as a transitional role to guide the team towards independence, and Agile Coaches may do the same in other environments but more likely in a less structured manner, but in both cases the goal is to create independent self-organised and continually improving teams.