4 ms·

As I experienced Scrum in practice, it is said that people should be "empowered". In reality, something totally different is happening: People are not empowered

As I experienced Scrum in practice, it is said that people should be "empowered". In reality, something totally different is happening: People are not empowered, but the management just delegates the responsibilities for the project to the developers and lays back, assured that they just have to wait for the "agile fruits" to be reaped. They have done everything, they could do, now the "empowered" employees have to see ... Those poor employees might feel "empowered", but in reality, they are "impoverished". They are now responsible for the project, but often without amble resources needed. For example, when they need additional hardware or rooms or .... they are not empowered to get it. They are still beggars. Instead, they are empowered to work longer hours to reach the project goals they have set themselves. Why did they such a stupid thing? Because they wanted to look bright or because of group pressure or because they want a raise ... And after they set their goals themselves, they are on their own. This is not "empowerment", it is not about people -- it is just a good excuse for the management to get rid of the responsibilities and to "motivate" people to work longer hours. It is the newest "silver bullet" process of a project management that already lost control.

yexponential 11y ago
This. 1000x. This is definitely one of the pitfalls of poorly implemented scrum. For bigger companies, scrum tends to be a decision by the higher ups and implemented by the lower ranks keeping middle management is disarray over their role in the change. Moreover as the author mentions agile is about people first, but followed by processes. If scrum teams don't have the power, or empowerment, to change the processes, to become more agile, to remove blockers/impediments, the team burns out / self destructs for the precise reason you mention about spending longer hours achieve the committed (not to mention the committed is affected by the deadlines which are manipulated by management/or worse, external stakeholders) in order to uphold their word/project. To me there is a flaw here. I do believe scrum can be an effective tool for a few use cases, but people often underestimate the warning signs. "Scrum is easy to learn, but difficult to master." - https://www.scrumalliance.org/community/articles/2011/may/scrum-from-student-to-master https://www.scrumalliance.org/community/articles/2011/may/sc...
- snow_mac 11y ago
  This is really the heart of it, I've really only worked in environments that have been top down as their implementation of scrum. When the engineer team got to decide, we picked Kanban. The lightest process for us. Scrum top down. I buy that. Bottom up? I'd give it a try, but the team needs the ability to say "no".

yexponential 11y ago

This. 1000x. This is definitely one of the pitfalls of poorly implemented scrum. For bigger companies, scrum tends to be a decision by the higher ups and implemented by the lower ranks keeping middle management is disarray over their role in the change. Moreover as the author mentions agile is about people first, but followed by processes. If scrum teams don't have the power, or empowerment, to change the processes, to become more agile, to remove blockers/impediments, the team burns out / self destructs for the precise reason you mention about spending longer hours achieve the committed (not to mention the committed is affected by the deadlines which are manipulated by management/or worse, external stakeholders) in order to uphold their word/project. To me there is a flaw here. I do believe scrum can be an effective tool for a few use cases, but people often underestimate the warning signs. "Scrum is easy to learn, but difficult to master." - https://www.scrumalliance.org/community/articles/2011/may/scrum-from-student-to-master https://www.scrumalliance.org/community/articles/2011/may/sc...

snow_mac 11y ago
This is really the heart of it, I've really only worked in environments that have been top down as their implementation of scrum. When the engineer team got to decide, we picked Kanban. The lightest process for us. Scrum top down. I buy that. Bottom up? I'd give it a try, but the team needs the ability to say "no".