A couple of weeks ago, a Tweet made rounds on the web, stating that "Scrum is cancer." In summary, the author says that Scrum feels more like a managerial control tool than something that benefits developers.
Go read the series of tweets; it's excellent. But it also overlooks the real problem: a deep-rooted culture of control and distrust pervasive in companies everywhere, especially in tech. A culture that operates on the belief that decisions made at the top are inherently superior and that those on the ground (developers) are mere executors of a grand vision. Implicit in this belief is the notion that these executors need close management; otherwise, they won't work efficiently.
To understand why Scrum is so prevalent in this environment and how it gets weaponized, you need to know the basic premise of Agile and Scrum:
- Agile is a philosophy. In its origin, the essence of Agile was to empower software developers: championing adaptability, prioritizing collaboration, feedback, and continuous improvement. Agile places trust in the developer's judgment and expertise to deliver the most value to customers.
- Scrum is a tool. It applies this broad ethos of Agile concretely, offering a set of roles, artifacts, and ceremonies that make Agile actionable on a team.
To say there is a "mismatch" of concepts ("Empowerment" and "Trust" vs. "Control" and "Distrust") is to put it too mildly - these are exact opposite words: These companies have no interest in Agile! But a billion-dollar industry of Scrum consulting made it perfectly suitable for control and distrust environments: Its artifacts, ceremonies, and roles weaponized into wonderful opportunities for collecting vanity metrics, micro-managing, and pushing the top decisions down the team's throats. You know how it goes:
- Sprints, meant to be time-boxed intervals for focusing on product increments, become stressful gauntlets where entire features are expected to be conceived, designed, built, tested, and deployed.
- Story points, designed as a relative measure to estimate the complexity of tasks, morph into an absolute indicator of productivity, a team metric. A tool meant for internal calibration becomes a whip of external pressure.
- Ceremonies turn into inquisitions: Daily stand-ups, which should be about synchronization and problem-solving, transform into pressure-cooker updates where individuals feel scrutinized for every perceived shortfall; Retrospectives, instead of being constructive feedback sessions, become blame games.
- The product owner becomes a dictator, sidelining the team's insights and making unilateral decisions.
I guess I should change the title of this article: Scrum is not fine anymore; it used to be. Now, it's a tool of oppression. Still, blaming Scrum won't lead anywhere - doing Scrum "better" won't fix the underlying cultural problem. So, what can you actually do?
If you're a manager, forget about learning Scrum and instead make an effort to understand our role and how to measure results:
- Your role is not one of command and control but one of serving, facilitating and providing resources to your team, removing obstacles, and creating a safe environment for them to voice their opinions and concerns.
- Measure Outcomes, Not Output: Instead of obsessing over story points or hours logged, focus on the actual results. Are customers satisfied? Are the products stable? Are we meeting our strategic goals? Metrics should serve as a guide, not a whip.
These are not new ideas; they have been used since the seventies with great success and captured in classics like Robert Greenleaf's Servant Leadership and Fred Brooks' Mythical Man-Month. And they're as relevant as ever (but don't trust me, go read about Google's project Oxygen, an evidence-based study aimed to determine what makes a great manager, that found that the best managers are those who act as empowering facilitators, supporting their teams, and putting emphasis on team success and well-being rather than strictly adhering to conventional performance metrics.)
If you're a developer, familiar with wearing your cynicism like armor and just playing along, remember that even in a toxic Scrum environment you have agency:
- Understand that it's not about rebelling but navigating the waters intelligently.
- Do the song and dance of reporting story points, but use dailies as opportunities to question and share insights and challenges rather than just ticking off tasks.
- Push for 'sprint goals' over an exhaustive laundry list of tasks; this way, even if the sprint goes sideways, there's a clear focal point.
- Find mentors within your organization who can offer advice on handling challenges and navigating the work culture. They can provide fresh perspectives and strategies you might have yet to consider.
- Establish clear boundaries: Avoid the trap of overtime as a 'norm' – it only feeds the cycle of unrealistic expectations.
- Lastly, remember your worth: If the culture continues to be toxic and there's no sign of change, there's no shame in jumping ship. Talent is always in demand, and there are organizations where your expertise will be valued and you can work in a more positive environment.