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.

img_0121

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.

 img_0218

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.

 

 

Advertisements

Building on the foundations of Joy

I have recently finished reading the book Joy Inc. by Richard Sheridan which is the story of a small software company that has been successful, most notably as being a great place to work. The CEO had come from a an extremely successful start to his career, he had been promoted up the greasy pole to VP of software for an established firm and he had become wealthy in the process. By most conventional accounts he was a success, but he wasn’t happy.  He made a decision to change his work environment with a focus on creating a place that made him happy to come to work. This single minded goal eventually led to the forming of a software company – Menlo – with him as CEO where he could create a place of work that brought him ‘Joy’.

For those familiar with the work of Ayn Rand, I found a great many correlations between Richard Sheridan and Howard Roarke from ‘The Fountainhead’.  Rich Sheridan had a very single minded vision and he chose the path his company would take without compromising on his views. The book portrays how he set the direction and imposed his plan of how things should be done, resulting in a company that has adopted many of the XP practices described by Kent Beck.  The business has been successful and the workers are happy, Pair Programming, short iterations, innovative software solutions and a focus on quality.  The workplace includes dogs and babies and sound like a fun environment. In many respects at first appearance this is a model that we could learn a lot from.

Rich Sheridan has demonstrated the effectiveness of using Agile Practices and that success doesn’t require death marches and unrealistic expectations. Rich has shown one way it can be done, and there is a lot to admire in how he has achieved it. There is certainly a lot to learn and I think there are a great many aspects of what he has done at Menlo that could be used as the foundations of creating a great company.

I don’t build in order to have clients, I have clients in order to build…

Ayn Rand

However, much as I admire Rich and see him as a modern day Howard Roark, it is because of that comparison that I also have a number of reservations.  Rich himself refers to the book “Good to Great” and he acknowledges that he is not a Level 5 leader, this was an assessment I shared whilst reading the book. All his decisions were about creating Joy for himself, but there were dozens of examples in the book of absolutes, where his vision may not be compromised. I got the impression that he made all the decisions, he decided a process and it must be followed, if someone wanted something – such as the wonderful example of babies in the office – they asked him. The decision to allow babies in the office seems to be as much about wanting to be regarded as a great boss as anything else. That is not a bad thing but I am assessing this in terms of a model that can be replicated. 

Rich is uncompromising in his objectivism and Ayn Rand would be proud. Which is only half a compliment, I always admired Howard Roark, for a while he was an inspiration for me, but at some point I realised that taking input from others didn’t automatically mean you were compromising your principles or were weak, we can learn and adapt and improve but still stay faithful to our principles.

Recruitment and single person decision making

His recruitment policy is a great example of what I see as this type of blinkered thinking. Rich has introduced a recruitment policy designed to prevent making mistakes in hiring.  The problem is that his solution is to require two separate interview days, and then a 3-week trial, and after this they make a decision and the vast majority will be unsuccessful.  Anyone else see the flaws in this? 

To get hired you must give up 17 days for one interview. For most people with jobs that is not even close to being possible, and for an good candidate looking they will likely have multiple options open to them and this level of barriers to entry makes it highly unlikely that any good candidate would bother or be able to apply.  Therefore he is limiting his recruitment to the unemployed and graduates that are able to meet his interview requirements.  Now this pool will contain some good (if inexperienced) candidates, but the process has excluded so many other great candidates that I think it is an example of a process that has forgotten what the problem is that it is trying to solve. In this case I assume to hire great employees.

He clearly loves face to face communication and paper based systems and estimation using hours. Therefore everyone must comply, everyone must communicate face to face, they may only use paper based processes and must use hours for estimation. It is not that I am questioning whether the decisions are good or bad, clearly he is getting many right – he wouldn’t be successful otherwise, but it is a company built around a single individual. He is seemingly a strong CEO and charismatic leader, but that leads to an unsustainable business model, where does it leave Menlo when he moves on? What is his succession plan?

Using Agile practices doesn’t make you agile

Menlo use a variety of Agile practices, mostly from XP, but from the way the book describes it they are a set of rules fixed in stone, thou shalt do it this way…

The practices chosen are good practices, but I don’t think that Agile is about using best practices, I think it is about a mindset of improvement. Menlo had adopted a variety of practices that generally I support and endorse, but I didn’t get any sense that there was a culture of reflecting and improvement. Retrospectives did not seem to be part of the accepted practices at Menlo.  This for me was the saddest omission, without retrospectives Agile is weak and ultimately cannot survive in the long run. Menlo seem to have adopted 11 of the 12 principles, but it is the 12th that I value most.

I so wanted to enjoy this book, it is one I had looked forward to reading for a while, but in the end I was left feeling that Menlo was actually on the wrong path. Not that using XP was wrong, but if you have a culture that is not always seeking to improve it will eventually fail. 

I probably sound horribly hubristic, and I have not achieved the level of success Rich Sheridan has, so this may sound hollow.  But Rich, please introduce retrospectives into your culture before it is too late and be prepared to let your teams guide you to improve, you may me amazed to find they have some great ideas. If you do I think you may find a way to improve on the Joy you have already found.