When Scrum Becomes Toxic
2 min read

When Scrum Becomes Toxic

When Scrum Becomes Toxic

Scrum is without any doubt the most known Agile framework nowadays. It became very popular as the easiest way to introduce Agile to organisations and especially, as an easy and efficient tool to start an Agile transition inside organizations. I had my first contact with Scrum in 2009 and it was exactly in this context: as a way to start a transition from a traditional model of software development to an Agile one.

The danger of this approach relies on how people are being taught about the framework and its origins, which I think didn’t change too much in this 9 years. It’s common to see in Scrum training an introduction to the Agile Values and Principles, that were written down and published in 2001 in the Manifesto for Agile Software Development. During the training, many correlations will be made between the Agile values and principles and Scrum practices and ceremonies as a way to justify the framework, its practices and structures, and make people believe that Scrum is the silver bullet they need.

What most people don’t realise is that Scrum is indeed a good agile management framework as it can provide a very good way to organise teams, structure roles that are needed to have a more customer-focused development approach, organize backlogs, support decision making, estimations, continuous improvement, etc. It’s fantastic on that matter, but it lacks severely one of the key components of Agile: Technical Practices.

There’s no Agile without Technical Practices. A team cannot achieve agility if they just use Agile frameworks as a means to improve how the work is managed. This is an illusion and will over time create demotivation and make people believe that Agile does not work. Yes, it does not work, and will never work, if you believe that it’s just about management practices.

I saw many big fans of Scrum over my career, and just a few really understood how it could help the organization to become better. It took me some years to really understand how Scrum could help organisations, when it’s applicable and when it’s time to move from Scrum to something else more appropriate. It’s hard to think this way when people that teach you don’t have such vision and just follow or repeat the same lessons that they’ve learned during their certification course. That’s I’d highly recommend you to be very careful when choosing any training on Agile. Do some research and figure out if the person giving the training has actual experience instead of just theoretical experience. That’s important because some theories are beautiful, but they don’t quite work very well on the battlefield, and this you only learn if you have fought one this battles.

Getting back to the point of this article, the Technical Practices, the best way I see nowadays for any organization to become better at Technical Practices, apart from recruiting the right people, is to use eXtreme Programming practices, that somehow were forgotten after Scrum took over the market with its promises and the modern DevOps practices as well. Those two combined with any other Agile framework are the real recipe for creating the right culture that will generate the conditions to move organizations from low to high performance over time.

It won’t happen in days, weeks, or months, maybe it’ll take your organization years to become a high performer, but from my experience, and the experience of many other people much more experienced than me that’s the best way we know at the moment on how to enable business agility inside organizations and transform them into high performers.