The SCRUM Hate(rs)

Agile Software Architecture, SCRUM

There’s a saying that you shouldn’t change what worked fine before. As naive as it sounds, people seem to argument a lot of their decisions based on it. And surprisingly, very smart people.

I’m not a big fan of SCRUM theory, I must agree that some parts of it are close to kindergarten reasoning. And this is why I was expecting this wave of rage against it. Yes, we are dealing with a snowball effect in terms of SCRUM disparagement. No, I won’t try to advocate for SCRUM in this article, I would just fall again in the theoretical concepts that make this subject so intriguing.

So what do I mean by rage against SCRUM? Well…There is a lot of reading material on every technical forum out there, I’m sure that for every article about SCRUM you will find some comments (usually more comprehensive than the article itself) that destroy and disqualify the whole meaning of SCRUM, ceremonies, roles or practices. I just want to mention two opinions that I personally consider as the most aggressive ones yet:

  1. SCRUM destroyed craftsmanship
  2. SCRUM promotes mediocrity (through the fact that it recognizes everyone as a team member with equal rights in terms of decision making)

Makes sense. If you observe this methodology from the outside it does seem that SCRUM is a somehow radically democratic process where chaos is hidden under the umbrella of self-organization.

In the end, how can a team of 2 juniors and 2 mid-level developers self-organize and estimate things that are clearly above their knowledge and experience ?! What is the point of a junior developer to provide an estimate for a user story where the senior developer clearly knows better? Why the hell would you need someone to watch over a team that is supposed to be self-organized anyhow? And on top of all, you also need to pay that guy, which for some reason also has a fancy name (Scrum Master) that by the sounds of it makes you think he is actually some brilliant mind (when in fact all he seems to do is organize meetings and help the team provide something called ‘story points’ that no one really knows what it means).

Every team used to have a team leader. In fact, it is proven that, in the context of any group of people, one will soon enough emerge as their leader (even if we don’t pay that person more than the others). This worked before and this is how the human nature is built to work so we shouldn’t fight against it. I fully agree with this and, at this point, I want to start and provide some personal points.

One thing that I noticed is that there are a lot of ‘used to be’ team leads that are now fighting against SCRUM.  And that made me think: Do you really need a written proof (the position within the company) to be recognized as a leader? Is this what makes you a true leader? I honestly don’t think so. So what does? Well… it only has to do with what the people that you work with think of you.

If you are a true leader people will come and ask for help or advice and they will respect you (in a natural/friendly way). It is your duty to help them do their work and help them become better at what they do. If this doesn’t happen naturally then a title that says you are a Team Lead, means nothing. If so, then probably you were not really a team leader even before SCRUM came and destroyed your position.

Consequently, you can still be a team leader even if you use SCRUM now. And no, the Scrum Master is not the Team Lead replacement/correspondent but there is no reason why the Scrum Master cannot be a team lead as well. It’s just a matter of how the team works and feels about each other, you can never truly control this. And you shouldn’t.

So you don’t understand what is the role of story points? Simple answer: Don’t use them anymore. If you feel it provides nothing for you and moreover adds overhead to your work then you were probably using them wrong in the first place. It doesn’t mean that you have a bad Scrum Master, in the end how smart do you have to be to understand story points? Anyone can do it. The Scrum Master should moderate the ‘planning poker game’ and put the end result in the story, nothing wrong there. Right?! I won’t provide an answer to this but I honestly recommend that if you are not able to find a good use for story points then is probably better to do everyone a good and don’t use them anymore.

Again, this is not an article about what a Scrum Master should or shouldn’t do so I don’t want to provide answers to problems that I don’t know. In the end, the one thing that matters most (for me) in SCRUM is that every single company/team/group should experiment and decide what works best for them. If you can understand this then you will understand what agile, self-organization and story points mean.

So SCRUM destroyed craftsmanship. Let me translate this for you using something from the Agile Manifesto (yeah, I know…another piece of crap):

“People and interaction over processes and tools/Working software over comprehensive documentation” destroyed craftsmanship.

WHAT?? That’s it, I don’t want to say more than this. If you are/were a craftsman you probably know what I meant to say by this point, so I will stop here by recognizing that I don’t consider myself as a software craftsman and I don’t want to sounds like I am advocating here on behalf of my fellow craftsmen.

But SCRUM promotes mediocrity. It forces us to think like everyone can do anything and we should all consider ourselves as equals while working on the same team. Why should a junior understand and contribute at what a senior does? He shouldn’t… and couldn’t … just don’t hire juniors anymore and your problem is gone. But what does this have to do with SCRUM?! Well, it doesn’t. Whether we do SCRUM or Waterfall or Kanban (or nothing at all) we will have the same problem: software development is not an obscure domain anymore, companies are expanding aggressively and it becomes clearer by the day that we can’t transform juniors to seniors at the same pace. Yet again, this is not a problem introduced by SCRUM. Moreover, as a personal opinion, I think that SCRUM is probably one of the best environments (yes, environment) to accelerate this process of ‘converting’ juniors to seniors. It forces us to improve and challenge people that have more experience (not necessarily smarter/better) than us, while at the same time takes off some of this pressure and makes us feel like it’s all just a team effort.

Do you hate SCRUM? Don’t use it. It is just one of the options, not THE Option. But if you are not the one (from your company/group/team) that gets to decide this then ask yourself two questions:

  1. Why aren’t you the one who can decide /participate in the decision that your company should use SCRUM or not?
  2. Did SCRUM cause all the problems described above or everything was all there before but you just didn’t notice it because it was not surfaced as clear as it is now?

What do you think?

  • 1. Seniors appear from juniors. They do not magically poof into existence as you and other people think.
    2. A master of all trades is a master of none. No matter how many years in programming one has there are still areas of this vast domain they have no clue about.
    3. When working on a segment of completely new code one always needs some time to understand it.
    4. Agile removed research from R&D
    5. Waterfall is not the only other methodology except agile and was always used as adaptive waterfall. Meaning that changes are accepted but the later in development they are they will cost more money and time.