Servant leadership and self-organizing teams are foundational Agile characteristics. However, defining these principles is like explaining gravity to a child—clear, tangible descriptions are elusive. The image of an English butler still comes to mind when I hear “servant leader.”
We can use simple rules to deconstruct, visualize, and describe these abstract concepts. I think the following rules will create an environment where high-performing teams can exist and flourish:
The official definitions of servant leadership and self-managing agile teams are vague. “The Scrum Guide” states, “Scrum Teams…are also self-managing, meaning they internally decide who does what, when, and how.”
“The Agile Practice Guide,” which was co-authored by Agile.org and the Project Management Institute uses the following definitions:
“Self-managing” and “fluid leadership” conjure up images of “The Lord of the Flies” or communal organizations where everyone and no one is in charge. Endless debate, frustration, and sub-optimal solutions may prevail. “Leading through service” is unclear. Converting “understanding needs” into high-performance is difficult to execute.
Disciplined Agile favors semi-autonomous, self-organizing teams. The definition recognizes that most Agile teams operate in an interconnected enterprise environment. The framework includes a team leader whose role is facilitating communication, empowering the team, ensuring sufficient resources, and removing impediments.
Google examined the characteristics of its high-performing teams and found they share common characteristics:
Simple rules can provide clear guidance for addressing complex situations. They distill wisdom into easily understandable and applicable actions. Three simple rules can describe how to create high-performing teams that enable the virtues of servant leadership and self-organization:
In traditional environments, managers have power. They prescriptively define the parameters of the team’s work—what to do, how to do it, and when it needs to be done. And they enforce accountability. This builds compliance but does not create high-performance.
Empowerment unlocks the team’s creative energies. It shifts ownership and responsibility for achieving outcomes from the managers to team members. Moving decision-making to the lowest responsible level in the organization is a tangible way to enable this rule.
Eliminating multiple layers of management approval works. When I managed the finance applications for a large telecommunications provider, my project managers approved production deployments. They knew if the release was ready to go and dealt with the fallout if it wasn’t.
Leaders should focus on strategy and goals—what to do, and why? Then, allow the teams to figure out how best to complete it. In other words, “no micromanagement.” Breaking the habit is hard but yields great results.
David Marquet shared how he shifted this dynamic as the commander of a nuclear submarine. He transformed the worst-performing ship in the U.S. Navy into the best. The secret? He refused to give an order. Instead, he gave intent. This sparked a tidal wave of change where his entire crew was now actively engaged instead of simply following orders.
When there is psychological safety, fear is absent. People are not afraid of being punished or humiliated by management or their peers. Fear is corrosive. It fosters distrust and stifles innovation.
Maslow’s Hierarchy of Needs sets psychological safety—feeling accepted by the group—as the precondition for self-actualization. In the workplace, this means people are willing to be creative and innovative. Scaled Agile describes how this unlocks the intrinsic motivation of knowledge workers.
A less eloquent way of describing this rule is the “no jerks.” People who abuse their power to embarrass or insult others should not be welcome. Teams should establish and enforce standards of acceptable normative behaviors. Managers should actively counsel and (in some cases) remove those that do not respect others. Leadership at all levels needs to demonstrate and create a safe environment. The old saying goes, “a fish rots from the head down.”
Psychological safety does not imply an absence of conflict. Rather, healthy conflict should be encouraged. Healthy conflict is the passionate pursuit of excellence and focuses on the problems, not the people. Speed Leas describes five levels of conflict. The first level is people working together to solve a problem. The remaining levels describe successive and increasing levels of personalizing the disagreement.
Patrick Lencioni, in “Five Dysfunctions of a Team,” identifies trust and the willingness to engage in healthy conflict as the building block of high-performing teams. If there is an absence of trust, there is a fear of conflict. People will avoid critical but uncomfortable discussions.
We create psychological safety by assuming best intentions and viewing mistakes as teachable moments. No one comes to work thinking, “how am I going to screw up today!” Mistakes happen. Rather than casting blame, we should identify what went wrong and how we can improve.
Many enterprise environmental factors conspire to challenge and limit the effectiveness of our teams. The list is seemingly endless:
Large organizations develop standards, processes, procedures, and cultures designed for control and oversight. Some are necessary to guard against fraud, waste, and abuse. However, excessive rules discourage collaboration, stifle innovation, and limit the ability to deliver value.
The Agile Manifesto defines simplicity as the “art of maximizing the amount of work not done.” Challenge the barriers to collaboration and productivity. Are they necessary? Do they contribute to delivering the product or service? Or do they just add the patina of control?
A large financial services company required over 75 documents to build a new application. A project quality office reviewed and approved each document before the team could progress to the next stage. This bureaucracy slowed progress without improving quality. Eventually, most of those controls were dismantled. The number of completed projects doubled. The time to complete a project and the number of failed projects both declined.
It can be done!
© 2022, Alan Zucker; Project Management Essentials, LLC
See related articles:
Image courtesy of: wrike.com