You probably know that the movie Enders Game was inspired by Orson Scott Card’s visionary novel of the same title. What you probably don’t know is that the novel, written in 1985, prescribed a kind of team dynamic that prefigured the Agile development framework called Scrum in several points.
If you’re not “read in” on “Scrum” methodologies, they prescribe a way for small multifunctional teams to develop projects in short development cycles, with testing and feedback at the end of each cycle.
If you’re not read in on Ender’s Game, “Ender” Wiggin is a gifted child being trained as a military commander in a futuristic “Battle School” where he eventually leads a team of fellow students in a series of mock battles against other teams in a null-gravity environment.
A person looking for correlations between Ender’s experiences and Scrum methodologies might be tempted to equate the series of battles with Scrum’s short development cycles.
But the real correlation is the way Ender changes the teams’ approach to the battles from a hierarchical approach in which team members are not allowed to think for themselves to a more free-flowing approach in which each subdivision has autonomy and members are encouraged to think creatively.
Some of the following examples are in the book but left out of the movie. You may read the book if you want, although I’ll warn you that the disturbing parts of the book are even more disturbing than those parts of the movie. (Also, the book spends a lot of time on the political intrigues of Ender’s slimy brother Peter, thankfully omitted from the movie.)
When Ender first comes to the Battle School, the upperclassmen are divided into teams of about forty children called “armies.” Each army is overseen by a “commander,” and divided into four platoons (“toons” for short). The first commander Ender serves tries to control every detail of every battle plan. But his toon leaders don’t have his permission to respond intelligently when unexpected variables make careful his preplanning irrelevant. In fact, Ender earns his commander’s enmity when he acts on his own to prevent a loss.
When Ender becomes commander of his own army, he divides his army into more, smaller toons and insists that they learn to function autonomously. He also rewards innovative thinking on the part of individuals. (Bean’s use of the rope is the one example that made it into the film.)
The moral of this part of the book is that all the planning and hierarchy in the world is no good if:
- Your subordinates are afraid to think for themselves or respond to unexpected challenges.
- You never look for new and better ways of doing things or give your subordinates room to do so.
If you’re well studied in Scrum philosophy, you already know where this is going. Scrum devotees champion team autonomy and vilify top-down attempts to plan every detail in advance and to micromanage those details throughout the course of the project.
According to Scrum philosophy, even large projects can be broken down into many small pieces, then handled a few at a time by small multifunctional groups working more or less autonomously. In fact, Scrum teams are even more autonomous that Ender’s toons, assigning tasks by consensus within the group, something that would probably break down in the Battle School’s military model.
There is another, surprisingly physical parallel between Ender’s strategies and the world of Scrum. The term “scrum” comes from a rugby play in which the whole team locks together in an effort to move the ball down field en masse. In the movie version of Ender’s last Battle School “battle,” Ender directs his entire team to clump together to guard one member who needs to get through the “enemy’s gate” unscathed, as close to a rugby scrum maneuver as you can get in zero gravity.
In case you have any doubt about Ender’s Game illustrating the advantage of small, autonomous teams and individual creativity over large hierarchies and rigid obedience, keep in mind (spoiler alert) that both Ender Wiggin’s eventual victory against the alien force and that of his mentor Mazer Rackham were possible because their enemies depended entirely on the guidance of a single central intelligence, which was neither infallible nor invulnerable.
By the way, if you’re too upset by (spoiler alert) Ender’s accidental genocide of the alien enemy at the end of the film or Colonel Graff’s casual attitude toward it, you should know that in the book, the aliens have already invaded twice. The second time they would have succeeded in destroying humanity if not for Mazer Rackham’s intuitive assessment of the enemy’s battle strategy. So Graff wasn’t wrong to see it as an “us or them” situation. Fortunately, most projects to which Scrum approaches have been applied are not “life or death.”
It’s impossible to tell at this time whether Orson Scott Card had been exposed to the “Japanese theories of management” that preceded much of the “Agile” movement, including Scrum. It’s just as likely that he’d seen enough dysfunctional hierarchical organizations to make him wonder what the alternative could be. After all, Card’s career as a Science Fiction writer requires him to wonder “what if?”
So, what if the rest of us wondered “what if?” a little more often on the job and not just in books and movies?
More user-friendly articles about Agile topics: