What is a Technical Scrum Master(TSM) or Technical Product Owner(TPO)?
I have been hearing about these roles lately, and the concept has been floating around for some time. I assume the TPO or TSM would be someone with a background in tech or someone specifically trained in those areas who also fulfill the roles of Product Owners (PO) or Scrum Masters (SM) in an agile environment.
The call for the distinction seems to come more from POs and SMs working in software development environments. This could be because of the specialized nature of software engineering and the fact that tech companies often have an architecture unique to the product.
This brings the question though, does a scrum master need to be technical?
There are many answers, direct and nuanced, to this question. The most important factor would be the environment in which the Scrum Master is working. Then you would have to look at the architecture of the product. How many microservices. How many external APIs. How many vendor partners. Ultimately, the product and how much knowledge of the platform they need to facilitate results would be the deciding factor.
Where the project is highly technical, with lots of moving parts and stakeholders, all with highly specialized skills, it may be helpful to be tech-savvy. My opinion is that that deep tech knowledge may still not be necessary. There are other factors such as the scrum teams themselves and organizational structure.
The non-technical scrum master Dilemma
What if you are a Scrum Master in a company where you find that your lack of technical context is preventing you from functioning in your role?
Do you sign up for technical courses or resign to the fact that you may not be the best person for the role?
What if I told you there is another option?
Get an Architect or Technical Buddy.
If you are a non-technical Scrum Master seeking more technical context to do your job, this is one of the easier ways to pull on resources you already have in your company to fill that gap. This person can partner with you to help provide much-needed context before meetings or regularly so you can be in the loop.
There should be some considerations for the other person when trying to form this relationship. It will not help the team to just impose your needs onto someone else, even if in the long term it could be beneficial for the team. Just to be clear, here are some things to consider when creating this partnership.
- Consider persons who have the knowledge to provide the context you need and who have the skill to deliver in a concise and knowledgeable manner. It won’t be beneficial to get the information little by little from many persons, as you will take more time away from the team.
- Be clear about what you expect and how it will benefit the team in the long run. It is important to get support when you ask someone to give up time from their daily schedule.
- Set clear goals for yourself. Highlight areas of the project you need the most information on. A key part of agile is continuous improvement, so you should be learning something from these sessions. Have a set list of objectives and time frames and try to follow.
If you are a non-technical SM or PO and you believe you could be more efficient in your role with some tech context, then find yourself a buddy.
Ensure you create an alignment on how all your actions as a servant-leader will help drive better outcomes for the team.
Social Profiles