In the world of technology and innovation, there are certain terms and processes that have become all too familiar. Scrum is one of such terms that seem to dominate the industry. But what exactly is it, and why should you think of Scrum as the worst thing in tech? And since we are at it, let’s lump in Agile in the same batch. They are (wrongly) used as synonyms anyway.

Brief history. Agile was introduced in a manifesto written around 20 years ago by a group of software engineers. It’s the tech-world mixture between the 10 commandments and Unabomber manifesto.

At the time the working environment in software companies was quite different. Engineers were treated as second class citizens in the business. Being bossed around by businesspeople who didn’t have the slightest clue about the technology underlying what they were selling. The Agile manifesto came as a (very) successful, almost ideologically driven set of demands, asking for better collaboration, user-focus (so not to waste engineers time) and more flexibility from the tyrannical orders of the business owners.

The Agile manifesto was tremendously successful, spreading throughout the industry. And beyond with “Software eating the world”. But as many things that are good in the conceptual stage, when they face reality, they change. Agile became productized and sold in many different formats. It’s part of the reason why it became so popular. Courses, certifications, seminars, consulting, etc.

Agile adapted to the market’s demand, and one of its offspring, Scrum, the most popular of its variant, got ground. Scrum is so popular that it is what people have in mind when thinking about Agile: Two-week sprints, Sprint planning, Refinement, Retrospectives, etc. Scrum defines the process of how tasks are created, assigned, decomposed, and scheduled. At first glance, these processes may seem like efficient ways to manage work, but the reality is quite different.

One of the most common problems with Scrum (and Agile) is that the people responsible for implementing them are often ill-equipped for the task. In many cases, the role of Scrum Master or Agile Coach is given to individuals who may not fully understand the intricacies of the processes they are enforcing. People that often don’t have any practical experience in the craft and that watch videos or take two-day online courses and think they understand the concept. Not by practitioners, but missionaries of a new faith.

These missionaries fail to consider the nature of the work and the complexities involved. They approach their tasks with a rigid mindset, expecting everything to go according to plan, only to face unexpected challenges and setbacks.

In addition, the people who oversee the implementation of Agile “practices” are often more focused on process and bureaucracy than on the work itself. They are incentivized to add more processes and make themselves indispensable, rather than promote efficiency and productivity. Scrum is the panacea to sell to solve all the problems. The result is a system that values process over results, leading to a lack of innovation and progress. A true misalignment of incentives.

People that want Scrum implemented are often looking for a framework to assess control. To bring reliability and reduce the anxiety coming from unknown business outcomes. And this is understandable, don’t get me wrong. It’s good to expect a level of predictability and reliability in development. Especially when companies don’t have any formal processes whatsoever.

Sometimes any process is better than no process.

I really understand it, but I think as an industry we tremendously over-corrected. We use “Agile” frameworks to assert rigid control. We set up a whole industry around selling Agile. Selling a product that has all its incentives around maintaining its presence. Spreading to teams that are not working in development such as Marketing or Design. Creating an industry that became so powerful that is now trying to assert control to every level of a company management structure with SAFe. Don’t get me started with that.

We took ideas of flexibility and user-focus and created rigid guardrails. We trained outsiders in the church of Agile to spread the gospel to companies around the world. We trained tech missionaries.