I am here with Linda Rising, author of the Patterns Almanac and a few other great books, recently Fearless Change. Linda, can you tell us a little bit about yourself and introduce Fearless Change?

I live in Phoenix, Arizona, which is a long way from where we are now - we are in the beautiful city of London, where the weather is not quite as warm as it is in Phoenix, but it is one of my favorite cities, so I am certainly enjoying it. I am an independent consultant and my main interests right now are in patterns, retrospectives, Agile processes - which is one of the hot topics, here at this conference - and change, and most recently primates and the brain.

Recently, in 2005, you wrote a book called Fearless Change. Could you introduce some of its concepts to us?

I gave a tutorial on that a couple of days ago, so I can tell you a little bit about what happened in the tutorial. It is a book about introducing new ideas and it is based on my experience and the experience of all the contributors because a patterns book has to be written by a community, so it is not just my experience. But in trying to get other developers to use patterns, specifically in 1994, we were looking at the design patterns book - the GOF book - and I was trying to get my team members to use patterns and I thought "Well, I bet there are patterns for introducing patterns." and that is how it started.

And over the course of many reviews and trips to patterns conferences people pointed out many things to me that were startling. One of them was that these are not just patterns for introducing patterns, they are patterns for introducing any new idea. So now, when we teach the tutorial, my co-author Mary Lynn Manns and I have a play, we act it out. What we are introducing in our play is Agile development, which is fortunate because right now the Agile community is struggling, there are a lot of people who are excited about it, but they don't know how they will get it going, and that is exactly what this book addresses: it is a collection of patterns for getting things going in your organization, whether it is Agile development, or patterns or some new programming language, or a new programming environment, could be anything.

Can you walk us through the patterns in an applied way, maybe give us a scenario of something being introduced and how will that actually play out using the patterns?

Let's suppose I went to QCon in London and I encountered for the first time some startling new ideas and I got very excited about it and I believed - here is the first step and the first pattern - I sincerely believe that if my team started using this particular practice or tool, or language, or approach, or whatever it was, that things would be better. Now, that pattern is called evangelist and it means that, when you go back and talk to your team, if you are just blowing smoke they all know that and they think "Oh, well, Linda is just talking about patterns because she is hoping to get the award for chief technical innovation of the year" or "She wants a raise" or "She wants a new salary level, or a promotion of some kind". Somehow people pick that up. If you don't sincerely believe that this is a good idea and that is why you want your team to do it, and that is why you are excited about it, then you might as well stay home - so pattern number 1.

When you go back to your team and you start talking about this on Monday morning, there are some people, that you are going to run into, that just love new cool things; it doesn't matter what it is, they like it because you heard about it in QCon and because it is the latest and the coolest. Those people are called innovators - that is the name of the second pattern - and those are the people you talk to first, because they get excited, they will talk to their friends, they will generate a little buzz around the topic and maybe even have some ideas for you about how you might get that going on the team - "Hey, maybe we could try doing pair programming! Just try it out! See what that is like." So you start talking to the innovators and you know who those people are; in your team or your organization people like new cool things.

The next pattern you might use in this little scenario is "Let me get all my team members together over lunch, and maybe I won't do a little PowerPoint or anything, I will just talk about it. I will tell them why I am excited, tell them I am not an expert but I think it would be a great thing for our team to get involved with whatever this is." That is called brown bag, and everybody is going to bring their lunch and they are going to hear about the new idea but it would be good if you brought something and that is culturally dependent, so, maybe your team likes chocolate chip cookies or banana bread or whatever it is, so you bring that. Now, that is a pattern that has been around for a long time and when Mary Lynn and I wrote it, we thought "Yes, it is a good idea, because people like food and it is a fun thing", but now, that I am interested in the brain, which has happened in the ten years that I was involved in writing that book, what I have learned is that we are hardwired to be more open when we are eating.

Do you have evidence that we are hardwired to being more open when we are eating?

Sure, there are many experiments and there are all sort of variations on the theme of this kind of generic set up. They took two groups of people - the one that I am remembering particularly had to do with political issues - and they tried to convince the group of people one way or another on a political issue. They have two balanced groups, about the same size, same population, give the same presentation to both. One group gets the chocolate chip cookies. Now the question is which group supports the issue? What do you think?

The one with the cookies?

Yes. Notice it has nothing to do with the quality of the idea. So one thing that people ask when they take the Fearless Tutorial or when they read the book and they read about the brown bag or the "do food" pattern they think "Well, I still believe that is depends upon the quality of the idea. If it is a good idea, OK, bring in the cookies and people will sign up". But what if it is a really bad idea? Will the cookies work even if it is a bad idea? I answer that question with another question which is "Can you think of a time when there were competing ideas - a good idea and a bad idea - and the people behind the bad idea were masters of the patterns which really sit on influence strategies, so they were masters of influence? Can you think of a time when a bad idea won because the people behind it were masters of influence?

Maybe even in the US, maybe even in the last two elections, when a whole country was somehow influenced to adopt a lot of bad ideas? And history is littered with examples, even technical ideas which were bad won out over good ones, because somebody behind it knew about bringing in the cookies and all the other patterns that are involved in convincing us. So when you tell to technical people that at first, they don't believe it. They say "It has got to do with good ideas and whether people care about what they are doing". If I want to sell patterns or Agile processes, I am going to convince people by telling them that it is a good idea and explaining why it is a good idea and it turns out that is not convincing at all.

Continuing with the scenario, how do you convince them to take an idea?

You bring in the cookies and some people will be convinced just because they are innovators and they like new ideas and some people will be convinced by the fact that the innovators are excited and you brought in the right kind of chocolate chip cookies, so you are slowly making headway. Other people on the technical environment are often convinced because they are early adopters and they need evidence.

So you might have a book, that you bought at QCon, about DSL or whatever the practice is that you want to introduce, and you say "Look, I have got this book, written by Martin Fowler who is a really famous guy and everybody has heard of him", and for some people that is convincing, the fact that there are experts who have written books or you might have some articles that you picked up in your presentation or tutorial that you attended and so that is sort of external validation -that is the name of the pattern-. People are convinced by a publication, a sort of a certification, a stamp of approval.

If Addison-Wesley or InfoQ published this, it must be OK, so it is convincing to them. Some people look to that kind of influence. So you have got the innovators, who like new things, you have got the people who sit down and eat chocolate chip cookies, you have got the people that like external validation, you are building steam, you are gaining ground. So, what convinces other people, in your experience? What convinces you? A good technical argument.

And some people want to see a good technical reason. There are certainly technical people who may believe that this is what they want to see, but you can forget about that. So one of the things that you can do in your brown bag, while you are serving the cookies, is actually go through some of the technical arguments for the good ideas. And some people will be convinced by that. Other people, who like technical arguments, are still not going to be won over unless they know that there is a local guru, someone they all respect - every organization has someone like that - and if they know that that particular guru says "You know, this stuff sounds pretty good. I think it looks like we might try it at least."

Is one of your patterns "Convince the guru"?

Yes. It is called "guru on your side". So, if you have the brown bag, the first person you might invite would be the local guru and give it a little head start because gurus do not get to go to conferences. They are too valuable. They are always working on 6 or 7 projects and they are loaded with deadlines, so they never let them out. They want to hear about this stuff, so you can overwhelm them, you can make them feel bad that they didn't get to go to the conference, but you give them a little preview, so when they come to the brown bag they already know enough, so they can nod at the right time and validate what you are saying and everybody in the room will be looking to the guru and say "Wow, he likes it, and we are having cookies and the innovators are excited" so they get caught up in that.

What comes next? Once you have had your meeting and you have raised the buzz, then what?

Nothing convinces people more than experience. And of course, you have just been at QCon and you have never done Agile development or whatever the new thing is, so you get maybe some available innovator, or maybe now somebody who is a little more open and say "You know, maybe we could try, just an experiment, pair programming. I am working on this particular part of the project. Would you like to try that with me? And then we could see how it works for us, so a little trial run, just a little experiment". And then, if it works, if it really does work, you have an ally because the two of you have tried it.

The friends of the ally who can hear "Yes, we tried pair programming, and here is what happened, and we really did discover something new that none of us would have thought of on our own. There really is benefit. Maybe we should try this on a larger scale". So a little experiment and then tell everybody about it, maybe have another brown bag to say "Hey, Floyd and I have been trying this pair programming and here are some of the benefits that we have seen. Maybe the rest of you would like to do, just try it. It is just an experiment" - so trial run. People are afraid of change, they don't want you to come in and say "We are going to do something totally different. Throw out everything you are doing now and we are going to do Agile stuff". Most people like to try something in the way of an experiment, and once they have tried it, not only is the experience convincing but - again this is a brain thing - why do they, when you go in to buy a new car, let you drive around the block? Because somehow that is your car, just for a little bit. And once you have tried it, you are more likely to buy it.

When you go buy a suit, or a jacket you are going to try it on. If they don't let you try it on, you are not likely to buy it. If they let you have the time and the space to try it on, see how you like it, you are much more likely to buy it. No pressure: if you don't like it, you don't have to buy the jacket. But if you try it on, they know you are very likely to take it home. So you get the innovators, the guru, all the people who follow the guru, people like chocolate chip cookies, people are convinced by reports of success, and then, of course, you need to try it full blown, pilot, have somebody try it on a real project.

Help them out and you learn yourself how it works out, and stay in touch with everybody, tell them you are doing this. Don't make it a special thing, you know, like pilots backfire most of the time is that they hand pick people and when it works no one is surprised and say "You put Floyd on that project, no wonder that worked. But that wouldn't work for my project". So it is just got to be a sort of an experiment for that project with just ordinary developers on it, ordinary scenario, nothing critical risk. They will try it for an increment or two, then let them tell us how it works.

How do you report the success of the pilot projects in the manner to create change?

One of the things that you want to do is make sure that nobody is afraid. So you don't make a formal presentation, make sure you have cookies. You just have people talk about what they have done - this is actually another pattern called "Hometown Story". You don't want the people around the project to be afraid to get up and talk about it, you don't want the people who are coming in to you to be afraid to ask questions, so the whole experience should be as informal as possible and you should make sure that people talk about it. One of the things you can do is enlist - you have the innovators on your side now and the guru. There are people who are called "connectors" - it is from Malcolm Gladwell's book, The Tipping Point -, there are people who know everybody.

In the organization where I was working with patterns, we had a music club and a flying club, well this was Arizona so we had a gun club and a horse riding club, and a golf club, and there were people who joined lots of those clubs. Now you are not just with the people who are on your team, when out to play golf you talk to people round lots of different projects and, in fact, if you belong to several clubs, you could pretty much cover the entire organization, with your golf team and the golf teams you are playing against in the tournament. What do you talk about when you are playing golf? Well, you talk about golf, and your family, of course, but you also talk about "Hey, what is going on with this stuff? I hear Agile.

What is that? And pair programming? Come on, are you really sitting in pairs? And who is typing? I mean how does that all work out, because I want to know!" They want to know what is going on and they want to know and they want to know in that casual setting, where nobody is going to pressure them to do something about it, they just want to hear the gossip. The connectors know everybody and, of course, you know who they are, because they also know you, and so you talk to the connectors and you tell them what is going on, so when they play golf, or work out at the shooting range they can tell all their friends. Managers often worry about something called "knowledge management", and they say "What we should have is some databases.

Let's have some knowledge management tools, and that will enable us to have knowledge spread throughout the organization". And I say "Well, that is not the best way. Think about the time when you had a meeting and you talked about secret stuff, like impending layoffs, and someone said, in the course of the meeting 'Now, this information is not to leave this room'. How long does it take, from the end of that meeting until everybody in the organization knows what happened in that secret meeting? Not very long. How does that happen?" Well, they play golf, they gather at the water cooler and then they see each other at lunch, and everybody knows that this thing is going on, they ask "Did you hear what happened in that secret meeting?". Important stuff makes around and is usually through the connectors, so toss to the connectors.

What is the strategy to talking to the connectors in terms of idea, the option?

Well, the strategy would be to involve them. In fact, I talked to a guy once at a conference - it wasn't QCon - and he came out to me and said "Linda, I bought your book. I am trying out those patterns." I said "Great" and he said "Well, I hate to tell you this, but they don't work". "Thank you" I said, "I love to get feedback on my book. Tell me about the patterns: what is not working?" So he started to talk about his change effort: "I had a brown bag, I brought in the chocolate chip cookies" and then, as he was talking, I had a vision of a man coming in on a white horse and saying to the great unwashed "I am here to save you! I know the one true way! I have the answer for all your problems.

If you just listen to me, I know all about Agile development and I will tell you the secrets." So you wonder: why wasn't he successful? He didn't know the pattern called "ask for help" and he didn't talk to the connectors. He probably didn't talk to the guru. He might have invited the guru to the brown bag, but he didn't really understand that the important way to spread an idea, is to get people personally involved. And you have to make them feel that they are not only involved, but they own a little piece of it. That is why, when you pair with the innovator, the innovator has a little piece of that idea, the innovator becomes an evangelist, you are spawning yourself all the time, you are spreading the enthusiasm by saying "It is not just about me, it can't be just about me!

Look at these other people who are also involved and who are doing it!" and you let them have a brown bag and you let them go to the conferences and you let them talk about it. The idea is not just about you, so you have got to get down from the white horse and ask for help. So, when you go to the connector, you say "You know, I've been thinking about this idea, we are trying some pairing. Do you know anybody else who would like to be involved in this?". He says "Yes, I know. I have talked to Fred and Joe, back at the golf club, I bet they would like to hear more about Agile!". You use their talents and skills, get them involved any way you can.

How do you deal with the vocal skeptics?

That is always going to be something you'll have to think about: that no matter how great the idea, how many wonderful patterns you have, there are always people who have negative things to say. So the name of the book is Fearless and that is one of the most important patterns in the book, which says that, if people come up to you and they have things to say, you should listen. I talked to a guy once who was working in an organization in Washington DC, at the last Agile conference, and he said "I am trying to get my team to adopt Scrum. There is a guy in my team that keeps saying the same thing over and over: 'We did that already. We tried that and it doesn't work'".

I said "You are lucky. You should sit down with that guy. You should buy him a cup of coffee and say 'Hey, Floyd, did you really do this? What happened? I want to know', because, if he is telling the truth, he can probably give you some of the most valuable information about Scrum, or what they did and your team and your organization that might really help you. And not only that, if you listen to him, really listen, just doing that might make him be, at some point, one of your greatest supporters. So that's always the first step: just listen, pay attention. Don't prepare your argument, don't argue back, just listen and use that information, it's valuable. And maybe he is right, maybe they did it, maybe it didn't work. You should know that."

What led you to write Fearless Change and what was the influence on your life?

In the beginning, all I was thinking about was patterns. In 1994, I bought the Gang of Four book and I brought it back to my team and my question was "How do I get the rest of my team to use design patterns?". I was a designer, I have a PhD in computer science, I am very technical person, that is why I was interested in good technical solutions, and that is what patterns are. In the process of trying to introduce it, trying to convince my team to use design patterns, I slowly began to think about "How is it that people solve problems?".

I mean that is what patterns are supposed to do: a solution to a problem, in a context. How is it that people solve problems? Are patterns really a good way to do that? How do people think? How do people listen to other people? And how do I help someone else solve a problem? How does that communication or interaction take place? What is going on there? Over time I realized that, what is fascinating to me now, is how our brains solve problems, how our brains influence other brains, something I never cared about before, that in all the years that I've gone to school and collected an enormous number of degrees.

I took one psychology course only because I had to, and I hated it, I thought it was boring, but as my husband points out, "The reason you are interested in all this brain stuff now is because it's not fluffy anymore, it's technical. You can actually put somebody in a functional MRI scan and you can look at what part of their brain lights up when they are being influenced by advertising, a can of Coke". It is not fluffy "Oh, let's sit around and observe a bunch of people and make some conclusion" anymore. It is about hardwiring, it's about really the neuron firing, it's really about identifying the parts of the brain that are involved in memory, in problem-solving, and it turns out that there are a lot of deep connections to the way we are at Agile software development. Who would have thought about pairing?

And our connection to bonobos -who would have thought these things were all linked together? So now when I say what am I interested in and what do I do, I don't develop software anymore. I help people develop software, and I do retrospectives, and I think about things that I would have been amazed of if you had told me in 1994 that I would be thinking about today. So Fearless Change changed me. Incredible journey!