I often come across the Developer AND Scrum Master combination. In other words, you have a developer in a Scrum team who volunteers (hopefully) and takes up the Scrum Master responsibilities as well. So far so good right? Well, NO. Hell NO.
Now I can already hear a manager’s voice complaining: yeah ok, but we don’t have enough people, we have been working like this for a long time and is quite successful, teams are happy with this concept, we are conducting meetings standing up and put sticky notes on the wall, so we are agile.
These are just some of the explanations I ‘ve heard over the years of coaching. I guess most of them are produced in the same factory; same pattern, same origins, same “yes but”. Let’s have a deeper dive in this topic then. <Quote alert> REMINDER: THIS IS BASED ON PERSONAL EXPERIENCES; THINGS I HAVE DONE AND OBSERVED. I AM NOT THE UNIVERSAL TRUTH BEARER. <Quote alert />
Assuming that the Developer volunteered to be the team’s Scrum Master and was not handpicked by a manager. 99% of the times, the Scrum Master Developer just pulls and works on the easiest PBIs, decreasing the Dev Team’s capacity and throughput. Moreover, by simultaneously being a Developer of the team, is almost impossible to distinguish between the duties of the Scrum Developer and those of the Scrum Master. The latter results in impeding the team’s self-organisation which as a result undermines the Scrum process in general. Of course it is always helpful for a Scrum Master to possess a technical background not for telling the team how to elaborate its work or for intervening with its self-organisation but rather for being able to foresee any potential impediments and take action.
In the best case of this (bad) scenario the Scrum Master Developer is an experienced and respected programmer/tester/Designer of the team. However, in most of the cases, it is the weakest or a junior team member of the previously mentioned roles who assumes the Scrum Master responsibilities. And the whole (Scrum) thing just falls apart as the rest of the team has no respect and or trust in his opinions, views and suggestions. The same applies to the actors outside the team. Combine that with zero management/sponsorship support and you have the perfect storm; the Scrum Master Developer ends up as a glorified team secretary, responsible for booking the scrum events, adding the sticky notes to the wall and working on PBIs from the Sprint Backlog. Change? Improving the process? Coaching the rest of the organisation? Oh come on, we already know the answer: “I have no time for these things. I am already occupied with the Scrum meetings and development work”. There you have it, another layer of nonsensical placebo management activities with no meaning at all. The Scrum Master who should be the spearhead of the change process for the team as well as for the wider organisation, becomes an obstacle and a useless role. Unless you praise the “Meeting-booking” skills as essential in the contemporary IT world.
OK, fine how can this be fixed is the typical question you hear. The answer is simple: “HIRE AN EXPERIENCED FULL TIME SCRUM MASTER AND LISTEN TO HIM”. You can’t afford it? Try to measure what you will get in return and the benefits in Scrum learning curve if you have someone who knows what he is doing. Still not possible? Keep in mind that according to the Scrum Guide, the Scrum Master role is just a role. Therefore, anyone on the Development Team may assume this role (wait for it) on a rotating basis. Personally I find this solution as the most bearable one, because it helps a team realising the importance of collective responsibility which will lead to a collective ownership mind-set of the work to be completed. It should be made clear that the inspect and adapt tactic has to be followed, otherwise the whole initiative will stagnate. Fast.
In short, the Scrum Master Developer hybrid role is already a smell. A smell which depicts the organisation’s lack of commitment to the Scrum change process and additionally an organisation’s/team’s Scrum maturity. Some of the most mature Scrum teams I have worked with, had understood the essence of agility and Scrum and where able to reach a high level of self-organisation making the Scrum Master role obsolete. But these were just a few cases and the people on the team were sticking to the Scrum values and to the mind-set of continuous improvement. As a footnote I ‘ll share this with you: The separation of the three Scrum roles enhances focus and let the team members concentrate on their tasks. The continuous switching between roles only results in a decreasing morale and undermining of any Scrum implementation.