Devops for Growth

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

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

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

• CONCEPTION (Niveau CONCEPTUEL)
  
  (3) La collaboration avec les clients plus que la négociation contractuelle
  
  • (6) La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  • (4) Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
• ORGANISATION (Niveau LOGIQUE)
  
  (1) Les individus et leurs interactions plus que les processus et les outils
  
  • (1) Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  • (3) Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  • (8) Les processus Agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  • (5) Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  • (11) Les meilleures architectures, spécifications et conceptions émergent d'équipes auto organisées.
  
  (4) L'adaptation au changement plus que le suivi d'un plan
  
  • (2) Accueillez positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement.
  • (12) À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.
• RÉALISATION (Niveau PHYSIQUE)
  
  (2) Des logiciels opérationnels plus qu'une documentation exhaustive
  
  • (7) Un logiciel opérationnel est la principale mesure d’avancement.
  • (9) Une attention continue à l'excellence technique et à une bonne conception renforce l’Agilité.
  • (10) La simplicité - c’est-à-dire l’art de minimiser la quantité de travail inutile - est essentielle.