Alex Kudinov

Alex Kudinov

Alex is a technologist, Professional Coach, and Trainer. He delivers business competitive advantage to his customers by growing and nurturing great agile development organizations.

At Tandem Coaching Academy, where we keep agile coaching non-denominational, Alex is a Managing Director. We work with agilists of all walks, bringing agile and professional coaching closer together.

In 2021 Alex co-authored Enterprise Agile Coaching: Sustaining Organizational Change through Invitational Approach to Coaching with Cherie Silas, MCC, CEC and Michael De La Maza, PhD, CEC.

Alex holds the International Coach Federation Professional certified Coach (PCC) accreditation. He is also a Board Certified Coach, Certified Executive Coach, Professional Scrum Trainer with,  Scrum Alliance Certified Enterprise and Team Coach (CEC and CTC) and Kanban University Accredited Kanban Trainer (AKT).

He holds an MBA degree from the University of Texas at Austin.


In 1968, researchers Bibb Latané and John Darley conducted 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.

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.

Diffusion of Responsibility and 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.

Diffusion of Responsibility and 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.

Diffusion of Responsibility and 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).


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.


“You are not doing Scrum.” How many times have you heard that? Scrum Police are a legion. “If you are not doing `insert your missing part of the framework here OR (even better) a complementary practice`, you are not doing Scrum.”

Whether or not you should be doing Scrum, whether it applies to your environment and context, whether your organizational capacity for change is capable of absorbing the shock that the Scrum framework will inevitably introduce (and that shock, in this case, may not be necessarily a bad thing): these things are not the focus of this post.


Shu-Ha-Ri has been a frequent topic within Agile communities for years to capture the essence, the progress of the agile journey we embark on as we grow and learn better ways of working. Many Agile leaders have written about Shu-Ha-Ri, from Martin Fowler to Alistair Cockburn both creators of the Agile Manifesto. But what is it, and why does it matter?

Shu Ha Ri of Professional Coaching

By Alex Kudinov, Erica J Henson

Shu-Ha-Ri has been a frequent topic within Agile communities for years to capture the essence, the progress of the agile journey we embark on as we grow and learn better ways of working. Many Agile leaders have written about Shu-Ha-Ri, from Martin Fowler to Alistair Cockburn both creators of the Agile Manifesto. But what is it, and why does it matter?

To understand what Shu-Ha-Ri is in Agile, it is essential first to know its origin. The concept of Shu-Ha-Ri originates from the Japanese martial art Aikido. Aikido master End Seishir Shihan explains the idea as follows:

It is known that, when we learn or train in something, we pass through the stages of Shu, Ha, and Ri. These stages are explained as follows. In Shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebears created. We remain faithful to these forms with no deviation. Next, in the stage of Ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process, the forms may be broken and discarded. Finally, in Ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act following what our heart/mind desires, unhindered while not overstepping laws.

Jeff Sutherland, the co-creator of Scrum, leased these concepts to describe the three states of Scrum Mastery and its progression. He rightly identified the same stages a Scrum Masters must pass through to achieve a deeper master of the practice.

Let us walk through a simple explanation of how it applies to Scrum Masters.


In the Shu state – the beginning stage, the Scrum Master is the master of the process, of the Scrum framework. She is good at going through motions of basic practices: setting up and facilitating events, helping her team achieve a stable state, helping the team find its velocity, and guiding continuous improvement through the process of retrospective. Her agile training finally pays off, however, in this state, the focus is more on how to achieve something without worrying too much about underlying theories of agile practice.


When the Scrum Master and her team achieve the Ha state, they are doing more than executing steps to follow a prescribed way of working. The Scrum Master with a better understanding of the underlying theory and principles feels more confident about her abilities, let’s go of the agile techniques mechanistic structure. According to Jeff Sutherland, the team can get software done at the end of the Sprint and has a good Product owner with a ready backlog at the beginning of the Sprint, has data that clearly show at least a doubling of productivity, and has strong management support.


In this ultimate form, a Scrum Master can step back and let the team, a well-functioning and productive organism, perform at their best. The Scrum Master is never in the spotlight and is never a puppeteer. The Scrum Master instinctively and seamlessly adapts to the environment and team needs as frequently as needed. That’s where the whole initiative of the agile transformation might start making sense.

Throughout my career, I have not seen a Scrum Master continuously operate within the team in a Ri state. I suspect there are a few reasons for that. First and foremost, the culprit could be the management. Probably for them, the Ha state is the Holy Grail of productivity. When management sees the teams achieve the Ha state, they could be easily enticed to spread success, and associated agile practices, across the organization. And boy, are they doing it wrong. The usual way the management goes about scaling Scrum in organizations is what we call a Copy/Paste Scrum. A Ha-level successful team gets disbanded to move the best players to different teams ignoring the team dynamics and resulting in the loss of velocity, camaraderie, and cohesiveness. The Scrum Master who helped the team achieve the Ha state goes her merry way, hopefully on to making another team great.

The second reason, I surmise, is that team development is not going in a straight upward only direction. Teams are living organisms. Organisms have good and bad days. They fall sick, and they heal. Teams are no different. They evolve, they improve, they get to the new heights, and they regress. Regression is painful and not tolerated well by a high-functioning team used to its high-performance.

Setbacks for such teams can be challenging to navigate. Ideally, a well-designed and functioning mechanism of inspection and adaptation should serve as a safety net for teams in such situations. When that safety net is present and robust, it catches the team and springs it back up again.

So how does a Scrum Master employ and remain in the elusive Ri state? Alistair Cockburn, in Heart of Agile , says that Ri-level people generally cannot say how they decide on a technique at the moment, because it is so ingrained and immediate. In general knowledge acquisition terms, Ri corresponds to invent and blend techniques. To borrow from Martin Broadwell’s four stages of competence , the Ri state roughly corresponds to unconscious competence.

The main skills a Scrum Master employs in the Ri stage are those of professional coaching.

So how do great Scrum Masters acquire the true mastery of professional coaching skills? How do they hone and develop them? How they keep the momentum going and the continuous improvement chugging along? I would argue that the development of the professional coaching skills by Scrum Masters follows the same steps of Shu-Ha-Ri or the four stages of competence.

The International Coach Federation (ICF) defines coaching as a coach-client partnership in a thought-provoking and creative process that inspires clients to maximize their personal and professional potential. Apply that to a Scrum Master, and you will see that it is precisely what great Scrum Masters do. Here are some useful examples. They challenge their teams to greatness. They raise awareness and build accountability. When a new Scrum Master takes her first step from unconscious incompetence to conscious incompetence (Shu), the sheer amount of knowledge, skills, techniques, and mindset changes are overwhelming. That is where the concept and the mindset of continuous, incremental improvement come really handy.

The Shu state is not for the faint of heart. It is not for those who are looking for quick wins. It is a hard work of learning, practicing, inspecting, and adapting, it is an ultimate learning process. Unfortunately, coaching skills do not make it to the top of their priority list at this stage, and that is a shame. Here, at the Shu level, Scrum Masters are working just way too hard and step in way too many situations that they should not have. In many occurrences this state is compounded by the fact that a Scrum Master is assigned to a new agile team with merely a nascent teams process. What they do not realize is that solid professional coaching skills appropriately utilized would have made their lives much easier throughout their learning journeys, and most importantly, at this Shu state. The sooner Scrum Masters are introduced to professional coaching skills, the easier their path to real mastery will be.

There is a vast misconception about professional coaching skills. Some people believe that coaching is nothing more than sitting on the couch and asking powerful questions. And that belief has its roots. It stems from the subpar education some coaches have received combined with limited knowledge of tools, techniques, and competencies of professional coaching. There is no argument that asking powerful questions is an excellent tool in the toolset of every coach. But a tool is only a tool. It is not merely enough.

Coaching first and foremost is a mindset, one that genuinely believes that a client is naturally creative, resourceful, and whole and doesn’t need to be fixed. A coach believes that a client has all the resources he needs to achieve his goals.

Coaching mindset is immensely curious. Curiosity is an integral part of the growth mindset the mindset that is characterized by an insatiable drive to learn, to push boundaries, and to improve continuously. That curiosity brings such words into a Scrum Master’s lexicon as: what if, I wonder, I’m curious. Notice that none of these are directive or prescriptive. This mindset allows its owner to be open to possibilities, new opportunities, and enables the belief that the team has all the answers it needs to be great.

The Shu Coach

When a coach enters the Shu state, she is already aware of the necessity to possess and potentially transform her mindset to that of curiosity and wonder. She is aware of some essential competencies a professional coach holds dear. She has some necessary tools in her coaching toolbox. She relentlessly exploits these tools and builds her competences while staying fully aware of the fact that only practice and a lot of it allows for the building of those competencies. She speaks less and listens more. She becomes very comfortable with silence. She starts listening not to respond but to understand. She makes mistakes and a lot of them. And she becomes aware of those mistakes. And she practices, and practices, and practices some more. She joins a group of like-minded Scrum Masters to practice even more.

As time goes by, she finds less and less need to use a directive approach to tell her team what to do as they mature in their practices and grow in their cohesiveness. She finds that her daytime job turns into that earlier elusive partnership where her role is that of support, encouragement, and acknowledgment. The buildup of the coaching competencies allows for the emergence of a well-rounded, albeit still a novice and inexperienced coach.

The Shu state of professional coaching skills roughly corresponds to the ICF ACC accreditation. The latter requires some formal training and education, which makes sense as the ICF is committed to upholding high standards of coaching skills amongst its members. Can a Scrum Master build their professional coaching skill competence to the level of ACC without formal education? Absolutely. This certification, like any other competency-based one, is an acknowledgment and confirmation of the level of the coaching capabilities achieved.

How do coaches transition to the Ha state?

Coaches will transition into Ha by actively learning more, practicing harder, and continuously expanding their toolbox. At this level, active listening to the whole person and coaching a person rather than a problem is mandatory.

If you are a Scrum Master, this is the level where you start digging deeper into the essence of the team. You begin noticing and addressing the interpersonal relations, tensions, conflicts. You realize that the team is capable of solving their problems, and your primary role is to help them uncover and understand their beautiful inner selves.

You recognize that, while skills and experience are essential, the intricacies of the personal relationships and team dynamics are what move them forward on their road to greatness. You, as a coach, are highly skilled at bringing about your teams’ self-awareness and building their accountability. You lovingly support the team while firmly and steadfastly challenging them. You become a master of balancing these two.

You realize that the effort you had to expend to practice all those coaching competencies at the Shu level diminish greatly at Ha level. You become consciously competent: you begin mastering the art of choosing the right tool for the right circumstances and do so seemingly. And you may be thinking of that coveted ICF PCC certification, which reflects the training, practice and experience, and adherence to the highest ethical standards coaching offers.

The Elusive Ri

At the Ri level, you are not beholden to any framework, method, or ideology. You pick what feels right at the moment and use it with seamless mastery. Your skills and experience are well developed and so vast that every situation prompts the right response. Can you still be wrong? Yes, you can. But you inspect, adapt, and fix–never letting the same mistake happen again. You effortlessly incorporate the environment and ecology into your work and coaching practices. They send signals that evaded your attention at both Shu and Ha levels. You coach the team as a living, breathing, whole organism as it is while understanding its complex laws of interactions and behaviors. You master scaling the ladder of environment, behaviors, capabilities, values, beliefs, identity, and spirituality up and down and up again, knowing intuitively on which step of that ladder a current situation belongs. Your learnings never stop. The layers and layers of new knowledge now interact with existing skills, behaviors, and practices, allowing you to create your unique style and way of thinking. You are not bound by any coaching tools or techniques that you learned in the previous two stages. Your skills transcend those and allow you to create the practices that serve you best in your unique environment.

The Ri state is exceptionally coveted. There is no yellow brick road anyone can show you that will lead you to it. Just keep in mind that some things in common for those who have walked the Ri path are hard work, an open mind, and an insatiable curiosity. Your mission is to find your way there, and you must want it.

Are you ready to start your journey?



© 2020 by Alex Kudinov, Erica J Henson

All Rights Reserved

This article was originally published at

About Best Agile Articles Project

Best Agile Articles is a collaborative project of the Agile community to bring you the best of the best publications each year. Our goal in publishing these yearly editions is to cull through the many articles that are published each year and provide you with a curated set of high-quality articles that capture the latest knowledge and experience of the agile community in one compact volume.
Our purpose is twofold. First, we understand that it’s hard to figure out where to go when looking for ideas and answers. There are thousands of blogs, videos, books and other resources available at the click of a mouse. But that can be a lot to sort through. So, we thought we could be of some help. Second, we wanted to bring some visibility to many people who are doing outstanding work in this field and are providing helpful resources. We hope that this publication will help them connect to you, the ones they are writing for.
Our intention is that this publication is to be by the agile community as a service to the agile community and for the agile community. With that in mind, we pulled together a great group of volunteers to help get this work into your hands.

The articles in this volume were selected by:
• A diverse Volunteer Committee of sixteen people with expertise in a variety of areas related to agile.
• The agile community. A call for article nominations went out in early 2020 and several dozen 2019 articles were nominated by the community.

The articles themselves cover a wide variety of topics including organizational structure, culture, and agile leadership. There is something for almost everyone here. All editions of the Best Agile Articles publication are available on Amazon and free to download on the Best Agile Article site.
We are thankful for the great participation by the agile community at large. If you would like to participate in delivering this publication in future years, we would welcome hearing from you.

Tandem Coaching Academy - Home of the Only ICF ACTP Accredited program for Agilists
© 2019-2022 Tandem Coaching Partners, LLC. All Rights Reserved

Subscribe To Our Newsletter

Get notified about new blog posts, classes, discounts, and more!