How To Set Up an Escalation Path

Many agilists do not deal well with corporate hierarchy.  "In the agile world," they say smugly, "we will all be equal."  Quick quiz:  although the venerable "pigs and chickens" metaphor is now sliding out of favor among the agile cool kids, which of the following are agile transformation coaches still very likely to do:

1. Characterize the direct line managers of team members as "people to keep out of the room at all costs, and if they must be there, to be tolerated only if they maintain a respectful silence."
2. Describe the entire group between CEO and the team doing the work as "middle managers--the people I wish didn't exist."
3. Make cruel and dismissive comments about "command and control."
4. Wear jeans to work every day, not just on Fridays, in violation of the corporate summer dress code.

Yes, sadly, the correct answer is "all of the above," although item 4 is just a passive-aggressive manifestation of the first three.

But hostility toward management is not a good idea in a corporate agile transformation.  In fact, if your goal is to succeed, and not merely to seem "agile cool," the entire hierarchy can and should be your staunchest friend and ally.  Pragmatic coaches need to start every coaching engagement by establishing a sensible escalation plan for good news and for bad.

Goofily, this comes from a D&D site:  http://rolesrules.blogspot.com/2012/03/high-level-d-combat-general-escalation.html

What do you need?

• Demonstrated executive cover.  The executive at the very top of the organization you wish to transform should have publically stated she supports the change, and she should be willing to push the concept down through her chain of command, even visiting people's office to say things like "how's the agile transformation going, Gary?"
• Demonstrated incentives for line management to support your change, and disincentives for them to thwart the change.  In a large company, you should expect management at every level to be skeptical of change.  They've been through TQM, Six Sigma, and any number of other fads.  They don't care how cool you are.  They care about results they can use to advance their careers.  What is in it for them?  The answer may be as simple as "top executive management has called this a priority."  I hope the answer is also that you are measuring your project's success in terms of improvements to the business bottom line.  Every manager benefits from being able to brag that their projects are faster, higher quality, more predictable, better for the team, and better for the customer.
• Executive attendance at project kick-offs and other important events.  Executives from the IT and business organizations should attend your project kick-off (you do have a project kickoff, don't you?).  This may not be executives at the very top, but it could be the "Garys," the people at the top of your line of business or vertical, if not at the top of the whole tree.  The Garys should explain the strategic importance of the project from their respective points of view, and they should explain why it is important for the team to be tackling the project in an agile manner, if agile is new to the environment.
• An escalation protocol for how the team should react to bad experiences with their coach.  Because you are the consultant, you should start by offering the protocol for the team's escalations regarding the coach or coaches.  Team members with issues should always start by bringing the issue to the coach's attention directly.  If the problem can't be resolved there, the team should know who the coach's boss is, and be prepared to let the coach know that the boss is going to be pulled in.  If there is a hierarchy of some kind over the coach (manager of coaches, reporting to director of transformation program, reporting to transformation executive sponsor, reporting to the CEO, or what-have-you), those lines should be established right from the start.  At every stage, you should agree that if the team member does not get satisfaction, they should let the person at the current level know that they will be escalating to the next level.
• Same protocol for coaches with team issues.  Inevitably in a corporate change program, the change-ees may be unwilling or unable to move forward on a new philosophy or technique that the change-er (the coach) thinks is important.  You must establish before you start the coaching that when this happens, chain of command will be observed.  The coach will work first directly with the problematic party, then with their manager, and then all the way up the chain to the executive sponsor.  The executive who decided that they want an agile organization must ultimately determine whether the coach's viewpoint should be enforced on teams or not.  

Or to put it another way, precedent-setting decisions about the philosophy and practice belonging to your organizational change should not be made locally by the team.  This is not "Lord of the Flies." Someone is investing heavily in paying coach salaries, or you wouldn't be there.  The person controlling that budget needs to ensure that the coaches are behaving, and that problems arising on teams can be resolved appropriately for the whole program, not just at the preference of the local team members.

I recommend that you understand what you need for an escalation path, and that you put together, yes, that anti-agile concept, a written statement of understanding of how you will escalate as needed, for every team being coached.  Name names and put time frames into this document.

But Elena, you say, this is pretty freaking negative.  Okay, yes, in a way, it is.  That's why I started by saying that you need your escalation path not just for bad news, but for good.  Establish metrics showing success in a way your management chain can brag about, and make sure you pump those positive messages up your escalation chain at every appropriate opportunity (without spamming people.  Management hates spam). 

Robert Frost's wall, from http://en.wikipedia.org/wiki/File:Mendingwall.JPG

In Robert Frost's poem, "The Mending Wall," the narrator's stodgy neighbor intones, "Good fences make good neighbors."  Like Frost, of course, we all know that good neighbors make good neighbors, and your agile transformation will either succeed or fail primarily due to the good will you show, and the good work your teams perform.  But let's build up the fences as an enabling step to breaking them down.  There's a paradox here: this contract for escalation actually enables and empowers communication within your team, across the organization, and up the hierarchy.