Often, I hear that people who promote Agile ideas and methods are viewed as “religious”. It is certainly important to ask ourselves why we could be perceived in such a way.
The most obvious answer is that I used the intentionally provocative word “Evangelist” in the title of this blog. But I feel (or hope) that it is more a statement of my intention rather than my attitude.
The more serious answer is somewhat more complex. It has a lot to do with how people are taught to perceive the world of software development. They are taught early on that you will get nothing but chaos and failure if you do not have a system in place where you pre-plan your work meticulously and where a hierarchy of managers tightly control the project’s execution. There are also many inherent prejudices such as “The customer’s requirements are always terrible”, “It’s the customer’s fault if we don’t understand what they want”, “We’re going to be blamed if something goes wrong”, and so on. Some of these prejudices might be derived from bad experiences, others are defense mechanisms to keep oneself from admitting own mistakes, and others might just be passed down from one generation of developers and project managers to the next. Either way, those prejudices together with the processes everyone was told to adhere to form a kind of box that is not easy to break out of.
Anyone who approaches this box from the outside with ideas that are completely different from what is inside that box will automatically be seen as strange. And the more fervently you start banging against the box, the more likely you are to look like a religious zealot.
Also, the other issue is that even with processes like waterfall that are not optimal, companies still manage to create and sell products. Projects overshoot their budgets, people have to work 80-hour weeks to meet deadlines, the customer doesn’t get what they expected and the software is buggy. But it still sells and the company manages to stay afloat. I call that “successful failure” (I am planning to elaborate more on that in the future), and there are probably many software companies that survive for many many years through a series of successful failures.
The problem here is that when people think of past projects, they like to think of them as successes, because they invested a lot of time and effort into them. Developers and project managers likely define their professional identity through whatever projects they have successfully shipped. So they prefer to see the positive aspects of their projects: They have managed to ship a product, earn money from it, and they have done so even in spite of immense difficulties. And let’s face it – such a glass-half-full attitude is not even the worst thing. But for someone who wants to introduce new methods, that is a difficult environment. Pointing out that previous projects were essentially failures is a dangerous thing to do when you are speaking to people who define themselves through their achievements in these projects. So that is another great way to come across as someone who is “out there” with “bizarre” ideas that have no connection with reality.
So don’t be surprised if you hear something like “But that is how we learned it, and we know it won’t really work any other way. And we have been doing it for 20 years, and look where we are!”
But it sounds like I am only looking for the problem on the “other” side. No, on the contrary. I think one issue is also that many proponents of Agile have had a kind of “agile epiphany” at some point in their lives – a moment or a series of moments where they had the sudden realization how Agile can actually work for them and how it can greatly improve the way software companies work. Such an epiphany is a great thing to have, but it tends to pull people away from others who have not had such an epiphany. And to be honest, it is very much akin to a religious experience. It can be difficult for someone who has had such an epiphany to develop the necessary empathy for people who are following another mindset. So many Agile evangelists can come across as extremely dogmatic without any understanding of other people’s points of view.
The end result of these three issues is that you end up with Agile evangelists who dogmatically tell people that everything they have previously learned is nonsense and that all their previous projects were failures. Now it’s not surprising anymore that such a person comes across as being religious.
So what is the solution? Well, I wish there was an easy answer. The short and overly simplistic answer would be: Don’t be dogmatic, be pragmatic. Don’t tear down old learnings but work on building new ones. Don’t focus on past failures but try to build future successes. Yes, that is easier said than done. And it poses a lot of questions, such as how you can actually motivate an agile transition if you have to tiptoe around the shortcomings of previous non-agile projects? So no, these three points can be suggestions, but they cannot be the full answer, and this topic certainly deserves deeper exploration.
There is one fitting response to the accusation of religious fanaticism though: If I compare Agile approaches with conservative approaches, then I feel people who believe that you can pre-plan a software project on a highly detailed level two years in advance are far more similar to religious believers, while Agile is much more built on empirical evidence and a healthy sense of realism.
AgileEvangelist 