Team managers hindering Scrum transition due to reluctance about developer autonomy

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.

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

Let's see what's wrong here:

1. The Project Manager is absolutely not supposed to be the scrum leader. Absolutely not. This person doesn't have the slightest clue what "scrum" means.

2. Line managers are absolutely not supposed to be team leaders and absolutely not supposed to be part of the development team.

3. Daily standup is run be the scrum leader. Not by the line manager. Not by the project manager. Daily standup is NOT for reporting.

4. The project manager doesn't understand the meaning of the word "deadline".

Adding your other comments, this seems to be an absolutely toxic and soul destroying environment. Are you happy working there? Do you like going to work, or are you dreading it?

Don't even bother trying to help. Make sure your CV is good, and look for a better job in a better environment.

Answer 2

My team has been trying to transition to Scrum for some time now,

I would say it hasn't. Scrum terms have been flung around and misused, but that's it. There is no transition visible.

A transition would need Scrum Masters leading it. A plan how to transition (maybe as it's own Scrum project). And support from upper management. I can see neither in your description.

In my experience there is nothing you can do really. The people in power will not just step off and give it up. The existence of 4(!) people titled "manager" or "owner" and only five developers in comparison means there is too much to lose for them. Implementing Scrum would mean at least two of them will lose their jobs and one might be trained to another position that is totally unlike their previous job description. They will not play any constructive role in their own obsolescence.

If upper management does not enforce this transition, and I mean enforce, not "wish for", this will not happen. They will cling to their jobs. It's not about culture, it's about the fact that with Scrum, they see that what they offer is not needed. They are running out of time in that business and any delay, any problem in the process of transitioning will grant them another fat paycheck.

Sorry to be so negative. The best options you have, apart from looking for a job that actually offers Scrum, is to keep your head down and hope upper management does it's job to enforce this transition. A first glimpse of this would be mandatory training, outside coaches on premise and filling the role of Scrum Master.

Until then, good luck and keep your CV updated.

Answer 3

Is there anything I can do in this situation to help the team?

Your company appears to be going through a common phase where everyone has their own interpretation of what Scrum should be, and is acting on their own vision. That's bound to fail.

Every company implements Scrum in their own unique way. Though there may be commonalities across companies, in my experience it's most important for everyone to be on the same page.

If you are in a position to provide or suggest training, that could be the key to success.

Get the leaders together, hash out how Scrum is expected to work in your company, then train everyone on your company's Scrum process.

You need to be open to the fact that your particular ideas for Scrum may not be the ones that will be designated for your company. You and everyone else needs to get on the same page.

Answer 4

Your company hasn't transitioned to Scrum, it has transitioned to Scrum vocabulary. It's an extremely common situation.

While the top answer suggests leaving, which is indeed the more convenient option, there are 2 paths you can take if you want to stay and help the transition:

1. Forget about Scrum as a whole. Look into Agile in general, and try to introduce some of the concepts to your team. Examples are User Stories (Who is the user of that feature and what do they want to do with it?), Pair Programming, Automated Builds, Automated Testing, a Definition of Done, and so much more.

2. Look for someone who is supportive of a Scrum transition and has some clout in the company. Convince them to hire professional Scrum Trainers for at least a week or two, to get the whole thing started. Your company's transition is not an exception, it's the norm; meaning Scrum Trainers have plenty of experience dealing with such situations.

Answer 5

The problem is you have missed the point of these frameworks.

The purpose of a framework is to provide value. A well executed framework is one that provides more value than whatever was before and is not one where the "rules" are precisely followed. The rules don't matter, the value does.

---

Back to agile and scrum - they gained acceptance because they provide value when it comes to new data for management to act upon.

Data has to be measurable. If more things are measurable, that is good value. If data is more accurately measured, that is also good.

The key objective of scrum is to provide management with sufficient data to aid in planning resources, alerting stakeholders of problems early and ensuring that deliverables match expectations. Saying "scrum says there is no team lead" misses the point - it's a methodology for visibility, not somehow pretending that developers don't need a team lead.

---

That's the problem with SCRUM's definition of no team lead etc. There is no real argument as to why this should be preferred over having a leader. Is there more data? More visbility? Is there anything that can be measured more that wouldn't be if there was a leader?

---

Once you understand that providing data to management is the key item, everything becomes easier. Don't fight for "correctly implementing a framework". Instead, every day, ask yourself:

• how can I create visible data for management to act on. Can I make a widget board that shows progress>
• how can I create more accurate visible data. Can I make a site that lists core features and the test coverage of them?

That is how you provide real value to management, and create real opportunities for growth.