I was recently sent a question that I've heard before. It's important, and I think my view (as someone with strengths Relator and Strategy) is not one I've seen much in the workplace. So, I thought I'd share the question and response with you. I hope it is of some value.
Question: Given a development team that is fully convinced of adopting the Agile methodology, what is the best way to get buy-in of upper management that is used to having hard deadlines and deliverables similar to what (allegedly) was delivered by waterfall methodologies?
My Response:
Good question, and I have a couple thoughts.
First, it would be nice if you could dig up even a few facts about what's happen in previous projects. Often I go through email from key people at milestones or deadlines and build a simple journal of events. It helps keep the facts simple and clear in my mind for when there's a key decision-making meeting later (I tend to lose my train of thought or important facts in those pivotal moment).
That ties into my bigger view, which is that my experience in winning others over starts with a focus on a short study of those people, and only after that, what their objections or concerns are. Often times "the issue isn't the issue." All problems are people problems, so focus on the person. It's likely the decision for this person is not about facts, but about their fear, uncertainly and doubt.
So, if they have their neck on the line, you present agile as a great risk-mitigation method (and let me know if you need the info on why that is so). Or if they need some wins with key management/peers in the company, present it as the best way to get game-changing features out, and out sooner. If getting stung by poor quality is the issue, take the approach of quality built in upfront.
Practically speaking, they are usually only concerned (or focused) on one or two aspects. Keep it simple and address those. If you're not sure what those are, we can talk about fairly simple ways to get at that information.
Also, I keep in mind a couple of personal aspects. First, natural law. You have to make this agile adoption a win for them *personally*. They have to believe at some level that you're looking out for them *personally*. This builds trust and that trust gives you political capital to get things going and get things done.
Second, they have a personality and strengths that incline them to look and interact with the world a certain way. The simplest paradigm is from Management By Strengths. If they are "me" centered, it helps to present information/options/decision in a succinct way that allows *them* to make the decision (rather than be told something like "This is obviously the right thing and we need to do it," no matter how earnestly you deliver it). If they are "we" types, present it as a something the whole team (whatever he sees as team - project, department, etc) will benefit and be a part of/involved in. If they are "pace" types, you have to deliver the information and decision points clearly, gradually over time. Those types can't be hurried to make a decision to get out of a burning house. Be willing to invest in being patient, consistent and clear in your message. If they are a "process" type, present more as a clean system and process approach, not some foggy, no-documentation devs-gone-wild weirdness that they might have heard. Give them the white papers and research from Microsoft, IBM and other respected companies.
There are certainly other personality/problem aspects, but I hope this is enough to get you started. A good patterns approach to bringing change to an organization is Fearless Change. You can flip through and find ideas to apply immediately.
