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.
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.