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.

Popular posts from this blog

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.

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 applicable) and your analysts at the beginning of the project, as always, b…

Requirements Traceability in Agile Software Development

One of the grim proving grounds for the would-be agile business analyst (henceforth "WBABA")  is the "traceability conversation."  Eventually, you will have to have one.  You may have seen one already.  If you haven't, you may want to half-avert your eyes as you read further.  It gets a little brutal.  But if you close them all the way, you can't read.
Dialogue:
WBABA:   ...so in summary, we complete analysis on each story card, and then we support the developers as they build it that same iteration!Corporate Standards Guy:  but how do you do traceability in agile?  You have to have traceability.  It's broadly recognized as an important factor in building rigorous software systems. These software systems permeate our society and we must entrust them with lives of everyday people on a daily basis. [The last two sentences are an actual quotation from the Center of Excellence for Software Traceability website!] WBABA: [cowed silence]Corporate Standards …

The Agile Business Case

Many agile teams have never seen a business case, ever, and they may even be proud of it.

Our mantra is that we deliver "business value," not just "software," quicker, better, and faster, but if so, we certainly don't spend a lot of time reporting on value delivery, and in fact we may be scornful about "analysis paralysis."  As software developers, we consider ourselves to be doing quite well if we can deliver the software every two weeks (or continuously).  And this is particularly if we've enabled this frequent high-quality delivery through automated testing and automated build-and-release techniques.  We've reduced business risk by making results visible more often, and allowing the business to change direction more frequently.  We assert that along the way of course we're also delivering value.  But how would we prove it?

I've recently posited that we shouldn't even think of doing agile projects without capturing and recording s…