If you’re an Agile evangelist within your company, you’ll need the help from a diverse group of people across the organization to have your Agile deployment be a success.  If they don’t see the value of Agile, and how it connects to them personally, they won’t help you. With the volume of things competing for their time, you need a compelling, tailored, message at the organizational and individual level to get heard.  Having a generic “why Agile is great” presentation won’t likely get you the level of buy-in you need.

This post discusses how to go about tailoring that message.

Connect Agile’s Benefits to your Company’s Priorities

Most good company have published priorities that are periodically reviewed and updated.  

Showing someone an Agile presentation and talking about the benefits without referencing the overall company strategic and tactical priorities will simply make it harder to get support. Saying that Agile is “better, faster, cheaper” may not be enough to cause a company to be willing to go through the often-painful process of cultural and process change.  You could implement Agile, but you could also try Six Sigma or Lean.  Saying that Agile is a general get-better remedy puts it in line with many other get-better methods.

If you can refer to a specific business issue and show the linkage, you are much more likely to get a receptive audience.  Here’s an example.

“We’ve been losing market share on our social media platform.  Frankly, our last two releases have looked like me-too updates, where we are just barely keeping up with our competitors.  People who’ve been committed to our platform have started to lose confidence and are looking at other vendors.  If they don’t see a meaningful update from us, at least once a quarter, we’re going to get kicked out of the game.  We’ve all acknowledged that as we’ve gotten bigger, our processes have become more cumbersome and now is the time to do something about it.  Agile will give us the ability to regain that rapid pace of delivering innovations to market that we were know for in our early days.”

The focus isn’t on Agile, its on business, as it should be.

If you want to be an effective change agent, you need to have a thorough understanding of the company’s priorities and speak to your audience from there.

Use Focused Messages for Key Individuals or Groups

At the organizational level you need a certain volume of people who are enrolled in the idea of Agile before you’ll see adoption start to accelerate, but you primarily need to connect with individuals and groups of similar people (e.g. developers, product managers). When you need a dedicated test environment for your project, the whole organization isn’t going to build it; someone in the environments group will.  If they don’t personally understand what your are trying to do and support it, you are just another person with a request that will increase their work load and possibly increase their department’s costs.  

People have specific needs in their role and they want to understand how Agile will affect and benefit them directly.  

For example, the CFO wants to make sure that the company is spending money on the right things and getting good return for the money spent.  He or she also wants an effective mechanism for managing risk: if a project is going awry they want it to be fixed or eliminated before it wastes too much of the companies money.

Developers, on the other hand, probably wants to know if they will have interesting work, the opportunity to learn new things and the ability to make an impact on the company’s products.

And a QA manager is probably interested in hearing how Agile helps enrich the QA profession.

The CFO, developer and QA manager have different roles in the organization and their needs are different.  If you want to enlist their support, be sure you know who you are talking to and what they value.

The easiest way to find out what interests someone is to ask them.  When you meet, leave plenty of time for talk.  Motoring through a well-rehearsed Agile presentation usually doesn’t work.  A lot of times I’ll have slides with me, but they are a backdrop for the conversation.  I’ll refer to slides when it helps move the conversation along, but otherwise don’t use them.  You might want to forget slides altogether and just draw things on a whiteboard as necessary.  This technique is particularly useful with an individual or a small group.  

Take it One Step Further: Collect Data to Gain Insight

When you are going to be transitioning a large group or an entire organization to Agile, you’ll be most effective tailoring your message if you invest some time conducting data through a series of structured interviews.  This is a fair amount of work, but well worth doing.

First, you’ll need a small set of questions prepared for the interviews.  Here are some examples.

• What is working with our current methodology?
• What’s not working with our current methodology?
• How do you think Agile would help our organization?
• What concerns do you have about Agile?

Send the questions in advance to the people you are planning to interview so that they have time to think about them. 

Interview a wide range of people: developers, testers, business analysts, managers, product managers, senior management, project managers and someone from finance.  To really understand the company, it helps to view it from many varied perspectives.

When you conduct the interviews, it is good to have one interviewer who has the primary responsibility for talking and the other person who has the primary job of taking notes.  You can switch off roles each interview so no one person gets stuck in either role.  Here’s how I typically start off.  

“Thank you very much for taking the time to meet with us.  We’re trying to understand how Agile will fit in this organization, so Greg and I are doing a series of interviews.  For this interview I’ll be doing most of the talking and Greg will primarily be taking notes.  We want to make sure we do a good job capturing what you have to say.  The interview is confidential and we won’t connect you to any of the comments when we compile and share them later.  We’re trying to identify common themes across the organization.  Is that all OK with you?  Do you have any questions before we get started?”

Remember that this session is intended for information gathering.  If questions about Agile come up, certainly answer them, but don’t forget to gather the data.  

Pay particular attention to the stories that people tell about the organization and make sure you write them down.  Which of the following two statements do you find more compelling?

“Developers have a hard time getting the information they need.”

“One developer was trying to get the right set of items for a list of values.  He was forbidden from talking with the business person who knew the answer and had to go through both a systems analyst and a business analyst.  It took him two attempts and three weeks of elapsed time before he had his answer.”

For me, it is certainly the second one.  People will give you real, specific examples in the interviews.  Write them down with as much detail as you can.

Once you’ve gotten all of the data from the interviews, organize it to look for common themes.  There are several ways you can do this.  I put all of the information we’d gathered into a mind-mapping program (Mindjet) and grouped like things together.  You could do a similar exercise with post-its.  Be careful not to lose the unique character of the information you’ve gathered by over-summarizing.  Make sure you keep interesting stories intact.  Specifics will help you make your cases

Using the Data

The purpose of the interviews are to gain a general understanding of the issues being faced by the organization today with the current development methodology and how Agile might help. Use the information as you design your presentations.  I generally have numerical data behind my presentations, but usually leave it off of the slides.  When there’s numerical data, people engage with a presentation in an entirely different way than they do when there are stories.  I find stories more effective, but do what works for you.

Here are a couple of sample slides I had to put together for a presentation.  I had interviewed over 20 people, complied all of the data into a big affinity diagram and pondered it for hours with colleagues, but this is all I put in the slide deck.  The heart of the presentation were the stories I told based on the interviews, not just on these slides but elsewhere through the presentation.

Note: I don’t say “these are the problems we face as an organization” because the people I interviewed my not completely reflect the views of the audience, and I don’t want to get into a debate early-on in my presentation.  Instead I say “this is what we heard from the people we interviewed.”  If we’ve done a good job selecting the interviewees, the message should resonate with the audience.  

Successful Hitchhiking

In the late 70s hitchhiking was my primary form of long-distance transportation (including a trip form Albany, NY to Champaign, IL in the winter).  When you’re hitchhiking, the goal is to get to your destination with the fewest number of rides and the least amount of waiting and discomfort. I learned I got better rides if I talked about things that were of interest to the person who picked me up.  Instead of dropping me off on an unlit stretch of road, they’d go out of their way to leave me in a better position for my next ride.

As an Agile evangelist, you job is to get Agile deployed effectively.  Along the way there are many people will be willing to go out of their way to help if you effectively speak to their interests and concerns.

If you are an Agile evangelist within a company, you probably spend (or will spend) a fair amount of time talking with people across you organization about Agile and its benefits.  When I was in this role I ran into a full range of responses from heated skepticism to full embrace.  Having the opportunity to talk with hundreds of people provided me with a wonderful laboratory to see what worked and what didn’t.  Here are some of the thing I learned.

Understand and Speak to your Audience’s Frame of Reference

I found that I was significantly more successful, unsurprisingly, when I put more of my attention on my audience’s perspective than my own.

When you are talking with a group about Agile, the people in you audience have probably worked hard to get where they are, and they have a level of pride and attachment to who they’ve become.  Almost involuntarily, they are comparing what you’re telling them to their view of the world to see if it fits.  If you are not speaking to them with an understanding of their issues and values, you may not be very successful.

You’ll be particularly unsuccessful if you directly threaten their position in the organization and the things that they value.

(click to view full size)

Here’s another example.  Imagine you are speaking to a group of mid-level managers about Agile and you say:

“With Agile, it’s all about the team.  Self organizing teams who determine their own work process.  We break down the rigid silos and get much better results.”

My guess is they’d be threatened, think you are dangerous and would trying to figure out how to get you escorted out the door.  You’ve practically said “sorry, what you do isn’t valued, there’s a new way that’s better.”  Not the result you were looking for.

Here’s an alternate approach.

“Organizing work in a complex organization is a challenge.  As a group we’ve risen to that challenge effectively in the past.  Yet we’re in a recession and we’re being asked to respond even more rapidly to a constantly changing world.  There’s enough evidence to indicate that Agile may be a powerful new process for our company.  It is an uncertain path.  We don’t know if it will work for us and what the long term implications are for our structure.  But we’ll take one step at a time.  We’ll experiment thoughtfully, discuss the results together and collectively decide how to proceed.”

There are a few important things here:

• You are acknowledging them for what they’ve contributed to the company.
• You are honest about the uncertainty.
• You’ve let them know that they will have a role deciding how to proceed in the future.

Before you make your pitch, think of the people who will be in the audience an how your message might be received.  Do your homework first.  Figure out in advance which people in the audience are most likely to help or hinder your cause, and set up some time to meet with them individually whenever possible.  In these individual meetings, listen a lot and talk very little.  Find out what is important to them, what they know about Agile, what they think it might offer and what concerns them.  Use that to shape how you talk with the group.

When something comes out of someone’s mouth that sounds like an objection, consider this important data.  If you don’t effectively address the concern, you might not get the opportunity to proceed.

Cognitive scientists have demonstrated that 20% of what you hear comes from the other person and 80% is what you fill in with things from your own perspective.  You are at an enormous disadvantage when you are really trying to understand what another person has to say.  But understand you must if you want to be an effective change agent.

Have Room For Your Audience to Say Yes or No to your Proposition

My preferred approach to discussing Agile with a new group is to let them know clearly that they are in charge and that any decision they make is up to them.  I describe the challenges that other organization have seen that have led them towards Agile, and then ask if they face the same challenges.

If some items resonate, they’ll usually want to talk more.  If a lot of things resonate, they may ask how they can proceed.

This I found to be far more effective than attempting to sell Agile.  When the only answer I’ll accept is “yes”, my audience’s instinctive reaction has be to try to protect themselves and we end up in a tussle.

For this process to be effective, I have to OK if the groups says “no thank you, this isn’t for us”.

I also have to be clear about what will work and will not work.  If a group wants to try Agile without product owner, or without a full-time team, I simply let them know it won’t work, why it won’t work and suggest they not try.

The Connection to Pigs and Singing

In the early 80s, I was given a rubber stamp as a “present” from my boss and a peer.  On the stamp was a quote from Robert Heinlein: “Never try to teach a pig to sing; it wastes your time and it annoys the pig.”

Their point was that I was wasting time trying to change people into something they weren’t and had no interest in becoming.  These days I try to avoid the temptation (although it is still there), put the attention on my clients, on their issues and let them choose.

If pigs are singing around me, it’s because they want to.