...copyright Elena Yatzeck, 2010-2017

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.