How Scrum Destroys Software Teams

Meneg Volkoc — Fri, 17 May 2024 09:22:53 +0000

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.

8 Software Truths

Meneg Volkoc — Wed, 15 May 2024 04:57:50 +0000

A poor abstraction is worse than duplicating code
Complexity is considerably easier to add than it is to remove
All code errors are type errors, but not all type systems are expressive enough to surface them
Given enough time all class hierarchies are eventually wrong for new use cases
Developers who believe they can foresee the future are more dangerous than missing business requirements
Meetings are not for communication, they are for making decisions
Methods that work well with remote teams don't work well with traditional hierarchical management structures
Code metrics are an effort to abstract developer output into something a manager with no domain experience can understand

DEV Community: Meneg Volkoc

How Scrum Destroys Software Teams

8 Software Truths