Top excuses for avoiding Scrum
As an Agile coach I have come across many different teams and heard a lot of complaints about Scrum. Now Agile is not necessarily Scrum, and an empty implementation of Scrum is not Agile either. Why did I need to make this statement? Because many people confuse those concepts and complain about implementations without the mindset. The focus in this article is on what excuses I heard about Scrum. What was common between all the people complaining was they either did not experience it right or did not immerse themselves in it. I am not claiming Scrum is not difficult, it is simple to start yet difficult to master and get right. You might feel you or some members of the team have those excuses and it is fine. hopefully, this article will help you understand how to use Scrum correctly and make the most of it.
Our requirements change daily and we need to be Agile and a sprint doesn’t allow us to be adaptable: While a shorter cadence may be appropriate, that is not really a problem of Scrum. It is a problem of decision making on prioritization. If you cannot manage the requirements for a sprint then you will sacrifice the teams’ focus and not achieve goals, plain and simple. I wrote an article offering solutions to this particular challenge. In general the problem is the inability to make a decision on requirements and seeing them as tests and learning opportunities.
There are too many meetings in Scrum: Scrum has meetings have a specific purpose and goal and are time-boxed. There is a level of collaboration that teams cannot achieve without meeting. The Agile manifesto has two direct principles addressing collaboration. First is “Business people and developers must work together daily throughout the project.” This might be interpreted as a non direct way of work, so I will add the second principle “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” Here notice the “to and within” to complete the argument. Besides, I would challenge comparing how many unproductive meetings you have now and see how much time they take from your week or month. I did this comparison once with a group and the results were humbling to the team. You cannot achieve the goals of Scrum without those meetings. They allow you to handle complex situations that require inspecting and adapting. Another interesting experiment I conduct with teams is trying to remove one. The sacrifice is usually the retrospective and this is a big sign of a much larger systematic problem.
The sprint is too short to deliver value: While a longer cadence might be appropriate, however, this is a fantastic exercise that Scrum helps teams go through creative constraints. Scrum helps the team think about breaking down those items of value, and how to build them incrementally and release/integrate them continuously. Having long release and feedback cycles as you try to navigate a complex situation is akin to driving a car with eyes closed most of the time. I had a team that said there is no way they can deliver a story in one week’s sprint from start to finish, and after 4 months, they delivered 16 stories. It is only normal to believe it cannot be done until it is actually achieved.
Scrum doesn’t work with Juniors/seniors: I heard opposing arguments where some people say Scrum doesn’t work with Juniors and others saying it doesn’t work with Seniors. This is a problem of ego. Scrum as a framework does not recognize these levels. Everyone in the team has a shared responsibility to deliver value to customers. Yet we are used to hierarchies and giving empty motivations to people to progress in that hierarchy. If our individualism gets in the way of the individual good as well as the common good, then it is not really the best course of action. Scrum works regardless of the composition, yet, like any other kind of teams, it is best to have a balanced composition in teams on the different skill levels.
The Scrum master role adds no value. I wish Agile coaches and Scrum masters are not needed. This actually means the work is Agile to such a level that Scrum masters get in the way of progress of the team. If a Scrum master is not helping the team focus, and removing impediments, then the Scrum master is not fulfilling the role as needed. What is interesting is that it is almost impossible to balance both the roles of the Product Owner and the Scrum Master, yet that is what most organizations force and face the consequences (check the Scrum guide). Want to understand further the value of the Agile coach and Scrum master, read it here.
Many people implementing Scrum forget the pillars and values that Scrum is meant to uphold. It is not easy to do so. However, if a team wants the results of Scrum such as 400% increase in productivity, they should not expect it to be easy.
