Agile is a nightmare that I’ve seen actually kill companies. By “kill” I don’t mean “the culture wasn’t as good afterward”; I mean a drop in the stock’s value of more than 85 percent. This is toxic and it needs to die yesterday.
For those unfamiliar, let’s first define our terms. Then I’ll get into why this stuff is terrible and often detrimental to actual agility. Then I’ll discuss a single, temporary use case under which “Agile” development actually is a good idea, and from there explain why it is so harmful as a permanent arrangement.
What is Agile and Scrum?
Agile is a trend that came out of web consulting that was created to deal with particular and picky clientele with no real direction. The first is to manage the client:get expectations set, charge appropriately for rework, and maintain a relationship of equality rather than submission.
The second is to accept client misbehavior and orient one’s work flow around client-side dysfunction.
It either directs a client towards set expectations or deals with the misconduct and manages workflow around their needs. Neither of these options is appealing to programmers since they usually do not react well to social demands.
Companies usually divide two types of work to consultants, which is the high-end work that they may not have the right people for or the low-end dirty work that they wouldn't dare give to their own staff.
So what are Scrum and “Agile”?
I could get into the different kinds of meetings (“retrospective” and “backlog grooming” and “planning”) or the theory, but the fundamental unifying trait is violent transparency, often one-sided. Programmers are, in many cases, expected to provide humiliating visibility into their time and work, meaning that they must play a side game of appearing productive in addition to their actual job duties.
Instead of working on actual, long-term projects that a person could get excited about, they’re relegated to working on atomized, feature-level “user stories” and often disallowed to work on improvements that can’t be related to short-term, immediate business needs.
Programmers are not taken seriously as they should be in this agile community and are expected to work on nonsense into valuable time just to appear productive along side with their actual work duties. It’s humiliating and a complete waste of time (tonally too strong), instead of working on meaningful long-term projects that are interesting for programmers they are regulated to work on short-term projects in crunch time and are often turned away to work on developments that cannot relate with urgent business needs. Agile terminates ownership and uses programmers as mindless robots that are only useful to get the job done.
Scrum creates stress and anxiety in the productivity of individuals. This makes work sloppier and can lead to mistakes since programmers usually perform at their best when involved in long-term interesting work instead of being pushed for a close deadline in an invasive matter. It simply does not work.
Agile reflects a dysfunctional organization with no well-defined hierarchy. Even with the team environment there is still an obvious ranking level system from highest to lowest, Product owners, Scrum and team members. Scrum puts engineering at a low level well below the ones that actually have full authority that decides which work is to be done. This causes problems because it means that engineers are likely to get pushed around or even penalized if work is falling behind and is taking longer than the deadline should be.
Deadlines are obviously important. So it is not wise for the company to be driven by engineers but when engineers have a sense of priority and ownership there is a happier and better quality of engineering in the workplace.
How is Agile causing destruction in the workplace?
Agile is created for companies that have no real credibility that would facilitate them to bargain with clients in an equal level, it is designed by consulting firms that are marginal that deal with short deadlines and puts clients at risk. It means to undergo the headaches and risks without any real positive feedback. It sets an emergency atmosphere when clients present reputation problems that need to be fixed quickly.
It is aggressive project management and should not be a permanent way of executing projects, it just doesn’t make sense and is not made for highly skillful programmers that deserve a better and enjoyable options.
Another real problem that agile creates is the invisible debt that piles up for every project. It is not brought to attention because higher leveled employees that direct the projects are blind to the problem until it is too late and too expensive to fix. Individuals working on these projects are either rewarded or punished based on the completion of the project with no regard to looking ahead towards the two-week deadline.
Agile corrupts the minds of these programmers to be mindless and near-sighted with no actual progress and improvement whatsoever. What’s even worse for programmers is that there is no career coherency for them to advance in there area of interest .
Scrum and the Individual
Scrum creates underperformers that place them in an observation state that demands for individual engineers to provide a transparent work flow to rate and judge their own productivity. It is basically a position for slackers that do not get the job done but demand for others to do it instead.
Scrum and Agile is not meant for the best performers because they immediately do not react well to this environment once they understand that there is no room for advancement or any real interesting work that would pay off, instead it is meant for the status insensitive workers that have not been faced with any real challenges and just want to have some sort of high level credibility.
Essentially, Scrum and Agile play a part in status profit so many scrum material people judge their advancements or failures based on status differential achieved. This usually describes a younger person that thinks they are higher than what they really are and will gladly take to a scrum level position. Scrum is falsely sold under the impression that it works well in every environment and as a permanent way of workflow.
What “Agile” and Scrum say to me is that older, senior programmers are viewed as so inessential that they can be ignored, as if programming is a childish thing to be put away before age 35. I don’t agree with that mentality. In fact, I think it’s harmful.
I’m in my early 30s and I feel like I’m just starting to be good at programming. Chasing out our elders, just because they’re seasoned enough to know that this “Agile”/Scrum garbage has nothing to do with computer science and that it has no value, is a horrible idea.
How Scrum can be useful?
Before the permanent implementation of Scrum and Agile in the workplace was put in place, it was best used as a tool during code red or in an emergency state. Scrum was when a team needed to act quickly when an unexpected challenge arose and has no clear manager but a leader that chooses to provide direction to a possible solution to the problem.
Since the emergency is short term then it is no problem to place the real and interesting work on a brief hold since they would be allowed to go back to it once the emergency is over.
However, it should not be frequent for a company to spend time in these emergency states more than 6 weeks per year because in that case the emergency state is not rare when it should be causing less focus into the real work that needs to be done.
Another problem is if consultancy is having trouble to establish itself and has bad communication with the client and is jeopardizing the reputation of the company then that also means that there is a permanent state of emergency.
More on Scrum issues.
Scrum and agile acknowledges that the state of emergency must be handed to a leaders that like to take charge and will do whatever it is to get the job done and advance in social status. It develops the problem of getting the job immediately and discussion later.
So those motivated by the emergency state feel comfortable in it and conclude to terrible management. Agile and Scrum praises emergencies and that is the real problem, it is aggressive focus on individual performance with hardly any concern for individual engineers career advancement and have them only work on the priority. It becomes toxic.
It’s time for most of “Agile” and especially Scrum to die. These aren’t just bad ideas. They’re more dangerous than that, because there’s a generation of software engineers who are absorbing them without knowing any better. There are far too many young programmers being doomed to mediocrity by the idea that business-driven engineering and “user stories” are how things have always been done.
This ought to be prevented; the future integrity of our industry may rely on it. “Agile” is a bucket of nonsense that has nothing to do with programming and certainly nothing to do with computer science, and it ought to be tossed back into the muck from which it came.