I have heard a lot of push back against Scrum recently, saying that it makes things worse for the engineers.

1. It takes the concept of "agile" and dumps a load of process on top of it.  This keeps managers happy, and the engineers get fed up with the endless meetings.
2. The "customer" is never actually the customer.  They don't want to tie up one of their staff in endless meetings with their suppliers.  So the "customer" is actually a manager.  And the manager already has a plan saying what tasks will be done when, because that's what managers do.
3. The whole thing turns into an endless treadmill for the engineers.  At the beginning of the sprint, you're given a task and a limited time to complete it.  Fail to complete it on time, and management will notice.  Do well, and they will give you a bigger task next time.  It ends up a way to keep loading more work on the engineers, while telling them that they are being "agile".

Hi Simon,

The concerns you have raised about the added layers of process that sometimes seem to detract from the core principles of Agile are valid.

It’s true that Scrum can end up feeling like an endless cycle of meetings and reporting, especially if it’s being adopted purely as a managerial tool rather than a way to genuinely improve collaboration and flexibility. The “customer” perspective you mentioned is particularly interesting. If the focus shifts from the actual customer to a manager who may be less involved in the product’s end value, it can feel like the system becomes more about ticking boxes than about true customer-driven adaptation.

I also get your point about the pressure on engineers. When sprints turn into a treadmill of tasks with little room for flexibility, the sense of empowerment and ownership that Agile is supposed to provide can quickly fade. If management’s focus is just on throughput and timelines, it can make engineers feel more like cogs in a machine rather than contributors to a creative, adaptive process.

At the same time, when implemented well, Scrum does have the potential to create a framework that fosters collaboration, adaptability, and continuous improvement. But like any methodology, it requires the right balance and alignment with team culture and objectives. It’s crucial that Scrum doesn’t become just a tool for micromanaging engineers or overloading them, but instead focuses on removing obstacles and allowing teams to respond effectively to changing needs.

It’s always helpful to hear from others with direct experience of how these methodologies play out in practice.

Best regards,

Mustafa

Hi Simon,

The concerns you have raised about the added layers of process that sometimes seem to detract from the core principles of Agile are valid.

It’s true that Scrum can end up feeling like an endless cycle of meetings and reporting, especially if it’s being adopted purely as a managerial tool rather than a way to genuinely improve collaboration and flexibility. The “customer” perspective you mentioned is particularly interesting. If the focus shifts from the actual customer to a manager who may be less involved in the product’s end value, it can feel like the system becomes more about ticking boxes than about true customer-driven adaptation.

I also get your point about the pressure on engineers. When sprints turn into a treadmill of tasks with little room for flexibility, the sense of empowerment and ownership that Agile is supposed to provide can quickly fade. If management’s focus is just on throughput and timelines, it can make engineers feel more like cogs in a machine rather than contributors to a creative, adaptive process.

At the same time, when implemented well, Scrum does have the potential to create a framework that fosters collaboration, adaptability, and continuous improvement. But like any methodology, it requires the right balance and alignment with team culture and objectives. It’s crucial that Scrum doesn’t become just a tool for micromanaging engineers or overloading them, but instead focuses on removing obstacles and allowing teams to respond effectively to changing needs.

It’s always helpful to hear from others with direct experience of how these methodologies play out in practice.

Best regards,

Mustafa