Breaking away from the Agile Cult mentality
Lately, it seems as though Agile is becoming more of a cult, as opposed to a tool to help developers make better products. This is becoming more widespread and is starting to hinder development. Here are 6 ways Agile is more like a cult and why this hurts developers.
The only way to salvation is through your wallet
Just one example of Scrum Alliance pricing
Agile Alliance membership pricing
One telltale sign of a cult is that if you’re not paying money you can’t do it properly. Most of the time, when you pay for something you usually get something of equal importance in return. However, in this case, you’re really just paying for nothing more than snake oil.
Some of you reading this will try and play it off as “There are plenty of things that ask for yearly memberships that aren’t cults” and you’d be right. Unfortunately, this I don’t believe that this is one of those times.
It’s absolutely crazy that you have to pay this much money just to do Agile “properly”. The truly insane thing though, is that these prices aren’t even that bad. You can end up paying many thousands of dollars to be a “Certified Agile or Scrum Practitioner/Coach”. If you search “Agile certification” on Google you will have no shortage of companies who have based their entire existence around selling Agile.
Why does this hurt developers?
One scary thing is that most of the people who are being pumped out of these courses are non-technical people. I have worked in at least 5 different teams where the Scrum Master, or Agile Messiah, was someone who has never touched a piece of code in their life. They think that because they attended an overly expensive 2-week course on “Agile Development Methodology” and got their special certification that they know how developers should be writing code.
This is so detrimental to developers because non-technical people know nothing about writing code or the process of writing code. Their mindset is trapped inside the Agile box they can’t think outside of it. If a problem arises and a developer solves it in a way that does not follow what they were taught in their 2-week course, they chastise that developer and say things like “That’s invalid because that’s not how Agile works”. Their singular knowledge of Agile makes them brittle to change and break easily.
I want to make very clear, this is not a problem I have faced alone, or even at a single company. This is a problem lots of developers face, and one I have faced at several companies. If you have never, personally faced this problem that’s great, but there are a worrying amount of developers out there who are, so you should have reason to be concerned.
Agile Evangelism
Sums it up perfectly
Agile makes money, we got that on point 1. They want to continue to make money so they have to get more people to take their courses and attend their seminars. To do this they have to evangelize Agile as much as humanly possible. There are some Agile extremists who sell Agile as the one true solution, the silver bullet to solve any problem, your ultimate salvation. Then there are Agile moderates who say that Agile is not the silver bullet and you can make it what you want. However, their end message is the same: if you’re not doing Agile you’re wrong. Evangelists don’t want to hear why they may be wrong or why Agile may not be right or even some issues with Agile, they just want to sell it to you.
I know there are people out there who are going to say “This is invalid because there are people who practice Agile who don’t do this.” Unfortunately, the point is that there are more people that do, and they’re heard more often.
Why does this hurt developers?
When you evangelize any kind of belief system like this or are unwilling to hear about a differing opinion, you reject common sense and original thought. Developing software is all about being able to think about problems differently and coming up with creative solutions, rather than following a rigid template to a T.
I will say this again, this is not based on a single experience, team, or even a single developer. There is a lot of frustration out there over this, and I’m trying to shed light on that.
Naming the “other”
Don’t be a FUD
Usually when you want to take people and make them militant to another way of thinking you usually have to name who the “Others” are. In this case, Agile extremists will most likely name me, and plenty of other people FUDs. This has become a shorthand for people who spread Fear, Uncertainty, and Doubt about Agile.
The goal of this article is to shed light on the issues of Agile and its cult-like following. I am fully aware that not ALL people who practice Agile are like this, but the overwhelming majority are, which is the problem. This is the problem because you always hear the words of the majority more than you hear the words of the minority. If you’re going to comment and say “Well my workplace doesn’t do this” just save it because you’re in the minority of Agile workplaces. The proof is in the number of people are pumped out of these workshops, courses, and seminars and given back to their company or go to a company to manage a development team.
Why does this hurt developers?
This is one of the most harmful things you can do to a person in general. A prime example is the persecution of heretics by the Catholic church in the middle ages. If there was someone you needed out of the way for any reason you can simply brand them as a heretic and that’s the end of it. That person or family would be shunned from their community and no trial or due process was necessary to brand someone as a heretic.
Agile does the same thing when they name people who step out of line a FUD. This is used to make an example out of you as well as give others the right to pile on top to shut you up. This is the most effective way to shut down any critical thinking of differing opinion. This also ignores the fact that people given the FUD label are trying to combat ignorance, which is happily spread among the Agile cult.
Some may say that I’m branding Agile the same way, and you’d be wrong. I’m fully acknowledging that this is not the case for all those who subscribe to Agile, and that’s fine. My main point is to shed light on the problems plaguing developers
Maintaining control of your subjects
I spoke about naming the “Other” in my last point and why that is used to shut people up. Now I’m going to tell you how that allows the Agile Messiahs to maintain control over their doting subjects.
When you name someone as an “Other” or a FUD in the case of Agile, you shun them from the community and label these people as harmful to Agile to ensure a militant response from your followers. This serves to make an example out of someone and display the dominance of your way of thinking. This is a trademark cult sign, but it’s also not the only sign Agile displays.
The psychologist Jon-Patrik Pedersen argues that human longing for comfort leads us to seek out people or things that can soothe our fears and anxieties as a way to explain why people join cults. The way cult leaders exploit this is by bosting your anxiety and then offering you constant peace of mind. On the Agile Alliance website in Agile 101, Agile is described like so:
Agile is the ability to create and respond to change. It is a way of dealing with, and ultimately succeeding in, an uncertain and turbulent environment.
Agile is sold as the solution for success in an uncertain environment. Just follow Agile and you’ll be fine. Just hire the Agile Messiah and everything will work out. Pay us some money and you will have the peace of mind you need.
Making people fearful and anxious, while at the same time selling them something to sooth that is an effective method of controlling people. As human beings, we don’t like to feel uncomfortable and we will often take the path of least resistance, especially when someone hands it to us on a silver platter.
Agile pushes the idea that we are living in uncertain and turbulent times in order to build our anxiety and fear about what we’re doing and to get us to doubt ourselves. However, they assure us that it doesn’t have to be that way and that Agile has the answers we need to quell our fears and anxieties. They offer us the path of least resistance on a silver platter so long as we fully buy into it monetarily and philosophically.
Why does this hurt developers?
This goes hand in hand with naming the other but goes even further. This creates a toxic environment where new ideas are met with militant behavior. When developers are shunned and put in their place by mostly non-technical Agile Messiahs for thinking outside the Agile box, something is very wrong.
I would like to stress once again, that this is not the case at all Agile workplaces, but there is an overwhelming number of workplaces that operate like this. I have worked at many of them and have friends who have worked at many more. I think it’s great if your workplace is not like this, as I wouldn’t want anyone to work at a place that does this.
What I will say is that if your criticism of this article is “It doesn’t happen on my team” then please don’t bother. It’s the same thing as “It works on my machine” which is a lazy write-off of my argument and gives to real attention to the fact that it’s broken in production.
Ritualistic Meetings
What better way to inundate people with the process of Agile/Scrum? To avoid swinging too far to the other extreme, I’m not saying that we should never meet but we certainly don’t have meet every day or even every week. I believe that a more asynchronous form of communication can be just as effective.
Have you ever suggested that maybe we skip a stand up as we’re in the middle of something important or nothing has changed enough to warrant a stand p meeting? I’ve done so many times on many different teams and each time I got the same response “That’s not how Agile is done.” period full stop end of discussion. Has anyone else ever been met with this response when suggesting that something should be changed with the current Agile process? It’s such a simple response from someone who is unwilling to think about the current process because the current process is comfortable, and as we know, humans hate being uncomfortable.
Why does this hurt developers?
This is yet another assault on our critical thinking capabilities and common sense in order to indoctrinate us in Agile. Making everyone perform the same drab meetings over and over again with no rhyme or reason is an utterly useless waste of time. If you think about it in different terms you’ve got a team of 5 developers who each spend about 3–5 hours a week in meetings. This means that your team is wasting 15–25 hours of time each week. That is 15–20 hours you’re paying developers who are supposed to be writing code to make a product work.
If you want to think of it in terms of money, let’s do that. The average pay for software engineers in the US is anywhere from 60k — 140k per year. Let’s go right in the middle and say each developer earns 100k each per year. That equates to each developer earning around $50 per hour (for a 40-hour workweek and before tax). So now you’re wasting $750 — $1,250 per week per developer. For your 5 developer team that’s $3,750 — $6,250 per week. I’ve worked with teams that have been on the low end of that and teams that have been way over. I think that we can all agree that is a massive waste of resources. If you feel as though you NEED to have all those meetings, then there may be something else wrong that needs to be addressed because that is egregious.
I’ll stress once more that if your team doesn’t do this then that’s great, and there are plenty of teams that don’t. If you are one of these people thinking “This article is stupid because my team doesn’t do this” then I want you to think about all the teams who are doing this. Think about the amount of time and money that is being wasted and you may wonder why anyone would want to do that at all.
No questions or critical thinking
From Agile Messiah to Supreme Agile Overlord
I think my other points have illustrated this one quite clearly, but I want to point it out again. The most dangerous thing to Agile is the critical thinking of Agile. The real power of Agile is that it gives you just enough freedom to make it feel like you’re in control by using terms like “self-organizing” teams. That’s a nice word, if we follow Agile we can self-organize! It’s a nice-sounding phrase that means very little.
Self-organizing is a label given to us by managers to maintain the illusion of free will. I’ll quote the Agile Alliance site once again:
That doesn’t mean that there aren’t managers. It means that teams have the ability to figure out how they’re going to approach things on their own.
It means that those teams are cross-functional. Those teams don’t have to have specific roles involved so much as that when you get the team together, you make sure that you have all the right skill sets on the team.
There still is a place for managers. Managers make sure team members have, or obtain, the right skill sets. Managers provide the environment that allows the team to be successful. Managers mostly step back and let their team figure out how they are going to deliver products, but they step in when the teams try but are unable to resolve issues.
If a team is self-organizing, wouldn’t that make them independent of a manager’s control? Meaning that a team can organize itself in any way they deem fit? Except in this passage, the manager is responsible for assigning the skillsets of the team members. One thing I want to shed light on is the fact that Agile is completely manager-centric. The manager is responsible for making sure that everyone is simply a cog in the software development machine and that everyone is replaceable.
While this makes business sense, it’s also a terrible way to treat your employees. I’m in no way advocating that companies should have a product hinge on a single developer because that’s also unfair to everyone involved.
Why does this hurt developers?
What I am saying here is that with Agile there is no room for advancement or specialization as a developer. You’re simply supposed to do your job and are at the complete mercy of the Supreme Agile Overlord. If you want to get the bigger picture so you can be more effective at your job, well that’s just too bad. The Agile Overlord hands you your stories and you’re supposed to just be thankful you even have a job.
I am fortunate enough to have only worked at one place, for a very short time, that operated like this but I’ve heard some real horror stories. I don’t think it’s fair to think of your developers, or any employee, as a cog in a larger machine.
Conclusion
I understand this article can be quite polarizing in the way it is framed, but I think it’s important to point more attention to these problems. I think that Agile is beginning to rely too much on dogma which is causing a lot of frustration. I think that far too many people don’t actually think critically about how they apply Agile. If you’re going to take Agile, think about it, and change it to meet your team’s requirements I say more power to you.
The crux of my argument is that much of the culture surrounding Agile has become more cult-like in nature and has stifled the voices of too many developers who would want to change certain aspects to better fit their team.
I’ve been consistently repetitive in this article about one thing and that is that these pitfalls do not apply to every Agile team. If you feel as though your team is doing great with Agile that’s all well and good, this isn’t about you. This is about how the philosophy of Agile has been turned into a cult-like process for business managers to assert dominance and control over software developers and how that has spread far and wide.
If you don’t think this is happening and you don’t think this is a problem then your either blind or have a vested interest in making sure that Agile goes unchallenged. If you’re profiting nicely off of Agile, I can see why you would have ill feelings towards this article. However, if your main source of profit is selling the Agile snake oil, you’re really part of the problem I’m trying to shed light on. I don’t think that development methodologies should be turned into a standalone business or be evangelized as Agile has.
What I want everyone to take away from this is that we need to think critically about the process we put in place. If there are things that are broken or need to be changed then you should speak out against it. I don’t think that a competent development team needs a scrum master, user stories, sticky notes, planning poker, or any of the other ridiculous things that Agile tries to push on us. If you want to be an effective manager your primary goal should be supporting your developers by making sure that they have the things they need to do their job. Make sure that they have the requirements and leave them to the rest.
If you want to read further try the book “Agile! The Good, the Hype and the Ugly” by Bertrand Meyer. He takes a very thorough and honest look at the failings of Agile as well as some of the things that may be worth keeping.
