The best Scrum teams that I have worked with were supported by management leaders focused on removing impediments, providing resources, and promoting an agile mindset and culture that supports the Scrum values. It’s not an easy job. Making it more challenging are the agile leadership myths out there that can get in the way of being effective.
From my experience, a lot of these myths come out of a misunderstanding of what team “self-management” means in relation to the manager’s role in an organization. In organizations new to Scrum, this misunderstanding can lead to tension between teams and managers.
In the context of Scrum, a manager isn’t there to tell the team how to do their work. Their role is to support and guide the team from an organizational context.
Managers can play a helpful role in organizations practicing Scrum because they often have a unique view of the organization as a whole. They are sometimes in the best position to see where impediments such as bottlenecks and lack of resources impact the Scrum Team and have the authority to resolve these issues.
In this article, we’ll look at three common agile leadership myths and how to move past them.
Myth #1: There’s no manager in the Scrum framework
One of the most stubborn myths about agile leadership is that there’s no manager in Scrum. I’ve often heard people say that the manager is obsolete because teams self-manage. It’s true that teams self-manage, but let’s look more closely at what that means.
Scrum requires team self-management because it makes sense that those closest to the work are best equipped to determine how to approach it. As the 2020 Scrum Guide points out, “Adaptation becomes more difficult when the people involved are not empowered or self-managing. A Scrum Team is expected to adapt the moment it learns anything new through inspection.”
Team empowerment and self-management don’t mean there is no need for a manager. Rather, the manager’s role — among other things — is to set the guardrails within which teams can self-manage. The self-management parameters will depend on the organization and the team’s maturity, which is the responsibility of the manager to assess. An example of a guardrail might be that each team has no more than ten members or that multiple teams supporting the same product must all work from the same Product Backlog.
Also, keep in mind that the Scrum Team does not operate within a vacuum. Scrum teams are usually part of a larger organization. Agile frameworks change the way that individuals work together. Those who may have operated in silos may collaborate more closely after an agile transformation. Processes that used to happen sequentially may be completed simultaneously. However, agile frameworks do not necessarily change reporting relationships. For example, if a development team adopts an agile framework, that doesn’t mean that the manager needs to hunt for a job any more than the CEO does. Agile frameworks help teams collaborate better and deliver value sooner, but they have no implicit impact on organizational hierarchy.
The manager’s role is to help guide the team to ever higher performance levels by focusing on the “why” of agile. Why are we delivering this product? What does success look like? They also ensure that Scrum teams have the resources they need to deliver value and understand how each member contributes to the team's success.
Myth #2: Managers cannot attend the Daily Scrum
The Daily Scrum is a collaboration opportunity for the manager and the Scrum Team. Its purpose is to improve the team’s likelihood of delivering a useful increment at least once per month that meets the Sprint Goal. Developers must attend this event, but it is not mandatory for the Scrum Master and Product Owner. If guests attend the Daily Scrum (including a manager), it is the Scrum Master’s job to ensure that they don't disrupt the event’s purpose.
Managers attending the Daily Scrum can support the team by resolving any impediments the team is facing. Being on hand at this event allows the manager to tune in more quickly to anything that might be hampering the team’s work.
How the team feels about having a manager present at the Daily Scrum depends on the relationship. If the manager has a command-and-control style, their presence can intimate the team and make that dynamic worse. A manager with a servant leadership approach is often less disruptive. The manager is best to consult with the Scrum Master to determine the impact of their presence at this event and whether or not to attend.
Remember that the Daily Scrum is a collaborative event rather than a status meeting. It’s an opportunity for the Developers to monitor the Sprint’s progress and make any adjustments necessary.
Myth #3: Managers should not attend Sprint Planning
The purpose of the Sprint Planning event is to lay out the work the team will perform during the Sprint. The Developers select the Product Backlog items they can deliver and outline how they will be delivering them. In addition, the Scrum Team collaborates to articulate the value the Sprint will provide to the stakeholders. This Sprint Goal gives the Developers focus.
It is typical for the Sprint Planning meeting to include guests who can advise the Developers on how best to approach their work. For example, a Scrum Team delivering new security features might invite a security subject matter expert to offer input on how best to deliver the requested features. A Scrum Team that has dependencies on another team might invite key stakeholders to lay out how best to manage those dependencies during the Sprint.
Given this context, it is natural to assume that managers may also attend the Sprint Planning meeting to better understand the Scrum Team’s plans for the upcoming Sprint. As with the Daily Scrum, managers attending the Sprint Planning meeting should respect the purpose of the event. They should not step in to alter the plans of the Scrum Team unless invited to do so. The manager’s role is to promote self-management, not tell Developers which Product Backlog items to select or how to deliver them. The manager should work with the Scrum Master to plan ways to ensure that the Scrum Team feels supported and empowered.
Myth # 4: Managers should never attend the Sprint Retrospective
OK, this one is controversial. Many Scrum Masters zealously guard the Sprint Retrospective as a private space for the Scrum Team to candidly discuss what could be improved about the team’s processes, interactions, and Definition of Done.
And they are right.
It is important for the Scrum Team to have that space to discuss improvements. I agree that managers should not attend Sprint Retrospectives as a rule. However, occasional attendance at the Scrum Team’s invitation, with advanced notice, can be beneficial.
For example, suppose a Scrum Team is facing a situation where the test environment is repeatedly unavailable and it’s slowing their ability to deliver value. In this case, the Scrum Team might invite a manager or other individual with budgetary authority to brainstorm ways to resolve the situation. Alternatively, if the Scrum Team is facing organizational impediments, they might choose to have a manager attend the Sprint Retrospective to brainstorm ways to improve the way that the Scrum Team interacts with the organization. These are both valid instances where the Scrum Team may decide to ask a manager to attend to discuss these topics in detail. If the manager does attend, they should work with the Scrum Master to plan ways to ensure that the Scrum Team feels supported and empowered in advance of the meeting.
Conclusion
There is often a strained relationship between new Scrum practitioners and the organization’s management team. Some of it comes down to a misunderstanding of the term “self-managing,” and that has led to the entrenchment of certain myths. Many managers newer to Scrum may need help understanding their role in supporting a Scrum Team and what that looks like. This lack of knowledge can add to the strain, but a little empathy can go a long way in these situations. Their role in the organization puts managers in an advantageous position to help the team remove impediments to their work. Rather than ostracizing managers, teams would do better to help them adapt.
The Professional Agile Leadership course from Rebel Scrum is an excellent way for managers to better understand how to support a Scrum Team. For managers who want to understand the day-to-day activities of the Scrum Team, the Applying Professional Scrum course is a great way to learn the mechanics of Scrum.
