Fixing Your Scrum: Practical Solutions to Common Scrum Problems

This sounds less like Scrum and more like “waterfall with Jira and recurring meetings.” I would stop trying to convince him that Scrum means “no project manager,” because that is probably the wrong argument. The better argument is that Scrum needs clear accountabilities. Product decisions need a real Product Owner. Process improvement and impediment removal need a real Scrum Master. The Developers need enough authority to decide how to do the work. If the engineering manager is acting as PO, Scrum Master, architect, project manager, and final approver for every decision, then the issue is not that Scrum dislikes managers. The issue is that one person has become the system constraint. Looking thru my library, here's some books that have helped me. Fixing Your Scrum by Ryan Ripley and Todd Miller is very relevant here because it talks directly about this kind of “mechanical Scrum,” where the old process gets renamed with Scrum terms but the same command-and-control behavior remains underneath. The 45-minute Daily Scrum example is almost too perfect. A Daily Scrum is not a status meeting for a manager. It is the Developers inspecting progress toward the Sprint Goal and adapting the next day of work. If it turns into a manager-led reporting ritual, you are not getting the benefit of the event. Lyssa Adkins’ Coaching Agile Teams is also useful here because she makes the point that agile coaching is partly about helping people recover from command-and-control habits. That includes managers, but also teams that have been trained to wait for permission. The hard part is that self-organization is not granted by a speech. The team has to start taking ownership in small, visible ways and the manager has to see that doing so reduces risk rather than creates chaos. Daniel Pink’s Drive is another good lens. A team like this is probably starving for autonomy, mastery, and purpose. If every decision has to route through one manager, people stop thinking deeply and start optimizing for approval. That kills initiative. The manager may think he is creating consistency, but he is probably creating dependence. Robert Greenleaf’s The Servant as Leader gets at the leadership side of it. A servant-leader listens first, helps people grow, and measures success by whether the people being served become more capable, more autonomous, and more able to serve others. That is basically the opposite of “all decisions come through me.” A manager who creates permanent dependency is not serving the team, even if he has good intentions. Turn the Ship Around by David Marquet is probably the most practical leadership example for your manager if he is willing to read anything. Marquet moved from “give orders” to “I intend to…” so decisions moved closer to the people with the information. But he did not just say “everyone is empowered now.” He paired control with competence and clarity. That matters here. You do not win this by arguing “Scrum says we self-organize.” You win it by showing the manager that the team has the competence and clarity to make more decisions safely. Stop debating Scrum theology and start making the bottleneck visible. Track examples where decisions are waiting on him, where refinement stalls because he has to approve everything, where Daily Scrum becomes status reporting, and where architecture decisions queue up behind one person. Keep it factual, not emotional. Propose small delegation experiments. Not “give us autonomy forever,” but “for the next two sprints, can the team own Daily Scrum facilitation and keep it to 15 minutes?” Or “can the team make low-risk implementation decisions inside these boundaries without escalation?” Or “can we define which architecture decisions truly need your approval versus which can be handled by the team?” Managers who fear loss of control often need controlled experiments, not abstract persuasion. Push for the missing roles. If there is no PO and no Scrum Master, then management cannot honestly claim the team is “doing Scrum.” They may be using Scrum events, but they are missing core accountabilities. I would be careful saying “we don’t need a project manager.” In a lot of companies, coordination, stakeholder management, dependency tracking, risk management, and reporting still have to happen. Scrum does not magically erase those needs. It just should not turn into one manager making every product, process, and technical decision. The reality is that if this manager truly believes all decisions must go through him, the team may not be able to fix this from below. You can create transparency, use the Scrum Guide, run small experiments, and show the cost of the bottleneck. But if leadership above him rewards control instead of outcomes, then you are dealing with an organizational design problem, not just a Scrum problem.