Scrum haters: You can read the Scrum Guide for free

I want to talk about this trend that lately extended writing articles claiming that Scrum is evil, destroys development teams, "kills agility" (Oh, my God) or even that encourages bad development practices.

I will try to touch some of the points of several of the posts that have fallen into my hands lately. Some of which I admit that get up my nose because of the unjustified and toxic commotion that they generate.

Most of these articles that I see seem (yes, pure opinion) written by someone in any of the following circumstances:

  • They have never read the Scrum Guide
  • They have never worked with Scrum
  • Have been unlucky enough to work in a place where Scrum was poorly implemented (in which case is true that it must be terrible and I really can understand)
  • Is a fan of command and control management
  • Is a technical person trying to be in absolute control of the process, forgetting that there are business needs.

In Scrum we don´t care about quality

It is not true. At no time is that said in Scrum, but rather the opposite.

No one (not even the Scrum Master) tells a development team how to do their job. The only people responsible for the quality level of the code are the members of the development team. Quality is not negotiated in Scrum. It is a habit.

No one tells the team how much work they put into the Sprint Backlog, so no one is forcing them to run to close things with a poor quality because there is too much work.

In fact, the teams have a definition of the fact that, among other things, protects them from having to deliver garbage only to meet deadlines.

Literally from the Scrum Guide:

As Scrum Teams mature, it is expected that their definitions of "Done" will expand to include more stringent criteria for higher quality.

Product Owners don´t care about quality

False again. Or a very bad generalisation at least.

A Product Owner watches over the quality of the product and understands that this quality happens, among many other factors apart than the number of bugs, due to the quality of the code.

Obviously, that is not their focus. But using this "is not their focus" to support the argument that Scrum does not take care of quality is, at least, forgetting that the Scrum team works through collaboration. In my opinion, it is also to treat the Development Team as young children who are not supposed to be able to assert their technical criteria.

By the way, Scrum does not enter into how the technical team executes its work. Nothing prevents a team (in fact it is desirable) to incorporate into their work practices of other Extreme Programming or other methodologies. Whether it's TDD, Pair programming, Code Reviews ... what the team thinks works for them and makes sense to them.

The lack of hierarchy in the Development Team does not work

Where doesn't it work? In what team? When and why?

Another soft argument.

Having a team with equal responsibilities favors emerging leadership. And yes, this happens and it works and I have seen it many times. The thing is that requires not believing that one is smarter than the others and letting each make one step forward when the time is right.

There will be a developer who takes the leadership in some case because something is undertaken for him is within his area of ​​expertise. In other cases another person because he has more experience in that code base, in others that one who has a moment of greater professional growth ...

Having the obligation to include a "code chief" in each small group of developers, can produce situations in which the criteria of that person is the one that has to be imposed only by title. Authority should always be earned, not imposed. It can cause the dependence of that person and a lower degree of involvement of the rest since they only have to be attentive to what the person in charge says they will already execute.

But also... if something goes wrong, is it going to be only that person's responsibility? Or, then, will it be good for us to have the development responsibility of the entire Development Team?

Of course this is not always the case. I also see Scrum Teams where the leadership is not executed in this way and leaders take care of promoting emergent leadership. In any case is something very important to take into account and be very careful with it.

This is talking about accountability towards development. Scrum doesn't care about the companies hierarchy but about the responsability of the develpment  on a daily basis. A team lead, if it exists and no matter how you call it is not more reaponsible towards the outcome of the Sprint or how they create the product in Scrum.

That the development team share responsibility also makes it possible for everyone to be free to join a task for the common good, to ensure the delivery of the product and that there is no ownership over the elements of the backlog when someone starts working on implementing something.

You can´t deploy so often with Scrum

First of all, I would like to know what period of time is "so often", because the romantic ideas of the past sometimes distort the reality of what has been lived.

The issue is that that is completely false. Scrum speaks of having at the end of the sprint a product increment potentially deployable in production. Never, at any point, says that you can not go to multiple deliveries.

What a team should not admit to itself is to take it as good that a Sprint ends and there is not a finished product delivery.

If your deployment system allows it and makes sense in your company, why not do five deployments per day? You minimize the risk due to the accumulation of developments, you collect feedback much more frequently and you contribute value continuously.

The concept of a Sprint puts pressure on a team

This argument seems to me naive.

Working with a time-box is a way to get among other things:

Minimize the risk. Working with a maximum time, it is assured that in case of error, if there is a change of intentions, if the development does not go where it was expected ... the risk of losing too much time and money is much lower. And yes, I wrote "money", because we are developing a product and everyone's salary is not paid with good intentions and desire to do it very well, but with the product that is delivered continuously.

Responsibility towards delivery. What a Sprint does produce is the responsibility to deliver the product. The teams get used to limiting their work in controlled iterations that they know they must deliver. And it is that you have to deliver. I insist It may seem like a truism but a development that lasts for infinite reasons is a black hole of time and money and you have to take responsibility for that.

I'm going to write this again: No one forces the development team to take on a certain amount of work. For what they must manage (which is part of becoming more professional) the amount of work they estimate they can carry out in a given time. It is their responsibility not to assume unmanageable amounts of duties and then not closing them.

It's funny because people would get very upset if they go to a restaurant and because they admit more customers they can attend take forty minutes to bring each dish, but it's hard for us to understand the customers to whom you deliver software (yes, also if your client is your own company) you must also deliver what you have agreed that you will deliver at the end of the Sprint.

The development team learns this on their own path, getting to know which is their real capacity. Is not something that will just happen overnight. Just be careful if after some time you find a Development Team that oversees this point and just have not finishing things as something normal and acceptable.

I leave for another article in depth the fact that this type of arguments and articles seems, deliberately or not, to obviate not only that the teams work on their own improvement Sprint after Sprint, but that Scrum is based on five values ​​that are fundamental for the Scrum team and that ensure the functioning of everything else in a healthy and professional environment.

  • Focus
  • Courage
  • Openness
  • Commitment
  • Respect
Show Comments