Scrum Team is composed of the Development Team, Scrum Master and Product Owner. That’s it. What happens if you add Team Leader or Tech Leader to this composition? Why would like to do that at all? In this article I would like to answer this question based on several different approaches that I experienced.
Pure Scrum
Development Team is responsible for delivering the value, while Product Owner is for maximizing the value of product delivered by the Development Team. Scrum Master is responsible for supporting Scrum – serving to the organization, Product Owner and the Development Team. Is there anything missing then? Of course! Scrum is a framework and does not provide answers to all questions which will be asked while you implement it in your organization. Areas which I would like to focus on are:
- Motivation and people development. Scrum Guide silently assumes that people are motivated – but what if they are not, and if they need to receive some support?
- Salary and reporting lines. We could think of teal organizations where all employees are responsible for setting salary levels, but still there are way more companies with traditional reporting lines and remuneration schemes. How to connect that with the Scrum framework?
Let’s take a look on three different scenarios – no Team nor Tech Leader, Team Leader on the Scrum Team level, Tech Leader on the Development Team level.
No Team nor Tech Leader
So just a pure Scrum. But what with these two areas I mentioned – motivation and development plus salary and reporting lines? Let’s call them together as people management.
There is no single word about people management in Scrum Guide and this is on purpose, because Scrum is a framework for work management, not people management.
These two fields should just stay separated, and how it is done in organization is dependent and strongly impacted by the organizational culture. Sounds easy to keep those apart, but it is not.
With Team and Tech Leader not being there, who will take responsibility for proper people management?
In project-like organizations such role may be fulfilled by Project Manager supporting Scrum Masters with environment creation, and at the same time working on people development, motivation and financial aspects like salaries or bonuses.
The biggest risk here is that Project Manager won’t be able to distinguish people related things from work ones. At the end, it is Project Manager who is responsible for delivering projects on time, which may force him to sacrifice people aspect for work aspect. It requires a lot of maturity and experience to keep balance between the two areas, which are contradictory sometimes. Should I push people to work harder this Friday or should I silently accept that we missed deadline for having production release? It is not an easy dilemma in a real-life situation when Project Manager is under pressure.
On the other hand, Project Manager is quite far away from the team, so there’s very little space for him/her to anyhow impact self-organization of the team. As you will see in the next two cases, this aspect will be the biggest threat of both.
What about product-like organizations?
From what I have seen so far, there always exists some variation of Team Leader role, responsible for people management.
When the person is outside the Scrum Team and is not related with work management, then we have very clear situation. Otherwise – see two next paragraphs.
Team Leader on the Scrum Team level
Someone who I call Team Leader is a person working on the Scrum Team level, taking care of some of the people and work management aspects, but is definitely not involved directly into the Development Team’s daily work. He/she can support in organization, coordination, dependencies management or so, but he is not coding, doing analyses or testing the solution.
This is the most common situation I used to work with: Scrum Team consists of Development Team, Product Owner, Scrum Master and Team Leader. And guess what?
It works, as far as a clear division of responsibilities between Scrum Master and the Team Leader is in place – Scrum Master is taking care of work management related aspects, while Team Leader for people management.
As a Scrum Master belonging to such a team, I take care of scrum process, support Product Owner, facilitate all events and so on. Team Leader, on the other hand, organizes regular 1-on-1s with team members, helps creating development plans and discusses financials. We support each other, while giving servant-leadership to the team.
Separation of work and people management is a cornerstone of having Team Leader within the Scrum Team. I have seen approaches where Scrum Master role was included in the Team Leader’s role, so work and people management were in one hand. The result was that there was no self-organization inside the team, and Development Team members were always staring at Team Leader and waiting for him to take all decisions and deal with any outside-the-team communication.
Another challenge in this case is how Team Leader is being chosen and promoted. In most of the cases it’s simply the most experienced member of the Development Team. Such person has already built his/her position inside the Development Team and probably is an authority when it comes to technical solution or product knowledge. When we promote such person to the Team Leader role, he/she should stop be related to work management but move to people management solely. It’s extremely hard to achieve though, if not impossible, as the authority which was built by this person over time is just more powerful than the new job title.
Development Team members will still treat Team Leader as a source of product or technical knowledge, which will make it hard to step aside and withdraw from work related activity. Failure here will significantly impact self-organization of the team, on extreme situations Team Leader may even become a single point of contact for anyone who would like to communicate with the Scrum Team.
If you really want to promote someone from Development Team to the Team Leader role, make sure that he/she will lead a different team than one he/she used to work in.
It seems to be the only way to support transition from work management into people management, without letting both get combined in one person’s hand.
Tech Leader on the Development Team level
Someone who I call Tech Leader is a person working on Development Team level, and is responsible for keeping quality of technical solution, supporting less experienced developers, aligning solution shape with architects, coding and doing code reviews. He/she does the work management then.
Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person.
Why does the Scrum Guide state so? To promote self-organization. When the team realizes that they need a Tech Leader role, they will just create it, unofficially. Let’s assume that team is combined of people with different level of experience, senior and junior developers. It is natural that senior developers will lead and control the quality of the product, as juniors do not have enough skills to do that yet.
Then, if that Tech Leader will also be asked to do people management and become supervisor of people outside the Development Team, we still keep wanted separation between work and people management. But what if the Team Leader is asked to supervise his/her teammates? We then start combining work management and people management in one hand, which was already mentioned to be a problem.
What is even worse is that we have expanded the Development Team by adding a new member, which brings unnecessary confusion. How should Team members treat a newcomer – as their superior or just a new teammate? No matter how good atmosphere and relations we have inside organization, such questions are not easy to be answered.
Titles and reporting structure do matter, not in terms of process and work, but in terms of motivation and safety.
With superios being part of the Development team, most of the people won’t feel safe and secure enough to discuss openly, no matter how loudly we will ask to be open and honest. Such structure will definitely reduce transparency, limit openness and breach people’s safety.
What are your thoughts, what solutions have you seen or experienced? Please share them in comments.
Reference: https://appdevelopermagazine.com/golden-rules-for-an-agile-reporting-structure/