While it's certainly possible that having additional resources available to meet a short term goal were helpful in meeting a near-term objective, it was clearly at the expense of a company-required process (whether that process is good or bad is beside the point here) and side-steps the question of whether the near-term re-allocation of resources outweighs the (perceived) value of the Scrum Master role as it is being practiced within your organization.
It is certainly possible, and perhaps even likely, that the team received a short-term boost in productivity from having another developer allocate 100% of their available time (rather than the estimated 50% under the current system) to product development. However, this is not desirable or sustainable within the Scrum framework, and is unlikely to be sustainable under any reasonable project management framework over the long term.
The team and the organization need to carefully re-think their process, and inspect-and-adapt until they achieve more of their desired outcomes with a sustainable cadence.
First of all, while it's technically feasible for a Scrum Master to also be a Developer on a Scrum Team, the Scrum Guide makes it very clear that these are distinct roles with distinct responsibilities. Asking one person to wear both hats is generally an anti-pattern over the long term.
Secondly, all project management frameworks, whether agile or not, incur a certain amount of overhead. This is sometimes perceived as reduced productivity when the outcome of project control is seen as reduced productivity rather than increased transparency, visibility, or process control. You can certainly direct budget and time away from project management activities and allocate them to development activities instead, but over time you lose the intended value of empirical process control.
Thirdly, the Scrum Master role (when done properly) is a full-time job. While very experienced Scrum Masters with very mature teams might be able to handle up to three projects, it is certainly not a recommended practice nor is it generally effective in the type of environment you're describing. In short, you have a part-time Scrum Master whose role is considered secondary to the product development effort, which is most definitely an anti-pattern.
Fourthly, none of the duties you are ascribing to the Scrum Master are very Scrum-like. For example, the Product Backlog is a Product Owner responsibility, while Sprint Backlog management and work assignments are the collective responsibility of the Developers. Having a team lead assigning work to individuals is about as far away from empowered, self-organizing teams as you can get. This is another implementation smell that you should get to the bottom of.
I've seen these anti-patterns at play in many Scrum and Scrum-like roles, including as a Developer, Scrum Master, Product Owner, agile coach, traditional project manager, and IT executive. They never turn out well in the long run, but that never seems to stop people from trying to turn moose nuggets into diamonds.
Here are some actionable recommendations that will help your team and organization inspect-and-adapt the process into something that provides a reliable delivery cadence.
- Decide whether you're really trying to adopt Scrum, or if you're just applying Buzzword Management℠.
- If you're really adopting Scrum, ensure you have all three essential roles on the team: Product Owner, Scrum Master, and Developers.
- Treat each role as a full-time job, because it is. You can either have people doing the job right, or a lot of people doing part of the job part of the time, usually with less-than-stellar results.
- Scrum is often described as a lightweight framework, but it still carries project overhead. All project control frameworks do; Scrum is just arguably a lot more transparent about it. This overhead must be accounted for as a visible cost to the project.
- A part-time Scrum Master (or project manager) can't magically put lipstick on a pig. If a project is failing or behind schedule, either fix the underlying problem through the framework's inspect-and-adapt events such as the Sprint Retrospective, or accept that the project is likely to fail.
- If the project is likely to fail, don't chase the sunk cost fallacy. There is value in failing early.
- If the project is failing or out of tolerance because of budget, scope, or organizational decisions beyond the control of the Scrum Team, escalate them to senior management. The success or failure is ultimately their responsibility, and if it's the direct result of poor strategic decisions (e.g. under-staffing or under-funding the project) then it's their problem to fix.
- if the team lacks the opportunities or job security to honestly inspect-and-adapt the process to make it better, the company culture is at fault. This is also a problem for executive management, and if they broke the culture they are the only ones who can fix it.
- Empower your team as best you can to fix the problems where they have local knowledge and control.
- If your team can't control any of the negative factors impacting productivity, then the smart ones are already updating their resumes. You should do the same.
Rules of ten are never meant to be exhaustive, but this is probably about as comprehensive an answer as anyone outside your company can provide. Basically, identify the problems, fix the problems as a team (if you can), and refer the rest to those with the authority to address the problems the team can't solve for itself.