.st0{fill:#FFFFFF;}

Agile Teams Don’t Self-Manage Themselves 

 November 17, 2020

By  Anthony Amos

My introduction to Agile teams happened just as I had transitioned from lead software engineer to release manager at an investment bank. Our team had just built an investment management system that was well received and quickly became quite successful. We were pleased with it, but the growing team struggled to keep pace with business demands, and that triggered concerns. In response to our concerns, senior management committed to direct a new development strategy.

We had already created a release team, a testing team, and then grouped developers into business domains. Then, one Thursday we got an invitation to an all-hands mandatory meeting set for this Monday. Next, our calendars were blocked off for a mandatory 1 or 2-day training session next Tuesday and Wednesday. What in the world is going on? No one knew, and we couldn’t reach senior management.

Monday morning came and teams were assembled in the auditorium. After some introductory remarks, we got the news: Effective immediately we are implementing Scrum. First, everyone will attend Scrum training tomorrow; then on Wednesday, team leads (me) will attend Scrum Master training while business analysts attend Product Owner training. I saw this as good news. Coincidentally, I had read Mike Cohn’s “Succeeding with Agile” a few months earlier, so I was ready to put an Agile practice to work.

In spite of all-around optimism, we learned many lessons; and ironically, the launch itself proved to be the first lesson.

Forming Agile Teams

Lesson: Team members were given an immediate mandate.

One essential aspect of the Agile mindset is mutual trust. Much of Agile cannot work without trust, and communication is a key element of trust; therefore, communication matters when initiating an Agile practice. Best intentions notwithstanding, the act of surprising people with a mandate serves to undermine trust. On the other hand, the act of incorporating team members into the planning process enhances trust. Furthermore, it provides a sense of inclusion and allows people time to adapt.

Self-Organizing and Self-Managing Teams

Lesson: Members were assigned to teams.

Agile teams are self-organizing and Scrum teams in particular are self-managing as defined in the 2020 Scrum Guide Update. Encouraging teams to manage themselves is a form of empowerment that leads to many other benefits that I will describe later. The core principle of self-management is that those closest to problems tend to be best equipped to properly resolve those problems; but self-management is neither natural nor easy.

Team members typically expect to take direction from management, but a self-managing team drafts it’s members and identifies and resolves problems themselves with assistance from a Scrum Master. They collaborate with other teams to minimize conflict and make effective use of the Product Owner to ensure they meet business needs; thus, eliminating decision-making impediments. While solving problems, self-managing teams also have the freedom to succeed or fail with experiments.

Empowered Teams

Lesson: Changes required committee approval.

Empowered teams have the freedom to experiment, but therein lies the challenge. Experimenters are often celebrated when successful and punished upon failure. This practice kills team empowerment. An experiment’s purpose is to teach, so when teams fear the consequences of falling short, they don’t grow much beyond the limits of their existing abilities

Mutual trust between teams and management is the lynchpin of empowerment. However, trust requires a willingness to be vulnerable, which can make almost anyone nervous. The cost, however, when mutual trust is absent, is that the team cannot function at its best. A team that is not empowered cannot self-manage.

Team Expansion: Adding and Replacing Members

Lesson: Outside control of ongoing team membership.

An Agile team should ultimately be able to fully deliver an increment of value without dependency on other teams; but there is no requirement that teams start out fully formed. Members can be added or replaced while becoming cross functional.

Adding and replacing team members will slow team progress initially as new people integrate with the team; so, take this into account when planning Sprints or program increments. When possible, it is generally better to add three members at once, than to add one member per iteration over three iterations; but evaluate individual scenarios as this is not always the case.

Impediments: Removing Members

A common myth is that team members cannot be removed from an Agile team. This is unrealistic. What Agile does expect is that the Scrum Master and team will make every effort to resolve problems within the team before resorting to removing someone. The team has a responsibility to act if a member’s behavior, when considered objectively, consistently interferes with delivery, quality, or value.

Self-managing teams are more reliable, creative, innovative, and they continuously improve. Furthermore, research shows that self-managing team members generally have high morale. For leaders, developing a self-managing team requires an organization-wide commitment to the Agile mindset. Back then, we expected to realize the benefits of Scrum; but we didn’t fully appreciate the concept of self-organizing teams.

I’ve described some of the lessons learned, but there were others. For example we kept using specialized teams, treated daily stand-ups as status meetings, and allowed influential people to sneak in “quick changes”. In a nutshell, we squeezed past practices into the Scrum framework.

Ultimately, we learned from our mistakes by doing other things well. We made effective use of Retrospectives; we experimented; we set boundaries with influential people; and we created cross-functional teams. We evolved practices to use the full Scrum framework and engaged experienced Scrum consultants. We began to show significant quantifiable improvements which made everyone’s work life easier and customers even happier. Teams of self-managed teams made this possible along with a leadership team that was willing and able to trust the process and the teams.

Anthony Amos


Anthony started creating software in 1981 when he curiously picked up the programming manual for a Wang OIS Word Processor while deployed with the US Navy. He had never seen a computer before, but he taught himself how to write programs that made his Navy work easier and more accurate.
After his honorable discharge in 1986, he began creating financial and analytical software for diverse organizations including Verizon Wireless, JP Morgan Asset Management, GoldenTree Asset Management, NASDAQ, Prudential Insurance, AT&T Capital Corporation, Lehman Brothers, Ernst & Young, and Blue Cross & Blue Shield of New Jersey.

Demonstrating his commitment to the principles and values of Agile Software Engineering, Anthony is a recognized SAFe® version 5 Program Consultant and holds many of the most challenging and difficult to attain Agile certifications. His practice is grounded in Agile Frameworks as he leads clients to implement Scrum, Kanban, Scrum with Kanban, Scaled Scrum with Nexus, and Scaled Agile Framework. He believes in using the framework that best fits the organization's cultural and business direction while maintaining disciplined processes.

Tony Amos

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}

Subscribe to our newsletter now!