An Ironic History of Agile

Jacob O Bryant

Reading time: about 5 min

Topics:

Behind The Scenes

In this week's post, we’d like to take a step back from our usual topics and provide a brief history lesson from one of our resident engineers-slash-aspiring-anthropologists. Original source. “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 co-workers. 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 co-workers)
Whom 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. The Scrum Master would say “3-2-1,” after which each engineer held 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:

Decide if you want the story to be worth many or few points.
Gauge how many points the other engineers will vote on.
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 several reasons. First, it nullified the engineer’s vote, eliminating their influence on the final worth of the story. In addition, nulls were considered unclean by many engineers and required the nullified engineer 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 to see what the other engineers’ 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 co-workers. One common tactic was to bring up “automated 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 in the testing center before marking the story as complete. In the testing center, the co-worker would be automatically exposed to a series of tests, including 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 fired. 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.” Think Agile sounds fun? Join the team!

About Lucid

Lucid Software is a pioneer and leader in visual collaboration dedicated to helping teams build the future. With its products—Lucidchart, Lucidspark, and Lucidscale—teams are supported from ideation to execution and are empowered to align around a shared vision, clarify complexity, and collaborate visually, no matter where they are. Lucid is proud to serve top businesses around the world, including customers such as Google, GE, and NBC Universal, and 99% of the Fortune 500. Lucid partners with industry leaders, including Google, Atlassian, and Microsoft. Since its founding, Lucid has received numerous awards for its products, business, and workplace culture. For more information, visit lucid.co.