Question on temporarily allowing a team lead to pause project management to go faster?

Question

Background

In our organization, our Scrum Masters are also engineers, and 30% to 50% of their time is organizing the team, backlog, tickets, etc. The last 3-4 weeks we allowed one of these Scrum Masters to eliminate his workload of tickets to speed up and deliver on-time. That Scrum Master thinks he would not have delivered on time if he had to keep up with his Scrum Master responsibilities. Now he is out of that fire-drill, he is getting back into organizing the pivotal board and doing iteration to iteration planning again. Obviously there was a cost and he now has to dig out of the hole from the previous lack of project management.

Question

Is it possible to speed up a team of three people by having one of them drop their project management responsibilities temporarily to concentrate on engineeing work? I realize longer term that this would not speed a team up. Do you think it sped his team up for that 3-4 weeks?

It would help to identify the perspective of your role in your answer, such as:

• current/previous software developer
• Scrum Master
• other role on the project

I know many teams that have done something like this in the past (especially smaller ones), but want to understand whether this truly made a material difference.

Answer 1

Am not really understanding the premise of your question. But I will address the cause and effect part of your question. Does applying any sort of intervention, such as adding a resources--machine or human--have an effect on work performance? At best, you can establish a contributory cause. Establishing an absolute or conditional cause is not likely in this case. Establishing an absolute cause is likely impossible.

Work is very probabilistic. There are countless variables affecting outcomes and most of these variables are random. On top of this, different tasks have different degrees of resource elasticity. This means that some tasks respond well with adding additional resources while other tasks won't respond at all or even degrade.

Therefore, your best answer is that the PM doing development work may have contributed to the favorable outcome you measured but you are not assured similar results again.

EDIT: Based on your comment, it sounds like a leader is questioning the decision made by the PM to assist with the surge to help recover the schedule. There is no industry that disallows, or should disallow, an all-hands approach to handle a surge, whether it is induced by a sudden increase in demand for that work or self-induced because you are intervening on the schedule. Before qualified people abandon their posts to handle the surge, there is obviously a cost-benefit-risk analysis that should be done but, during a surge, the benefits are typically quite high where the costs and risks are absorbed and mitigated, making this decision favorable likely in most cases.

Imagine a head of an ER sitting in her office to continue to "manage" while the ED is being overwhelmed by the victims of some catastrophic event. All hands on deck and everything else is tabled until later when the surge chills. It doesn't come for free so there are costs to pay.

Answer 2

TL;DR

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.

Analysis

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.

Recommendations

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.

1. Decide whether you're really trying to adopt Scrum, or if you're just applying Buzzword Management℠.
2. If you're really adopting Scrum, ensure you have all three essential roles on the team: Product Owner, Scrum Master, and Developers.
3. 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.
4. 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.
5. 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.
6. If the project is likely to fail, don't chase the sunk cost fallacy. There is value in failing early.
7. 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.
8. 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.
9. Empower your team as best you can to fix the problems where they have local knowledge and control.
10. 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.

Answer 3

For an SM to spend 50% of their time organising a single team and backlog sounds way too much. If the SM supports multiple teams then the 50% figure could be more credible but in that case it doesn't seem realistic that the same person would also be a developer. Scrum teams should be self-organising and the workload of the SM ought to be spent on supporting them when needed, not on organising them and their backlog.

A team of 3 is quite small however. You should consider amalgamating at least two teams of that size. You didn't say what your sprint duration is. If the 4 weeks you mention is the sprint duration then I would suggest that may be too long for a small team. Long sprints require more time to prepare and plan, particularly with a small team where there is little margin for error.

Look carefully at the team's velocity is my advice, suggest that the whole team and not just the SM take responsibility for backlog refinement and make sure they allow time for refinement activities when planning a sprint.

I am an engineer, SM and agile coach.