Should you have technical background as a scrum master/product owner?

Agile delivery has been popular over the last few years. Although it started with software delivery, it is now popular with other industries. Sometimes during interviews for scrum master on a software team or even during conversations, you could be asked if have a technical background. Personally I did have a technical background before I turned scrum master and product owner. There are both pros and cons.

Why are people interested with technical background?

Typically what they mean is, if you have been in any part of software development – For example -Analyst, Developer, Tester. If you were in any part of software delivery, then you would have experienced SDLC i.e. software development lifecycle. More than anything, software development is collaborative work. You cannot operate in isolation. For example, you have to collaborate on design, tests, other teams. If you would have worked in a software delivery team, you would know what it is to work with other people. It is not uncommon that if you were a successful team player, then you would be empathetic towards your team. Scrum ceremonies are important but that’s not the only thing that the scrum master is responsible for. No one wants a “task master” just trying to get statuses. Soft skills are HARD and perhaps harder than learning technical skills. They would want someone that understands the team’s problems.

Organization structure

Every organization is different and form scrum teams differently. Some teams are truly full cycle i.e. extremely less dependency on external teams. In my opinion though, many companies can never truly have full cycle teams because eventually they are too big to be independent. You could be more efficient and even release independently. However, it takes a village to release the final product! In most cases, to truly release a minimum viable product, there are multiple teams involved. Some common examples of the way teams are formed.

·         Technology focus - Some teams do API or UI or database work exclusively.

·         Own part of the flow – Some teams might own specific functionalities. For example, search feature page could be an app by itself and your team could do UI, API, database etc. However, the reality is that you get projects involving multiple features. In other words, you are just part of the project. Although you may be able to release independently, the project cannot be turned “on” unless everyone else is done. In short, in most companies, no matter how you slice and dice the teams, you cannot operate in isolation.

 Understanding the responsibilities of your team & your dependent teams is really important.

Pros of having a technical background

·         Removing impediments is one of the responsibilities of a scrum master. If you understand the organization structure as mentioned above then you will be able to figure out the network required for your team to operate.

·         Champion your team’s pain points – I see this even with the best of tech leads/developers/testers. If you need decisions/clarifications from external teams/senior staff then you need to champion your team’s pain points. A lot of times, your team might not be in the forum (for example - scrum of scrums meeting) to raise these but you as scrum master might be involved. Understanding pain points might help you raise risks appropriately. Knowing the network of people and understanding pain points will lead to faster removal of impediments. You can involve the right people at the right time depending on the situation.

·         Better conversation with the team – Many companies are involved in agile transformation to be able to deliver faster. This means that modernizing the tech stack. Teams will face challenges and need help from outside the team such as from architects, open source companies etc. Supporting your team and understanding when they are truly blocked is important. Talking to your developers and testers can help your understand their problems better.

·         Identifying risks – With an understanding of your team’s ecosystem, you can watch out for risks. For example - Company execs love agile delivery but also still give you deadlines around production delivery! That mindset has still not changed. Sometimes your project might have fundamental questions unanswered. With a technical background, you tend to see RED sooner.

Cons of having a technical background

·         You have to learn to shut up J appropriately – While you will understand your world properly if you have had a technical background, you‘d have to back off when it comes to technical decisions. Software design is an art. There are several ways to accomplish the same thing. The tech lead/developers/testers will figure that out. If you have a different idea, you could ask a leading question but know that it is NOT your call. Your job is to get consensus and figure out if there are blockers. It is hard to do that, I admit and do not take anything to heart! Your role has now changed to a consensus builder and working with tech leads/developers/testers to create the best solution. Using your background for better conversations is a tough skill!

What part of technical background do I really use?

It is long since I coded but as a scrum master/product owner, I use my analytical skills more than anything else. Understanding the flow between major components/applications is the key to several conversations – like who owns different components. The right conversations with the right people move the needle. As a scrum master, you are often in a position to drive this. I try to use my background to have the right conversations!

What can you do if you don’t have a technical experience?

The good news is that you can still be successful without such expertise. Learning basic concepts can help you prepare for your career as scrum master in software delivery. The article describes the training and readings you can do to prepare for the future.

Disclaimer – This blog is just based on the author’s personal experience. Use your own discretion.