Introduction
If you’ve read the Scrum Guide or checked out the SAFe “big picture,” you’ve undoubtedly noticed that there’s no mention of managers. Anywhere. Neither mentions anything about reporting structure or organizational charts, and those are ultimately very real concerns in the places where we work. It’s enough to lead one to ponder the question — “What role do managers play in an agile team?” The answer is that it can look very different based on the person and context.
But first, know that the manager role is an area where change agents must bring empathy and tact to their work. Many managers were once valued contributors who made the decision to go into people management. Different folks are intrigued by different aspects. Some are weary of the technical career path. Others want the real or perceived authority to influence what their teams are working on, while some want to really work on building a leadership skill set. And for some others, it comes down to simple economics — moving to a manager role is sometimes the best way to make more money.
When an organization shifts to an agile mode of operation, managers can often be the toughest people to win over. This is because the transition often means that you’re taking part of their job — perhaps a part they like very much — and giving it to someone else. Read that sentence again and let that sink in. And now for an example. Let’s say a person got into management because they wanted to prioritize the list of things that the team is going to build. Transitioning to Scrum, for example, means that this is no longer their responsibility. That now falls to a new role, the Product Owner. Or maybe the person really enjoyed architecting and executing the process that the team used to operate on a day-to-day basis. If the team is shifting to Scrum, that responsibility now falls to the Scrum Master and the team.
Now that you have some awareness of what the transition might mean for a manager, you hopefully won’t be surprised to know that managers can often be the biggest roadblocks to team agility.
Agile Manager Patterns
Manager as Team Member
In this pattern, the manager is serving as the manager and is a team member on the agile team. They are doing work items — either on their own, or pairing with other team members. This pattern most often manifests itself when the manager starts off as part of the team. When this pattern is effective, it’s because the individual has a level of awareness that comes with their new role. They realize that they have to balance team participation with the fact that they’re now the team’s manager. The flip side of that coin is where the dysfunction can creep in. Every time the person says something, team members have a hard time distinguishing whether the individual is speaking as a team member, or as the manager. Whether it’s something important or a trivial decision doesn’t really matter. There are layers of ambiguity in almost every conversation.
Manager as Product Owner
In this pattern, the manager is serving as the manager and the Product Owner for the same agile team. This pattern can manifest itself in cases where the manager of the team is very knowledgeable about the product being built. Perhaps they were the most knowledgeable technical person on the team, or perhaps they came from outside the team and brought a significant amount of product or technical knowledge with them. The organization doesn’t want to lose that accrued knowledge, nor does the employee necessarily want to give up that knowledge. There also may not be an obvious person to fill the Product Owner role. When a manager steps into the Product Owner role, there’s a risk that the team will see them as a task master. Since the Product Owner’s domain is the Product Backlog, these concerns are very valid. Worse still is the fact that the manager may have enough technical chops to dictate “how” the team should do the work. No longer are backlog items an opportunity for a conversation about the best approach. Instead, they read like a numbered list of steps to take to achieve the goal, maybe even complete with snippets of code in-line. Role ambiguity can creep in with this pattern, as well. Every conversation can be infused with quizzical looks from team members about whether they’re being spoken to by “the manager” or “the Product Owner.” In one instance where I’ve seen this pattern be somewhat effective, it was because the individual doing both roles made a point to explicitly say when he was speaking as a manager, and when he was speaking as the Product Owner. “As a Product Owner, I want us to…” was a frequent phrase I remember hearing. Whether or not the team valued his attempt at real-time role playing is anyone’s guess, but his behavior felt genuine.
Manager as Scrum Master
In this pattern, the manager is serving as the manager and the Scrum Master for the same agile team. Wearing the Scrum Master hat can seem like a natural role for a manager to occupy. “I need to have an awareness of how the team is doing. I also need to help them solve challenges. What better way to do that then to be the Scrum Master?” The risk of dysfunction with this pattern is very high, however. The Scrum Master role involves guidance and coaching. When a manager plays this role, it can take on a leader-as-symphony-conductor feel, where the manager uses heavy-handed coordination in place of gentle guidance. While not quite as potentially dictatorial as the manager as Product Owner pattern, the risk for that is here, as well. To make this pattern work, the manager must bring a high degree of coaching acumen to their management style, and know when to keep quiet and let the team solve problems.
Manager as CEO (Chief Enablement Officer)
In this pattern, the manager is serving in one role — a manager of an agile team. The manager is an enabler, enabling the growth of people on the team, and keeping the focus squarely on professional development of team members and overall team development. In this pattern, there’s complete delegation of the product and process responsibilities to the Product Owner and Scrum Master, respectively. But there’s not an abdication of all responsibility. The manager is keenly aware of the work that the team is doing, as well as the process they’re using to do the work. However, they remain laser-focused on growth of their people, with an eye on roadblock removal, as well.
Manager as Absentee Landlord
In this pattern, the manager is almost completely transient. They occasionally show up to team events, but are mostly “doing manager stuff.” This detachment can be for numerous reasons. It’s possible that they resent the new roles taking over previous responsibilities. It may also be because they’re struggling to figure out how they can contribute to their team’s success. They may also be actively looking to move out of their current role to a different role. It might come as a surprise, but team members actually tend to be alright with this pattern. At least until performance review time, at which point the conversation quickly turns to examining how their manager is supposed to judge individual contributions when they weren’t around to see them. But performance reviews is a different blog for a different time. The Scrum Master role is the area where this pattern can present the biggest challenge. If the manger isn’t in tune with what the team is dealing with, it can be a challenge for the Scrum Master to escalate and get issues resolved in a timely manner. It can also be hard to get buy in for continuous improvement opportunities. For example, let’s say the team identifies a need and there’s a cash outlay required, which needs managerial approval. If the manager doesn’t get the rationale for the request — from having lived through the pain with the team — challenges can arise.
Elements of an Effective Agile Team Manager
Enabler of People
This is the chief concern of the manager of an agile team. No longer responsible for product and process decisions and guidance, managers of agile teams can really excel in this area. This element can take a few forms. If the manager is a technical expert, for example, and trying to grow the technical skills of their team, they can use the work as an opportunity to do that. Pairing with the team on stories, or performing code reviews, is a common manifestation of this behavior. Managers can keep skill development at the forefront of any conversation they have with their people and the team as a whole. If they note gaps in the team’s skill set — for example, let’s say a person with a skill in a specific area is scheduled to retire and there isn’t anyone else on the team who knows how to do that one particular things — the manager can work with the entire team to make sure this skill development can happen in tune with the work. Professional development is one of those things that often gets lost in favor of “getting work done.” Managers who are true enablers of people understand that “sharpening the saw” is the real work.
Systemic Roadblock Remover
Depending on your organization, there are areas where managers can achieve things that Scrum Masters and other change agents cannot. Some of this is merely because of their job title. But some of it may also be because of rapport they’ve built with upper management. Managers who have been with organizations for any length of time have often built a social network throughout there area, particularly if they “grew up” in the organization. Systemic roadblock removal is an area where managers of agile teams can provide a lot of value, and that value might stretch far outside the bounds of the team they manage. For example, let’s pretend that a team discovers an impediment in an area that other teams have also been struggling with. The difference with this team, though, is that their manager is going to take action to resolve it. The removal of the impediment becomes a game changer, not just for the team they manage, but for the entire organization.
Partner of Product Owner and Scrum Master
Managers of agile teams must actively cultivate relationships with the Product Owner and Scrum Master. They must be proactive with engaging. They’re quick to schedule recurring 1:1s and never shy away from using them as opportunities to get and give feedback. They see the roles of Scrum Master and Product Owner as something to enhance their team’s ability to deliver great products; not as a threat to their managerial turf. They view the partnership as an equally balanced triad that’s destined to lead the team into an exciting future.
Conclusion
“Agile” has never been synonymous with “get rid of the managers.” Instead, managers must find potentially new ways to contribute to the overall success of their team. Their contribution is probably not going to be from playing an additional role, because the chance for dysfunction is way too high. Know that there is no “best practice” when it comes to this territory. By focusing on the elements listed above, managers of agile teams can ultimately set their team up for success.