Originally posted on jacobobryant.com

"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 up a real career as a doctor, a lawyer or an actual engineer. Agile was created as a form of entertainment for Scrum Masters, software engineers who had been given special privileges in return for keeping the others in line.

Like other sports of 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 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 they earned per day while minimizing the same ratio for their coworkers.

Engineers could score points 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 based on the votes, the group would decide how many points each story would ultimately be worth. Before deciding on a number of points, each engineer would have to consider:

• How hard the story was (both for them and for their coworkers)
• Who the story would likely to be assigned to
• How many points they thought the other engineers would vote on

Each engineer hoped to receive stories that 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 and the large amount of bluffing involved. After the Scrum Master gave a countdown, each engineer would hold up a number of fingers equal to the number of points they thought the story should be worth. After removing outliers, the story was worth the average of the votes.

A basic strategy 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 because it nullified your vote. In addition to eliminating your influence on the final worth of the story, nulls were considered unclean by many engineers. Nullified engineers were required to work from home for three days.

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 heighten 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 there was at least one trick taken from professional rock-paper-scissors tournaments: an engineer could pretend to vote at the same time as the other engineers but really wait a split second longer; thus they could see what the other votes were and respond accordingly. Only those with more experience employed this tactic, 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 "tests" right before a co-worker was about to finish a story. If the other engineers agreed, the co-worker would be forced to spend a day "testing" before marking the story as complete. During the test, engineers were buffeted by a series of impossible-to-answer questions such as "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 "Manager." 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 burndown 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 burndowns: "Waterfall."