Scrum Sucks! Part 3 – Why Scrum Sucks | The 6 Figure Developer
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.
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.
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.
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.
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.