A brief history of Agile

September 2018

Written from the perspective of a future anthropologist, partially inspired by The Dragon’s Tomb.

“Agile” development was a peculiar sport played by “software engineers,” a type of indentured servant who made their living by tapping buttons all day instead of taking a real career as a doctor or lawyer (“Engineer” was included in the job title to make them feel more prestigious, in the same vein as sanitation engineers). Agile was created as a form of entertainment for “Scrum Masters,” engineers who had been given special privileges in return for keeping the other engineers in line.

Like other sports from the time, Agile was divided into various phases of game play. Due to the indoor nature of button-tapping and the relatively low amount of energy required to do so, Agile was played year-round. A 12-month long season was separated into 4 quarters, each composed of 6 “sprints.” Whoever scored the most points won the sprint, so each engineer’s goal was to maximize the points per day they got while minimizing the same ratio for their coworkers.

Points were scored by completing grueling tasks. These tasks were called “stories” to make them sound more fun. Each story was assigned a certain number of points at the beginning of each sprint through a ritual called “Estimation.” Each engineer would vote on a number of points for the story, and then from the various votes a single number would be decided upon. Before deciding on a number of points to vote on, each engineer would have to consider:

Each engineer hoped to get stories which were easy for them but still worth a lot of points.

This voting process was called “planning poker,” so named because of the highly psychological nature of estimation. The Scrum Master would say “3-2-1,” after which each engineer holds up a number of fingers equal to the number of points they think the story should be worth. After removing outliers, the story was worth the average of the votes.

A basic strategy then was:

  1. decide if you want the story to be worth many or few points

  2. gauge how many points the other engineers will vote on

  3. vote on a number of points that pulls the average in your desired direction without turning your vote into an outlier

Being an outlier was very bad for two reasons:

  1. It nullified the engineer’s vote. In addition to having no influence on the final worth of the story, nulls were considered unclean by many engineers and required the nullified engineer to work from home for three days.

  2. In order to further humiliate outlying voters, they had to give an impromptu explanation for why they voted so ridiculously. These reasons were expected to be related only to the difficulty of the story, providing outsiders with the illusion that estimation was simply part of getting the job done. But for insiders, the humiliation damaged their ability to influence other engineers in future estimations.

To increase amusement for the scrum master, engineers were restricted to choosing votes that fell in a certain set of numbers called the “Fibonacci sequence,” so called because the estimations were really just fibs.

There were many intricacies in planning poker strategy, most of which fall outside the scope of this article. But one trick taken from professional rock-paper-scissors tournaments was the practice of pretending to vote at the same time as the other engineers but really waiting a split-second longer so that the engineer using the strategy had more information to inform their decision. This was a difficult tactic only employed by experience engineers, as penalties for being caught were severe.

After estimation was finished, it was a race (hence the term “sprint”) to finish as many stories as possible while subtly hindering coworkers. One common tactic was to bring up “automated tests” right before a coworker was about to finish a story. If the other engineers agreed, the coworker would be forced to spend a day in the testing center before marking the story as complete. In the center, the coworker would be automatically exposed to a series of tests, including impossible-to-answer questions like “when will the current project be completed.”

Like the gladiatorial games, Agile was high-stakes. Engineers who won the most sprints would be promoted to “Senior Engineer,” “Epic Engineer” and finally “Chancellor Engineer.” Promotions came with respectable pay increases but also tougher competition. On the other end of the spectrum, a chart was used to keep track of engineers who didn’t finish all the stories they were assigned each sprint. This was called a “burn-down” chart because if the line on the chart reached the upper right corner, the engineer with the highest point deficit would be burned.

Eventually, engineers started to revolt and Agile fell out of practice. It was replaced by a new movement, the name of which was chosen to represent the end of the Agile burn-downs: “Waterfall.”

Got feedback? foo@jacobobryant.com