Code Quality, Technical Debt, and Scrum Masters
According to the Scrum Guide, a Scrum Master's responsibilities include s "Teaching and leading the Development Team to create high-value products."
For software projects, does this mean that a Scrum Master needs to know how to write high-quality code and automated tests plus any necessary documentation and training materials? No. But to balance the Product Owner's focus on delivery of features and ROI, the Scrum Master should be concerned with quality (and not delivery) and therefore facilitate a team quality mentality and remind the team of its Definition of Done.
And given the number of projects I've seen that deal with legacy code, Scrum Masters also need to be aware of technical debt. The best attitude to take towards technical debt is this:
...when it comes to creating technical debt, the one thing you must do is, stop. No matter what, you must not create more. And, if you wander into some code or tests that have technical debt, I do not see how you can be a professional and leave it there.
It might not be the most popular attitude with the development team initially, but it's the one that can do the most good in the long-term. Johanna Rothman has some great actionable steps a team can take to manage technical debt. A Scrum Master also needs to be able to pick up on the signs of technical debt when talking with team members, perhaps even asking them questions to understand how much debt there is.
A Scrum Master doesn't need to know how to develop the product himself, but he should be able to guide the team to develop a high-quality product.