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 Management, 2010)

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.