Fire Emblem Agile: The Pair is the New Individual

Like so many of you other senior agilists out there, I'm currently playing the latest entry in Nintendo's "Fire Emblem" series, Intelligent Systems' "Fire Emblem Awakening" for the 3DS (henceforth "FEA")  And I'm sure I'm not the first to notice the wonderful insights FEA provides on Agile software development!  But humor me as I spell it out a little bit.

Free!  Fire Emblem Awakening wallpaper from Nintendo:  http://fireemblem.nintendo.com/downloads/

You may not have focused on this aspect of the game when you played it, but the essence of FEA is that the power of the team grows exponentially based on skill with which you, the player, build out the pairing between those characters using the game's new duel system in which you fight cooperatively with nearby comrades.  (This would be in addition to the game's "marriage" system, first introduced with the fourth game in the series, Fire Emblem: Seisen no Keifu, released for the Super NES system in May 1996. During the game, characters fall in love and that pairing causes their children's abilities to change.)

Obvious Similarities between FEA Gameplay and Agile Leadership:

• Your role:  Just as your employer sets you loose to guide teams in building valuable working software, FEA makes the player responsible for assembling, investing in, and coordinating the actions of a team of heroic characters who pursue an important quest involving a valuable artifact with some missing jewels gouged out of it.  
• Your team's diverse base classes:  Just as an agile team has what you might call "base classes," which is the capabilities and labels bring to the team:  developer, tester, analyst, scrum master, product owner, etc., FEA offers a selection of character classes, like troubadour, myrmidon, or pegasus knight, each with its own basic strengths and weaknesses.
• Team member career progress:  Just as agile team members may move up from their base class to senior or lead level, based on how things go at their annual review, characters in the game can gain experience and be promoted to valkyrie, assassin, or dark flier.
• Team acceleration through experience:  Just as your agile team gets better as individual members become more experienced, FEA offers game play where the team members are able to battle progressively scarier 3D monsters as they "level up:"  originally you might battle bonewalkers, and then as you get to be more senior, you can successfully deal with wights.
• Winning:  in FEA, as in agile, winning is experienced as a team state, not just the accomplishment of one individual hero.

Less Obvious, But Crucial Implications:  as you know, from the first, the Fire Emblem series has been a sort of cross between a "simulation," in which you as a player interact with a simulated world, and a strategy game, where you as a team leader guide your group to success through appropriate choices about who to put into each battle, and where to position them.  This new entry in the series has polished up the personal interactions between characters in the game to heighten both aspects of the game play.  Here's FEA project manager Masahiro Higuchi, describing the game in a 2012 interview:

I think the essence of Fire Emblem is in how the ties between characters—the character's conversations and worldviews, the friends and lovers and parents and children—connect and form a big group, and you sense how all the characters are living and participating in the game. As the bonds between the characters form and the conversation increases, you want to have more and more conversation. On the other hand, I think the essence of Fire Emblem is how you can enjoy a game with the tension of a sim.

Implications for software development teams?  I'll provide four:

1.  As modeled by FEA, team trust is built through an additive series of parallel, successful, one-on-one pairings of team members:  FEA introduces a "dueling" system in which you collocate two or more characters for the purpose of a battle, and they gradually build trust by working together, and they work better together as they build trust.  I'm sure Intelligent Systems has a table somewhere that measures the trust between game characters numerically, because how else could they know when to show the little heart icon?

The numeric measure of personal trust is not possible  to measure on software teams, so far as I know, at least the ones who object to wearing those Borg-inspired implants, but we real-world agile leaders should keep the principle in mind: 

• "Trust" is not a gimmick you build by locking people in a darkened room and making them play childish games involving noses, balloons, a rope maze, and a flashlight.  
• In software development as in Fire Emblem, trust involves two or more people solving a difficult real-world problem together and gaining mutual respect through the collaboration.
• Further, "team trust" isn't something you build from the top down.  Multiple one to one trust relationships can be built simultaneously through virtual or physical collocation.

2.  There is no substitute for side-by-side success in building individual and team trust:  In the clinch, in a close combat situation, FEA is designed so that your team may win a close battle solely because in multiple skirmishes within the battle, individuals jump in and help each other to overwhelm an opponent too strong for one person alone.  If you haven't taken the time to pair your characters in multiple battles before, they watch each other with feigned interest during battles, and many of them die. And if you're not playing in "Casual Mode," they're really dead--they don't come back to fight again once the battle is over.  Enough said, from an agile perspective.

3.  Teams win or lose based on invisible bonds, although they can only be measured by their actual results:  Fire Emblem Awakening calculates whether you have won or lost a skirmish based on objective factors like "did your tactician plus your great knight have enough combined magic power and brute force to beat the evil Aversa, or do you need to get a little more experience under your belts?"  If not, you lose.  Nobody is dropping in on your FEA team to do a little "mood audit."  Nobody cares.  And yet, the overall level of comradely sharing of burdens makes a decisive difference.  Not to stretch the parallel too far, but in software development, it is definitely empirically true that you will get your most predictable and high-quality results over the longest time period from a team which develops a pattern of repeatable success through repeated and disciplined pairing.

4.  The pairing doesn't have to be all uncomfortably self-conscious:  FEA has two "pairing" modes for game play.

• "Support mode" gives you the ability to drag and drop one character's icon over another's to create a relationship which lasts until you explicitly break the two up.  (You drag Lisse over Frederick, for example, and then in each skirmish, she can use her wand to zap the monsters Frederick doesn't wipe out with his axe).  Characters in a "support" relationship do everything as a pair--they move together, they battle together.  They get one shared turn with one character driving and the other one chipping in.
• You can also just simply place one character next to the other one on the board, and they will work together just as though you had formally paired them, simply based on collocation.  This allows you to create low-overhead combinations of pairing throughout a battle without worrying about who already knows who, and what they do.

Agile "pairing" has gotten a little bit of a bad rap, because people think of the practice narrowly in terms of two developers at a special "pairing station" with one shared monitor and two keyboards, breathing the same air, and one doubtlessly dragging the other one down.  Like FEA characters, agilists tend to be self-confident and other-doubtful by nature.  As FEA models, you can benefit from both types of pairing:

• Formal "pair programming" in which developers take turns seeing the big picture and building out the next stage has been proven to create high quality code with a built-in "code review" more comprehensive than what you can get by making some poor architect read through pages and pages of code later on.  Late at night.  While eating vending machine food.
• A team that works together has constantly shifting "pairs" which build relationships very effectively as well.  And the collocation doesn't have to be physical.  I have solely worked with non-geographically-collocated teams over the past five or so years, and the crucial bond is built through the pattern of collaborative shared victories, not shared spots at a rickety table with Diet Coke stains on it.

So there it is.  I do apologize again for bringing these obvious similarities to the page this way.  They are clear to all who love agile leadership and Japanese turn-based RPGs for the Nintendo platforms.  Although I can't be the first to notice, I'm still hoping to be the first to blog about it!  If I'm not--don't tell me--I'll be devastated!