That’s quite an interesting question I oftentimes come across from the first days of evangelizing Scrum approaches. Small teams of 5 to 9 guys, especially those involved in outsourcing, may find it very difficult indeed to hire a dedicated ScrumMaster. As is sometimes the case, this role is just not clear to the team and customer/management. Or, as is often the case, companies just don’t have enough money to hire a good experienced ScrumMaster to help bring the team up to speed and reach the most aggressive goals.
Anyway, some teams come up with a seemingly logic idea of combining this role with a technical one in order to get a productive player spending half of his time as a ScrumMaster and for the rest of the time to bringing value being involved in other technical tasks (e.g., mobile development, testing, business analysis, etc. ).
Let’s review some aspects of such combinations and figure out pros and cons as well as duties prioritization while combining roles.
Check out a related article:
Example #1: ScrumMaster – software developer
It’s probably the most widely spread case - we take John Doe, an experience engineer (aka Team Leader speaking in old school terms), and call him a ScrumMaster. We can even send him to a training to get the missing knowledge.
And voilà – we face quite an interesting situation straight away!
As an experienced developer, John should take upon his shoulders some most critical tasks and help the team by fulfilling them. Otherwise, the rest of the team will spend a hell of time doing this work and won’t be efficient at all.
On the other hand, as a ScrumMaster, he should help the team to be focused, eliminate procrastination, understand where time is mostly wasted and how to increase the team’s effectiveness. For me this sounds like completely opposite duties to the developer’s responsibilities.
Apparently, the positive aspect of such roles combination is that ScrumMaster is aware about technical details and could advice a better solution or see when the team is not efficient technically-wise.
The most apparent negative aspect is a tough conflict of priorities between these two roles – on the one hand, our John should focus on the task (= help out a team), on the other hand, he should make sure other team members are focused and committed to the task (= help out a team). As it’s very difficult to keep such a balance, the person and a software company should revisit their attitude towards combining these roles.
In my career I witnessed successful cases when developers first and foremost focused on their ScrumMaster role and did their best to help the team from this angle while spending the rest of the time on technical mentoring and infrastructure setup (i.e. they save the team’s time on less critical tasks priority-wise). In some cases they even were involved in technical problem solving (at that moment one of their biggest challenges was how to avoid I-am-the-smartest-guy-ever syndrome). All the above require a certain level of developer’s maturity, both professional and personal.
Unfortunately, I more often come across negative examples of ScrumMaster and developer roles combination. Especially in case when Joe used to be a senior developer or a Team Lead, which usually assumes some company level empowerment and additional credentials related to the Title. In such cases the new ScrumMaster role is perceived as a new title or even as a career upgrade. This leads to “the crown on the head” and NOT seen as a role to improve the teamwork as it supposed to be according to Scrum methodology.
These are short thoughts on problems when old titles are mixed with new roles. In my following posts I’ll review other examples of role mixtures such as ScrumMaster - QA engineer (tester), ScrumMaster – Business Analyst, ScrumMaster – Manager. Stay tuned!
Original article in Russian is published on my “The Improved Methods” blog. Feel free to sign up to my updates.