Scrum is the Symptom, not the Problem

Scrum is horrible. It's an unrelenting tool of micro-management that robs engineers of their productivity and self-esteem. It doesn’t take much googling to find a vast number of developers griping about it on their blogs. So why are most companies still using it? Developers have been screaming about it for more than two decades now, yet it stays firmly entrenched.

Many hoped that, with time, a more sensible methodology would emerge to replace it. Engineers naively believed their appeals to reason would eventually fix the industry. But no such awakening has occurred. One sad truth has emerged: corporate processes are not chosen for their ability to effectively organize and motivate workers. Corporate processes are chosen for their ability to control people. Scrum is too good an instrument of control for the industry to let it go.

Scrum is proof that any philosophy, no matter how enlightened, can be twisted into an instrument of exploitation. The Agile Manifesto evangelizes “Individuals and interactions over processes and tools.” It preaches the gospel of trust and flexibility:

…

Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

…

The best architectures, requirements, and designs emerge from self-organizing teams.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

…¹

After the manifesto appeared², Scrum quickly declared itself to be “agile” in spite of its focus on mandating specific and immutable processes and tools. While agile intended for developers to direct their own meetings and rituals, Scrum installed non-technical “certified” Scrum Masters to run meetings and enforce the use of soul-shattering tools of bureaucracy (I am looking at you Jira!). Where agile called for close and frequent customer relationships, Scrum placed a barrier between developers and customers — a non-technical “certified” Product Owner. A system more diametrically opposed to the Agile Manifesto would be hard to find!

With Scrum Masters and Product Owners running the show, waving their certificates in the air, it’s easy to feel like everyone suddenly knows how to code better than programmers themselves. Any objection to the new process is greeted with suspicion. “These developers must be lazy or incompetent! I’ve been to the conferences; they can’t fool me. Let’s get more stuff into Jira and see who’s not pulling their weight.”

As infuriating as this is, it’s important to step back from arguing the efficacy of Scrum with your manager and realize that this problem dates back much further than agile. Before Scrum poker and story points, the industry was preaching the gospel of upfront planning. We spent months trying to design and scope out projects that would run for a year or more into the future. When these software mega-plans inevitably slipped past their deadlines, who was to blame? “These developers must be lazy or incompetent! If they can’t get their work done, I guess it’s time for another good old-fashioned death-march.” Same story, just a different framework and different instruments of torture.

Whether it’s waterfall, Scrum, or Excel spreadsheets, environments of low trust will always produce processes of low trust. Management may profess to be part of an enlightened future, a new progressive workplace, but they will resort to the same tactics as before, just packaged differently; Scrum is merely the package they are using today.

This realization has an important corollary. A new process won’t make any difference. Even if Scrum is suddenly eliminated, a new system of control will fill its place. The root problem is the imbalance of control in software corporations. Developers have no real power or seat at the table. They are not peers engaged in a common creative enterprise — they are hired, replaceable machinery, no different than the computers and monitors they use all day. In other words, the root problem is the system that allows for something like Scrum to be used in the first place.

Unfortunately, as long as the lion’s share of company ownership resides with a handful of founders and investors, this will never change. Experience, competence, and talent will always take a backseat to the only thing that really matters: ownership. The only company rule with any teeth is the golden rule: Whoever has the gold makes the rules. And the first result of ownership resting with only a few is a system of corporate governance that gives all meaningful control to those same few. While it is true that more egalitarian systems of governance can show up in organizations from time to time, they have no guarantee of permanence without employee ownership. You are always one management change from returning to the same chains you wore before.

So what is the real solution? Engineers need meaningful ownership. If engineers could acquire enough ownership to represent a significant percentage of the company, they could demand to be part of decision making. They could insist on software practices that make sense. Management would have to listen and take them seriously. A system of actual distributed decision making (like the Agile Manifesto describes) could be implemented.

Obviously, this is easier said than done. No software company operating today will be interested in giving away enough ownership to make this dream possible. This leaves only a few options. Developers can:

1. Start their own employee-owned and managed companies that are governed by distributed decision making.

2. Become freelancers that insist on being in control of how they work as a condition of taking a job.

While not easy, both are possible. There are no legal barriers to prevent them, it just takes work. If enough developers refused to rent themselves to micro-managing, ownership-hoarding organizations, then the good jobs they create will start replacing the bad ones. Even existing companies will have to start changing their ways or risk not being able to find programmers. This the power of the labor market. A software company needs programmers to write software. When hiring becomes difficult, they have to start playing ball.

Conclusion

If developers want the freedom to write software in sensible ways, they need to enter the market directly as either founders of companies or freelancers instead of through the comfort and convenience of existing companies. It’s a hard pill to swallow, but there just aren’t many companies doing it right. Luckily, I am guessing it is easier to teach business to a programmer than the other way around. Think of it this way: it HAS to be better than doing Scrum!

Side Note

Another pleasant side effect of working where you have real equity is that you get paid more appropriately for the value you bring to an organization. Our system of consolidated power also operates under the delusion that someone who comes up with a roughly developed idea for a business is the only one who deserves any compensation if the business succeeds. Upon a successful company exit (i.e. getting sold or going public) nothing goes to the many individuals that sweat, bleed and grind to develop that idea into a viable product. This is equally unethical. But that’s a blog post for another day…

1. https://agilemanifesto.org/principles.html

2. Contrary to what many believe, Scrum was not a process designed to implement the ideas from the manifesto, it predated it by at least six years. https://en.wikipedia.org/wiki/Scrum_(software_development)