Tuesday, June 25, 2013

Sheryl Sandberg has become internationally famous in 2013 (and even more fabulously wealthy than she was before) by publishing her bestselling book, Lean In. Corporate women everywhere are now encouraged to perambulate on a perpetual forward pitch, which adds even more difficulty to the challenge of wearing pumps every day. One is tempted to accessorize with a rescue helicopter dangling a safety wire.

Awesomely, this is from: http://www.bunionadvisor.com/blog/2012/05/knowing-how-to-walk-in-heels-may-stave-off-foot-pain/

On the one hand, I love that we are talking about equality for women again.

It isn't as though we really succeeded completely before we gave up on Second Wave Feminism, even from a legal perspective. Seriously, the US wouldn't pass the Equal Rights Amendment? What (medieval) century do we live in here?

And clearly, we are even further behind culturally than legally, when we see that women in the US can be making 80 cents to men's dollar in wages for the same job, on average, without laws being violated.

And 20 years after 50% of the annual US college degrees began to go to women, only 8% of corporate executives are women. It seems as though something is still wrong here.

So huzzah to Sheryl Sandberg for ushering in Wave Three Feminism! (or Wave Four, if indeed, as alleged by Wikipedia and others, there has been a Wave Three I have missed, somehow). We are women, hear us roar.

On the other hand, I worry that most of Sandberg's advice is counter-productive for all but a small, select, group of her large reader base. Her book seems just right for top executives like herself, looking to go still higher. But many people who are discussing Sandberg over lasagne at their book club even as we speak are people who graduated from college with high hopes in the 1980s, but who have now been stuck for a decade or two (or three), crawling slowly up through the ranks in middle management positions. For us, the research shows, "leaning in" aggressively is not really going to help very much.

Think for a moment. Sandberg posits that we women are exacerbating our cultural disadvantages by being insufficiently pushy and tenacious. She says we need to:

get our partners to shoulder their share of the housework and childcare,

take our seat at the executive table, and

"not leave until we leave," which is to say, aggressively take on showy new challenges right up until we go into labor.

To whom does this list apply? Women:

Young enough to be concerned about housework and small children, but old enough to be thinking about joining their company's upper echalons of executive management.

Executive enough to be taking on showy challenges, but still taking home a low enough salary that housework and childcare could only be done by nuclear family members, not hired housekeepers or nannies.

Pushy enough to plop themselves at the executive table, but still appealing enough not to be kicked right back to the (large number of) middle management table(s), along with the other thousands of men and women who would like to crash the executive conversation.

If there is an appropriate audience for this book, and you disregard the red herrings about being young and worrying mostly about childcare and housework, the target demographic is composed people who are already executives, and who are looking to move up and become C-level executives or corporate board members. And I'm glad Sandberg has written this book for this market. Women at the C-level and on corporate boards are the least well represented of all.

For the rest of us, however, I recommend a 2011 Catalyst Report entitled "The Myth of the Ideal Worker: Does Doing All The Right Things Really Get Women Ahead?" Catalyst has been working on a longitudinal study of women's careers for more than a decade now, and they issue reports annually with new findings. This particular report shows that women who assert themselves don't actually do better. Findings revealed that:

Men benefited more from adopting proactive strategies.

When women did all the things they have been told will help them
get ahead—using the same tactics as men—they still advanced less than
their male counterparts and had slower pay growth.

What does work best for women? Among the career advancement tactics we
studied, one stood out as having greatest impact. The women who did more
to make their achievements known advanced further, were more satisfied
with their careers, and had greater compensation growth. (A second
strategy was also effective: Women advanced further when they
proactively networked with influential others.)

In other words, don't lean in--lean out! Make your accomplishments known to your boss, your mentor, your sponsor, and your whole network. Agitate for a culture where metrics are public, and actual performance is rewarded at the end of the year, rather than golf course schmoozing. Have a network, and create reciprocal relationships of mutual "amplification." Create a buzz around yourself which is about what you've done, not who you are. And amplify the achievements of your friends, so they can advance too.

Along the same lines, find someone who will do more than "mentor" you. You don't mostly need moral support and a shoulder to cry on. You need a cranky over-achiever who will push you to do better, and advocate you for the big, gnarly jobs at your company that move you ahead. You need a "sponsor." You need a top-level executive, man or woman, who will reach down and pull you up (most likely in a way which is painful to you at the time). And you need to do the same for women in your network who want to come to your level.

Which brings us back to Lean In, and its implied "can do" philosophy, based on one talented woman's singular experience. How can the Sheryl Sandbergs of the world best help women? And if we are all as powerful as Sheryl, in our own way, what should we be doing?

Let me put it this way. How many of us felt a rush of excited sympathy for Sandberg herself, as we read about how she got the head of her company to create maternity parking spaces when she, herself, was heavily pregnant? Or for Marissa Meyer, who took on the CEO position at Yahoo six weeks short of giving birth, and then returned to work two weeks afterwards, so she could be more efficient and quick about her ban on everyone else from working at home? That was hardly a big step forward for women, if we are going to define "woman friendly" as "supporting work-life balance."

I want to reach out to Sheryl and Marissa, as I call them, and ask them to sponsor me, or someone like me, and put me out there to do a crazy-difficult project with a high risk of public failure and embarassment. I'm not as excited to have them further push their model of what they think they did differently. Seriously, as women executives, are these our role models? Or is this the kind of help for women, in the words of Shel Silverstein, "we all can do without"?

You can do it this way. But this method might make you crazy and sad. By the time a hiring company posts a job to their web site, and especially by the time they post to Monster.com or Dice.com, they have committed their hiring process to recruiting professionals who will do agonizingly specific resume screening, word-by-word, on a lot of resumes. Hundreds or thousands.

For each 50 resumes you send out, you will be lucky to get one non-automated response (drafted and sent by a human), and even more lucky to get an interview. Chances of getting an actual job this way are microscopic, viewed in terms of submitting a single resume to a single job posting. Applying by resume is the equivalent of advertising a product by blowing coupons into magazines. If you want to do this, plan to send out a lot of resumes.

What I Think You Should Do:

Figure out what you want to do.

Find some companies where you want to work

Build some marketing collateral for yourself.

Network by asking people for help reviewing and improving your collateral.

When the time comes, and you meet with one of the people you want to work for, tell them you want to work for them.

This is not some kind of scary visualization technique. I'm not going to suggest that you start by reading The Secretand then buy some crystals or something. This is the same advice I give my sister and my friends, and none of us are woo-woo. No offense, Secret-reading crystal users.

I do indeed recommend a book, but it is Orville Pierson'sUnwritten Rules of the Highly Effective Job Search, along with his companion book, Highly Effective Networking. I don't get kick-backs for this--this method simply works really well. This is the method huge corporations use to relocate their executives when they have to get rid of them. Read the books!

But if you don't have your local library handy, and your credit card is overdrawn, so you can't buy it for your Kindle, here's a sort of précis:

1) Figure out what you want to do:
This is hard! That's why you want to just go apply for jobs, rather than thinking it through. Please, please take the time to think this through. You don't have to buy and follow the massive What Color is Your Parachute. That book is probably good, but it is scary.

Faster, use the MAPP Assessment, which was suggested to me by my own career coach, Joe Vranich (who has now moved away from career coaching to business relocation coaching, sadly for you, unless you are relocating your business). Neither Joe nor I get a kickback for this recommendation. There's a free version of the MAPP, but it's worth it to pay for the cheapest not-free one, to get the interpretation of results. It's a 90 question multiple-choice test that will help you translate your preferences into actual jobs that exist in the real world.

As part of this definition process, please develop an "elevator pitch" that quickly describes your planned next job. This is a single sentence that describes what you want to do, and at
what company. It should be something like "I'm looking for a
Director-level position in a mid-sized software company, where I would do mostly
management, but could still be hands-on." You want to be able to rattle
this off whenever anyone asks.

2) Find some companies where you want to work:
This is hard too. But if you know what you want to do, it's just a matter of research. Make a list of 40 target companies who offer the job you want to do, and who meet your other criteria: location, non-bullying policy, benefits, salary, etc. You can research this online and get help from reference librarians at libraries. You may rule some out and add some new ones as you go, but make sure you are spreading a wide enough net, and keep the number of potential employers up around 40.

3) Build some marketing collateral for yourself:
You will feel tempted to hire a professional resume writer, and maybe join a site like "TheLadders," or post a request on "LinkedIn." Emotionally, this may be the best you can do right now, but none of these are a good idea.

As soon as you can do so, make your contacts with future employers in person, not via written materials. But you do need those materials.

Build a resume. I can't give you the format. Some random professional resume writer can't either. Don't hire them! Instead, find a person who does the type of job you want to do, get them to give you a soft copy of their resume, save under a new name, like "my resume.docx", and put your information in, replacing theirs. I got invaluable help on my resume from Drew Jemillo, for example. Thank you, Drew!

Build a LinkedIn Profile. Take the time to fill it out with all of your accomplishments. Again, in a pinch, copy your role model, disguising the copy well enough so that you won't look like some kind of weird stalker.

Build a one-page handbill. This is trendy, but good. It's a thing to use instead of a business card, but which is less imposing than a full resume. Here is a sample, which to me, errs on the side of too wordy. But you get the idea. Print a few of these out, and carry them with you, so you can give them to people.

Get business cards made. You can go to a web site and design these, which is totally fun. Include your cell phone number, your email address, a link to your blog if you have one, and the address of your linked in profile. You want to be able to hand these out when you meet people. Old fashioned but true. Here's a sample.

Build a list of accomplishments. I originally put this first, but I actually built the resume first and then harvested the list from that, because I was anxious to get going on something real. Do it either way. The point is that these are the building blocks of all your other collateral. Make sure that all of your collateral is built out of accomplishments from this list, vetted for maximum power. This should be a series of statements in the format:

<power verb> <immediate object of your power verb> with the result that <eventual measurable result>

People will always tell you to "network," which is very irritating, because it can cause you to picture yourself pathetically cold-calling some major executive and begging for a job, using the words "desperate, children, retirement, and/or mortgage."

From http://www.rainsalestraining.com/blog/cold-calling-objections-overcoming-3-common-ones/

It doesn't need to be like that.

Here are four magical words to use on your friends, and, as your network grows, on their friends: "I need your help." Start with your closest friends and the family members who like you, and take them to coffee (or beer, if they're more beer oriented). Start with your elevator pitch, and then ask them to go over your collateral with you and make suggestions. If they know people you should talk with further, ask them to introduce you. People will give great suggestions about things to change about how you market yourself, your dream job, and your list of companies. And they will generally be glad to help by introducing you. What goes around, comes around.

Until you meet the person who would logically be your ideal next boss, at each target company, you don't ever need to utter the words "can you hire me?"

After each meeting, send an email thank you or an actual postal letter if it is warranted, and attempt to link the person in on the LinkedIn site.

Oh, and speaking of LinkedIn, if you don't normally introduce yourself to people for the first time using social media, don't start by trying to introduce yourself to contacts at a new company through LinkedIn. This is not a group to practice on, if you are awkward at all. If you're great at making friends online, then you'll be fine. Otherwise, reach out on LinkedIn only to people you actually know. If you want to meet someone through a person you know on LinkedIn, ask that person in a normal email if they could introduce you. Leave LinkedIn out of the work flow, except to record people you have actually met.

Orville Pierson's book is mostly about setting targets for yourself, in terms of how many people you talk with, and how many of those are in a position to hire you one day. So if you're this far along, you should definitely get his book! One of the keys to non-crazy job hunting is to treat it as a project, and review metrics, instead of lurching from one potential job posting to the next, thinking each one is "The One."

5) When the time comes, and you meet with one of the people you want to work for, tell them you want to work for them.
Normally, you will have plenty of time to work the kinks out of your networking techniques before you meet with the first person who might eventually be your boss. Even so, the "interview with a person who could hire you" is different in kind from the previous meetings, which have been focused on getting you to talk with someone who might be a good boss for you.

Orville Pierson's book has great news, which is that on average, you
will need to talk to about 25 potential next bosses before you will find
the job you have been looking for. That can take a while, but it's a
finite number, and once you have gotten going, it's just a matter of
following your script and doing the legwork. Using this logic, the odds
of any given "decision maker" who could hire you offering you a job on
the first interview are less than one in 25. This means that you don't have to
put all of your emotions into the discussion. It's always best to be
non-hysterical, to make a good impression.

You can, however, use most of your standard networking technique for this meeting. Thank the person for taking the time for meeting with you, give your elevator pitch, explain why you think you could contribute a lot to their area of influence at their company, and let them know you're interested in working for them, if they should have the need for someone with your skill set and interests.

All of this should take 1 minute or less. Please make sure you get THEM to talk more than you do. If they don't need you right now, or if they dislike you (some people will, statistically), then thank them graciously, leave some collateral behind, send a thank-you note, link them in, etc., and move on. Or call to follow up every few months or so, if you're invited to do so.

But here's the important part. If they have a need to create a position for you, they will tell you that. If they say they're going to do that, then make sure to say "I want that job! What can I do to help convince you?" This is not the time to be coy. It is not over-eager to be enthusiastic. Do not flub on the doorstep of your dream job. If you see your dream materializing, say so matter-of-factly, and jump onboard.

Thursday, June 20, 2013

Are you new to the testing concept, or the "quality" concept, as I've learned to describe it? I'm still learning, myself. You may have seen some previous attempts, but I'm happier now. Here's the framework I've devised most recently to help express how I think you need to design and implement agile quality tactics. Your mileage will of course vary. Experienced quality people please jump in and help me, where I've gone completely off the mark!

Step 1: Know what to test. This can be a metaphysical question, but our friends at ISO have come up with a good practical starting point, code named SQuaRE: Systems and Software Quality Requirements and Evaluation, aka ISO 25010. It has 31 separate quality dimensions which roll up into seven "non-functional" categories, and one "functional" category.

From http://a2build.com/architectedagile/Architected%20Agile.html?ISO25010.html

There are many quibbles out there about whether the ISO categories are
the right ones or not. If you have a better set of categories, I say, use it, and
tell us about it! But for most of us testing novices, this is a real
eye-opener. Many of us may have thought "testing" was a synonym for "functional
testing." And here we find out functional testing is only the tip of
the iceberg. Holy value burn up!

Step 2: Decide how much to spend on testing, and where to invest that money, based on expected ROI for each of the dimensions. Each of the 31 ISO dimensions translates into a different level ROI for your project, and those ratios are not fixed. Security testing on a system protecting trillions of dollars has a bigger ROI than security on a site that lets you draw your favorite Pokemon character. Performance matters more for real-time systems guiding brain surgery than for systems tracking glacial melting. Here's a handy chart to help you think about it, showing only the high level dimensions. It is worth it to consider the 31 individual dimensions in detail, but this chart is huge enough as it is, and you get the point!

ROI-based Tactical Quality Plan

Dimension

ROI Will Be Measured In Terms Of

Technique

Cost

Who Delivers This

Portability

Cost of delayed deployment or failure due to browser incompatibility

Investment in setting up and running Continuous Integration tools, and setting up multiple platforms for testing. (Tools such as Hudson or Go)

Cost of awkward patterns of use to operational users or online customers

Usability design and testing techniques

Varies with tools and techniques chosen

User Experience Owner for project--may be called "design" or "analysis" or architecture

Functional Suitability

Value of software continuing to deliver on business strategy over time

Functional tests enshrined in a reusable regression set, described in detail below

Varies with tools and techniques chosen

Functional testing group leadership

What a big table! I've indicated the type of cost and ROI you may incur--for home use you will want to put actual net present value figures into the box, and potentially even actual dollar values at different project milestones, to understand needed investment and expected timing of returns.

Step 3: Determine which person with P&L responsibility sponsoring the project owns quality decision making, and arrange for them to keep an eye on quality throughout the duration of the project. I hope the scary table above has suggested to you that quality ownership of a project requires a point person who:

Knows how much money (or other desired benefits) the application is going to accrue for its host company, and based on what.

Is available to evaluate the competence of the experts who will be implementing tests in each quality dimensions, and the techniques they choose

Is powerful and knowledgeable enough to demand "project health readouts" from some kind of dashboard on a regular basis (certainly as regular as the functional views into the software the "product owner" gets from attending standups and end-of-iteration showcases). And these readouts need to be on each of these dimensions.

Quality ownership, in short, is a vital part of product ownership, from a software development perspective, but it is difficult to imagine one person able to be expert on all of this at once. You may need to organize a single "Quality Czar" for a large project, shared across workstreams, or a quality person for your whole company or division who can keep an eye on the dashboards of multiple projects at once.

Step 4: Decide how to test functionality. Aha! You say. Now we're in familiar territory. Well, yes and no. Functional testing itself has a number of dimensions including:

How are you measuring value accrued through deployment, as opposed to "absence of defects?" As Jim Highsmith frequently points out, software delivers value. It doesn't merely deliver functionality that meets some minimally defined need. There is a feedback process in every software development endeavor in which decisions can be made to change the way the software works to add additional value at equal or lower cost than doing what the product people initially suggested. How do you plan to track the up side of functionality delivered as well as the things not delivered or the things broken?

What is your test data strategy? (Do you just build out a masked copy of last quarter's production data and tinker with it, or do you script synthetic data to allow for rigorous control over the tests, even at the developer level? Who curates the data, and how do they do it?)

When do you want to develop the functional test scripts, relative to building out acceptance criteria and building the actual software that delivers project value? (The default in waterfall is that you start immediately after development, at best. Agile allows you to have testers work with analysts to build automated scripts immediately prior to and during the software development cycle, working directly with recorded software acceptance criteria)

When do you want to run the scripted functional regression tests, relative to software development? (Your default is likely to be that you first exercise the scripts when development is finished, and the code has been deployed to a "quality" environment which is protected from the developers. Behavior Driven Development tools such as Fit, Fitnesse, Lisa, Concordian, and Cucumber allow you to run the tests, complete with temporary deployment of just the data needed for each test, as part of the build cycle, pushing almost all tester activity to the front of the SDLC instead of the end).

When do you want to exercise the functional regression tests, and how often? If your testing is manual, that requires a period of code freeze at the end of each software development sprint to allow the testing to occur. If you have automated BDD testing, at the other end of the automation spectrum, you can be testing and developing continuously, as frequently as with every check-in.

How much scripted testing do you want to do manually, on an ongoing basis? You may not start your agile project with a set of veteran functional test automation experts. You may need to build a plan for gradually phasing in more automation as you go, and as your team picks up the skills. Some things may always need to be tested manually, because the automation would be more expensive than the number of manual tests which need to be run on that area of software over the lifetime of the product.

How much exploratory testing do you want to do without a script, on an ongoing basis? In a world of reliable automation, where all high-value business functionality is covered by an automated functional test, you have the luxury of deploying your test analysts primarily to do creative "break the code" efforts, which may lead to additional automated tests. Contrary to what you might think, exploratory testing should increase, not decrease, with an agile project that uses a lot of test automation.

What gets tested by professional testers, and what constitutes "user acceptance" by actual customers or operational users? Some organizations define "user acceptance testing" as having a group of professional testers paid by the "business owner" of the software re-run the scripted tests built by the "technical owner" of the software. For both waterfall and agile, this seems unnecessary, if those scripts are high quality. True "user acceptance" testing should be done by...users.

Operational metrics for ongoing analysis. How much metrics gathering do you want to build into the software itself to be run operationally, and to provide ongoing usability and frequency of use data to drive subsequent versions? Waterfall and agile projects alike may want to take advantage of the "feature toggles" concept coming out of the Continuous Delivery movement, where different versions of the software can be toggled on or off through environmental variables, to compare "A" and "B" usage scenarios.

Step 5: Build your quality tactics into your agreed upon and/or written/posted software development life cycle artifacts. Your decisions about testing impact some of the standard operational rules your team makes for itself at the beginning of the project:

Your staffing model. Traditional teams use a "rule of thumb" about the ratio of developers to testers and analysts (say 2 developers per tester, for example). A full quality strategy at the departmental, program, or project level makes that type of staffing rule of thumb too crude. Who does test case design and scripting? Who does automation? Who does performance and security testing? Who plans for computability and usability. You need to know your quality requirements before you can plan who to staff on your project. If you haven't thought all these dimensions through, you're staffing in the dark, and unpleasant surprises await you.

Roles and responsibilities of team members. On a related note, people's roles on the team may not match what they're used to. A functional tester who merely exercises scripts may be a person you don't need any more. An analyst who designs scripts is someone you need very much. People who automate test fixtures in addition to developing business functionality need to be found somewhere--is that a development responsibility, or do the functional test people own that set of automation tasks? What is the responsibility of your overall architect or security person, and what fraction of their time do you need?

Definition of done for stories. In a multi-dimensional quality world, your software may not literally be "done done" until you've run a battery of performance and security tests against your code base. In many environments, you may find that those performance or security tests can't be run for every iteration. As a team, you will want to understand what the constraints are on what can be tested, and create a team "definition of done" which includes all testing actually under the team's own control, and which excludes steps that require help from outside organizations.

Story development life cycle. The "life of a story" for your team should account for all of the tests that will be run, and indicate when they will occur, relative to that story.

Check-in, build, and automated deployment schedule. The need to test more than just functionality may drive you to a more aggressive continuous integration/continuous deployment strategy than you might have had otherwise.

Extended story (or "narrative") template. For small, collocated teams, stories may be nothing more than cards with jottings on them to serve as the occasion for conversations and test development. For larger teams, teams within large programs, and teams which are geographically dispersed, the team may develop a template for what needs to be "extended" in the story, beyond the basic "as a...I need to...so that" (or alternate) story format. In a regulated environment, the written form of the story may require reference to a central "NFR testing" document which speaks to the non-functional testing the story requires from the development or business resiliance or security teams, in addition to the functional acceptance criteria.

Step 6: You need a project health dashboard. There are a lot of metrics your automated tests can collect for you, in addition to the financial data you have available, and the data your card wall can give you about progress against goal. You do not want to be sifting through hundreds of disparate documents.

For a single collocated project, it may be enough to set up a lava lamp to glow red when the build fails. For a larger endeavor, however, like governance of a whole business, a line of business, a program, or a department, you will want to think through your dashboarding strategy, and plan to be able to plug each project into it using all of the measures which contribute to all of the financial and progress data, along with all 31 dimensions of quality.

Step 7: You need to pay attention. All of this effort is meaningless if you're not running a healthy project in the first place. In a world of lies, damn lies, and statistics, no dashboard in the world is going to substitute for proper respect, two-way communication and support for the teams on the ground.

Counter to what you might expect, if the data is presented in a helpful way, people love working in an environment where things about their performance are measured automatically, and they can use the feedback to improve their game. Individuals and teams can treat their job as one big video game, and keep trying to be the one to get the high score. That concept alone, (plus the seven steps, plus an army of experienced testers), is the key to successful agile quality practices.

Wednesday, June 19, 2013

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.

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!

Friday, June 7, 2013

I was speaking with a group of fellow would-be agile change agents last week, and one of us described "the opposite of agile" as "mortgage driven development." Of course I found this funny and apt, and I looked it up online, where I found Jason Gorman's tongue in cheek manifesto for the MDD movement online:

We are uncovering better ways of making money from
software by doing it and hindering others from doing it.
Through this work we have come to value:

Timesheets and invoices over principles and ethicsUnmaintainable software over clean codeContract renegotiation over a barrelUnlimited overtime over a sustainable pace
Contracts that fall outside of IR35 over and over again

But as I reflected on the matter, I realized I would prefer to describe the above manifesto in terms of "Marauder Driven Development" instead, if we must have a straw man abbreviated to MDD. Our enemy isn't mortgage-holders with their desire to maintain a stable
family home, or even normal climbers of the corporate ladder who are most concerned about hanging on to their maid and their boat. The real enemy is the kind of arrogant short-term thinker who lives in corporate housing and doesn't even unpack her bag, except to send wrinkled clothes to the dry cleaner.

Unlike, say, the phrase "mortgage-backed securities," "mortgage" is a word with strong emotional pull and a relevance to real people who think in terms of life-long responsibilities, careers, and families. "Mortgage-driven people," loosely defined, are our our best agile allies, and their
similarities to the marauders implied by the MDD manifesto are quite
superficial. They do not deserve our scorn! Scorn at the "mortgage" orientation implies that "real agile" is too proud to consider money making, because it is focused somewhere unsullied by the profit motive. Turning our noses up at money is all well and good, but that attitude and a dime (and a time machine) will buy us a cup of coffee. Our richest target market segment, if we intend to make money by being self-identified agilists, is "Mortgage Driven," and there's no point in alienating these people unnecessarily.

Why do companies hire us?
To spread credit (and especially blame) fairly, I must say that this is a question I was privileged to discuss with Jake Calebrese, Russ Miles and Ahmad Fahmy last Friday (follow their blogs!). One thing we agreed was that if we want to figure out how to change the world through value-driven agile techniques, we have to recognize that we aren't hired by companies. We are hired by people. So railing in general against "the machine" isn't a practical marketing approach.

Since we are hired by people, we need to understand how to to motivate them, as Aristotle would say, in terms of logos, pathos, and/or ethos: logic, emotion, or social pressure. Or as Dan and Chip Heath would say in their book Switch: How to Change when Change is Hard, we need to motivate the rider and the elephant, and we need to prepare the path. (Read the book!) Okay, you say, then:

Why do people hire us?
The moral awesomeness of agile isn't enough for most people. "Awesome" doesn't overcome people's even deeper allegiance to "avoiding change." Picture this in terms of Maslow's hierarchy of needs:

A client who is can be motivated by our moral disapproval is unlikely to show up waving her checkbook at us for several reasons:

This person would be coming from the very top of the pyramid, not, perhaps the most populous segment to pick, if we're picking one. Look at the pyramid and compare it to your life experience. How many people with true profit and loss responsibility make decisions first about morality or the respect of others in complete isolation from expected return on investment?

A person in this happy place is likely to be able to adopt agile on her own if she wants to.

Seriously? Would you seek out someone who has just morally disapproved of you as a client? In other words,

Such a client doesn't exist.

Good-fit clients are doing household maintenance of some kind
A whole slew of people are likely to be interested in doing a controlled agile transformation over 3-5 years because they think they might otherwise be standing on a burning platform in
the foreseeable future. Perhaps they have aging infrastructure they
want to replace in an orderly way. Perhaps they are concerned about a
trend towards increased regulation, and want to avoid future surprises.
Perhaps they are "ripe" to be promoted to the next level in the
hierarchy in a year or two, and they want to show off. They're
intellectually curious about agile, they are thinking about the future, and they're also powered by the
understanding that even though their platform isn't burning, maybe it is
smoldering.

Our "best fit" clients are motivated by mortgage-style concerns.
Our most promising potential clients are people with a genuine problem to solve which is the emotional equivalent of "if I don't do this, how will I pay the mortgage"? They would include corporate employees who have responsibilities to fulfill and choice about how to use their money to fulfill those responsibilities. The agile metrics story is logical to them, but the emotional appeal
speaks straight to the "fight or flight" impulses in their brain stems.
They have some kind of burning platform:

Continued employment requires a change: These people need to improve their metrics around quality, speed to market, transparency, and customer satisfaction annually or else. The "S curve" will eliminate them if they are a "bottom performer." "Not moving forward" is the same as "fired" for these people. And then how will they feed their children?

Continued viability requires a quick release to market: a person may develop a sudden and unprecedented interest in agile if she is facing a normal software development life cycle that takes 12-18 months, but she has a 3-6 month opportunity to be first to market with a new product, or even to be a fast follower.

Continued reputation and hireability into the next job requires a project to be rescued: if all else fails, try something new, our prospective client may feel. Better to be agile and succeed than do business as usual until one is requested to fall on her sword.

I guess in Japan it might have been a real sword even quite recently, but in most 21st century cases today, even if the sword isn't real, our best potential clients have an emotional aversion to it which goes quite deep.

Either way, the point is that most of the visceral, emotional energy that leads to an initial engagement can be described beautifully by the words "mortgage driven." It's about making money, but unlike other candidates like "Cash Driven Development," say, or "Loot Driven Development," or maybe "Pillage Driven Development," for me, "mortgage" brings to mind people here in the the US over the past few years who lost their homes when they couldn't afford their payments, or people who are grateful every day that they were able to keep up. So if that's Mortgage-Driven Development, sign me up!

About Me

Elena is a Principal Business Architect for ThoughtWorks, London. In this capacity, she focuses on transforming business architecture to better support digitally enabled retail clients. Prior to ThoughtWorks, Elena was a Program Manager and Chief Agilist for the Treasury Services vertical at JPMorgan Chase, followed by projects which measurably improved scalability and productivity in IT processes for the Corporate and Investment Bank (CIB) and the Consumer and Community Bank (CCB). In addition to business architecture, Elena’s areas of professional interest are value chain mapping, change management, and non-annoying IT productivity strategy and measurement tactics.