La suppression des silos ne se fait pas du jour au lendemain
Il s'agit du deuxième article d'une série visant à aider votre équipe d'ingénierie à effectuer la transition vers un modèle organisationnel DevOps. Nous verrons ici comment commencer à éliminer les silos dans votre organisation. Cliquez ici pour commencer par le début de la série, Pourquoi vous devez établir une culture DevOps .
Introduire une culture DevOps dans votre entreprise et briser les silos n'est pas la même chose que d'autres changements au sein de votre organisation. Vous ne soumettez pas de proposition et ne pesez pas soigneusement le pour et le contre. Si vous le faites, vous rencontrerez probablement beaucoup de résistance. Obtenir l'adhésion des parties prenantes de l'entreprise peut sembler presque impossible. Mais cela ne signifie pas que vous ne devez pas plaider en faveur du changement, vous devrez peut-être simplement adopter une approche discrète.
Il vous faudra beaucoup de patience si vous souhaitez changer l'état d'esprit de vos pairs. Pour ce faire, vous devrez commencer par établir des relations solides et leur enseigner des concepts avant de leur présenter les outils nécessaires aux tests et à la gestion de la configuration.
Commencez avec ce que vous avez
Les gens sont naturellement réticents au changement. Pour les chefs d'entreprise, le changement semble coûteux. Pour d'autres, il est perçu comme perturbateur. Votre meilleure option est de nourrir la culture préexistante de votre entreprise. Vous devrez leur transmettre les valeurs de votre entreprise et déterminer ce qui compte vraiment pour tout le monde.
Commencez par évaluer votre culture. Votre entreprise se concentre-t-elle sur le client ou est-elle vraiment une question d'argent ? Êtes-vous décontracté ou avez-vous un environnement d'entreprise classique ? Vos fêtes de bureau se déroulent-elles dans des verres solo rouges ou des flûtes à champagne en cristal ? Vos réunions de travail sont-elles consacrées à des parties de paintball ou à des parties de country club ? Il est important que vous preniez du recul et que vous trouviez comment faire la transition vers un modèle DevOps avec votre culture actuelle. Le changement ne se produit pas du jour au lendemain et il serait vain d'espérer que votre entreprise fasse rapidement un virage à 180 degrés.
Après avoir évalué votre culture, commencez à renforcer les aspects que vos coéquipiers apprécient et ceux qui correspondent à votre culture DevOps idéale. Ensuite, faites participer tout le monde à votre culture. Organisez des événements auxquels les équipes interfonctionnelles peuvent participer. Allez jouer au bowling ensemble, prenez une bière, mélangez les équipes et allez à un cours de paintball. Ou invitez-les simplement à une séance de brainstorming plus large juste pour entendre leurs idées et nouer des relations. Travailler ensemble est la première étape pour partager la responsabilité afin que vous puissiez réussir, et parfois échouer, ensemble.
« La bière est l'outil le plus puissant dans l'environnement DevOps. Invitez tout le monde au bar et laissez-les discuter. » – Ben Rockwood, Joyent [Source : Discours d'ouverture de la 25e conférence sur l'administration des systèmes d'installation de grande taille (LISA '11)]
Inspirez les autres en valorisant leur opinion et en les incluant.
En parlant de réunir des équipes interfonctionnelles pour réfléchir, inspirer et inclure les autres fera des merveilles pour briser les cloisonnements dans vos organisations. Dans une culture cloisonnée, il est facile de se sentir exclu. Cela conduit à penser que vos idées n'ont pas d'importance, que vous ne pouvez rien changer et, à terme, le fait de ne pas être inclus peut conduire à l'apathie.
Commencez par inviter les développeurs et les ingénieurs d'exploitation à discuter des exigences d'un projet. Ne déléguez pas les tâches, mais laissez plutôt les gens jouer un rôle actif dans la recherche de la meilleure façon d'atteindre un objectif. Le fait de participer et de jouer un rôle dans la prise de décision pour un projet créera un sentiment d'appartenance et de fierté dans son travail. Cela vous donnera la possibilité de reconnaître les contributions des gens pour renforcer encore ce sentiment.
Le fait de commencer par un seul projet ouvrira la voie à toute la culture d'ingénierie de votre entreprise. Cela permettra aux gens de suivre les projets depuis leur conception initiale jusqu'à leur achèvement. Cela permettra non seulement aux gens d'être fiers de leur travail, mais aussi de commencer à briser le sentiment « nous contre eux » qui règne souvent au sein des équipes de développement et d'exploitation. Il s'agit de réussir ensemble, et non de pointer du doigt quelqu'un lorsque quelque chose d'inattendu se produit.
Il suffit de poser une question ou d'inviter à une réunion pour susciter une conversation et impliquer les participants et leur donner un sentiment de responsabilité dans la réussite d'un projet. Vous ne trouverez pas seulement des solutions pour votre projet unique, mais vous commencerez également à identifier des processus et des tactiques pour travailler ensemble à l'avenir.
Montrer, puis raconter des concepts
Vous devrez adopter une approche de type « montrer, puis raconter » lorsque vous enseignerez des concepts. En montrant que vous donnez l'exemple et en démontrant la validité du concept, vous devez être réellement intéressé à aider vos collègues à améliorer leur travail en enrichissant leurs compétences.
Par exemple, si vous faites partie de l'équipe d'exploitation de votre entreprise et que vous souhaitez aider un développeur à être plus productif, vous pouvez lui montrer, puis lui dire, comment exécuter une commande. En apprenant de votre exemple, et non en vous contentant de lui expliquer, il sera plus susceptible de reproduire ces actions à l'avenir.
Vous devrez également éviter les mots qui peuvent avoir une connotation négative, avoir un sens vague, être associés à une mode ou être considérés comme un mot à la mode vide, comme « DevOps ». Si vous voulez vraiment avoir une culture DevOps, vous devrez la vivre pour lui donner un sens, pas seulement en parler.
Concentrez-vous sur les avantages de la collaboration et sur l'amélioration des méthodes globales de prestation de services, comme l'envoi plus rapide de fonctionnalités aux clients afin qu'ils ne vous dérangent plus, lorsque vous devez utiliser des mots pour renforcer ce que vous leur avez montré.
Trouvez vos défenseurs
À présent, vous avez réussi à faire travailler votre équipe ensemble, vous l’avez inspirée et vous lui avez même appris quelques nouveaux concepts pour ajouter de la fluidité à leurs rôles. Avec un peu de chance, vous avez également appris quelques nouvelles astuces en cours de route. Après tout, c’est une voie à double sens.
Malheureusement, votre travail est loin d'être terminé. Il est fort probable que tout le monde n'ait pas été réceptif à vos invitations ou à votre collaboration. Tout le monde n'était pas ouvert à l'apprentissage. Si c'était aussi simple, tout le monde n'utiliserait-il pas un modèle d'organisation DevOps ?
Pour combattre leur apathie pour la cause, vous devrez trouver des défenseurs dans différentes équipes pour vous aider à enseigner et à faire connaître vos idées. Pour qu'un changement de culture ait lieu, plusieurs personnes devront commencer à le défendre. Trouvez ceux qui semblent les plus réceptifs à vos invitations et à vos enseignements, puis recrutez-les.
Pour les sceptiques, aidez-les à comprendre (peut-être autour de quelques bières) comment la transition vers un modèle opérationnel DevOps aura un impact direct sur leur vie. Discutez de ce que chaque équipe souhaite et attend de l'autre et demandez-leur de défendre leur point de vue en rassemblant tout le monde pour commencer à résoudre les problèmes ensemble dès le début.
Les défenseurs de l'innovation peuvent rallier davantage de membres de leur équipe en les rassurant sur le fait que la transition se fera en tenant compte de l'avis de tous. En impliquant les gens dans une collaboration honnête et bénéfique, vous serez enfin sur la bonne voie pour créer une véritable culture DevOps.
Mise à jour du 10/04/14 – Suite de la lecture de la série sur la transition vers DevOps :