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.
