Every software developer has it. An annoying, gnawing, scratching little itch in the back of their brain. Its like the one that tells them all of their code is crap, but this one is almost always ignored. Its the little voice that whispers during 9AM stand-ups and hints during hours-long PI plannings. It nudges you softly while you add comment on comment to JIRA tickets and discuss story points, and it only ever says three little words:
“Agile is bulls***t.”
A Sum of its Parts
While the original intent for the agile methodology might have been good the implementations we see today are far from productive. Hours upon hours every week developers sit not at their desks, hands on keys, but in meetings and screen-shares discussing project planning and negotiating small insignificant changes to a project that is larger and more complex then any one person can grasp. What should be the domain of a small group of project planners and team managers has become a collective community experience that invariably devolves into debates over stupid things like “tabs vs spaces” or what flavor of configuration language to use. Agile’s daily and weekly rituals have turned the development process from a rational one into its own brand of religion and has rewarded zealots with overpaid positions leading their bands of disciples down this ever-deepening rabbit hole. “But no!” the evangelists will cry, “that’s not real Agile! Real Agile(TM) empowers developers to do their best work!”, they try to convince themselves as they yell it. But the reality is that it does not matter what the intent is, you must judge something by the sum of its parts, not the intent behind their design. If today’s agile is different from the prototypical agile method then today’s agile is Agile, not the prototype.
Even within itself the Agile religion isn’t so peaceful, it has its own divisions and divides. Scrum masters and project managers arguing about whose Certified Scrum Master certification is real and whose it not, devolving into a loud chorus of “no true Scotsman…” arguments, and holding up their certification zen masters as gods to be revered. Elsewhere the Great Story Point War rages on, with multiple armies fighting over imaginary numbers. Do they represent complexity? Or do they represent time? Are they an arbitrary measurement of something? Values change, ideas change, people flip sides, but the truth is plain to see: story points are made up numbers to make higher-ups feel like their teams are accomplishing something. But no one in the Agile bubble can agree, so the war rages on and on with no end in sight.
Sacraments and Sacrilege
But the most useless part of Agile are the ceremonies, specifically stand-ups. All at once they are a tool of social pressure, micromanagement, a waste of time, touted by Agile disciples, yet ignored by developers. Here again we see the original idea diverges from reality; where once an informal daily huddle where developers share, among themselves, their plan for the day and if they have any impediments, we now have a formal meeting where engineers argue about issues, managers are enabled to micromanage, time is wasted from the abnormally long meeting times, and scrum masters walk away believing that it was something productive. The truth is closer to this: developers are pressured into attending, ignored by other developers, and everyone goes their own way. Developers routinely step on each other’s work — work that was announced in a stand-up — so what is the purpose of a stand-up? The answer is none. We must again infer the value and meaning from the sum of its parts, and the sum is zero.
If we zoom out we can see the next part of our Tour of Agile: the sprint. Sprints are arbitrary lengths of time — usually one to two weeks — that are used for planning and scheduling. Sprints are the sums of their story points (themselves arbitrary) and are a way to track how much work is done in a period of time. In theory every story should be done within the confines of a single sprint, but it never works out that way. Sprints give managers and scrum masters a way to track how much gets done, and more importantly to them, how much more can get squeezed into a sprint. And this is where we start to see the true face of Agile emerge: Agile is far from empowering developers or creating iterative development cycles that are flexible and accepting of change. That’s just the facade that Agile’s evangelists want you to see but the truth is deeper still. The truth is this: Agile tries to turn man into machine. Agile takes thinking and creative developers and turns them into developer-robots, each incapable of independent thought and initiative, blindly completing tasks assigned to them. Software houses, once sources of incredible creativity have become assembly lines of mediocre software, complex and complicated, riddled with bugs and void of innovation.
We must find a better way, a Third Way, of doing software development. A way that doesn’t depend on scrum masters who get paid more than developers, that doesn’t waste time with useless sacraments, and that doesn’t allow managers to micromanage their employees. We must find a way that allows developers the freedom to create, the creativity to innovate, and the desire to stay.
And never, ever ignore the itch.