Scrums Bad Rap

29 Jan Scrums Bad Rap

Agile-Development-Intro-with-Scrum

Scrum’s Bad Rap

There are numerous articles out there about Scrum’s failings and how it isn’t Agile. There are no perfect systems and Scrum is no exception but many of the arguments are flawed. Scrum may or may not be right for your organization but before you decide, you should have a good understanding of the arguments for and against Scrum.

These are certainly problems that companies experience with Scrum but are they really problems with the system? You can decide for yourself after we dive in a bit.

As we walk through each of the items listed, I will reference the Scrum Guide which the co-founders of Scrum put together to share Scrum with the world. If you are not familiar with it, I would recommend a giving the completely free, 16 page document a quick read. If you are having problems with Scrum, it may be a good idea to review it more deliberately to see if your problems may be coming from a misunderstanding somewhere in your organization.

1) Sprints are inflexible – The Scrum Guide says that no changes should be made that jeopardize the sprint goal, the team and PO may renegotiate the scope and provides a mechanism for the PO to cancel the sprint if things get too far off. Part of the goal here is to keep the team focused on delivering value at the end of the sprint but the larger benefit is keeping management from coming in and making changes which can have major impacts on teams and productivity.
2) Estimating and planning poker are a waste of time – The Scrum guide does not say anything about planning poker or how to estimate. It only says that backlog items are estimated and that the team provides the estimates. It could be T-shirt sizes, hours, points or whatever works for the team. It just so happens that story points are a generally accepted method in Agile frameworks. Besides providing information for product owners to prioritize and management an idea of how long things will take, estimation helps drive discussion on the stories. The discussion brings out unidentified acceptance criteria which helps to create a better product and gets the team on the same page about what is expected which reduces rework.
3) Story points are confusing – Story points are not mentioned anywhere in the Scrum Guide.
4) Developers don’t have control – This is a common problem in Scrum implementations but the Scrum Guide says teams are supposed to be self-organizing and nobody is supposed to tell the team how to accomplish their work. The team is also supposed to pull stories into the sprint and not have them pushed. This means that they do not have to precisely follow the PO’s priority order and can optimize the work in more efficient ways where it makes sense.
5) The Scrum process is too prescriptive and not Agile because it can’t change – The Scrum Guide does say that in order to call it Scrum, you have to follow all of the rules and that they are immutable. It also says that you can implement some pieces on their own but you can’t call it Scrum at that point. Aside from the rules of the framework, everything else including tools, processes and organizational structure is open to change. Scrum is a framework and the pieces of the system build on each other just as the structural components of buildings. If you take one away, the structure is weakened and the whole thing might collapse. This may be a weakness of Scrum but is it unique? In a waterfall project, if people stop providing estimates or take away the project schedule, what would happen? In the agile world, if a team is doing Kanban and they take away the board, what would happen? Scrum is also a much different way of thinking about and approaching work from what people are used to and having a rule in place that you have to follow all of the rules is a tool to help change people’s mindset.
6) Scrum puts process over people – Scrum certainly requires a level of discipline and adherence to the process but the process is all about getting people to talk to each other. The framework is also the minimal set of rules that the co-founders determined to be necessary to keep things from breaking down. This is another reason that the guide says that all of the rules have to be followed to call it Scrum. Aside from the process, Scrum considers anything that impacts team performance to be an impediment. For those that take this literally, that would mean that if a co-worker can’t get to work, somebody on the team or in the organization would help them. If there is a personal issue distracting from work, the team should be there to support or help remove the distraction if possible.
7) The team is not capability of self-organization – This is a tough one to address because it really depends on the individual. Most of the time, people are capable but managers have a hard time letting go of control and take actions that actually encourage the team to avoid responsibility. Scrum gives control to the team and removes the manager’s ability to hinder accepting responsibility if the rules are followed. On the other side of the coin, if somebody really is not capable of picking up a task and running with it, are they really somebody that you want on your team?
8) Scrum does not focus on delivery – The goal of every sprint in Scrum is to deliver working software.
9) The ceremonies are unnecessary and a waste of time – This is probably the most common complaint about Scrum and also the most difficult to address because if people decide a ceremony is worthless, they will make it that way. Any framework or methodology is subject to the people that utilize it. When done well, Scrum ceremonies are minimal and effective and each one has a very important purpose. Planning is generally the biggest complaint but from personal experience, planning sessions are very valuable when people believe they are collaborate to make a plan for the upcoming sprint. Usually, the value starts to break down when rules of Scrum are not followed such as the team not having the authority to determine how to approach the work.

Hopefully this helped to clarify some of the misconceptions about Scrum. For more information on why Scrum fails and the scenarios where it is not the best choice, see our “Why Scrum Fails” blog post (coming soon).

No Comments

Sorry, the comment form is closed at this time.