«

»

May 11

Persuasion and Agile Development

Having recently purchased and listened to Dr. Robert Cialdini’s 45 minute lecture on persuasion and influence, I’ve been working on thoughts on how to apply those lessons to Agile Development, in terms of:

  • How to convince the necessary managers that switching to agile techniques is a good idea
  • How to convince the developers that switching to agile techniques is a good idea.
  • How to convince the customers that they should support the process
  • How to get the team involved in delivery to do their best.

First: thanks to Dave Taylor for the suggestion to download the lecture. It is probably the most valuable $2.95 I have ever spent. It isn’t a perfect lecture, but it is extremely good.
Second: Quick overview – Dr. Cialdini’s lecture talks about the keys of persuasion, centering around the concepts of reciprocity, commitment, exclusivity, gain and loss, and authority. He lays out techniques for influencing and persuading people, using these concepts. What I am going to do is try to cement those concepts to the heavy lifting of
getting agile projects underway.

Third: I am sure that these will seem manipulative techniques to many people, especially introverts (like me) who don’t like having to persuade. They are. But at the end of the day, Dr. Cialdini’s techniques seem very solid, well supported by experimental evidence. I would rather persuade someone to do agile development than fume and grow bitter and angry in a non-agile environment.
How to convince management to switch to agile techniques

  1. Do you actually need to ask? Many agile experts suggest that since the management team doesn’t understand programming, they won’t really care if you change the methodology
  2. Ask to convert the whole organization, or as much of it as you think could succeed. The key here is to think big – go for the big win.
    1. If they say no, back down gracefully, and ask “Well, what about a pilot project?” According to Dr. Cialdini, people are more likely to agree with you if they think you’re trying to find common ground (giving them a concession)
  3. Don’t talk about how much there is to gain from agile development – describe the change in terms of what they will lose if they don’t switch:
    1. Less responsive to change
    2. Less effective feedback
    3. More likely to go over time and over budget
  4. If you believe it to be true, find exclusive information that justifies your position. For example, perhaps you have a report from a consultant, talking about how agile development is transforming your industry, a report that you have paid for and is not widely known.
  5. Or, alternatively, if there is already significant movement towards agile development in your industry, play up this consensus – try to get management to feel that they are lagging behind.

Again, buy and listen to the podcast if you want more insight into why I chose these particular 4 topics. And if you have suggestions on how I could add to them or improve them, please feel free to share.

How to convince the developers to switch to agile techniques

  1. Many of them will already be familiar with agile techniques. Some may be doubters, some may be evangelists. Try to see if you can get a sense of consensus – that most of the team is with you. It will help move the doubters your way.
  2. Admit to a failing of agile development in your industry – perhaps the documentation requirements aren’t quite good enough, or the iterations might be too short. Then, talk about the benefits – faster response to change, better involvement from customers, faster starts. Most importantly, bring up the weakness before anyone else. Be honest about it, don’t try to sugarcoat it, and don’t try to hand-wave it away. Instead, say – this is a weakness, yes, but all these other strengths outweigh it.
  3. If the developers continue to resist, consider saying “this doesn’t have to be a permanent arrangement – why don’t we try it for a few iterations and see how it goes?” You want to concede a little bit here, in some meaningful way, but (the tricky part) without conceding so much that you end up losing the power of the combined agile techniques.

How to convince customers to support your agile process

  1. Point out that the customer will have exclusive access to your development group, and exclusive information about their status and their progress.
  2. Remind them of what they stand to lose if you go away for a year and end up building the wrong thing.
  3. Point out before they do that heavy customer involvement is a challenge and a sacrifice. Then point out all the good things that agile development will bring to them (insight, better knowledge about the progress, regular demos, etc), and say that the good things outweight the negatives.
  4. Ask for the maximum amount of customer involvement you could possibly want – for example, two of your people on site, all the time, dedicated to our project. If they balk, back down to something less stringent, but still effective – “well, what about 1 person then” or “How about two people, each half time”.

How to get the team to deliver their best

  1. Ask for their verbal (or even better) written commitment that they will do their best to get the project done on time. I personally would follow that up with my own commitment that I will hold true to the fixed scope of the iteration, and do my best to remove all impediments to progress, up to and including taking care of their laundry, bringing in food, etc.
  2. Be like them – if at all possible, find common ground. Make them feel that you are part of their “tribe.” They are much more likely to work hard for someone they respect and trust than someone they barely know and can’t relate to.
  3. Remind them of what they stand to lose if you are forced to go back to a waterfall process – death march deliveries, brittle designs without unit tests, weeks or months spent making no progress on the development while the clock ticks.

What not to do

  • Do not, under any circumstances, concede the core agile techniques away. If you do, you are inviting failure on many, many levels. Concede the duration and scope of the agile experiment, not the agile process. But don’t concede what you believe to be the keys to agility. I can’t tell you what those keys are for you, I can only tell you what they are for me (Iterative Dev, Unit Testing, TDD, Continuous Integration, paper prototyping, customer involvement or excellent customer proxies and user stories/informal use cases). If you trade those away, you’re effectively gutting the process. It would be better to just walk away than to pilot a project that is doomed from moment #1.

Thanks again for the time you took to read this, and let me know a) What you think, b) If you try it out and it works.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>