Leadership is the big gaping hole in the Agile Manifesto

From time to time, people will declare Agile dead. On December 1st, Cliff Berg declared Agile dead in a viral post on LinkedIn. Personally, I think declaring a tool like Agile dead because it doesn’t work is like declaring a pencil dead because it doesn’t turn us all into Michelangelos. A tool enhances human capabilities. A tool is only as powerful as the people using it. But declaring things dead can be a good way to see what is wrong with it, maybe redesign it. In his post, Cliff stated that “Agile is dead … but companies still need agility.” Agile is dead, long live agility.

The misinterpretation of leadership in an Agile context

Cliff proposes an evolution of Agile: Agile2. Agile2 starts with an analysis of what is wrong with Agile. If I read Agile2, I read that there is nothing wrong with Agile but that there is something wrong with the leadership model people tend to use with it. As I have pointed out in a previous blog, the way I see the Agile Manifesto is the way I see the Tao Te Ching: it points to something that cannot be described. The way that can be described is not the way. To me, the Agile Manifesto points to something that cannot be described and that is the Agile mindset. But if the Agile mindset cannot be described, there is bound to be interpretation differences. What Cliff and his friends found is that there is a bias in the Agile Manifesto when it comes to leadership. They found that people tend to misinterpret what leadership means in an Agile context. Most people tend to interpret Agile as having self-organizing teams that require no (hierarchical) leadership. Hierarchical leadership structures tend to breed toxic, power-oriented, behavior. This is bad, so a lot of people use Agile as an anti-hierarchical leadership model. Managers are toxic, so let’s abandon leadership for self-organizing teams.

The Agile Manifesto says a couple of things about leadership:

“Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.”

“The best architectures, requirements, and designs emerge from self-organizing teams.”

It’s easy to see how this can be read as: just leave the teams alone. If the team members are motivated, they will get the job done. These texts are from the principles behind the Agile Manifesto not from the Manifesto itself. The Manifesto itself is about balance, not about black-and-white extremism. But this is how people tend to interpret it.

If these principles would have been in the balanced part of the Manifest they would read something like:

“Self-organizing teams and motivated individuals over hierarchical leadership and compliance.”

It would say that motivated individuals and self-organization are great and preferable but that sometimes hierarchical leadership and compliance is necessary. Just like the fact that working software is valuable doesn’t mean there should be no documentation. The line a lot of people seem to miss in the Agile Manifesto is:

“That is, while there is value in the items on the right, we value the items on the left more.”

In an Agile context, leadership is still essential. It’s just a different kind of leadership that is required.

Servant Leadership and Agile

The element that determines if Agile “works” or not is leadership. The crisis in Agile is a leadership crisis. There is a misfit with our dominant leadership model (hierarchical leadership) and Agile. But abandoning leadership all together is not the solution. Agile asks for a different kind of leadership. Agile asks for leadership that is empowering and gives direction. Agile asks for leadership that can combine planning with adaptability. Agile asks for leadership that can balance autonomy with alignment. Agile asks for Servant Leadership.

Servant Leadership can also be easily misunderstood. Servant Leadership is still leadership. There is still authority and accountability. The key aspect of Servant Leadership is that is it based on trust. There is authority but is is rarely used. A servant leader is motivated by what helps the team while hierarchical leaders have a tendency to be motivated by what helps them personally (career, money, power). A servant leader empowers the team to make decisions but if the team is not able to do so, authority needs to be used. Sometimes, the team will ask the leader to make a decision. Sometimes the leader spots a problem in the decision making and interferes. It all depends on the maturity of the team. This is why everyone is a leader in a mature Agile team. The people who do the work can make the best decisions so they should lead. But if overview is needed or business insights or strategy, the leader can help. In Agile Scrum, there is a divide between the Product Owner that determines the what and the Team that determines the how. This an exact fit with the servant leadership model in which the team has the autonomy to make decisions. The what is for alignment and the how for autonomy. This balance between alignment and autonomy is what Servant Leadership is all about. Sometimes, the how can be strategic and the servant leader needs to step in.

“The leader should never settle for mediocrity or second best. People have a need to be pushed to be the best they can be. It may not be what they want, but the leader should always be more concerned with needs than wants.” — Agile2.net

Integrating technology and business

Another leadership problem in an Agile context is leaders that lack either the technology or business knowledge. To build the right things, the business needs to be understood by the leader. To determine whether the how has strategic importance, the leader must onderstand technology and development. Leaders in an Agile way of working need to see the bigger picture. And that picture can be pretty big ranging from business strategy, business politics, product design, product development, IT architectures, etc.

“Technical agility and business agility are inseparable: one cannot understand the one without understanding the other.” — Agile2.net

Agile offers us the tools to implement Servant Leadership

So Agile asks for different leadership skills that are fundamentally different from the hierarchical leadership model. But Agile also gives the leader tools to implement a Servant Leadership model. In Agile Scrum there are tools that help:

• The retrospective is a great place to build an environment of psychological safety. If anything can be discussed and criticized and there is follow-up on the action points, this is a great tool for establishing a safe environment and personal leadership.
• The sprint review is a great place to let the people who do the work take ownership of the work and receive the credit.
• The daily standup is a great place to keep an eye on the process, connect dots and people and see where improvements need to be made.
• The refinement is a great place to identify if the how becomes strategic.
• And in the poker sessions, an even deeper dive into the complexities of the development is possible. Here you can find deeper issues with the architecture or the up and down sides of solutions.
• The product vision is the place where the people in the team can find direction. That direction is needed to make decisions in the team.

Balance between autonomy and authority

As mentioned above, the divide between what and how is a great tool to empower people. But that doesn’t mean the Product Owner doesn’t need to intervene in the how when needed for strategic or process purposes. Agile still needs leadership. Leadership that empowers and directs. The best leaders use authority sparingly but they still need to when the situation requires it. Agile product development still needs planning. But it needs the planning to be adaptable. Agile needs more leadership: it requires the team members to develop personal leadership. The more personal leadership, the more mature a team, the more self-organizing a team can be. This should be a goal for the leaders: to make themselves as unnecessary as possible so they can focus their energy on strategic themes and alignment with the organization and users. But on the other hand, they shouldn’t shy away from interventions if needed. It’s a paradoxical balancing act. Agile is not an excuse to have no leadership.

→ Make sure to check out the whole Agile2 philosophy on Agile2.net.

Thank you for taking the time to read this essay. I hope you enjoyed it. If you clap for this essay, I will know I connected with you. If you follow me here on Medium, you will see more essays pop up on your Medium homepage. You can also subscribe to an email service here on Medium which will drop new essays right into your inbox. You can also connect with me on LinkedIn to see new articles in your timeline or chat with me there.