Wednesday, April 11, 2018

The Manager Role in Scrum Team | Supreme Agile


The scrum framework contains three mandatory roles that co-exist as scrum team, Development team, Scrum Master and Product owner (The general direction for the rest of the stakeholders such as management, architects Etc. is to support the team).

Because of this definition, we can now understand why the same question arises in almost any organization that is trying to make a transition to Scrum. “Where is the definition of team leader in scrum?”  Alternatively “Is there a necessity to keep them?” By asking these questions, we can understand that the organization is in the first phase of exploring scrum and what does it really means to implement it.  

If you are familiar with the Scrum framework, you are most probably aware that scrum teams are structurally different from traditional development teams.

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 own pace and deliverables based on prioritization, Velocity, and capacity of the team (Under the restrictions of the organization boundaries of costs, Budget, declines etc. ).

The traditional role of a manager in the corporate world


The traditional role of a manager based on a well-known method of “Command and Control”. This method based on one single authority (Manager) that will control the major aspects of the project such as Team deliverables, Processes Schedules, and budget.

In this method the interaction between the manager and the employees is based on four simple phases:
  1. The Manager will identify the organizational “Needs” that based on budget, commitments and pre-defined plan.
  2. The Manager will provide to his employee a list of detailed instructions of demands, expectations, and goals (The employee should follow the instructions trusting the experience, judgment, and knowledge of the manager).
  3. The Manager will monitor the employee progress that based on specific instructions.
  4. The Manager will compare the employee deliverables based on the preliminary goals.
In the constantly changing software industry, this approach becomes less efficient and by far less productive than what we have in agile frameworks. There are many reasons that can explain 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 (At least not in an effective way). Just think about the areas that this manager will have to handle in a single project starting from Understanding the organizational and technical requirements, Scheduling, Deliverables, and Quality.  

Centralized Management – We cannot throw this method just because we now have an alternative, but let us face it; centralized management comes with some major challenges starting from the need to issue list of technical instructions to the team (sometimes per employee), Handling internal/External dependencies and continuing with dealing with HR issues that may critically affect team performance.

Team Motivation – I think that we can all agree that this type of management (Depending on the manager and his leadership style) will not help to increase employee motivation. As followers, the employee role is to follow their manager instructions with the absence of freedom, decision making and trust that will not provide any sense of real ownership of their work.

Why agile can be scary for some managers? 


Prior to diving into the manager role in Scrum, I want to add more information about the “Bottom-Up” approach that used in Scrum. Scrum uses a more advanced approach to creating “Self-Organized, Cross-Functional” teams that can take full ownership of their work. This ownership is reflected in many aspects that were once fully managed by a single manager (described in the previous section) such as; determining the amount of work to deliver per iteration, Collective ownership of their work, Self-Management and the ability to decide how and who will perform which task to take. 

Now, as I mentioned at the beginning of this article, the Scrum Framework contains three main roles (Team, SM, and PO) that are critical to the success of the project. However, the Scrum Framework does not provide the same level of details regarding other main stakeholders that we expect to see in any SDLC project such as; Development manager, Project manager, product manager test manager or any other stakeholder that possess a management role.  

Therefore, those stakeholders who are involved in agile transition will struggle to find their role in the new agile teams. Especially when there are no criteria that specify their new responsibilities.  

The role of Managers in scrum team

In theory and based on my own interpretation of the Scrum Framework, the role of a manager in Scrum can be summarized as follows:

Re-Organization – I think that it is a classic for managers to help the organization to make the transition from a traditional way of working to scrum. Their work will focus on the “Re-Organization” and in the removal of any barriers that may affect this transition.

Servant leader – Similar to the role of 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 aspects that will help their teams such as; creation of safe working environments to their teams, investigating for new tools that can improve efficiency and plan technical training that will improve areas where the team's skills could be improved.

Not interfere – It is simple, to allow Scrum teams to grow, the old fashion management must be removed and the team manager should take one-step back and not interfere with the Scrum implementation (It is a critical point for new teams that just started with scrum).

Change Agents  The organization TL’s should allow the organization to get the most from Agile, One way to achieve this, is to embrace the new agenda and state of mind that comes as mandatory part from this approach and to grow with it to help the organization to achieve better results.

Lead by Example – This is probably one of the most important keys to an Agile transition. Leaders that used to lead by “Authority” now must embrace the new culture and start to lead by “Example”. This is while at the same time allowing their teams to grow and take further ownership.  

Removing organizational Impediments – like we expect from the team Scrum Master to remove impediments that affecting their team capability to perform at the highest level, we can expect the same from the organizational TL’s to do the same. They need to reinforce the team with relevant resources, remove bureaucracy, and provide training as needed.

Feedback – Constructive feedback is another tool that managers can use to promote their agenda in their teams without enforcing it with authority as they used to do in the traditional style of management. Constructive feedback will assist the team to improve continuously.

Technical Assistance - Managers can use their knowledge, experience, and expertise to provide assistance whenever the team needs or ask for it.

Determine prioritization – This is a classic area for these managers to show their importance to their teams and especially in the process.  Using their knowledge, experience and broad perspective, they can allow the team to make a robust and more effective prioritization to increase their ROI.

Classic examples:
  • Assist team to prioritize technical debt affecting their ability to deliver real value. 
  • Assist team with the iteration planning and prioritization of their stories.
  • Assist Product Owner to prioritize the product backlog
  • Assist Product Owner and team to achieve the balance between “Functional” and “Non-Functional” stories.

Drop Their Ego – To be able to take part in the agile transition, managers will have to drop their ego and learn Agile from their Scrum Masters. Now’ it is easy to say it, but I have seen too many managers that fail to drop their ego and learn from someone that was under their direct management. This leads usually to unwanted results. 

Human Resources – Well, this aspect is still under the management responsibility. As part of his job, the TL will conduct regular 1:1 meetings with team members and provide assistance 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 negative effect that may arise while integrates a new employee into the team.

The traditional manager as the new scrum master


A common approach to redefining the role of the traditional manager is to convert them into the new Scrum Masters of their old team. On the face of it, this seems to be good for the company, but believe me that it can be devastated for the team. When the manager plays the role of the SM, it is very unlikely that the team will gain a true confidence to begin to self-organize itself. The manager will most likely keep the hold management patterns and old habits that will make it almost impossible for him to release ownership to team members (an Agile fundamental concept).

Now, I have seen many team managers successfully transition, this is because they strongly believe in their team and in the Agile values. However, I always believe that the Scrum Master must be chosen and agreed by the team members and therefore should be one of them and not their old manager. 

Wrong Practices to avoid


Let us review some of the most common incorrect practices that I have seen in organizations in relation to this topic.

Assign the work for the team – one of the major cornerstones in Scrum, it the creation of “self-organized” teams that can determine for themselves the team member who will take ownership of the specific unit of work. Therefore, there is no need for using old management habits of assigning the work to the team.

Ensure work is completed – The team is responsible, therefore they need to follow the “Definition of Done” and “Acceptance” criteria.

Monitor what team members are doing – This responsibility belongs to the team, they need to provide answers during their daily scrum meeting. 

Work with your ego – Team leaders who fail to drop their ego and do not listen to their teams will become the team most critical impediment.

Prioritize the work – The team together with the product owner own the work. Therefore, the TL can assist and share his thoughts. He must not have the authority to delegate or priorities the work items. 

Decide what work needs to be delivered – It’s simple, the scrum framework provides two roles that are responsible to this issue, the PO that determines the features and requirements that need to be delivered and the development team that determines which tasks are necessary to achieve it.

Micro Management – I think that if you went this far in reading this article you have gained the knowledge to understand that Micro Management and Scrum are not linked to each other. 

2 comments:

  1. Perhaps others with more experience can help comment, but I might expect organisations with more experience of what in the 1970s was called 'matrix management' (separate but intersecting lines of reporting for administrative management and professional tasks) might be better able to make the necessary shift in perspective to embrace self-organisation.

    Otherwise, self-organisation can be a difficult concept to grasp for all involved - team leaders and others in the management hierarchy, team members and other people in the organisation outside the team. Some of the best thinkers on this subject can be found outside IT or traditional management disciplines; radical politicians activists and even revolutionaries may have insights into self-organisation that are useful here.

    ReplyDelete
  2. I agree with the content of this post. Well written. I find the most challenging aspect as determining which people report to a line manager after an agile transformation. One option is the Spotify model, where managers are leading the community of practice of a specific technology domain. That is classic and we have used that in one case. However, when your organization gets, for example, brand new projects (and technology) and you restructure the teams (using self selecting teams approach) around those projects, you face a real issue. The managers are no longer technical experts (it is a new domain). I strongly believe that they shouldn't be the line manager of a Scrum team (I see many companies doing that mistake and defining the line manager with the title of Scrum Master). And here is where you face the problem of who reports to them and what their role definition is. I believe that a manager can contribute even without being a technical expert. The manager needs to work with the people and evolve them - soft skills, technology growth path, etc. The manager should have 1-on-1 face time with every person at least once a week.
    The challenge is how to structure the who reports to whom structure. It really depends on per case. This is what my group is struggling right now.

    ReplyDelete

My Presentations