Skip to main content

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.

Comments

Popular posts from this blog

How Do You Vote Someone Off of Your Agile Team?

One of the conundrums of agile conversion is that although you are ordered by management to "self-organize," you don't get to pick your own team.  You may not have pictured it this way, but your agile team members are going to be the same people you worked with before, when you were all doing waterfall!   I know I wasn't picturing it that way for my first agile team, so I thought I should warn you.  (I thought I was going to get between six and eight original Agile Manifesto signers.  That didn't happen.). Why "warn" you (as opposed to "reassure" you, say)?  Because the agile process is going to reveal every wart, mole, quirk, goiter, and flatulence issue on the team within a few hours.  In the old days, you could all be eccentric or even unpleasant in your own cube, communicating only by document, wiki, email, and, in extreme situations, by phone.  Now you are suddenly forced to interact in real time, perhaps in person, with written messag

A Corporate Agile 10-point Checklist

I'm pretty sure my few remaining friends in the "small, collocated team agile" community are going to desert me after this, but I actually have a checklist of 10 things to think about if you're a product owner at a big company thinking of trying out some agile today.  Some of these might even apply to you if you're in a smaller place.  So at the risk of inciting an anti-checklist riot (I'm sorry, Pez!), I am putting this out there in case it is helpful to someone else. From http://www.yogawithjohn.com/tag/yoga-class/ Here's what you should think about: 1.        Your staffing pattern.  A full agile project requires that you have the full team engaged for the whole duration of the project at the right ratios.  So as you provision the project, check to see whether you can arrange this staffing pattern.  If not, you will encounter risks because of missing people.  Concretely it means that: a.        You need your user experience people (if a

Your Agile Transformation Needs to Start with a Quiet Phase

From a really great blog post on agile adoption:  http://smoovejazz.wordpress.com/2011/02/16/an-agile-approach-for-adopting-agile-practices/ I've observed some different agile transformation patterns, and maybe you have too: Just Do Standups   (Shoot, then Aim):   some people feel that since you're "agile," you should just start doing stuff, like daily standups, and then build more of the the plan as you go.  Find a team and start doing some agile with them!  Start a revolution one practice at a time, one team at a time. Pros:   you're very busy from the start. Cons:   what exactly are you doing and why? KPI-Driven Change (Aim, then Shoot) : some people who have worked in large corporations for a while will tell you that to get the respect of the people, you need to start with a plan, support the plan with awesome printed and online collateral.  Then you "kick off," tell teams what to do, and measure them using "Key Productivity Indica