Why do a lot of developers dislike Agile?

A lot of developers dislike agile because they also simultaneously and secretly dislike each other, their bosses, and their customers. And they don’t even know why…

It has a lot to do with the “business model” of agile and why it is so darned popular in the first place.

A long time ago a group of intelligent programmers wanted to improve themselves and their profession. So, they tried some ideas that might solve the problems they were facing every day at work.

Ideas like pair programming, planning meetings, user stories, estimation, points, retrospectives, and so on were all just ideas and experiments initially, but some of them worked!

This is exciting, so they kept experimenting themselves on their own teams, and eventually they started telling other people about what worked for them.

A lot of the ideas were similar and people noticed how similar they were. There were no certifications, brands like extreme programming or scrum, and most people weren’t even familiar with “agile” at all.

So over a period of years you had things like the agile manifesto, Extreme Programming, Scrum, Programmer Anarchy, and other ideas start to take root. In fact, the ideas were so interesting to people that people wrote books, gave talks, and began to evangelize the sublime nature of agile.

Years later, an entire market formed around the agile process. You now have agile coaches, agile books, agile conferences, agile tools, and what amounts to multiple “religions” around agile.

Scrum has become such a popular flavor of agile that its language is now the dominant language in the agile world and business people outside of the developer world are going agile too.

You would think this is a good thing, but it’s really not.

You see, there is one thing that defines agile and it has nothing to do with all of the nonsense above.

Agile is about responding quickly to change. Actually I can write that better.

Agile is about contextual change.

That is to say, the purpose of agile is to change quickly to meet the current context you are working in. That can be the market you are in and the demands of your customers. It also means you must change to effectively use the resources at your disposal.

That idea sits in opposition to all the structure and formality people built around the idea of “agile”. Scrum in particular is quite problematic in this regard and this is where people start to secretly hate each other.

See, in Scrum you have all these rules and roles like a scrum master, sprints, planning meetings, points, backlog, stand ups, retrospectives, and so on. There are rules about the “right way” to do all of those things. There are training programs and certifications that ensure that you know and follow the rules.

In fact, Scrum done “right” according to scrum isn’t agile at all. Scrum the way it is taught is a process designed not to change. That is a massive failure. It breaks the most important principle of agile.

Agile is about contextual change.

To make Scrum agile, you have to be willing to change scrum itself to fit your context. That means more than just the length of your sprint. It should mean that you might not do sprints at all, or stand ups, or points, or estimates, or stories, or epics, or anything.

In a truly agile world, nothing is sacred. You do what makes the most sense in your context to achieve whatever the goal is.

That is the secret of The Toyota Way – continual improvement. That means over time the assembly line, process, and anything else will end up looking completely different than where it started and everyone is better off for it.

Now, there is a reason that Scrum is so popular and why it will never be truly agile, at least in the way that it’s sold to so many teams…

Most people don’t want a truly agile process.

80% of the people doing Scrum or other forms of agile aren’t truly agile and they have no interest in being agile. In fact, they are happy being unhappy in their broken process because Scrum (and every other formalized agile process) gives them something they deeply desire.

People desire a structure that allows them to abdicate responsibility. A structured agile approach gives them that.

Think about it, people want the cookbook, recipes, tips and tricks, 5 step process, 12 “hacks” and on and on that will tell them what to do so that they don’t have to take responsibility for the process themselves.

If you are using Scrum and things go wrong, you can blame Scrum. That’s exactly what this question is about. It’s not our fault, it’s the process that is broken!

Agile is broken!

But you see, the purpose of Scrum Masters and Scrum Certification and books and conferences and consultants and whatnot is to allow you to say that. It gives you an easy out.

The truth is – any process that you slavishly apply out of context to what you are doing is going to fail most of the time.

Waterfall was a very good process for a certain type of project and a certain type of team at a certain time. It’s horrible for most projects and most teams most of the time.

Scrum is a very good process for a certain type of project and a certain type of team at a certain time. It’s horrible for most projects and most teams most of the time.

Funny how that works right?

And it gets worse. You see, the same desire to abdicate responsibility not only causes us to blame the process, it also causes us to blame our bosses, coworkers, and customers for the crappy situation many people find themselves in.

Think about it, the sprint fails and people point fingers. It’s Bob’s fault because he didn’t work hard enough. It’s Joe’s fault because he let the customers walk all over us. It’s Sue’s fault because she mismanaged the team.

After a while, the bad process makes a team hate working together or working at a company at all. But, you can’t really fix it because the reason the process exists is to abdicate responsibility, not to improve things.

Now, people think they are trying to improve the process, but if you pay attention you’ll see they don’t want to change anything about the process. If anything, they want to add more processes on top of the existing process to “do it right” or “do it better”.

For example, people are bad at estimating. They will never be good at estimating because in general most software is custom and you never have enough information to truly know what you’re getting yourself into.

Teams should be smart enough to not do estimates or know that they are wrong 100% of the time.

Instead, they try and get better at estimates. They add more process to the estimation. They want to get the estimates right so they don’t “fail” the sprint. The process never works and people continue to give bad estimates. So more process is added and so on.

Think about how crazy this is. Instead of finding and molding ourselves to a situation (which requires constant change and growth), people will cling to a process at the expense of everything else.

And all of this leads to developers disliking agile. Ironically, the question itself about alternatives points to the same problem. People want a system and a process that will magically fit the context without changing anything.

In reality, there is only one system that will fit your context perfectly – your own. To find that system, you have to work toward it over time using something like Toyota does – continuous improvement.

That means you try something for a while, then you look at the situation and see what needs to change. You must do this every day, week, month, year over and over again to improve.

In practice, that means at regular intervals you meet as a team, talk about what works, talk about what doesn’t, and talk about what you want to change. Scrum calls these retrospectives, but the name isn’t as important as the process of examining and improving at regular intervals.

Everything else should be subject to change based on context. Even the retrospective meeting frequency and process is subject to change based on context.

There is no one right way to do things. You can never get to a perfect system. You can only change and get better within your context.

If all teams did agile this way, they’d be a lot happier, but then they’d only have themselves to blame when things don’t go perfectly. Until human nature changes, most people won’t allow that to happen. They’d rather have someone to blame than a better outcome.

Most people fear failure more than they desire success.

Because of that, developers (and soon many other professions) hate agile because it doesn’t fit their context.

No amount of new magical agile flavor of the month will change that.

P.S. If you made it this far, you should check out Creative Genius