SCRUM — The Innovation Killer
SCRUM, which aims to account for all the engineer’s time in a structured way, may discourage innovation. The SCRUM methodology tried to standardize how engineers worked, accounting for each minute of their day but often stifling creativity. Employees had to stick to a rigid timeline and were discouraged from deviating from it, resulting in less risk-taking and fewer creative ideas.
SCRUM was designed to get the most out of development teams with minimal effort, creating a step-by-step process for ensuring predictability. Though it is effective at meeting deadlines, it needs more flexibility and precise execution of its principles to succeed. Its rigidness does not encourage creativity or experimentation, and its attitude of absolute obedience to its processes has earned it a reputation for being uncompromising.
SCRUM emphasizes efficiency and finding the “least amount of work possible” solutions to meet its stringent predictability requirements. It is also known for its inflexibility and the need for complete adherence to its principles during implementation. Its attitude of intolerance to self-examination is present in all its practices.
SCRUM is very management heavy
Task management tools like Jira and TFS were touted as helpful, but they often took up much of the Team’s time and locked them into one mode of operation, regardless of how ineffective it was. SCRUM focused on what the Product Owners deemed worthy tasks while overlooking critical fixes and backlogged technical debt.
SCRUM was a bit hypocritical — managers and Product Owners didn’t have to estimate their tasks, present burn-down charts to justify their activities, or hold bi-weekly sell-off meetings. So why were they demanding this of the development teams? Typical teams have Product Owners, Scrum Masters, and Team Leads. Innovative, motivated teams operate better with less management, not more.
SCRUM makes many faulty assumptions
The organization embraced SCRUM as the primary project management methodology but needed to make more correct assumptions. It assumed engineers lacked the experience to manage their tasks and needed guidance to stay on track with time management. It thought everyone was on the same page and engineered meetings with a SCRUM Master to facilitate. It positioned itself as an overseer that knew the organization’s best interests better than the engineers, implying tight supervision and control. Story points were tracked and reported at various organizational levels, even though they were arbitrary and had no real meaning. This practice failed to reflect the Team’s actual performance. Worst of all, SCRUM was designed to manage the least experienced engineers while disempowering those with more experience. SCRUM also overlooked that many software development tasks can be reused and copied, thus making them easier to estimate.
In conclusion, SCRUM may have benefits in meeting deadlines and creating a structured approach to managing time, but it also has drawbacks. Its rigidness can stifle creativity and discourage risk-taking, and its reliance on task management tools like Jira and TFS can be time-consuming and inflexible. While SCRUM may be effective for some organizations, there may be better fits for some teams, especially those that value creativity, flexibility and impact.
–-
[¹]: Jeff Sutherland (2014): (Amazon.com: Scrum: The Art of Doing Twice the Work in Half the Time eBook : Sutherland, Jeff, Sutherland, J.J.: Kindle Store)
