Skip to main content

Technical Knowledge and Knowledge of the Product

Last post 04:28 pm August 14, 2018 by Timothy Baffa
6 replies
08:04 am August 14, 2018

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.

10:56 am August 14, 2018

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.

11:02 am August 14, 2018

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?

11:58 am August 14, 2018

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.

01:03 pm August 14, 2018

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! 

01:28 pm August 14, 2018

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.

04:28 pm August 14, 2018

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.

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.