Updated: Mar 2
Scrum teams are structurally different from traditional development teams. The Scrum framework contains three mandatory roles that form a Scrum team: Development Team, Scrum Master and Product Owner. The general direction for other stakeholders (such as management, architects, etc.) is to support the team and come to its full potential).
Because of this definition, we now understand why the same question arises in almost any organization trying to transition to the Agile frameworks (Scrum in our case). “Where is the definition of team leader in Scrum?” Alternatively: “Do we need to keep them?”
In most cases, the traditional teams will follow a “Top-Down” approach where Management defines the project deliverables, schedule, and pace. While on the other hand, Scrum teams will utilize a “Bottom-Up” approach, where they will determine their rate and deliverables based on priority, velocity, and capacity (under the restrictions of the organization and boundaries of costs, budget, etc.).
The Traditional Role of a Manager in the Corporate World
The traditional role is based on “Command and Control.” This method includes one authority (Manager) that will control the significant aspects of the project, such as team deliverables, processes schedules, and budget.
In this method, the interaction between the manager and employees is usually based on four simple phases:
The manager will identify the organizational “needs” based on budget, commitments and the pre-defined plan.
The manager will provide his employee a list of detailed demands, expectations, and goals (the employee should follow the instructions trusting the manager's experience, judgment, and knowledge).
The manager will monitor the employee’s progress based on specific instructions.
The Manager will compare the employee deliverables to the initial goals.
In the constantly changing software industry, this approach becomes less efficient and by far less productive than what we have in the Agile frameworks. There are many reasons for this and why more and more organizations are now moving to Agile. To clarify my point, I will focus on these three aspects:
Productivity – There is no way that a single manager can handle the current challenges that arise in almost any software development project. Just think of the areas this manager will have to handle in a single project, understanding the organizational and technical requirements, scheduling, deliverables, and quality.
Centralized Management – We cannot throw this method away because we now have an alternative. Still, centralized management comes with some significant challenges, starting from issuing a list of technical instructions to the team (sometimes per employee), handling internal/external dependencies and dealing with HR issues that may critically affect team performance.
Team Motivation – I think we can all agree that this type of management (depending on the manager and his leadership style) does not help increase employee motivation. As followers, the employees’ role is to follow their manager’s instructions with no freedom, decision-making, or trust. That will not provide any sense of absolute ownership of their work.
Why Can Agile Be Scary for Some Managers?
Before diving into the manager role, I want to discuss Scrum's “bottom-up” approach. Scrum uses an advanced approach to creating “self-organized, cross-functional” teams that take full ownership of their work.
The Scrum framework contains three leading roles (Team, SM, and PO) critical to the project's success. However, the Scrum framework does not provide the same level of detail regarding other stakeholders such as development manager, project manager, product manager, test manager or any other stakeholders that possess a management role.
Therefore, those stakeholders involved in the Agile transition will struggle to find their role in the new Agile teams, especially when there are no criteria that specify their new responsibilities.
What Is the Role of Managers in this World?
In theory, and based on my interpretation of Scrum, the role of managers has a substantial impact on the team’s ability to succeed in this new environment. Below are just some of the insights I have gained on this topic:
Promote the new re-organization
This is classic for managers. Help the organization transition from a traditional way of working to Scrum. Their work will focus on the re-organization and removing any barriers that may affect this transition.
A servant leader with a corresponding state of mind
Like the SM, managers should shift their state of mind from a single authority into servant leaders of their teams. Their new activities will focus on many activities that will help their teams, such as:
Creating safe working environments for their teams.
Investigate new tools that can improve efficiency.
Planning technical training that will improve areas of knowledge as required.
To allow Scrum teams to grow, the old fashion management must be removed, and managers should take one step back and not interfere with the Scrum implementation (this is critical for new teams who have just started with Scrum).
Lead by example
This is one of the essential things in an Agile transition. Leaders who used to lead by the authority must now embrace the new culture and lead by example. At the same time, they must allow their teams to grow and take further ownership.
Removing organizational impediments
As we expect the Scrum Master to remove impediments affecting their team’s capability to perform at the highest level, we can expect the same from team leaders. They should reinforce the team with relevant resources, remove bureaucracy, and provide training as needed.
Generate constructive feedback
Constructive feedback is another tool that managers can use to promote their teams' agenda without enforcing it with authority. It also helps the team improve continuously.
Use their experience by providing technical assistance
Managers can use their knowledge, experience, and expertise to help whenever the team needs or asks for it.
Help determine prioritization
This is a classic area for managers to show their importance to their teams. Using their knowledge, experience and broad perspective, they can work with the team to make robust and effective prioritization decisions. This will ultimately increase their ROI. The following are examples of where the managers’ contribution can be felt:
Help the team prioritize technical debt affecting their ability to deliver real value.
Help the team with sprint planning and prioritization of their stories.
Help the Product Owner prioritize the product backlog.
Help the Product Owner and team balance functional and non-functional stories.
Manage all HR issues
As part of his job, the TL will conduct regular one-on-one meetings with team members and help with different HR issues. In addition, they will recruit and hire new employees, integrate them into the team (with the collaboration of the SM) and remove any harmful effect that may arise while a new member integrates into the team.
The Traditional Manager as the New Scrum Master
A common approach to redefining the traditional manager's role is to convert them into the Scrum Masters of their team. On the face of it, this seems good for the company, but believe me, it can be devastating to the team.
When the manager plays the role of the SM, it is doubtful that the team will gain the confidence to begin to self-organize. The manager will most likely keep the old management patterns and habits, which will make it almost impossible for him to release ownership to team members.
I have seen many managers who successfully made this transition, which is the approach I believe in. This is because they firmly believe in their team and the Agile values. However, it’s best that the Scrum Master is chosen by the team members and can be anyone from the team itself.
Do Scrum Teams Need a Manager?
If you had asked me the same question five or six years ago, my answer was very decisive, stating that Scrum teams do not need managers as they have the SM and PO now doing the same job.
After all those years that I used to believe in this approach of clear separation between managers and Scrum teams, I realized that I was severely mistaken, and now I don’t waste my customer's time providing the clear separation between managers and Scrum Masters. I currently use the approach that the Scrum Master is the old team manager.
Although it counters the theoretical foundations of Scrum and what is common in the industry, I realized that this was the best solution for my teams. Although there are still occasional minor problems, mainly related to “don’t let the fox guard the henhouse,” these problems are nothing compared to the problems created when we use the unnatural separation of managers and Scrum Masters that need to work together with the same team.
To be able to succeed in their role as the new Scrum Masters of their teams, managers will have to evolve and change their management style; here are just a few examples of how:
Managers will have to promote their team and provide them with the tools to improve.
Managers will have to challenge their teams to expose their actual capabilities and creativity.
Managers will have to let their team know they trust them by providing them the room to work and make mistakes.
Practices to Avoid as Managers
Let’s review some of the most common bad practices in organizations related to the manager’s behavior.
Assigning work in their teams
One of the major cornerstones in Scrum is the “self-organized” teams that can determine which team member takes ownership of a given unit of work. Therefore, there is no need for old habits of assigning the work.
This responsibility belongs to the team, and they need to provide answers during their daily Scrum meeting. There is simply no need for micro-management, as the team will follow the Definition of Done and Acceptance criteria.
Not listening to their teams.
Team leaders who fail to leave their ego at the door and do not listen to their teams will become the team bottleneck. Good managers put their egos aside, listen to the team, and respect their decisions even if they think there is a better way to do it.
Prioritizing work for the team
The team, together with the Product Owner, owns the work. Therefore, the TL can assist and share his thoughts. He must not have the authority to delegate or prioritize work items for the team.
Deciding what work needs to be delivered
The Scrum framework provides two roles that are responsible for this issue. The PO determines the features and requirements to be delivered, and the development team determines which tasks are necessary to achieve them.