Advice for a Non-Technical Newbie Scrum Master

Question

I have recently joined a fantastic company which prides itself on its Agile philosophy and work ethic. I am a VERY junior Project Manager, and the more I learn about Scrum and Agile, the more I want to specialise in this space. However, I see two potential problems:

1. I am not technical (Ie: I cannot code) and am concerned this will interfere with my efficiency when liaising with team members
2. I am a junior and so acting as a team mentor/servant leader sounds fantastic in theory, but I know how I would perceive such a person were roles reversed, and so I really don't want to tread on anyone's toes

I have trained as a counselor and psychologist, and so my real passion is people and bringing people together. What I love about the Scrum master role is that it is that of an enabler, empowering people in the work place. The company took me on as they saw potential and wanted to train me in this arena. However, I am concerned that without a technical background coupled with being so junior, I might not be effective in this particular role.

Is it feasible or even possible to enter the IT industry in a Scrum Master role? If so, does anyone have any recommendations, or lessons learnt from being in a similar position once upon a time? Any practical tips would be greatly appreciated.

Answer 1

I would take great care diving straight into being a Scrum Master, as you risk being perceived very negatively by teams. I am a Scrum Master who has come from a development background, which makes it much easier to fit in with the team naturally and not come across as 'management'.

There are three stages of Scrum Teams, sometimes referred to using Shu-Ha-Ri; a martial arts term. Your background will mean you fit into teams in some of these states much easier than others.

In the 'Shu' (Obey) stage teams are learning the fundamentals. This requires more of an enforcement attitude from the Scrum Master, and is where technical knowledge would be most useful. This is where teams are likely to be creating their 'development best practice' - so to me the scrum master should be enforcing code reviews, helping to implement XP or whatever approach the organisation are taking, and suggesting (often technical) additions to the definition of done. This is where many 'Scrum Consultants' (who are often not technical) seem to be failing the industry to me - they bring in 2 week sprints, self organised teams, and backlogs, but do not address the most important part - the underlying development standards that Scrum was built and relies on. Most teams never leave this stage, and this is where Scrum Masters who are not technical are really hurting the industry.

The next stage teams reach is 'Ha' (Digress) where they are working as a good Scrum team, and start to understand why they are doing things, rather than just following the process. This is where the team have the basics down and are working as a good team already. At this point they must have good development practices in place, so a Scrum Master who is less technical could probably get by. The team is motivated to keep up their technical excellence, so the Scrum Master doesn't need to be driving this, but might want to keep reminding the team to keep up their technical excellence. There is still a risk development practices could slip and the team not notice, and without being technical a scrum master may never know.

If you get the rare chance to work with a team at 'Ri' (separate) who is hyper-productive, I don't think you need to be technical. This is probably the best sort of team fitted to your situation. Your psychology background would probably make you better than most Scrum Masters at really getting to the bottom of deep, hidden issues that many Scrum Masters might miss, so you may want to try to specialise in working with awesome teams that are trying to etch out additional improvement. This is where teams are coming up with their own ways of working, maybe abandoning Scrum all together.

I have a software development background, and have led multiple organisations through the Shu and arguably Ha stages - often after agile consultants have already done a lot of damage by bringing in Scrum without any consideration of the development practices it relies on. If you are involved in agile adoptions, ensure to work with a development manager or senior developer to put best practice in place BEFORE bringing in agile. Without this, non technical Scrum Masters can seriously break teams and organisations. You can do it, but the more technical knowledge you can get the better.

Answer 2

Technical skills are not absolutely necessary. You could argue both ways, in fact:

• By lacking technical skills, you are freed from trying to analyze the technical issue and trying to deliver a technical solution, while helping the team identify the collaboration and communication issues and address non-technical obstacles. With your background in psychology you would be able to ask direct, thought-provoking questions to the team members which would lead to a resolution of the obstacles or would help you escalate to the right people.

• Having technical skills would allow you to discern between simple obstacles caused by small issues or lack of knowledge, vs. much larger issues caused by deep complexities which might not be resolved on the spot. A deeper understanding of the technology would allow you to quickly identify who to escalate an obstacle to, or even suggest to the team that "digging deeper" on a certain obstacle/topic is not worth the business value.

Regarding being junior and acting as a mentor, IMHO you have to see the Scrum Master role as a servant leader role rather than a mentor role. While you do act as a mentor with respect to the process itself, you are a servant to the team with respect to the daily flow and the goal of delivering business value. You focus on eliminating those obstacles that developers don't like dealing with anyway ("people stuff", management issues, etc), and focus on bringing the right people together at the right time. From my personal experience as a Scrum developer, Scrum master, and now team manager, I can say that so far I have not experienced developers reluctant to work with a junior Scrum Master just because of age/experience. I have seen developers reluctant to work with a Scrum Master who doesn't fully understand the process: i.e., as a junior Scrum Master, focus 100% on understanding Scrum, Agile, and Lean, and providing business value by constantly questioning and improving the process.

Answer 3

Yes, it is feasible to enter the IT industry in a Scrum Master role even with a low technical background. That is not the key point within your job. It is more about to understand a team and removing obstacles.

Nevertheless, I would like to encourage you to create your own small technical background, because in some occasions you will need to understand some technical issues expressing during meetings, or perhaps to remove obstacles or to request help for other areas of the company.

1. Pay attention, hear what happens and after that, read and learn about the concepts. Only concepts, only the main ideas.

2. When you understand the basic concepts and how the concepts are related, perhaps it would be a moment to give one extra step: checking what happens with X concept, generating questions to your team in an informal way by asking: I understand Y, because in the last meeting it happened Z, am I wrong?

Answer 4

It does not cause as long as the team you are working with takes it in a positive note. But, most times the technical teams expect Scrum master to have technical knowledge. As a new bee if you don't have it, it does not cause you to be a problem. As the time pass by, you can capture knowledge on technology and development of your project/Product that would help you understand what tech teams are talking.

If you are not getting upto speed, then teams would look at you as a problem. Because, managing a technical team for long without understanding their problems, or what they are actually doing would not work longer.

Just, start with '0' and capture knowledge as you go. This should work.

Initially, they may look at your organizing skills and PM skills. If they are impressed, for sure any positive team member would extend support for you to learn.

Answer 5

IMO, you should get alteast 3-4 years experience under the belt by working in varied roles such as Developer (backend or frontend), QA before diving into the role of Scrum master. The experience gained by working as a team member will be invaluable and give justice to the role of SM. Otherwise you would be applying bookish knowledge learnt from the 2 day SM workshop.

Answer 6

Whew. Please don't do this. I really don't think you know what you are getting into. Let a developer be the "Scrum master" and you should focus on the project manager type stuff like scheduling meetings and doing spreadsheets and whatnot.

Look, I can understand why tertiary players on the stage want to get involved with these things. Pad out the resume with buzzwords, gain some credibility "on paper" in the industry, etc. But from a pure standpoint of efficiency, it does not work. I have seen it several times - it really can rip a team apart. This whole deal about "psychology" and "helping people come together", that's great and all and noble but that is not what will happen, it will be the opposite. Trust me.