Alex Kudinov — September 19, 2019 — September 19, 2019
rawpixel / Pixabay
On March 13, 1946, 28-year-old Kitty Genovese was stabbed to death in Queens, NYC, across from the apartment building where she lived. Later that year The New York Times published an article claiming there were 38 witnesses to the murder (primarily residents of the nearby apartment building) yet no one provided help or called for it. Although the NYT later admitted that the story “exaggerated the number of witnesses and what they had perceived,” the impact was still significant, as Kitty Genovese’s death and the NYT article gave birth to what psychologists call the “bystander effect.”
In 1968, researchers Bibb Latané and John Darley built on this idea when they described a series of experiments in which they studied how a subject’s readiness to help in an emergency was affected by the presence of a bystander. As the number of bystanders increased (even if only as perceived by the subject), the willingness to help dropped precipitously. This behavioral pattern has become known as the “diffusion of responsibility.” More recently, Daniel Kahneman, in Thinking Fast and Slow, picks up on this “helping experiment” and discusses it in the broader context of the diffusion of responsibility, which is where I first picked up on the concept.
By now you are probably thinking, “Well, ok, but what has it got to do with Scrum?”
I would argue – everything.
Let’s look at some factors that cause diffusion of responsibility.
Team Size
Let’s start with team size. According to the Scrum Guide,
Optimal Development Team size is small enough to remain nimble and large enough to complete significant work within a Sprint […] Large Development Teams generate too much complexity for an empirical process to be useful.
I would also argue that increasing team size beyond the recommended nine members encourages diffusion of responsibility. As the team grows in size, each team member’s sense of responsibility is likely to drop, as they start thinking that other team members will take on the responsibility of completing a specific task. Greg Barron and Eldad Yechiam write about this in Private e-mail requests and the diffusion of responsibility where they observe that “the probability of receiving a helpful response is an inverse function of the number of simultaneous addresses. […] there are more responses to e-mails addressed to a single recipient, that these responses are more helpful, and that they are lengthier.”
Another potential reason for the emergence of the diffusion of responsibility in larger groups is the perceived sense of anonymity. It’s been proved time and again, that people’s behavior can change dramatically if they feel that the flurry of activities of a bigger social group anonymizes the individual actions. Look at some anonymous comments on any social media platform and ask yourself, if these individuals had a reasonable belief that their comments could be attributed to them personally, would they publish that comment anyway? In many cases, the answer is a resounding no.
While the chance of the perceived anonymity as a cause for the diffusion of responsibility is remote and its effect might be quite insignificant on the Scrum Teams, I would argue that we still need to keep in mind such a possibility and watch out for the associated behaviors.
Task Focus
Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment. Scrum Master serves the Development Team [by] coaching […] in self-organization and cross-functionality.
Albert Bandura, the father of Social Cognitive Theory, emphasizes that managers assigning specific tasks to employees gives rise to the diffusion of responsibility by shifting the focus from the organizational or social (team) goal to individual task-oriented activities. When individuals are assigned tasks, not only does Daniel Pink’s autonomy go out of the window, but also purpose — another pillar of the personal motivation factor. Purpose suffers as people narrow-mindedly focus on their role as “task doers” as opposed to their role as team members in the larger organizational context.
Personal assignments tend to blur the organizational goals or product-driven outcomes in individual minds. “Hey, it’s cool,” we think, “my goal is to get this widget working; someone else will make sure the whole thing makes sense for the customer.”
Individual assignments on Scrum Teams are done for a variety of reasons. One anti-pattern I see repeatedly is when managers become part of the Development Team and assign tasks to team members. Not only does it go against the grain of the self-organizing behavior; not only does it eliminates any autonomy the team members might enjoy and get motivated by, but also, while narrowing down the responsibility for an individual task to a specific team member, it defuses the more important responsibility for the outcome of a PBI and shifts it towards the manager, who chooses to assign the work.
In some cases, the assignment is done for the sake of keeping people busy. Such action misses the point of achieving the desired outcomes — which is usually not staff busyness. In other instances, the assignments are performed based on team member skills. It takes away from collaboration and promotion of skill development, learning, and propagation throughout the Scrum Team.
The less evil version of task assignment is when Development Team members themselves pre-assign each task in their Sprint Backlog during the Sprint Planning event. As opposed to just-in-time collaboration and agreement on the ways of tackling a specific PBI, pre-assignment leads to a narrower focus for the individual team members and a potential loss of the bigger picture and responsibility for the outcome.
If you didn’t have enough reasons for managers, especially those with the historically strong command and control mentality, not to be on Scrum Teams, here you have another one – their actions will increase the diffusion of responsibility.
Expertise
The Scrum Framework, being a framework for creatively and collaboratively developing complex products, provides several rules that should eliminate this described behavior.
First, the framework does not want managers to be part of Scrum Teams. I hear the framework purists sharpening their knives already. However, since, “Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person,” and since the title manager still bears a lot of loaded meaning and associated responsibilities, I believe that manager being a part of the team is a disaster waiting to happen.
In hierarchical structures, people tend to diffuse the responsibility to those who are above them in the hierarchy, possess more power, or bear more organizationally mandated responsibility. Violating the boundaries of the responsibility that match the team boundaries by bringing a manager into the team’s fold will inevitably skew the perceived level of responsibility. The perception of responsibility will shift from being evenly dispersed across the team members towards those with more positional and organizational power on the team. In Separating Leadership from Leaders: An Assessment of the Effect of Leader and Follower Roles in Organizations Virginia Vanderslice notices that “the association of level of expertise or role and the amount of work required can cause people to feel varying levels of responsibility and accountability for their contributions.”
“But Alex,” you say, “the Scrum Guide says nothing about banning managers from being a part of the team!” And you’ll be right — the Scrum Guide speaks nothing about organizational structures. However, for potential managerial candidates to the Scrum Team, I would pose the following questions, “Are you ready to check your managerial powers and responsibilities at the door when joining a Scrum Team? Is your organization ready for that? What impact will this leveling have on your identity as a manager? On the team’s identity? Is your team ready to accept you as an equal? Will the team environment become safer, more collaborative and creative with a manager on the team?” If you answer “no” to any of these questions (and I would be shocked if you don’t), then I would suggest that managers joining Scrum Teams undermine the Scrum framework and jeopardize the desired outcomes.
Second, the cross-functionality of the Development Team is one of the main concepts of the Scrum Framework. From the framework perspective, cross-functionality results in a team’s ability to perform work necessary for delivering a Done Increment with minimal or no outside dependencies. The concept of cross-functionality in its turn heavily relies on the T-shaped (or Pi-shaped, or comb-shaped) approach to developing team members skills. Sole reliance on individual expertise does not bring enough focus on the necessary skill development.
Third, local optimization for efficiency (“busyness”), rather than for outcomes have similar consequences to that of tailoring work to specific individual skills and expertise. While utilization optimization is a topic for another day, one of its impacts is that it transfers the responsibility and accountability for success from the team and organizational levels (i.e., responsibility for outcomes) to the individual and task level (i.e., outputs).
Conclusion
If you still think that diffusion of responsibility is not a big deal, think again. In its various forms and shapes, it can lead to such ugliness as moral disengagement, increased beyond-the-reason risk-taking behavior, social loafing, and groupthink.
The Scrum Framework puts the responsibility for achieving the Sprint Goal and delivering a Done Increment squarely on the Development Team. Bloated team size, assigning work to the individuals, pushing work to the team, relying on unique positional, organizational, and skill expertise all lead to diffusion of responsibility and can be considered anti-patterns that contradict the letter and spirit of the framework.
Diffusion of responsibility is a real and quite nasty thing, and its consequences are potentially very damaging. That is how a meeting of excellent facilitators might end up with no facilitation or poor one. That is how teams might not reach their full potential, attributing the responsibility to individual team members or those outside of the team. That is how organizations might find themselves not achieving organizational goals as their employees are focusing on the parts of the whole, while the whole is not taken care of. That is how victims of an emergency might not get help where and when needed.
As discussed above, Scrum at the professional level has a few levers that either eliminate or significantly reduce the diffusion of responsibility effect. With that said, it is still prudent to keep the consequences of this effect in mind and be on a lookout for the diffusion of responsibility raising its ugly head.
Business & Finance Articles on Business 2 Community
(33)
