Why don’t most of the developers in my organization like Scrum?
It’s a question that’s been asked time and time again — and one I recently found myself pondering. As someone who’s been in the software development game for a while, I’ve seen my fair share of agile practices, frameworks, and tools come and go. But there’s one agile framework in particular that’s stood the test of time: Scrum.
Now, I know some of you might be thinking, “Agile? Scrum? These are just more corporate buzzwords, aren’t they?” But hear me out. The Scrum framework, as an agile framework, is arguably one of the best and most versatile out there. It defines “just enough” while leaving out plenty for interpretation to the Scrum Team and the organization sponsoring it.
On the one hand, this is a good thing. If Scrum is established well, facilitated by a skilled Scrum Master, with a capable Product Owner, and with Developers who understand the theory and the practice of agile development, it can lead to a motivated team and great outcomes.
The Scrum Team’s stakeholders and the organization as a whole also matter. A Scrum Team can’t do much if it’s part of a rigid, waterfall organization and it has many dependencies on other teams or third party vendors that don’t play along well with the Scrum Team’s agile ways of working and delivery cadence.
Which leads me to why many a developer frown when they hear the words “Agile” or “Scrum.”
The unfortunate reality is that many organizations aren’t as agile as they claim they are — and the upper management in those organizations misuses agile methods and frameworks like Scrum in ways that leave the members of the teams unempowered and demoralized.
It’s no wonder that developers, who are often the ones on the frontlines, end up feeling like Scrum is just another tool for management to micromanage and control them.
When an organization proclaims itself to be “agile,” or on the road to “agile transformation,” it often means that they have adopted an agile framework like Scrum to improve their development process and increase efficiency. But many organizations haven’t defined what it truly means to be “agile,” and end up implementing the methodology in a way that’s counter to its principles.
One of the key principles of the Scrum framework is empowerment of the individual Scrum Teams. The Scrum Teams are self-organizing, cross-functional, and are responsible for delivering working products at the end of each sprint.
And yet, in many organizations, the Scrum framework is established in ways that undermine this principle, with upper management retaining too much control over the development process and micromanaging the team. This can lead to developers feeling like they are not trusted to do their jobs and that Scrum is just another tool to control them.
Even more, many organizations that adopt agile and the Scrum framework don’t really embrace the agile mindset and culture. They turn it into yet another business process and a way of tracking and forecasting rather than as an approach to embracing change and an iterative, incremental way of building.
This leads to Scrum Teams not understanding the reasons of practices and ceremonies, and just following instructions without understanding the “why.” This can lead to developers feeling demotivated and disengaged, and that they are not empowered to make good decisions and improve their ways of working at all.
Let’s take a look at a couple of examples.
The IT leadership of a large corporation misuse Scrum as a tool for enforcing strict deadlines and delivery schedules, rather than embracing the principles of flexibility and adaptability that are core to the agile methodology and the Scrum framework. The Scrum Team members feel pressured to meet unrealistic goals and deadlines, and do not have the autonomy to adjust their work based on the ever-changing needs of the customers.
They feel like they are being controlled by the framework, rather than empowered by it.
A Scrum Team is formed within a highly bureaucratic and hierarchical organization. The team members are not cross-functional and have many dependencies on other teams or third-party vendors, which do not play well with the Scrum Team’s agile ways of working and delivery cadence. Consequently, the team members feel unempowered to take ownership of the products they are building.
They keep missing their goals and not being able to complete sprint backlog items because their dependencies are never resolved on time, and the Scrum Master’s attempts to resolve these issues prove fruitless.
Scrum, like any framework, is only as good as those who use it. And if they don’t have a true understanding of the principles of agility and are more keen on taylorist control than empiric thinking, well, it’s no wonder that developers end up feeling like Scrum is just another headache to deal with. When it really shouldn’t be.