Why “Agile” and especially Scrum are terrible – Michael O. Church
Michael O. Church
Rants, essays, and diatribes.
Why “Agile” and especially Scrum are terrible
Agility is a good thing, no doubt, and the Agile Manifesto (http://www.agilemanifesto.org/) isn’t unreasonable. Compared to a straw-man practice called
“Waterfall”, Agile is notably superior. Yet, so much of Agile as-practiced is deeply harmful, and I don’t really think that the Agile/Waterfall dichotomy is
useful in the ﬁrst place.
There’s a variety of Agile, called Scrum, that I’ve seen actually kill a company. By “kill”, I don’t mean “the culture wasn’t as good afterward”. Rather, I mean
that its stock dropped by almost 90 percent in less than two years.
What is Agile?
Agile grew up in web consulting, where it had a certain amount of value: when dealing with ﬁnicky clients who don’t know what they want, one typically
has to choose between one of two options. The ﬁrst is to manage the client: get expectations set, charge appropriately for rework, and maintain a relationship
of equality rather than submission. The second is to accept client misbehavior (as, say, many graphic designers must) and orient one’s work ﬂow around
Programmers tend not to be great at managing clients. We’re very literal people. We like systems that have precisely deﬁned behaviors. This makes working
with non-technical people harder for us than it needs to be, because we tend to take every request literally rather than trying to ﬁgure out what they actually
want. Corporate Agile, removed from the consulting environment, goes further and assumes that the engineers aren’t smart enough to ﬁgure out what their
internal “customers” want. This means that the work gets atomized into “user stories” and “iterations” that often strip a sense of accomplishment from the
work, as well as any hope of setting a long-term vision for where things are going.