I’m a “people manager” person. There, I’ve said it. But truth be told, I’m very proud of that fact. More often than not, I’m faced with the argument that “we need a technical person to manage a technical team”. I even head the (red. absurd) argument that “the developers does not trust a non-technical person to coach them”. So in all fairness, this article is about what I believe is the actual difference (also in a “pro/con” kinda way) between a “technical person” in a ScrumMaster role – or a “people person” in the ScrumMaster role.
Scenario
In this scenario we imagine that we have a development team who are doing Scrum. The team is in a good stage of transitioning to the agile mindset, but they are not there quite yet. It has been decided to open a vacancy for a “ScrumMaster” or an “Agile Coach” in order to speed things up faster and more coherent.
The task
The task for the new ScrumMaster or Agile Coach is to enforce the Scrum framework, optimise the processes and implementing them widely so that both business side and team benefit to the fullest. He/she is supposed to coach and lead the team into the next stage of their agile transition and encourage them to select the tools and/or methods that are most valuable for them at this given time – and also implement a roadmap for which processes to implement at a later point. The task is NOT to decide which code framework the developers should use. Nor is it the task to decide what kind of build server the team should install or even how the team should do code review. These tasks belong to the (wait for it…) – “Tech Lead” (or CTO).
A note here on title in general… It somehow seems to have been mixed up along the way. The ScrumMaster (or Agile Coach) is responsible for the “Agile Process”. The Tech lead or CTO are responsible for the technical implementation of tools and code. And the Head of Development (or Head of IT – NOT the CFO???) is responsible for the managing part of the staff. You could even say, that to have a fully succesful team that thrives and make awesome code and do it in the most sustainable way, the Head of Development, the Agile Coach (or ScrumMaster) and the CTO should all be aligned in the different decisions that directly involves the team. I know this can vary from company to company (or even from team to team) however, I do strongly believe that mixing these titles and collapsing them into containing something that they’re not supposed to, is a negative approach and will not benefit the team in the long run.
The Technical ScrumMaster
In the approach with the technical ScrumMaster I often see that the ScrumMaster role is being filled by a person from inside the team. In many (definitely not all) cases I see that this person has a 30/70 percentage role as ScrumMaster/developer. This means that when he does not have a direct task that relates to the agile process, he is back at picking items from the backlog and are working alongside the rest of the development team. Meanwhile, no one is developing the agile process. The technical side of the ScrumMaster might also favour his own user stories or tasks higher than the rest of the teams. Also, there’s a very potential risk that he will leave the “coaching role” and tell the developers how to solve their technical tasks rather than inspiring them to find their own best solutions.
The People ScrumMaster
With the people minded ScrumMaster the things are very different. However technical a discussion inside the team can be, then ScrumMaster’s focus is on finding the fastest and most sustainable solution to the problem – not to favour any technology or platform over others. He/She will guide the discussion into a way where it’s being concise and consistent. When the artefacts of the Scrum framework has been delt with on a daily basis, the ScrumMaster can indulge in the development of the process and refine the elements. This way the process is never left to a halt. Scrum is more about people than it is about code. It’s a means to a goal and with the people manager in front, the focus will also be on the smaller (“softer”) things in the team. The people. Working with the group dynamics – the clashes that naturally happens between passionate developers – is a vital part in a teams existence. In direct collaboration with the Head of Development the ScrumMaster can provide in-depth knowledge about reactions or counter reactions of the teams members. This can ultimately assist the management in becoming better leaders.
The right approach
I’m quite aware that this approach does not apply everywhere. Organisations are different, however, I tend to see that the ScrumMaster role is being thought of as “another part of the development team, which is filled with engineers”. The ScrumMaster is in my best belief NOT an engineer. It’s a people person whos most important job is to coach and lead the people who do technical stuff. In most cases the ScrumMaster role is not being respected enough. I see that people make part time vacancies and share the ScrumMaster role between several developers or QA (QA is a far better choice for ScrumMaster than developer – but that’s a whole different talk) – thus not taking it very serious and uses the role to its fullest potential.
Over time I hope to see more and more teams with dedicated “People ScrumMasters”. I hope that I can be proven wrong in my assumption that many teams just don’t take the role serious enough (actually, it’s not the teams but the management usually). And I do hope that you will be so kind to share your beliefs and own experiences in the comments section.