Preexisting culture issues during Scrum transition

Question

My team has been trying to transition to Scrum for some time now, but it seems like the preexisting culture is preventing the team from switching to a new mindset or even causing it to move in the opposite direction.

For reference, the team has two line managers, a project manager, a product owner, and five developers.

• Developers never have direct contact with the product owner. Although it could be argued the line managers fill that role since they define the work for the team, that is denied by PM.
• The project manager insists she is the 'Scrum leader'.
• PM also insists line managers are part of the Dev Team since all Agile teams have a "Team Lead" role, and direct supervision of the work by LMs is fine since they are the technical leads after all, which is a valid Scrum role.
• PM also insists daily standups serve as a reporting tool.
• Daily stand-ups are run by LMs who use it to track daily progress, supervise each individual developer, comment on their approach, and assign new tasks.
• 1-3 days per user story is taken as a hard limit per user story by LMs instead of a breakdown guideline. If a developer exceeds 2 days on a user story he receives an email about how a developer is responsible for delivering on a deadline.
• LMs insist collective ownership means there should be an individual per feature responsible for its development.

Bonus:

• When I brought up these points in an impromptu way at a meeting, I was pretty much told I was silly for suggesting to remove the LMs from the development process since they were the ones with the business knowledge, or making suggestions since I was new.
• A few hours after I sent out an email to the LMs with the devs CCed summarizing the points I made citing relevant articles, I received an email CCing all people in that email about an issue with a feature I have been working on and how it was taking too long.

Is there anything I can do in this situation to help the team as a developer transition to a Scrum mindset and avoid breaking the morale of the team due daily monitoring and supervision resulting from this that takes as much as 10-15% of the work week?

Answer 1

Focus on individual problems rather than methodologies, and get everyone involved.

Rather than jumping straight in and proposing changes, start by suggesting that the team holds regular retrospective meetings every few weeks where the objective is to discuss what's going well, what isn't going well, and what could be improved. This should be the starting point for identifying specific problems to be solved, as well as deciding whether the problems are worth solving and putting forward suggestions for possible remedial action.

Retrospectives are a chance for everybody in the team (including stakeholders and people responsible for delivery) to have an honest, open-air discussion about what the team is currently doing well, and the things which are causing pain or problems. This doesn't just include process/human problems, it may be that there are persistent technical problems or technical solutions too. It's a matter for the team as a whole to discuss whether the problem identified really need solving or whether it's something the team can live with, or it may be that the problem exists entirely outside of the team's control and it may need to be escalated upwards.

For example, if you're saying that developers are not given the opportunity to provide estimates for the work to be completed, it might be a case that technical risks may not be getting identified as quickly as they otherwise might be, or that the estimates being provided may not be realistic.

It's a matter for the team as a whole to discuss these and to decide whether these are real problems which have a real impact on the delivery of the software; if the team agree that these are problems which need solving, then everybody in the team also has an opportunity to suggest improvements, and for the person/people responsible for delivery of the software to listen and raise their concerns too - ultimately they are the ones who bear responsibility if anything goes wrong so their involvement is critical.

Remember that a methodology shouldn't be the goal, the goal should be to have a development process which allows the team to manage risk effectively, to respond to the demands of the business in the best way possible given whatever constraints exist around the team, and just to get working software delivered which meets everybody's expectations.