Show (Don't Tell), Persuade (Don't Preach)

Welcome back to another episode of The Agile Guerilla series. The focus of this series of articles is to to help you introduce change, specifically moving to agility, into your organization from the grassroots level.

In our last episode, we defined guerilla warfare and looked at why using guerilla-like tactics can be an incredibly effective way to spur on an agile transformation from the bottom up.

In this episode, we'll zero in on the two fundamental tactics employed by the agile guerilla: demonstration and persuasion.

Demonstration

Consider the task of purchasing a new car. What is it that really sells the car to you and makes you want to take it home? Is it the salesman standing there droning on and on about all of the car's features? Or is it the test drive, where you get to see and feel the car in action? The smart salesman gets you behind the wheel of the car as soon as possible.

Why this works has little or nothing to do with cars. It's the principle of demonstration. When we can actually see and experience something, it becomes real to us. We can see ourselves owning or doing that thing.

You can apply this principle to your agile transformation goals. Let's say you've been reading about agile (that's what you're doing right now!) and you've come across a new practice - perhaps continuous integration - that you think will be a real benefit to your team. How are you going to get your team on board? Do you stand up at your next team meeting and summarize Martin Fowler's article on the subject? Do you count off all of the great features of Hudson and describe how they'll fix all of your team's problems?

Let me tell you from experience - that doesn't work!

Before you ever say a word about continuous integration to your team, you need to do it yourself first. Learn the techniques inside and out. Install Hudson on your own workstation and experiment with its features. Set up your current project in it and have it start building every time code gets checked in. Connect Hudson to your company's mail server (or if that's a non-starter, go with GMail!) and start the build notifications flowing.

Now, the next time the build fails, walk over to the poor guy that committed the code with a printout of the email (I know we're trying to go green, but forwarding the email won't work! You've got to have a face-to-face.) and say, "Hey Joe, I've got this new tool that monitors our project and it says the code that you just checked in doesn't compile. Do you mind taking a look at that?" That's it - no confrontation. Just state the facts. Keep doing this periodically. Before you know it, folks are going to start begging you for those emails. Politely add them to the list and pat yourself on the back. You've just infected your team with continuous integration.

This is just one example among many. Here are the general keys:

• Learn the techinique and then do it yourself FIRST!
• Show your team the new technique, don't just tell them about it!
• Contrast how well it works with the your current way of doing things.
• Look for opportunities where it may help and jump in!
• Do your homework!

The bottom line: Show, Don't Tell!

Persuasion

Let's get back to the car purchase. Does the successful car salesman talk your ear off about how he's going to spend the fat commission check he'll take home from the deal? Does he whine about how he hasn't sold a car in weeks and how he needs you to sign on the dotted line so that he can make the rent? Or does he look you over, listen with attentive ears, try to figure out your needs, and then speak your language?

When you're trying to communicate effectively, you've got to speak your recipient's language. Not only that, you've got to speak to their his needs.

Your fellow geeks...err developers...speak your native tongue, so they're going to be the easiest to work with. However, introducing new practices across a team will generally take you outside the team to get buy in if you're not in an agile shop. You'll have managers and team leads to think about, and even customers (think user stories and customer tests!). You could preach and preach and preach about how technique X is the right way to go and will make your life as a developer so much easier, but you won't be very effective.

What are your manager's interests? Typically they're pretty basic. He wants to bring your project in on time, on budget, and at the specified level of quality. Unfortunately it's fairly doubtful that he's terribly interested in how clean the code is, and he's probably none too thrilled about two developers working on the same feature (i.e. pairing). So selling a practice that appeals to other developers in a developer's language isn't going to work with him. Tell him how your new technique will increase the likelihood that you'll deliver on time...or early. Explain how this new tool will save her money. Share with him how automated tests can prevent defects from leaking into production. Now you have your manager hooked - reel him in!

What about your customer? What does she want? If she's like my customers, she wants features and she wants them now. He's also interested in saving time and money, but its the features that he's really after. They need to work, and they need to work the way she wants them to work (and not necessarily the way she told you she wants them to work). How do you scratch his itch? How about explaining how frequent, iterative releases will get features into his hands faster? How about sharing the fact that more frequent demos will make sure things get done right the first time? You see? It all gets back to value. Figure out what your target audience values, and then sell your technique by showing how it gives them that value.

The bottom line: Persuade, Don't Preach!

Well, that about wraps up this installment of the Agile Guerilla series. Next time we'll look at some practices that you might not have thought about that are guaranteed to make you more agile. Until next time!