Focuses on fake metrics instead of code quality: Emphasizes superficial performance indicators, like burndown charts or number of Jira tickets, rather than the actual quality, functionality, and maintainability of the code. This approach can lead to bloated, inefficient codebases that are difficult to manage and evolve over time.
Wastes engineering time with unnecessary meetings and ceremonies: Implements excessive meetings and rituals that do not contribute meaningfully to the project’s progress. These can drain significant amounts of productive time, reducing the overall efficiency and morale of the engineering team.
Removes code ownership: Distributes responsibility for code in such a way that no individual or small team has clear ownership. This can lead to a lack of accountability, reduced motivation for maintaining high standards, and difficulties in managing and improving the codebase since no one feels directly responsible.
Creates a churn culture: Encourages a high turnover rate among engineers, leading to instability and the constant loss of institutional knowledge. New hires have to repeatedly climb the learning curve, which disrupts continuity and hampers long-term project success.
Prevents code refactoring: Stifles the necessary process of restructuring existing code to improve its structure, readability, and maintainability without changing its external behavior. This results in an increasingly unwieldy and fragile codebase over time.
Ensures technical debt: Accumulates technical debt by prioritizing short-term gains and quick fixes over sustainable, high-quality solutions. Over time, this debt can slow development, increase bugs, and make future enhancements more difficult and expensive.
Caters to the lowest common denominator creating replaceable, low salary engineering positions: Standardizes roles and responsibilities to a level where individual creativity and higher-level problem-solving skills are undervalued, leading to a workforce of easily replaceable, lower-paid engineers. This can demotivate talented engineers and stifle innovation.
Prevents career advancement: Limits opportunities for personal and professional growth within the organization. Engineers may find it difficult to progress in their careers due to a lack of challenging work, mentorship, or recognition for their contributions.
Creates the illusion of progress: Generates a false sense of accomplishment by focusing on surface-level activities and deliverables rather than meaningful, impactful progress. This can mask underlying issues and create complacency within the team and management.
Prevents engineer interaction with users of the software: Separates engineers from the end-users of the software, leading to a disconnect between those who develop the product and those who use it. This can result in software that fails to meet user needs and expectations, as engineers are not able to receive direct feedback or understand real-world use cases.
For further actions, you may consider blocking this person and/or reporting abuse
Top comments (2)
This list starts with two points that seem easily substantiated and then moves onto ones that are more debatable. This isn't necessarily a problem, but it sort of makes me want follow-up articles or deeper discussion.
Unfortunately, I don't have much to contribute to the discussion since I've only worked one place that used Scrum and it didn't seem to cause any major problems, but it's hard for me to say how helpful it was, either. There were times when it did encourage dubious things such as not assigning new tasks until the sprint was over (though this was not particularly common), and sometimes the ceremonies seemed a bit excessive, but it wasn't anything too bad. Things mostly moved along smoothly enough. But from what I've heard, some organizations have a worse time with it.
Most developers wouldn't complain about any of these issues because it's just easier to avoid confrontation, be quiet, collect your paycheck and find another job in the meantime. Been there, done that. Though, if you were to ask developers that quit teams where they practice Scrum, I'd wager their response would align pretty closely with one or more of the points in my post.
It's also quite common for the Scrum discussion to end in the fallacy of the no true Scotsman, where the assumption is that nobody is doing Scrum right but the person for which it went well.
Early in my career I wouldn't have noticed or even cared about any of these issues because you're learning so you think it's just part of the job, but when you work on a highly productive team that does not practice Scrum and then go back to a Scrum team, the issues become really apparent and you start to question this whole practice.
The truth is that the best team strategy is the benevolent dictator. Pay your top engineer top dollar, accept that institutional knowledge is not easily transferable, and keep management technical. This is true of any highly technical knowledge job. Companies obviously don't like this and Scrum is a futile attempt to subvert this practice to appease the management's ego.