Technical Knowledge and Knowledge of the Product
Has knowing the product extremely well or being highly skilled in development ever increased or decreased your quality as a Scrum Master? I've found that sometimes not being highly technical has made it difficult to understand the problems Developers have sometimes come up against, but at the same time, I'm also then not expecting shortcuts or traditional tendencies because I'm not biased by my own technical experience. The same goes with having a thorough understanding of the product - I'd say this is particularly true in companies that are, for all terms and purposes, still very traditional. What are you experiences in this? I imagine in the perfect world, you'd want to be as close to as 100% knowledgeable about anything yet fully be able to restrain your own biases.
I have found that organizations rarely need a Scrum Master as a technical product specialist, but they do need an authority regarding agile ways-of-working.
The challenge is that this might not be understood by organizations at the time, nor may they necessarily even grasp the distinction between the two.
Completely agree, however, this was more of a question looking for anecdotal responses. Do you think such technical knowledge or product knowledge (or lack thereof) has ever impacted the way you have performed? Has that influenced your approach to later products/projects?
As Scrum Master I have in my opinion two major roles:
- internal to the Scrum Team: coach, agile expert and enabler to get flow
- external to the Scrum Team: ambassador for the team’s interests, if needed fighter for the team to ensure we have the required management attention to resolve impediments outside the team’s influence.
Given this, I propose that neither very deep knowledge of the product, nor the implementation technologies are needed. Still, if matters on product or implementation are discussed, I need to at least be able to broadly follow what is going on. Sometimes this knowledge profile is referred to a T-shaped knowledge/skills. The vertical bar of the letter T standing for very deep knowledge in one domain, the Scrum Master’s core-domain of agility and coaching/consulting/convincing others. Whereas the horizontal bar stands for a broad knowledge covering both business and technical aspects to some (limited) extent, deep enough to at least enable communication with experts in other domains.
In our large organization I am for example not expected to be able to go into depth in software architectural questions, but I am expected to know when to propose we involve an architect. The same for other technical or business matters.
On the product side, I should rather be able to understand and defend the Product Owners Vision than to have one of my own. I would feel uneasy if I would be seen as a product expert and be pushed into a position to answer questions on the product.
Having proposed this for a large organization, I am aware that it might be different for smaller companies, where for example no architect is available. Still, to be 100% perfect and knowledgeable in all domains is impossible. Trying to be or make the impression to be so can be pretty dangerous.
Still, if matters on product or implementation are discussed, I need to at least be able to broadly follow what is going on.
100% agree!
Even if you have a technical background, it is unlikely that you will be able to update the latest technology as well as the developer once your role has changed.
But, as Stefan said, at least be able to broadly follow what is going on.
In my experience as a Scrum Master, I have found that not having a strong technical or business background can be an advantage, in that I can use my understanding as a guide whether items have been sufficiently communicated/refined.
To put it another way, if the item is clear to me, then it should be clear to most everyone else, and the Scrum Team has done a good job communicating and refining the item. If the item isn't clear to me, perhaps we're making some assumptions or getting too deep into the weeds around an item.