The darker side of SCRUM

How an agile framework can be ironically be sluggish

So, SCRUM, it went from a trend to the new standard of agile and general software development. SCRUM was groundbreaking at its time, it changed the classic waterfall model which was rigid and implied a lot of work had to be done to change scopes and requirements. Well, not with SCRUM, now you had sprints, these short and intense cycles in which you had a goal and at the end of which you’d had a feasible product or improvement to show to your stakeholders.

The name comes from rugby, neat, right? Photo by Quino Al on Unsplash

So, the main issue with SCRUM is what makes it so great in the first place. You see, mental health (specially in these times) is something that you really have to look for in your employees, specially in your software developers, who tend to suffer from burnout pretty easily. So what does this have to do with sprints? Well, if you ever had a really important test back in college or in highschool, you probably understand the problem. See, the thing with tests and big events overall, is that they have this big hype behind them, you study and prepare for a test or a presentation or the end of the sprint.

Some studies in students show that deadlines can lead to a lot of stress, and that’s young, healthy students, think about your every day software developer that does not sleep or sit properly and probably does not take their health seriously. Deadlines are poison for your mind.

So, when you have this big sprint rush coming on, you constantly check the work you’ve done, you think if you’re ever gonna make it and each day, each hour, each minute of that countdown until the end of the sprint is a huge torture, specially towards the end.

This can lead to two main outcomes:

1. You work hard on and sometimes rush your tasks so you can accomplish your deadline or…
2. You overestimate the work in your sprints so you try to avoid the sprint rush

See, both of these are problematic, you either exploit your developers to the ground until they are burned out or you underestimate and end up being slower that you would have to begin with.

You could say that given a team that is mature enough, these problems tend to fade away, but the thing is that in our industry we cannot afford maturity, people are changing jobs, scopes are changing even the team’s internal composition may change.

So, what to do?

Well, software (and technology for that matter), is an industry that is constantly changing and reshaping itself. Maybe in a couple of decades SCRUM will be seen in the same way we perceive waterfall today, who knows?

The most important thing to me is to take SCRUM and all frameworks with a grain of salt, each team is different, each project is different. There are some good variations on SCRUM like Kanban (a personal favourite of mine), so you should just adapt your framework to the team and the situation you’ve got, don’t try to do it the other way.