Scrum Sucks! Part 3 – Why Scrum Sucks 3


Okay, so why does scrum suck?

To understand why scrum sucks so bad, first we have to understand why the company has decided to use scrum in the first place. It is my experience that companies switching to scrum do so because they have been told that scrum will make development go faster. They are told about user stories and hear that less work must be done for requirements. They hear that Agile is all about change and think that planning, the kind of deep planning done in a waterfall world, is no longer necessary. All of this leads to the issues I will be discussing in this article.

Agile, ugh

I almost wish this term would stop being used. Agile, when it comes to business, has a direct association with change. I don’t know how many companies do this, but several that I have worked at tell you on the first day, “The only think you can count on here is change.”
That statement simply means that the company is chaotic and has no clear direction or plan for success. These companies typically don’t know what they are doing and, typically, have no interest in investing the time and effort to figure it out. For them, Agile is an excuse to be disorganized. Agile is the crutch that allows them to make last minute additions to a sprint and expect the work will still get done.

Scrum, because it’s the most like waterfall

At the heart of the problem is that companies choose scrum, not because they believe it is the best path for success, but because it is the closest Agile methodology to waterfall. Scrum is designed like a tiny waterfall and with out the overlapping of phases, each sprint becomes a tiny waterfall. First, planning and requirements gathering are done before the sprint begins. Design is typically skipped altogether or is done at the same time the requirements are. Development happens during the majority of the sprint. QA tends to happen on the last day of the sprint. Finally, deployment of the completed sprint happens after several months worth of sprints because the company doesn’t understand the purpose of iterative cycles and feedback. In the end, Scrum has delivered nothing but frustration to all parties involved.

The business doesn’t care

The switch to Scrum, and Agile in general, seems to be a mostly bottom up driven change. When you are told to do something but you really don’t want to, you typically do the least amount possible to appease the person telling you what to do. In this case the developers are frustrated with waterfall and they are telling the business that a change needs to happen. So, the business does the least amount of work possible to appease the developers. A scrum team is assigned, The waterfall requirements and design are secretly created, and then a set of really crappy User Stories are created that are based on the waterfall requirements and design. This is done because at some level in the company the business still wants to sign off on the completed spec before development can begin. Again, the company is only doing Scrum to make the developers shut up.

Nobody knows anything

Business Analysts, our new Product Owners

Even if the business buys into the Scrum process, the individual typically doesn’t. Pretend for a moment, you are a Business Analyst. You are being told that you now have to make User Stories instead of specification documents. This change is immediate, and you only get a 1 hour Scrum workshop to understand this new process. You exit the workshop with the new knowledge that requirements need to come in a very small format. The requirements for an application feature used to be pages and now you have to cram all that knowledge into a single sentence. This is complete and utter nonsense. How in the world can it work. In the end, you do what you have been told, but only because it has been mandated. You put very little effort into understanding the purpose of this new format or how to use User Stories effectively. You just use the format, because you have to.

Quality Assurance?

Now, pretend you are a QA Analyst. Before Scrum, you had a specification document that was several pages long explaining, in detail, everything about how the product was supposed to work. You also had a complete design document detailing how the application should look. Writing and executing your test plan was easy. Now, all you have is a silly sentence that barely tells you anything at all. You are on a team filled with a Business Analyst and several Developers, but you are the only QA member on the team. Being the only QA Analyst means you don’t even have anyone to confer with to make sure you have the right idea about the operation of product. Now you have to actually talk to the developers, and they are just pompous angry people that you would rather leave alone.

Developers

The story doesn’t seem quite as bad here. Pretend, again if you will, you are a Developer. With a specification document from Waterfall, there was simply too much information that didn’t matter. You are actually happy to hear that the company is switching to Scrum and can’t wait to get started. Then on the first Spring Planning meeting you see the User Stories that have been prepared. What is this? Now there is no information. That “Story” doesn’t tell me anything useful. Where is the requirement that explains what this is supposed to do? What, there is no design either? How are you supposed to know what to make if there are practically no requirements and there is no design? How in the world are you supposed to estimate this when you can’t determine what it is that you are supposed to be doing in the first place? You ask the Business Analyst, who is now a Product Owner, for clarification and they have no answers.

What a tool

On top of the other changes, businesses typically implement one of several automated tools to help organize the project and manage the different backlogs. I use the terms help and organize loosely here. These tools are a full body cast where a crutch is needed. Planning needs to be fluid and changeable without friction. All of the tools that I have seen and used go against this principle. Once a story is placed in the system it becomes more rigid. Some systems, such as TFS (Team Foundation Server) from Microsoft, impose a very rigid hierarchy that does not allow for a User Story to become a Theme or an Epic. This means that when you discover that a story is larger that you initially though you have to actually delete the story and recreate it at the appropriate level. It doesn’t take long to make the adjustment, but it provides friction during a time when you need as little friction as possible. Every single automated or online tool that I have looked at has some limitation that adds friction. Friction is about the only thing, in my experience, that these tools bring to the table.

Put’em together and what have you got?

In short, when you take all of the factors that go into a companies decision to implement Scrum, and then add the misunderstanding and miscommunication typically present during that implementation, you end up with a hot mess that causes frustration from everyone involved and costs the company more money when it should be saving the company money. Scrum sucks because we are all doing it wrong. It’s my opinion that this doesn’t have to be the case though. In the next article I will tell you how I think scrum could be done better.


Please Consider Sharing This Post:

FacebooktwitterredditlinkedinFacebooktwitterredditlinkedin