...copyright Elena Yatzeck, 2010-2017

Thursday, December 5, 2013

3 Reasons Agile is Best in Cynical, Cutthroat Cultures

As agile divas coaches, we are prone to think things like:  "agile is never going to work in a company [like this one] with a horrible, toxic culture. [but I will take the money and give it a shot.  What the hey, it's job security.]."  In fact, "company philosophy or culture" was one of the top two "leading causes of failed Agile efforts" for the 2008, 2009, 2010, 2011, and 2012 "State of Agile" Surveys administered by the Scrum Alliance.  And I don't think the 2013 results are out yet.

One pictures the coaches of the world flouncing around in art deco silk wraps and soft curlers waving our collective hands and wailing things about "not being able to work under these conditions!"  It's poison I tell you, poison!
From the excellent http://www.theculturedoctor.com.au/blog
But let's turn the question around.  If we, as agile coaches, have a preference to work solely with small groups of (kind) super-geniuses in converted warehouses which have bean bag chairs, and everyone is playing the dulcimer all the time, let's own that as a personal preference, but let's not build it into a whole theory we force on others.  And by the way, how many real-life companies have we coached at that turned out to be Nirvana?  Were the bean bags in the break room a lead indicator for anything except germs from people who drool while they are napping?  The Intelligencia coffee is free, but it isn't decaf.  Nobody cleans out the refrigerator. 

Let's stop asking "what my company culture can do (or not do) for agile," and ask instead, "what is the best business option here?"  Nine times out of ten, the best option will be to apply agile philosophy and methods, and not just the superficial ones like "stand up meetings" and "burn down charts."  Politically challenging organizations are especially good places to set up teams to self-organize into a state of extremely high productivity using our best techniques--sustainable pace, evolutionary design, refactoring, continuous delivery pipelines, real options, feature/behavior driven development, deploying from trunk, and especially information radiators even including bullhorns that go off when the build breaks.

Why, you ask?  Three reasons:

1)  Productivity.  Most techniques under the agile umbrella can be deployed independently, one at a time, and they can provide proven results in terms of productivity, quality, total cost of ownership, speed to market, awareness of risk, controls, and so on.  Embrace cafeteria agile!  Automated testing.  Automated build and deploy.  Virtualization.  Collocated kick-off workshop to align on scope.  Attending to intrinsic code quality.  Suss out your client's perceived pain points.  Make a case for what practices you suggest to fix those things at lowest cost to them.  Coach those practices for the allotted time to confirm you were right.  You have created a benefit in a challenging environment.  And that's a good thing.

2)  Skills.  Regardless of how you feel about the people at your organization when you talk about "the culture," at the end of the day, the enterprise is comprised of a group of people who have a variety of motives for the engagement.  Proper agile coaching provides every participant of your engagement with something new to bring to work each day, whether here, or at their next job.  Sometimes it's best to stop looking so hard at the forest and start hugging individual trees.  Coach those people.  You have allowed some group of people to feel more excited about their work.  And that's a good thing.

3)  Power.  Bottom line:  knowledge is power, and agile delivers knowledge frequently, at high fidelity.  You have a unique product to sell here.  In cynical, cutthroat cultures, the survivors who have clambered successfully to the top board and executive positions are especially hungry for information which is spin-resistant.  Facts are rarer than diamonds in waterfall enterprise software development:
  • Except at release time, it's anyone's bet about what is going to happen.  If you have a project which will take 12-18 months from requirements to completed software, and you launch one of these every few months, you are making a series of expensive overlapping long-term bets.  You can use phrases like "earned value" all you want, but that's just a fancy way of saying "we're halfway through the requirements period, and we're looking good."  How good?  It depends on how fast the requirements are changing in the background, how well the desired functionality is passed from hand to hand inside the development group without losing fidelity, and how lucky the team is in terms of estimated effort compared to actual.  And it depends especially on how well the stakeholders spin the tantalizing hints of information they have available.  In a company with a major release 4 times per year, an executive with responsibility for waterfall projects knows something tangible 4 days out of 250 working days, once after each release.
  • Even at release time, "what happened" is up for debate.  The discussions at release time are not typically "what revenue streams have we opened up" or "what operational savings have we made."  Those discussions will happen months later after everyone finishes figuring out whether the problem was "the requirements were wrong" (business stakeholders fall on the knife) or "the estimating was bad" (IT takes the fall).  Then the people who have to make the partially finished software meet their needs figure out the manual workarounds, and everyone goes back to working in the dark until the next release. In a waterfall world, most stakeholders spend most of the time in the dark.  In companies running even one agile project well, outcomes and productivity for that project can be measured tangibly and accurately the majority of the time.
At every level in an organization delivering waterfall projects, executives live in a perpetual "prisoner's dilemma" of bluffing, finger-pointing, and turf protection.  From a pure game theory perspective, stakeholders who can base their message on more provable facts have more options--bluff or tell the truth?  When to tell the truth?  Let someone else really dig themselves a deep hole, and then sweep in with a surprise which is no surprise to you, the messenger?  This is powerful stuff, even when we as coaches do not see teams broadcasting their progress to each other with big posters over every cube.

So stop being such a wuss.  Embrace the challenge.  Own the factual changes you can create.  Own the techniques you can bring to the people who want to hear about them.  And own your ability to bestow actual power to your clients, and the value that power brings them.  In the end, this is the only way to measure your effectiveness.  And seriously, wash your hands after occupying a used bean bag chair.  It's flu season.

Sunday, November 24, 2013

Don't Just Conform: Harness the Power of the Surprise Attack

I was privileged to hear Sallie Krawcheck speak last week at a Chicago meeting of a women's networking organization she co-owns, called 85 Broads.  Those of you who are interested in women's networking should definitely look into this organization.  And the rest of you should please keep reading, because this is not going to get all hissy--there's something for everyone!

From http://crossroadsworshipteam.com/uploaded_images/Suprise-attacks-748698.jpg
At the 85 Broads meeting, a young African American woman stood up and asked Sallie, "what if nobody wants to network with me?  I don't look like anyone else I meet in my male-dominated industry."

Krawcheck, who has made a phenomenal career out of building relationships with sponsors and coworkers, responded brilliantly, saying that people from any minority group within their work environment need to proceed with caution. Paraphrasing, Krawcheck's suggestions were:
  1. Understand the unwritten rules and work within them.  They are not fair, but they are real.  In most of corporate America, it's okay for an older male colleague to go out for drinks with a younger male colleague, but if he goes out with a female colleague, that will create gossip.  It's okay to go out for drinks with the guys, but don't get drunk. And so on.  Ignoring the rules doesn't change them, and simply hurts you.
  2. Look for, and embrace sponsorship.  As Sheryl Sandberg says in her cultural explosion of a book, Lean In, what you need is not a mentor, a person to give you advice.  Ultimately, what you need is a sponsor, a person who will put you into high-prominence assignments to show what you can do.  As with a romantic relationship, "envisioning" your next sponsor won't conjure that person up out of thin air, but if you think through what you want, you will be faster to see and reach out to a potential sponsor than you will be if you just keep your head down and hope to be discovered.
  3. Experiment with the techniques you have for self advancement, and use the ones that seem to work.  Sallie describes being the only woman at the table countless times and using humor to build relationships--embracing the group, not just self-deprecatory!  Or, she said, she created a pattern of waiting for a pause in the conversation and suggesting something good with the opening, "what if we look at this a little differently?" 
These suggestions, which are wonderful, triggered a final one in my mind which I wanted to put out there explicitly as well, although sadly I can't take credit for this one either--I got it from the amazing Chris Matts, and of course I got it as an aside, because he just flings these ideas out there like they are nothing, all the time.

As my blog title hints, I urge you to stop trying to fit in all the time, if you want to move ahead.  "Following the rules" is a constraint which cannot be avoided, but it's hardly a strategic, proactive way to plan out your career.  Steps 1 to 3 may be necessary if you want to swim successfully upstream in a dominant culture.  But at least one more concept is needed before your portfolio is sufficient:

Use your individuality as an opportunity to surprise your networking partners, to create a strategic advantage, and then go for what you want.

Facilitation context
Let's use a folksy metaphor to help you see how this works, within the context of a facilitated meeting, which is something you have probably experienced.  Agile coaches you hire will always make you and your colleagues do something horrible, like juggle hacky-sacks, or throw a ball, or play with legos, and it's not just because they all originally had names like "Rainbow" or "Feather," and grew up in yurts in California.

They do these things to get you off guard so you can bring some of your defenses down long enough to learn and even begin to want to change.  Once one sees this pattern, as a coach, it's glorious (plus, one no longer feels obligated to apply stalwart tools for humiliating people who got chosen last for teams in middle school Physical Education classes).  How many of us have dropped the "talking stick" when it got hurled at us by some ex-jock across the table?

But back to the point:  Chris says that, generically, a good facilitator will purposely throw a group off-guard by surprising them, in order to get them to actually engage in the facilitation.   And indeed, this is advice you can get from other facilitation coaches as well, once you know to look for it.  A good facilitator, as Impact Factory suggests, will "try something different. Take a look at what happens in your meetings and try to 'do' something to the environment or how the meeting is run or how you handle the attendees so you can get people more alert, thrown off guard or surprised."  Note that the good facilitator still needs to reserve a room and make sure there are white board markers.  Surprise is not a substitute for preparation--it is a vehicle for communication.
From http://myob.co.nz/blog/dont-drop-those-balls/
Career advancement context
Let's return to you and your career--consider your networking partners a group, and consider yourself the facilitator.  And let's return to Sallie Krawcheck for a moment, as well.  Krawcheck didn't get to the cover of Forbes by being a mousy conformist.  If you do a little research, you will find that she is famous for working 90 hours per week, always being ruthlessly well prepared, and putting herself out there.  She spent six weeks personally wooing thought leaders at Bank of America one on one before she took on her executive position there, and turned a slam-dunk disaster into a very effective engagement.

Your mission, should you accept it (and that's a big "if," for some of us, unfortunately), is to take a page from the Krawcheck playbook and to ambitiously own the responsibility for taking your career in some specific chosen direction.  Where do you want to be in 1 year, in 5 years, in 10 years?  Let's say you want to be Chief Information Officer, presiding over larger and more complex organizations.  Or let's say you want to be a career change agent who is constantly in demand, getting more and more interesting engagements, where you catalyze change in a whole bunch of disparate organizations.

Like the facilitator, out at Office Depot at midnight looking for a flip chart for tomorrow's meeting, and like Krawcheck, you need to prepare.  You need to know what a person in your next goal position does, and be able to make a case for why you have the potential to do it, even if you haven't done it before.  You need to know who the key players are who can get you that job.  You need to know what things to say to be convincing, and what things, intrinsic, or extrinsic, to the job you need to be able to talk about fluently.  You should be able to throw off examples of your past accomplishments the way Chris Matts throws off ideas.

But then....

SURPRISE THEM.  Boldly approach people, embracing all of your obvious physical differences, and engage them as equals and peers.  You're prepared--why not take advantage of your audience's stunned silence and say something?  Are you over 50?  Wear your pince-nez proudly, and scare that whipper-snapper from the game industry by engaging them in sensible conversation about the future of the Xbox.  Are you a woman?  Wear a dress!  Not a revealing, provocative dress that breaks any rules of propriety, but not a man-tailored grey suit either, if that doesn't look good on you.  Then talk about calculating NPV on a service portfolio.

Why take this risk?  Why leave the herd?  Two reasons:
  1. Your surprise creates a multiplier effect around your prepared message.  While the person is still gasping internally at your audacity in approaching them, you can say virtually anything intelligent, and sound ten times more impressive than someone who they're expecting to talk with.  
  2. You're fooling yourself if you think you weren't doing it anyway.  If you are the only woman, or only old person, or only person of color, or only transsexual at your business, you are not going to blend in, no matter how many pinstripe suits you wear.  You are hiding your light under an unattractive bushel.  In fact, even if you don't listen to me, and you insist on trying to blend in, you will need to be aware that you have this impact and take measures to avoid scaring your interlocutors into a defensive strategy prematurely, even if they don't act like you've surprised them.
Career advancement can be a cooperative game, but don't make the mistake of thinking it is always that way.  Plan your career like a battle, and don't be fooled by the air kissing at the cocktail party.
From http://www.therightplanet.com/2013/09/sun-tzu-on-syria/
It is a standard tactic in warfare for a weaker nation to take on a stronger one using surprise as a strategy.  CACI strategists JP London and Lani Kass point out that "asymmetric foes, unable to take their opponents head on, rely on surprise, shock, and psychological dislocation as force multipliers." They go on to say that the surprising thing is how few underdogs take advantage of their moment of surprise to press forward with a particular agenda:
Ironically, at times the initiator [of the surprise] is too surprised by his initial success to fully capitalize on its impact.  This little known phenomenon - wherein the psychological paralysis and dislocation one intended to inflict on the victim spills over and affects the initiator's own follow-on actions - reflects one of the many dualities inherent in surprise.
Bottom line:  sometimes you can blend in, sometimes you can't, and sometimes you can control your impact in one direction or the other.  By all means, blend while the blending is good.  But where your differences will help you, play them up, don't play them down.  As the inevitable Sun Tzu points out in the Art of War, "All warfare is based on deception.  Offer the enemy a bait to lure him.... Be seen in the West and attack from the East; lure him in the North and strike him in the South.  Drive him crazy and bewilder him so that he disperses his forces in confusion."

Be glad you don't look like anyone else, and go for it.

Monday, September 30, 2013

Staffing for Scaled Agile: Retention is Better Than Acquisition

As you begin your large-scale agile transformation, you may find yourself printing out posters of The Big Picture, jack-hammering cube walls into pulp, and negotiating an awesome corporate site license for an Application Lifecycle Management (ALM) tool.  Plus you are likely putting rigorous product management, architecture and continuous integration practices into place, along with test driven development, and automated functional testing, without the last of which you will be completely helpless under your regression load.

This is all heady and exciting stuff, and just keep doing it, but I would recommend that as you do, you put staffing at the top of your list of concerns, and put a fair amount of energy into the effort.  The Agile Founding Fathers weren't messing around when they put the words "Individuals and Interactions" at the very top of the manifesto.  Make no mistake--agile lives or dies by the quality, motivation, and communication of the people practicing it, regardless of methodology and tools.

Resources are People Too!
No matter how comfy the bean bag chair, it can never support production of high value software if it is occupied by the wrong person, organized into the wrong team, doing the wrong thing.
amazon.com image of the Eazy Bean Bag(TM) chair
So who is the right person, what is the right thing for them to do, and how should teams be organized? Who manages them?  And what's all this about "self governing teams?"

Your Agile Organization
Despite what you may have pictured in the dark of the night, your key to success as an officer, executive, or manager in a scaled agile enterprise is going to be "self organizing" teams, not "self-leading or self-governing" ones.  I really like the way Steve Denning graphs the difference.  Here is his menu of organizational structures:

On graphs such as this one, in a book with "Radical" right in the title, one might expect that the team structure on the far right is going to turn out to be the most productive.  But one would be wrong, or at least, wrong in most actual corporate entities.  Here is Denning's chart of the team structures' comparative productivity:


Within the team, self-organization towards a shared goal is of paramount importance to productivity.  But all of this is for nothing without a well-communicated feedback loop with company management to provide those shared goals in the first place.

Self-organizing teams are not "natural."  Denning goes so far as to call them "precarious."  A whole team of people (that would be you, management people!) needs to be constantly in motion in order to create, protect, and maintain the ongoing health of those teams in a corporate environment.
In effect, a set of management practices needs to be put in place that encourages self-organizing teams to evolve into high-performance teams.  When things go wrong, as they inevitably do with something as precarious as self-organizing teams, safety devices need to be in place to identify and rectify the situation quickly and decisively. [The Leader's Guide to Radical Management2010)
Denning's book has a whole recipe for what these leadership and governance practices need to be, and I recommend you read it, but for purposes of this blog post, suffice it to say that you should not picture a bunch of wild agile teams running the world through their whims.  Scaled agile requires scaled leadership, communication, and governance.  So on to the next question:  where do we find the type of people who we can entrust to self-organize their team practices?

Your Agile Staff:
With few exceptions, the standard business rule that "retention is cheaper than acquisition" applies here. Your best agile people are almost without fail your best current people, whose numbers can be maintained, refreshed, and augmented as needed through high quality recruitment practices from the global job market.  What you need is training, and communications.  What you do not need is a wholesale house-cleaning.  Or if you do, please don't blame "the agile transformation" for it!

In particular, please be very thoughtful about your approach towards your current software functional testers as you embrace test automation.  People who are currently employed under the title of "Manual Tester" typically take one of three paths during an agile transformation:
  • Out.  If your people are manually tapping out steps from scripts they did not write themselves, and if they don't understand the application or the script, and if they are not interested in learning anything new, then you probably don't need them any more, right?
    • This is a particularly good context for applying the rule of "not throwing the baby out with the bath water."  If you have employees who truly do nothing but pound keys mindlessly, by all means, replace them with a machine.  
    • But be aware that you have two specialized testing positions to fill which can best be handled through retraining and enhancing the jobs of current testers with mental curiosity, an endless excitement about breaking software, and either analytical or automation skills.
  • Up/"The Devster."  This one you are probably familiar with--agile teams are often populated with testers who can code, and with coders who can write test automations.  Proper automated functional testing requires specialists in test environments, tools, tooling, widget-writing, data store versioning, and so on.  This is a great path for your more technically oriented testers.  Devsters could either be cultivated from your pool of:
    • Current testers with junior or senior software development skills, or
    • Developers who have a specific interest in building test tools.
  • Up/Functional Test Architect/Analyst:  What you may not know is that modern agile teams require an extremely well-crafted test strategy, based on an initial operational architecture for the system comprised of individual operational roles and end-to-end tests that represent user-testable paths through the system.  
    • Someone has to document that architecture with user acceptence in mind.
    • Someone needs to do an impact analysis per story on how that story changes existing or to-be end-to-end tests, and build out the documentation on that operational architecture as more is learned.
    • Someone needs to build out a proactive strategy for handling masked and synthetic test data, combinatorial analysis of how many scenarios must be run, and curation of reusable test modules, along with one-off tests specific to context.  
    • And all of this must focus on appropriately building out supplied acceptance criteria, which are often phrased positively, into appropriate positive, edge and negative test cases.
    • In sum, be very careful about your diamonds in the rough.  It would be sad if you find yourself surrounded by eager-beaver young people bristling with automation skills who don't have half the experience and talent needed for your test architect/analyst role.  Those skills are best found in your current staff: testers who can routinely design and implement the right set of test scenarios, composed with the right number of combinatorial data runs, and comprised of exactly the right test cases.  Hang on to those people.

And all of this segways, neatly, into one last point:

What People On Your Agile Staff Do
Oh!  Oh!  I know all about that!  You say.  There are three standard Scrum roles:  "Product Owner," "Scrum Master," and "Team."  I'm not sure how we're going to retrain everyone to do everything, but it's got to be done!  Otherwise we have SILOS and that is BAD.

The fact that an agile team needs to do an assortment of tasks doesn't lead to the inescapable conclusion that everyone on the team needs to do everything equally well.  In fact, I have seen and agree with the ideal of a team which evolves into a set of "T-shaped" individuals--each individual having deep knowledge of one or two sets of techniques, and enough to get by on the others.

For best results, in fact, you want people to be able to fill in for each other gracefully as needed, but that's not the same as posting an advertisement for a position in your organization as "agile team member."  Ask yourself, do companies who deliver custom software using agile techniques hire that way?  No, they don't, even the ones that let youself create the job title on your business card as "Disruptor" or "Hard Rockin' Rocket Scientist.". Professional agile software delivery firms classify people into the same types of roles that non-agile IT organizations use: "application developer," "analyst," "project manager," or "tester."

Please remember, until the revolution is complete, your agile team does not exist in a void:  you need to avoid crippling people by giving them a goofy non-fungible title.  Picture your smartest software developer at a job interview after she moved to Dubai to take care of her niece and nephew after their parents' tragic helicopter accident.  "Agile team member?" the interviewer would say, coldly.  "I was a developer," your smartest person says.  "Right, we'll hire you as a junior analyst." the interviewer says.

Don't let this happen to your best people!  And don't reinvent the wheel.  If you're a scaled organization, you're probably already running your business with a matrixed structure where individuals report to a line manager for practice guidance (Analyst Lead, Dev Lead, Test Lead), but get assigned to a team for project purposes, with that team lead by a project manager of some kind.  Here's what you do:

  • Leave your organization intact, with individual practitioners reporting to thematic line managers who, in turn, report into a management hierarchy as deep as is needed to do proper support of individuals' careers.
  • Allocate those same individual practitioners, already blessed with the titles "tester, developer, analyst, project manager," etc, to agile work stream groups.
  • Encourage and reward people if they pick up new skills, and allow them to recategorize themselves, if they qualify.
  • Ensure the project managers are "scrum master/facilitators" not "managers" in the old command-and-control sense of the word.  Empower scrum masters to escalate problems to program and line line management as needed, including people who are a bad fit for the team.
  • Leave your PMO intact, or create a small new one, to monitor metrics which you collect automatically from your teams for governance purposes.
The power of the agile team is in self-organization.  But the power of the agile organization is in...organization!  You need leadership, you need vision, you need energy, you need fair and automatically created metrics about progress towards well-understood goals.  Agile has a way of exposing people who have been free-riders in the past, so expect a certain amount of "Emperor's New Clothes" moments, and expect to act on them.  But in general, your staffing plan should be to retain the good people, the good leaders, and your existing good practices for leadership and governance, to ensure that your newly fostered hyper-productivity has the right channels for self-expression.

Thursday, September 5, 2013

The Periodontal Probe: A Cautionary Metrics Case Study for Coaches

Did you visit your dentist today?  If not, perhaps it is because in modern dentist offices (at least in the US), a routine dental checkup consists of four key steps:
  1. A hygienist grimly and repeatedly stabs your gums with a pointy stick called a periodontal probe (6 stabs per tooth!), and loudly calls out numbers from 1 to 15 with each stab, where anything over 3 means "tooth about to fall out." These numbers, they assure you, go on your permanent record.
  2. The same hygienist scrapes some stuff off of the teeth along your gum line, a painful process appropriately known as "scaling."
  3. The hygienist gives you a choice of grape, watermelon, or mint toothpaste, and uses that little round tooth cleaning widget to clean the remaining surfaces of your teeth.  They don't say it, but you know and they know that the widget is actually a disguised drill.
  4.  The dentist comes in, looks things over, and gives you some summary advice and follow-up requests, like "come back in six months" (that's good) or "let's make an appointment for you for a new filling/root canal/major gum surgery/denture fitting" (that's bad).
Amazingly, this sequence of events is considered a "best practice."  One dental blogger writes:  "Next time you visit your dentist, if you don’t hear them calling out your numbers ... find another dentist!"
Sir Lawrence Olivier as Dr. Christian Szell, in "Marathon Man," http://www.aveleyman.com/ActorCredit.aspx?ActorID=13188
He continues:
[If] the screening occurs in silence, the patient does not have the advantage of listening to their own pocket depths and correlating what they are hearing with the health, or lack of, inside their own mouth.  What a missed opportunity!  Listening to the numbers could directly impact patient “ownership” of an infection that generally has no symptoms. Patients should be given an opportunity to hear their own numbers as the data is collected, as well as see evidence of active infection by looking in the mirror to see tissue that bleeds readily during measurements.
Nice.  It is no wonder that RDHMag.com, the Registered Dental Hygienist site states that:
...over half of the American population suffers from "dental phobia or related anxieties."2 Some have a fear of dentists and what they might say or do, while others are terrified of dental procedures, some to the point that they do not want to think about or be aware of even minor interventions. Others have specific problems, such as a bad gag reflex, a fear of needles, or a prohibitive embarrassment about seeing a dentist.3
"So what," you say.  So, even if you scoff at the need for shiny teeth and not-bad breath, gum disease is actually quite a serious health risk.  As MayoClinic.com points out succinctly, "Periodontitis can cause tooth loss or worse, an increased risk of heart attack or stroke and other serious health problems."  Also, gum disease has been correlated with Alzheimers.  I'm not even kidding.

"Yes," you say, perhaps grinding your teeth, "But what does this have to do with the use of metrics for coaching, particularly in large-scale agile transformations?"  Here's the point.  You can't help people if you are scaring them to death. 

Your dreams, as an agile coach, are akin to those of the dental hygienist, who (presumably) dreams each night of rows and rows of shiny teeth embedded in plump, light pink tissue.  You envision your enterprise, line of business, large program, or team, having big, automated, visible charts out the ying yang, telling the (firewall protected) world on a minute-by-minute basis how healthy things are, so that someone can jump in and fix the little problems as they occur.

Your patients, pardon me, your clients, are in a bad way.  That is why they have asked you for help.  In fact, you can be sure they are in a VERY bad way, because they are executives, and by nature, executives don't ever want to give the perception that they need help, even if they do.  In fact, maybe someone forced them to retain you.

This is not an EDUCATIONAL OPPORTUNITY, dear reader, where the first thing your hiring sponsor wants you to do is an instant, detailed, and gruesome metrical depiction of what is wrong.  If this is where you start, especially in writing, then you have now escalated the executive's situation from "I don't want people to perceive weakness" to "my coach has now broadcast my weakness to the world."  You have if you will pardon the expression, taken the most efficient route to biting the hand that feeds you.  You can't coach an organization effectively if they have fired you.

And it's not just about you.  It's about them.  Do you really want to help?  Then you need to be encouraging, not judgmental and demeaning.  And let me help you make this leap.  Anything that smells like "I'm the expert, and you're the failing executive" comes across to an executive as judgmental and demeaning.  You are the dental hygienist who holds the screaming child down to prevent them from escaping while you do the cleaning.  You have just created a life-long agile phobia.

Here are some lessons for agile transformation I have taken directly from the world of dentistry.  Please allow Registered Dental Hygienist Carol A Jahn, MS walk you through it as a sort of guest blogger.  I've taken the liberty of swapping in software delivery words for dental terms of art,  but virtually all the rest of the advice works intact!  Check it out.
  • Promote self direction.  Rather than identifying for [clients] areas that need improvement, begin by asking them how they feel they are doing. Good trigger questions to ask might be:  Where do you think you could improve?  Are you satisfied with your [SDLC]?  What are you most concerned about? [Quality]? [Speed to market]? [Transparency]?  Encourage [clients] to be honest and realistic. It's still OK to point out to [clients] areas you feel are of the greatest concern. However, if you encourage [clients] to identify their own [software delivery]-health status and needs, not only will their [technological] awareness be enhanced, but so will your understanding of what [software delivery] issues are important to them.
  • Focus on the [highest priority] problem or goal: Most [transformation coaches] are adept at focusing on [any prioritized] problem or goal, such as reducing [cycle time] or [defects which escape to production]. However, the tendency to "scare" the [client] by discussing "worst-case scenario outcomes" should be avoided. This is not to say that [clients] should not be informed of the consequences of their lack of compliance, but be realistic. Try to focus on the positive outcomes of improving their self-care habits or treatment, such as a better [relationship with business partners], better [transparency], or [talent] retention. Enhance your credibility by providing your [clients] with appropriate resources that support your information and instruction.
  • Let the [client] explore and choose. This is the pinnacle of customization. Keep in mind, though, that the first choice that [clients] make may be that they are "not ready" or they don't see the need. [Clients] also may choose a [tool or process] that they think they will use. Help guide [them] to [solutions] that may be beneficial for their particular situation, but be sure to give them a choice so that they ultimately make the decision and the accountability resides with them.
  • Identify all possible [automated tools they can use to make this more fun], including [virtualization packages], [code quality dashboards], and [virtual card walls] that have research to support their efficacy. At this point it becomes clear that Carol A. is a representative of WaterPik, and she goes on and on about putting up a nice display in your practice, and having working demos for patients to try, and so on.  I will spare you these tips and tricks, but I think this might, ironically, be the best advice she has for us.  Change your approach from "your project is a death march, and I can prove it" to "hey, want to try some great new tools that will make you look great?"  I hadn't identified this pattern for transformation explicitly until I read this RDH blog post in a fit of rage after my last dental appointment, but think about it, who doesn't like new, fun tools?  Especially complicated ones that require new certifications that you can put on your resume?!
I believe I have quoted my wise old aunt on this point before, but it bears repeating.  "The truth is something to be very careful with."  Think of your client interactions as respectful conversations where your client always comes out feeling better about herself, but still happy to have been equipped with a new strategy.  There is no need to shout out the numbers.  And face it, most of us don't have the option to sweeten the deal by offering an hour of nitrous oxide.

Wednesday, July 10, 2013

From "Agile" to "Astute:" Value Wrangling Requires Technique

I've been putting my shoulder to a wheel which Jim Highsmith has steadily pushed for a long time, and which Gojko Adzic has started actively evangelizing over the past year or so, which is a group effort to brand, rationalize, and advertise practices to help teams "build the right thing" as a complement to the fairly well established "agile" practices for helping those teams "build things right."

Like the Agile Manifesto drafters, who came together in 2001 as established and successful software delivery practitioners, Adzic has brought together some wonderfully talented practitioners into his discussion space, many of whom have already published substantively on the topic.  To name just a few:
Additional contributors to the effort include Scott Selhorst and Adriana Beal, who have recently posted some great observations to their respective blogs about avoiding "cargo cult" requirements.

But there is a problem.  As the original Agile Manifesto framers did in 2001, Adzic is facing a tricky task this year in coming up with the right name for his endeavor, or even to get something of a grip on what the goal is.  Code names used so far by Adzic include: "February Revolution," "ThisCon", and "Astute." 
An Astute class submarine, from http://www.military-today.com/navy/astute_class.htm
I was excited to find out that "Astute," the last of these three, is not only a clever and alliterative companion-concept-name for "Agile," but also a class of nuclear submarine.  Despite, or perhaps because of, its ominous echoes of instrumentation for mass destruction, "Astute-as-submarine" provides a nice metaphor for practices needed to find out what a project sponsor actually wants on an ongoing basis, and how to provide her with an evolving product which is always a good fit.

There are (at least) three problems a value-wrangler needs to solve using a whole arsenal of tools:  1)  motivations behind product investments are never visible on the surface, 2)  the decision maker is going to keep changing the exact coordinates of the destination, in terms of the specific features which will best express her motivations, and therefore 3) if a professional value wrangler is doing her job well, she will be invisible except at deployment, and maybe at that point, you don't see her either.

Unaddressed, these three problems leave teams team constantly looking for new landmarks, and, worse, they fail to recognize team members who are vital to their continued success.  "Astute" philosophy and practices address these problems.

1)  Why Are You Building It?  Don't Trust Surface Appearances.
You may be tossing your head and saying "just calculate the per-feature NPV and go!  How hard can this be?"  Indeed, the "Net Present Value" of an investment, looking at initial investment, income stream, ongoing maintenance costs, all adjusted for inflation, if calculated uniformly over a set of investment possibilities, could lead to an orderly portfolio process.  Entire books assert it!

But anyone who has ever provided advice to an executive knows that the numbers are simply a proxy for the power structure of the organization.  The project will be executed or not, based on whether the detractors are stronger or weaker than the proponents, regardless of what the numbers say.  To provide just two large-scale examples:
  • Read this independent analysis on Chicago Mayor Rahm Emmanual's business case for closing 57 public schools this month, the largest mass school closing in the history of the USA.  The cogent fact is, he wanted to do it, he could do it, and he did it.
  • Read this analysis from a Financial Times article about the business case for building next generation High Speed Rail in the UK (thanks to Ross Pettit for the tweet calling out this wording!)  One day there may be numbers, but they will come after the decision.
Organizations are about emotion, power, and influence.  The numbers will always support those actual drivers, or the numbers will somehow turn out not to be "Key Performance Indicators" in one way or another.  Do not be tricked into thinking that you can understand why a project is still funded, or why a project is getting started, based simply on a logical business case.
  • Sometimes there's a burning platform .  Ockham's razor says that at least some of the time, all you need to do is some sanity checks with key players to confirm their real motivation.  It could actually be true for this project that there's some "pain point" or some huge opportunity that the company should logically pursue, and your decision maker is making sure that the company does so in a cost effective way.
  • Sometimes the real motivation is completely different.  If the CFO is asking you to fix the problem with "waiting room utilization" in the company's fleet of podiatrist offices, she could be asking you to create a more welcoming atmosphere to drive sales, or to grab some of the space for a bigger display of shoe polish, or she could be creating a cover story in order to get the company facilities architect fired, because she's mad about love gone wrong.  You don't know. 
You need to know.  Your project's success rests entirely on getting aligned appropriately to the actual motivations as well as the sanitized ones used for public consumption.  That is a tricky business, requiring work at multiple levels and repeated adjustments to avoid getting the bends.

2)  What Are You Building?  Don't Get Too Attached To Your Original Landmarks.
For a typical product, the visible landmarks representing "product value" are a choice of:
  • A "fixed scope" with specific features and components laid out in detail and analyzed by the product people for potential ROI or
  • A determination to avoid "fixed scope" in favor of creating a permanent team which can react quickly to breaking market conditions by waiting to split and estimate stories from epics until "just in time" at a rate of 5-10% per iteration (recommended by "Pure Scrum" advocates Ken Schwaber, Jeff Sutherland and even Mike Cohn).
Fixed "scope" has some limitations in terms of its ability to represent value.  The Scrum process is intuitively appealing, because in real life, software value cannot be measured until the software is delivered to people who will use it.  If your team delivers EXACTLY what was described in the requirements documents everyone signed eighteen months ago, but nobody can actually use the software as delivered, someone didn't get the value they expected, and lawyers will determine who has to cover the costs.

Pure "trust me" time and materials based project approaches also have limitations.  Someone has to put some kind of stake in the ground, and in some organizations, "progress" needs to be measured in some way.  The classic scrum "burn down chart" showing how much planned effort has been delivered each iteration is not going to be satisfying to a business person with end of year bonus concerns, where that particular thing has a fairly large "minimum viable feature set."  Questions like "when can we ship" are valid questions.

"Astute" describes a submarine navigating in a specific direction without landmarks, and arriving at exactly the right coordinates when requested to surface.  Successful projects need to use a set of reliable techniques to balance out the need for some overall direction (we are building a wheel barrow, not the Empire State Building), with the need to be flexible about the details, and the ability to be pinpoint precise at delivery time.
  • Models need to be created to help users and sponsors visualize the software more concretely than can be done from reading a formatted DOORS file.  
  • Techniques need to be used to track the movement of the scope details within the guard rails of the overall project road map, if that variance is important for future planning models.
  • Product owners need to assign value to the items as they are planned, using "value points," so you can chart the overall value a project delivers separately from the actual scope items delivering the value.  If you can get them to do this, you never need to understand their actual motivations.  Jim Highsmith's famous inverted "Agile Triangle" shows it this way:
From http://theagileexecutive.com/2010/01/28/use-the-agile-triangle-instead-of-the-balanced-scorecard/
3)  Just What Is It You Say You Do Here?  How Do You Brand Yourself if Your Goal is Invisibility?
Because the politics around project delivery are complex, and messaging is a huge part of project success, the vast bulk of what a professional value wrangler does every day is invisible, by design.  You aren't just building a product--you are building a perception around the product.  And as anyone who has delivered anything, anywhere, knows, perception is reality.

The best "Astute" practitioners, at sea, and ashore, don't publish "tell all" books about their journeys.

Bottom Line:  It is High Time to Brand, Professionalize and De-Stigmatize Astute Practices.

I don't know where the naming committee will come out on what to call this.  But this is an exciting vehicle to jump aboard, whether submarine or just band wagon.  New techniques are being born all the time impacting the "value" space.
  • Continuous Delivery is the new coolest thing for developers to do, and it also creates a fascinating problem space to explore, which is twice as large for analysts, in terms of engineering their value hypotheses into their investments.  
  • BDD, theories around test data management (synthesizing and masking), and combinatorialial optimized testing techniques create a discipline about how acceptance criteria should be structured, and how end to end tests can grow architecturally the same way code does, and in real time.  
  • Lean startup suggests purposely experimenting, and changing direction altogether, when in a startup mode, and so on.
Scott Ambler famously dismisses the need for an agile team to waste money on professionalized value-tracking techniques as follows:
A business analyst (BA) is a poor substitute for developers who have both ready access to actual stakeholders and agile modeling skills.
Remember, BA is also the abbreviation for band-aid.
Perhaps the time has come to re-occupy the two letter acronym, and take pride in branding and participating in "Being Astute." Interested?  Join us in the FebMeeting space:  https://plus.google.com/communities/117918808932484104617.

Tuesday, June 25, 2013

Lean Sideways or Up, and then Down

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.
As the report authors, Christine Silva and Nancy Carter, suggest in their follow-up article in the Harvard Business Review , here's what makes the difference:
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"?

From:  http://imaginationsoup.net/2012/05/great-illustrators-study-shel-silverstein-plus-some-poetry-too/

Non-Crazy Job Hunting in 5 Steps

No matter how much you like your current job, you should always have a Plan B.  And if you're finding that job hunting has suddenly become Plan A, this advice may be even more timely.
From:  http://thecreativescribbler.com/2011/05/26/life-of-a-job-hunter/
What You Think You Should Do:
  1. Find a list of jobs somewhere.
  2. Apply for those jobs.
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:
  1. Figure out what you want to do.
  2. Find some companies where you want to work
  3. Build some marketing collateral for yourself.
  4. Network by asking people for help reviewing and improving your collateral.
  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.
This is not some kind of scary visualization technique.  I'm not going to suggest that you start by reading The Secret and 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's Unwritten 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>
    Here' are some examples from a nice blog on this.
4)  Network by asking for people's help with your collateral.

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

Agile Quality Tactics Explained in 7 Easy Steps

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) Additional environment setup and maintenance Project environment czar, usually a Dev person, and CI expert. 
Maintainability Ability to leapfrog competitors quickly, lowest cost for basic BAU maintenance Static code quality tests, dev practice dashboards, unit test coverage reports, etc. Cost of initial supervision and enforcement, but may actually self-fund through decreased work in the long term Architecture/Dev leadership
Security Cost of a security breach to the application Security testing Varies with tools and techniques chosen Risk/Dev leadership
Reliability Cost of down time Simulated down conditions Varies with tools and techniques chosen Risk/Arch/Dev/Ops leadership
Performance Cost of slow response: operational inefficiencies or actual lives lost Performance testing through tools like LoadRunner, Dynatrace, etc. Varies with tools and techniques chosen Performance leadership (usually architecture or testing)
Compatibility Cost of virtualizing and/or changing the system or other related systems to allow for seamless interfaces Architectural analysis and estimated costs to change or change partner code Interface contracts, IT Operations SLAs, etc. Business and Architectural Owners of Cross-Impacted systems
Usability 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.