First of all, I will confess that I’m also an Agile Coach. I’ve spent a lot of my energy in the last few years helping teams, groups, and organizations become more agile. By delivering value faster, working better or just being happier. The agile movement played a very important role in my journey. Without Agile, I would probably never be at Target Teal.

But not everything is perfect. Agile, like any group or social technology, has its shadows. What I have been observing, however, is that little is said about this in the community.

Maybe some agilists don’t want to talk about it. Or maybe many they aren’t even aware of these shadows. My hope with this post is to cast some light on them and start the conversation.

And the first shadow is …

Extreme focus on the team

The agile movement places a great weight on the concept of team. If you need to make a decision that can change the course of the product, take it to the team. If any new technology needs to be tested, take it to the team. If you have a problem with your fellow coworker, take it to the retrospective. In many groups that call themselves agile, several issues should be brought into discussion with the group, at the risk of you being socially excluded for not doing so. In that case you don’t know how to work as a team, as I’ve heard.

This overfocus manifests itself in relation to other areas of the organization as well. Excessive focus on building a high-performance team can lead to inter-group competition, local optimization, ingroup bias, and strengthen silos. Silos that before Agile were functional, but now are cross-functional. What an improvement! The result: several “high performance teams” and a dysfunctional organization.

Recently I was at a conference talking to other people about taking the benefits of Agile to other parts of the organization. One agilist then told me: Interesting, but I don’t really care. If the team is delivering value, that’s what matters. Ok, but what about the rest of the organization???

Another consequence of the supremacy of the collective is the concept of shared responsibility. In an agile team, everyone is generally accountable for everything as a whole team. There is no clear division of roles within the development team (in Scrum for example). What happens? Many issues discussed at retrospective meetings turn out to be a list of intentions and commitments that never materialize.

In addition, Agile Coaches and Scrum Masters put tremendous energy into team building activities with the goal of strengthening team identity. Oh, and the team can’t change its internal composition, otherwise the work will all go down the drain… Too bad, because the world is volatile and it always ends up happening.

Agile puts so much emphasis on the team that it forgets the organization and the individuals. Only teams have autonomy. Individuals don’t. That is, group value delivery is optimized, but not the organization’s.

Lack of clear agreements about power

The second great shadow of Agile is certainly the lack of agreements regarding power and authority. I believe this is because any traces that remind the old traditional world – processes, structure and division of responsibilities – will be promptly discarded by card-carrying agilists. It will probably be labeled as bureaucracy.

However, we already know that the lack of structure and clarity about authority has a terrible effect on groups. The text “The Tyranny of Structurelessness” portrays this very well. Each and every group has a structure of authority, whether explicit or implicit. Self-organized Agile teams fit well into the category of implicit structure, since in general few individual accountability agreements are made.

Slow and inefficient meetings

Agile teams know how to deliver value to the customer quickly and in short feedback cycles. But this only works from the door to the outside…

The lack of structure and decision-making processes also has another side effect: several slow and inefficient meetings. Four hours of Sprint Planning? Hell boring. Retrospectives? Important, but often ineffective.

Teams usually have endless discussions, unable to reach consensus on which way to go. Check this story:

Eric knew that the X technology being used by the team needed to be changed to avoid future technical debt problems. He brought the alternative A several times to the retrospective meeting, but the team couldn’t move forward with the decision, although they agreed the problem was real and X didn’t really work. Bob and Karen preferred alternative B, which also had advantages and disadvantages in relation to the alternative A that Eric brought.

Fernando, the facilitator and Agile Coach, knew that if he pushed the decision, forcing the participants to move forward even though they were not comfortable, the result would be even worse. The identity of the team would be jeopardized, as wouldn’t be fully committed to the decision.

After several unsuccessful encounters, Eric gave up talking to the group about X.

In the end, the organization was damaged not changing technology X. After a few months it was too late to make any changes, because the cost would be too high. Much code had been created on the top of the obsolete technology.

Individual egos hidden in the collective

If I had to point out the biggest shadow of all, it would be this one.

Do an experiment. At your next retrospective meeting, write down how many times the word “we” or a reference to the group as a whole appears. Also note how many times the word “I” or an individual reference appears. You’ll be scared of the disproportion.

And why is this bad? The team, the collective or the “we” is an abstract entity that we created to facilitate communication. But the real thing is that this “we” doesn’t exist at all. A group has no will of its own. What happens is that people often use this so-called “collective being” to manifest an individual will or need. For example, Éric could say:

We need to change technology X to alternative A, because this will bring benefits to us as a team in the future.

This may be true. But know that Éric also has individual gains in this decision, such as programming in a language he likes and want to improve his skills. Perhaps he has trouble speaking in the first person, as this would make the group suspicious of his intentions…

Éric’s individual need is legitimate, without doubt. What is not functional is to hide it with rational arguments behind a supposed collective will… And the extreme focus on the team, promoted by Agile, intensifies this effect.

Agile in the stages of organizational development

As you may already know, we reference a lot the organizational development stages identified by Frederic in his book Reinventing Organizations. And even if it is difficult to frame a company in the X or Y paradigm, we understand that Agile fits well into the fourth stage: pluralistic organizations.

Look at this description:

These companies seek to create an environment centered on culture and values, generating value not only for shareholders, but for customers and the people who work there.

An horizontalization movement of the structure and empowerment of the teams is common, and the goal is to help groups make decisions autonomously. Many of these companies invest heavily in employer branding, cultivating an environment that is enjoyable. People’s happiness is a priority.

They greatly value joint decision-making, especially by consensus (sometimes consensus by unanimity). In general, many hours are invested in meetings to ensure that everyone is heard. Individual preferences are always considered.

You can replace the bold words with either pluralistic organizations or Agile. Both will fit well.

Is there any hope? What should you do?

Any approach, method, social technology or stage of development will cast its shadows. We just need to be aware and develop new ways to reduce or eliminate them. Obviously, new shadows will arise and we will have to deal with them too…

The work is infinite. If you want to better understand what approaches we are using to navigate the VUCA world and deal with Agile shadows, see this post.

How about you? Do you see any other shadows in agile movement? Share with us. :)