I am a little disappointed when I look around, and I see that many decisions that involve me, are taken by persons who will not handle the consequences directly, and all of these without asking me for an opinion. Is like I have to drive a car, but another person would position the seat the steering wheel, and the rear view mirrors, without asking me if I reach to the pedals, if I am able to orientate myself in space by looking in the mirrors, etc.. and on top of that, that person would not even be in that car with me, when I will be on the road. I am not talking about the decisions related to what types of electrical wires to be used when the car was designed, or the size of the electrical fuses… but some small details that depend on the context.
A scrum master is a facilitator for an agile development team. There are multiple areas where there are facilitators, even though they are not called Scrum Masters. For example, in the automotive industry, one of the examples might be FMEA Coordinator.
From my point of view, the technical expertise of the Scrum Master is a plus… it can be compensated by viewing the things applied to the context of the team but being technical or willing to understand the technical part would certainly help. My opinion can be influenced by the fact that I am a technical person. But here is why I consider this:
● Having a Scrum Master with Technical Skills doesn’t mean that she/he should be involved in technical decisions, but it might be more comfortable knowing the fact that if needed, she/he can give an advice, or change her role if needed. On one hand it is an advantage to receive a verbal advice, but sometimes, a more involvement by the person who wants to help might do the difference – if that person knows and understands the context, perhaps with his/her experience might directly help in solving the encountered issue / difficulty. The way I see it is like traveling a lot on mountains, during the cold seasons, and having an emergency blanket.
This does not mean that you should use it every time. You can even decide that you won’t buy one, because you don’t see the benefit. But in a lifetime, there might be 1-2 situations where you could have used it (for you or for somebody else) and then having it on you might represent the difference between life and death. Of course, like having a Scrum Master with technical would not 100% solve all of your problems, same with the emergency blanket: It does matter to take it with you – it is not sufficient to buy it and leave it home when you are traveling, or to carry only the emergency blanked.
● I practice ski touring. This allows a person, during the winter season, to follow paths on mountains, for example, uphill and downhill as well. In the safety equipment it is recommended to have with you, among other items, an avalanche transceiver. This is a small device that emits a beep sound on a certain frequency, and the signal becomes stronger as the person who is looking for you is getting closer. It is used, as the name implies, in finding avalanche victims. You carry it with you on emitting signal while you travel, and if you notice an avalanche, you might switch it on search mode, and try to find the victims as fast as you can.
I’ve told you about this, because I see a parallel in Scrum framework as well.
It is very good for a Scrum Master to know and understand her role very well, and all the needed steps described, but sometimes I think that these should be applied according to the context. For example, a transceiver would not be very useful if you are alone in the mountains and you are caught by an avalanche. So, if you are in a similar situation, you should pay attention to avoid as much as possible a disaster. What I mean is that you might be 100% covered by the book and definitions, if the context is not favorable for you, then you should adapt and not only rely on what you’ve read / experienced / known before. In a team context, applying for example Scrum Guide ad-literam, might bring frustrations and stress among the team members.
A scrum master with technical skills can cooperate easier with the product owner and expressing him/herself from the point of view of a scrum master, but also considering the technical part and intervene in order to prevent some things that can go wrong in that project.
The main purpose of a development team is to build a software product that meets its users’ expectations, in the minimum amount of time, and with very few or none defects – of course, this is the ideal solution. The main purpose is not to write automatic checks… or to decide to use story points when estimating stories / epics / tasks that are centralized in a tool; – these decisions should be taken considering the team’s opinions, and adjust them according to the needs, without abusing them, and of course to be applied on the context.
It is nice to have a sprint planning / retrospective / daily meeting (and useful sometimes), but not necessarily when you have a team of 1 person for example. Or even a team formed by 2-3 persons that can communicate and coordinate so that there is no need to have some of those meetings.
I have worked with Scrum Masters that were technical and Scrum Masters that were not technical and had positive and negative experiences with both. But, in my opinion, the issues were because some were operating by the letter of the law instead of operating in the spirit of the law:
● In most situations where the development team is too deeply involved in finding a solution for something that does not work, just talking with someone else would help a lot in unblocking the situation.
If we talk with a person who is not 100% involved in the development of the product, we might find alternative solutions, that as a team we somehow missed, guided by not looking at the problem from a critical point of view.
By not being involved 100% I mean that has some knowledge over the project, but it does not specifically work to develop / test it as a daily basis. That person could be for example, the Scrum Master. If she/he has some technical background, already knows the product, and some of the issues that we already encountered as the time passed by.
● There are some parts of the management of a project that might be easier to be aligned, accomplished, and applied when the Scrum Master is a technical person, because she/he knows some things from both domains. She/he does not need to be an expert but can help a lot if she/he has some ideas.
A technical scrum master can cooperate easier with the product owner and expressing him/herself from the point of view of a scrum master, but also considering the technical part.
● A big minus is that by at least not trying to understand the process, to discuss it with the team members, and instead doing things by the book, can lead to uncooperative environment, and doing some things for the sake of being done. We are not robots, so we can think freely, depending on our previous experiences, of course. There is a saying: « beware of single source people who do not have an open mind. « Ok, you may know exactly the words that describe a process, if you are not able to adjust it according to a context, then It might be better not to apply it at all or to ask for support.
Perhaps this might be one of the scrum master’s role – to defer / avoid using things that do not make sense for the entire team. Maybe I’m wrong… but by not doing this, it might bring some frustrations among the team members, sometime this can reflect in management and in the overall result as well.
A flexibility can be part of the solution and apply things not blindly but depending on the context. In order of this to happen, a lot of experience is needed along with an open mind and courage to stand out of the crowd and work for the company / product / client / colleague’s benefit.