Skip to main content

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!

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica