Cas 1

Développant la plateforme Internet & Mobile Banking d'un groupe bancaire français, l'équipe était particulièrement satisfaite de ce grand moment qui visait la mise en production généralisée de la solution, un grand moment préparé avec soin pour que la nouvelle solution soit disponible sans aucune interruption de service. Les meilleurs spécialistes de Paris avaient convié les meilleurs spécialistes de Bruxelles et tout ce beau monde était prêt à poser les actes qui avaient été souvent répétés avant le moment fatidique. La seconde du grand basculement arrive et … tout se passe comme espéré ! C'est formidable. Le champagne coule et l'anxiété fait place au soulagement. Gavés de petits fours, la bouche pleine de sourires, l'équipe de Bruxelles se met tout doucement en ordre de retourner vers la Belgique quand une alerte se fait entendre après 1h ou 2h de fonctionnement fluide. C'est un opérateur de Paris qui s'étonne d'une forme de ralentissement d'une des fermes de serveurs. Tout le monde fait mine de s'y intéresser de manière affairée mais au fond parfaitement distraite. Quel est ce grain de sable qui grippe la machine ? Le phénomène échappe à la reconnaissance d'un problème classique; il est inexplicable et … il commence maintenant à se répercuter sur la deuxième ferme de serveurs ce qui commence à sérieusement inquiéter ceux qui étaient restés fêter le digne événement. Il ne faut qu'une partie du temps pour que le problème infecte maintenant la troisième ferme (il y en avait 4 pour un total de 84 serveurs) et avant qu'on ne connaisse la nature du problème la 4ème ferme est à son tour touchée, tombe et fait s'effondrer tout l'édifice. Nous sommes à ce moment-là sans plateforme bancaire pour le grand public, une situation parfaitement gênante. Les plans de rollback sont déroulés ce qui permet de rétablir le service, l'ancien banking. La perturbation aura été réelle, certes, mais temporaire. La cause ? Des traces / logs qui ont complètement rempli l'espace disque ! Ni plus, ni moins ! L'espace disque devenu rare, les activités de garbage collection étaient devenues singulièrement plus lentes jusqu'à rendre indisponible la première ferme. La charge étant alors repartie sur 3 fermes au lieu de 4, chacune était maintenant sollicitée davantage générant le même comportement que celui observé pour la ferme #1 mais plus vite. Le reste de l'histoire se devine aisément : une deuxième ferme tombe et le problème se reporte sur celles qui restent, accélérant de plus belle.

Quel est le lien avec DevOps ? C'est très simple : si nous avions embarqué les opérateurs dans le processus de développement, le problème se serait présenté bien avant, et sur des environnements de test au lieu de la production. À l'heure H, nous n'aurions pas connu cette déconvenue assez frustrante.

Cas 2

Le cas 2 est finalement la suite du cas 1. Les traces étaient générées par des appels à une fonction unique : le code en était truffé. Il y avait bien une paramétrisation possible, on ou off, mais sans aucune autre granularité que celle d'un système binaire. L'équipe de développement s'est alors saisie du sujet et a fait œuvre de finesse dans la manière de générer des traces en utilisant une sorte d'Error Level. Plus le niveau était élevé, plus les traces étaient abondantes. Parfait.

Un nouveau jour J a alors été décidé entre Paris et Bruxelles, un nouveau déploiement, bien moins festif que le premier, question de mauvaise expérience passée j'imagine. Ce nouveau déploiement a été un succès. Aucun doute là-dessus. Cependant…

La nouvelle plateforme est donc disponible et est maintenant active depuis 1 ou 2 mois quand nous recevons un message inquiétant ramené au support technique parisien par un client qui a vu des mouvements affichés dans son relevé d'opérations n'appartenant pas à son compte (juste l'affichage, heureusement). Que s'était-il passé ? C'est justement dans cette enquête que je puise mon deuxième exemple DevOps ^[3] : les opérateurs parisiens voulant retracer les opérations effectuées par le client pour déterminer la cause du problème en étaient réduits à consulter 84 fichiers de logs différents, 1 par serveur, si bien que suivre la totalité d'une opération de A à Z impliquait des recherches archéologiques synchronisées sur 84 sites différents, avec le début de l'opération sur la machine X, la suite en ordre dispersé sur d'autres machines et la fin sur la machine Z. L'enfer ! Là encore, aurions-nous été structurés en mode DevOps que nos opérateurs nous auraient tout de suite informés de la complexité du suivi des logs. Nous aurions évité une nouvelle frustration et une frayeur peu commune qui a d'ailleurs nécessité un retour temporaire à l'ancienne plateforme et à une forme de compromission de la confiance de Paris à l'égard de Bruxelles !

Conclusion

En incorporant les opérateurs dès le développement de la solution, c'est-à-dire dès la collecte des exigences, vous vous épargnez bien des frustrations et désillusions ultérieures parce que vous aurez pu anticiper les problèmes qui ne seraient finalement jamais apparus, du moins pas en production, là où ils coûtent jusqu'à 500 fois plus chers à résoudre.

C'est ce qu'Yves Morieux et Peter Tollman ont exprimé dans leur excellent livre Six Simple Rules, How to Manage Complexity without Getting Complicated. La règle numéro cinq : Extend the Shadow of the Futrure. Cette règle crée des boucles de rétroaction en exploitant l'effet du temps. C'est une observation sacrément simple pour comprendre l'importance de ce qui se passera demain suite à ce que nous faisons aujourd'hui. Par conséquent, nous devons créer les boucles qui font que les gens ressentent les conséquences de la façon dont ils gèrent les choses aujourd'hui. J'aime cette façon de le représenter : faire en sorte que les gens marchent dans les chaussures qu'ils fabriquent pour les autres.

Selon Morieux et Tollman, ces boucles de rétroaction sont bien plus préférables et efficaces que l'utilisation de la supervision, des métriques et des incitants. C'est ce que DevOps apporte à l'organisation et le sentiment d'accomplissement dans L(i)VID.

Vertues attendues

Production-ready

Lorsque les équipes doivent opérer elles-mêmes les solutions qu'elles développent et lorsqu'elles sont secondées par des ingénieurs de l'exploitation le code informatique produit contient d'emblée les éléments qui vont faciliter les opérations de maintenance et de contrôle. Ce sont les cas #1 et cas #2 dont je parlais ci-avant. Les considérations principales des Ops sont prises en compte dès la collecte des besoins, et elles font l'objet de tests. Elles sont donc éprouvées d'abord dans des environnements où les dégâts occasionnés sont mineurs. Le temps agit également comme révélateur et lisseur : plus le cérémonial se répète, plus de problèmes sont révélés, souvent d'ailleurs de manière notablement fortuite, sont adressés et résolus et ensuite contribuent à immuniser les développements futurs.

Résolution AVANT problème

Quand les problèmes de production deviennent aussi les problèmes de l'équipe qui a développé les solutions, on assiste à une forme de créativité préventive : on crée des procédures qui vérifient l'espace disque, la mémoire disponible, la charge sur l'application, on invente des messages de service, … Les programmeurs ADORENT ça ! Ils ont l'impression de créer des objets vivants. À l'utilité ils joignent l'agréable.

Transparence

Personne ne veut que son temps personnel soit interrompu. Celui qui prend les appels fera tout son possible pour éviter de les recevoir en premier lieu. Vos équipes souhaiteront naturellement une plus grande transparence dans l'environnement et mettront en place un suivi proactif afin de pouvoir identifier les problèmes ou les tendances inquiétantes avant qu'ils ne se généralisent. En plus de permettre de détecter les problèmes avant qu'ils ne se produisent, ce type de transparence devrait permettre de trouver beaucoup plus facilement les causes profondes des problèmes qui persistent.

Autonomie et sens

Être au contact direct du client est une expérience dont bien des informaticiens n'ont jamais fait l'apprentissage. C'est très enrichissant et très responsabilisant. Cela donne du sens au travail réalisé et fait prendre conscience que le code informatique produit est un objet vivant dont le client se saisit pour effectuer un travail qui, pour lui, est important. C'est son JTBD — Job To Be Done à lui. Cela augmente aussi l'autonomie de chaque membre de l'équipe, ce qui n'est pas sans rappeler le concept MAP — Mastery, Autonomy, Purpose.

Dev et Ops : le mur tombe

La compréhension des problèmes des autres (utiliser soi-même les chaussures qu'on fabrique pour les autres) c'est faire tomber le mur entre les Ops et les Devs. La compréhension va dans les deux sens et ne se limite pas à l'entendement des objectifs des autres mais aussi de leurs contraintes. Les gens se parlent et continuent à se parler par la suite, pour d'autres activités. La communication quitte de plus en plus le formel et migrent vers l'informel.

Qualité opérationnelle; problèmes en baisse, satisfaction et confiance en hausse

Comme le disait Adrian Cockcroft, les développeurs détestent être dérangés à 3 heures du matin. Les problèmes sont anticipés avant leur apparition (alertes générées en console avec interventions préventives) ce qui diminue sensiblement le nombre d'incidents.

La satisfaction de l'utilisateur final s'en trouve améliorée et avec elle sa confiance dans l'entreprise. Une autre confiance est en hausse : celle du Business vis-à-vis de l'IT.

Automatisation

Les développeurs détestent les tâches manuelles répétitives, donc s'ils découvrent qu'ils doivent faire quelque chose encore et encore en production pour résoudre un problème, ils ont l'envie d'en trouver la cause et d'automatiser la solution. J'ai même vécu l'expérience d'un groupe qui, au contact d'un API de virtualisation, s'est trouvé à engager des appels pour … augmenter la mémoire dévolue à la machine virtuelle sur laquelle leur appli tournait, à augmenter la puissance des processeurs, leur nombre, l'espace disque, etc. puis à relâcher les ressources quand elles n'étaient plus nécessaires. Les développeurs ADORENT automatiser et, soyons de bon compte, les ordinateurs sont des machines à automatiser !

Qui est de garde ?

Le succès de Netflix est planétaire. Ce succès, la société le doit à sa grande maîtrise technologique qui lui a permis de migrer d'une entreprise de location de vidéos pour être aujourd'hui l'une des plateformes leader de services de streaming. En matière de Transformation Digitale, je pense que nous avons là l'exemple archétypal !

Un des architectes, sinon THE Architect, qui a été mis à contribution pour entamer la grande migration d'une infrastructure dédiée, avec ses propres centres de données, vers une architecture Cloud est Adrian Cockcoft. Il s'exprime ici sur le mouvement DevOps et ce qui a été le positionnement de Netflix sur le sujet :

Voici la traduction de transcription de ce que dit Cockcroft entre 38min 45sec et 40min 37sec dans la présentation, :

Je travaillais sur la migration de Netflix dans le cloud et, en 2006, […] les développeurs créaient des produits et les utilisaient en production. C'est ce que la plupart des gens appellent maintenant DevOps. Il y a deux versions de DevOps, mais la façon dont Netflix a abordé le problème était que les développeurs sont les propriétaires de leur code en production, donc nous avons construit un système qui était supporté par tout le monde. Cela signifie que vous pouvez faire plusieurs modifications par jour et que la personne qui connaît l'état actuel du système de production est le développeur qui le modifie. Il n'y a donc pas de silos, pas de réunions, pas de tickets à remplir, et tout le monde est propriétaire de tout, tout au long du processus. Alors, mettez les développeurs on call et comment faites-vous pour que les développeurs soient on call parce qu'ils disent je ne suis pas devenu développeur pour être on call ? C'est souvent la réponse ! Eh bien, demandez au vice-président de l'ingénierie qui dirige le développement, vous le mettez on call, et vous mettez tous les directeurs en garde et vous mettez tous les managers en garde et ensuite vous mettez les développeurs on call et vous dites au programmeur si vous ne décrochez pas le téléphone quand le système subit une panne à 3 heures du matin comme c'est toujours le cas, la prochaine personne dans la cascade est votre manager et s'il ne décroche pas le téléphone, on continue l'escalade jusqu'au plus haut niveau. Vous avez donc maintenant un système qui fait que les gens (1) écrivent du code qui ne se casse pas à 3 heures du matin et il s'avère que les développeurs sont très bons pour écrire du code qui ne se casse pas quand ils sont on call. C'est une boucle de rétroaction très puissante et l'autre chose que vous trouvez, c'est que les gens n'aiment pas réveiller les supérieurs, le management, parce qu'ils ont « merdé ». Il y a donc une très forte incitation à suivre cette voie.

Pas de solution miracle

Il est naïf de penser que le rapprochement entre les ingénieurs d'exploitation et les programmeurs est la réponse à tous les problèmes. Ce n'est évidemment pas le cas.

L'immersion temporaire, ou de plus longue durée, des Ops parmi les Dev est par contre une vertu qui n'a jamais été prise en défaut, du moins lorsque les groupes ainsi formés ne devenaient pas à leur tour des silos.

Ce cas de nouveaux silos peut se présenter lorsque les Ops deviennent plus préoccupés par le succès de l'équipe dont ils font maintenant partie que par leurs préoccupations de la bonne gestion de moyens mutualisés. Les silos qui sont tombés réapparaissent alors, ce qui est un comble.

L(i)VID, pour éviter cet écueil, recommande des tournantes de Ops parmi les Dev de telle sorte que les équipes puissent garder le contact avec des infrastructures partagées, ne fût-ce qu'au niveau physique et cela même si la tendance, comme en tout, est de dématérialiser le … matériel. L'apport régulier de nouveaux points de vue permet de garder l'équilibre souhaité entre Dev et Ops.

Les 4 étapes du modèle de Tuckman

Le modèle de Tuckman sur Wikipedia : Tuckman's stages of group development

Forming

La formation d'une équipe est presque l'étape la plus facile du processus. La composition de l'équipe n'est que très rarement optimale. En général, les membres de l'équipe sont attribués plutôt que choisis; ils le sont souvent sur le critère de leur disponibilité et non sur leur apport adapté potentiel à la tâche à réaliser. Pour ces raisons, et d'autres inhérentes au fait que les hommes et les femmes sont des êtres imparfaits, une équipe est presque toujours intrinsèquement dysfonctionnelle.

Néanmoins, à ce stade, il règne une atmosphère en général positive et polie, les gens sont agréables les uns avec les autres et ils ont des sentiments différents d'excitation, d'enthousiasme et de positivité. Ils font bonne figure comme on le fait dans une soirée où un premier contact est établi : chacun veut donner bonne impression, il faut se montrer sous un bon angle et gagner la confiance des autres.

L'équipe se réunit et apprend à connaître les opportunités, les dangers et les défis qui sont les siens. Les objectifs sont présentés mais chacun s'en fait une représentation propre sauf si les membres de l'équipe se sont côtoyés et entendus pour des missions précédentes et qu'ils ont pu apprécier leurs contributions personnelles avec justesse. La compréhension partagée est donc souvent un leurre même si l'équipe déclare le contraire. L'équipe n'est à ce stade guère plus qu'une collection d'individualités indépendantes tournées sur ses propres problèmes et objectifs. Le projet dont il faut se saisir est considéré comme une opportunité personnelle par chaque individu. En revanche, il peut arriver que certaines personnes, intégrées dans le groupe par obligation, se désintéressent d'emblée du sujet qu'ils trouvent absurde.

Les membres matures de l'équipe ont quant à eux un comportement différent dès cette phase initiale. Ils engagent à la cohésion du groupe. Ceux qui ont été exposés aux principes de l'Agilité tentent d'en insuffler l'esprit aux novices. FROCC — Focus, Respect, Openness, Courage, Commitment est répété aussi souvent que possible :

• Exposer le pourquoi du projet et les objectifs du groupe (OKR — Objectives and Key Results)
• Établir une charte (périmètre, mission + objectifs, rôles, règles, critères de succès, …)
• Définir les rôles personnels et les objectifs de chacun
• Placer la charte à un endroit visible par tous pour que personne ne puisse l'ignorer et qu'elle imprègne toutes les actions menées.
• Exposer les contraintes circonstancielles (budget, timeline, défis, …)
• Être le chef d'orchestre des tâches qui doivent être menées
• Identifier les besoins, tant matériels qu'humains. Cela va jusqu'à identifier les besoins de formation.

Membres de l'équipe DevOps

En termes simples, une équipe DevOps comprend tous les rôles quotidiens nécessaires pour mettre en production des logiciels de qualité de la manière la plus sûre et la plus appropriée possible, dans le respect des règles établies par l'organisation (parfois en renversant le statu quo). C'est la phrase clé pour résumer la composition de l'équipe. Elle ne se limite donc pas aux seuls développeurs et aux opérations : testeurs, middleware, sécurité, base de données … ^[4] .

Bien sûr, il ne sert à rien d'assembler des équipes DevOps si l'organisation n'a pas rendu possible le déploiement en production par les équipes, le cas échéant avec quelques étapes supplémentaires (sécurité, vérification, …), peut-être sous-optimales, mais constituant déjà une nette avancée dans le paradigme DevOps. Cela implique de repenser en profondeur plusieurs processus de base, ce qui est plus un changement culturel que technique, donc beaucoup plus difficile à mettre en place.

Longévité

Il y a une confusion apparente entre la longévité d'une équipe DevOps et la durée des contrats passés avec les personnes de l'équipe. J'y reviens avec le point ci-dessous.

Il faut voir cela comme un club de football (l'équipe 'DevOps) et les joueurs qui composent l'équipe : le club existera très probablement bien après qu'un individu soit transféré vers un autre club. L'équipe DevOps existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation.

Les contrats

L'équipe peut et doit évoluer mais son noyau doit rester stable. Cette réflexion nous amène à considérer avec attention les contrats qui sont établis avec les collaborateurs externes.

La majorité des personnes qui travaillent pour une organisation peuvent encore être des employés de l'organisation. Mais une minorité très importante et en constante augmentation — bien que travaillant pour l'organisation — ne sont plus ses employés, et encore moins ses employés à plein temps.

— Drucker, Peter F. in Management Challenges for the 21st Century

Les membres d'une équipe DevOps doivent être « signés » pour une longue période, généralement entre 1 et 2 ans au moins, mais certainement pas pour 3 ou 6 mois ce qui est le signe d'une organisation qui ne comprend pas que le travail d'équipe, et que c'est la qualité des femmes et des hommes qui est devenu aujourd'hui le moyen le plus sûr de générer des avantages compétitifs. Cette recommandation vise avant tout les collaborateurs externes mais le principe vaut pour tous les collaborateurs, ce qui met d'ailleurs à mal le principe d'organisation autour de … projets ^[5] .

Ce n'est pas la finance, pas la stratégie, pas plus la technologie mais bien le travail d'équipe qui reste l'avantage compétitif ultime, parce qu'il est à la fois si puissant et si rare. — Patrick Lencioni in The Five Dysfunctions of a Team — A Leadership Fable

Le texte qui suit est temporaire

C'est un malfonctionnement que de ne pas intégrer la dimension travailleurs externes dans les politiques de ressources humaines et d'achats. Expliquer cela. Dire que c'est nécessaire de prendre cette problématique à bras le corps ce qui peut d'ailleurs commencer assez simplement par une déclaration de principe : «nous prenons le même soin avec les travailleurs externes qu'avec nos employés" ... puis évidememnt vivre pleinement ladite déclaration sans quoi nous serions dans la schizophrénie en annançant une oersonnalité et en en vivant une autre.

TEXTE A RECASER

Inversement, il faut savoir qu'une escouade de DevOps doit rassembler toutes les compétences nécessaire à la réussite du projet au sens propre du terme. équipe fonctionnelle est. Cela pose la question des compétences qui peuvent ne pas être présentes (parce qu'elles n'ont pas été détectées lors de la mise en place, par exemple) ou des compétences qui ne sont plus nécessaire à un certain moment. L(i)VID réagit à ces deux cas avec bon sens : les faire monter à bord en cas de besoin et les libérer si ce n'est plus nécessaire. Malgré ce que diront la plupart des anciens d'Agile, cela nécessite un peu de la planification et donc certaines compétences en matière de gestion de projet.

La raison pour laquelle L(i)VID recommande cette pratique est que les membres du groupe ont besoin de se dompter les uns les autres avant de pouvoir prétendre à une forme d'excellence. C'est un processus lent et organique que Bruce Tuckman a modélisé avec la construction de la cohésion d'équipes en 4 phases (petits groupes). On mise sur l'humain et sur ses interactions. Disposer d'un noyau stable de long terme est un élément substantiel de la mise en place des équipes DevOps.

Il n'y a pas de montée en puissance soudaine (ramp-up) (nous le savons depuis Frederick P. Brooks — The Mythical Man-Month — Pearson Education) et pas de descente en pente raide (ramp-udown), sauf à vouloir connaître la phase de Storming à chaque recomposition d'équipe, sauf à s'exposer à chaque fois aux coûts des courbes d'apprentissage, sauf à […]

Nous en sommes venus à valoriser les individus et les interactions plus que les processus et les outils […] — Manifeste pour le développement Agile de logiciels

Il y a un véritable dysfonctionnement à travailler avec des départements Procurement complètement détachés des réalités du Management du 21ème siècle. Il est nécessaire de revoir ce fonctionnement tout en dépouillant le principe général — et idéal — des formes de naïveté qui lui sont préjuciables. Il faut un modèle équilibré où la réalité économique de l'entreprise n'est pas oblitérée. Voilà un sujet significatif des politiques de Sourcing qui rendent souvent nécessaire de revoir les positions globales. Là encore, il s'agit d'un chantier qui n'est pas mince.

The Contract

The individuals of a DevOps Team are « signed » for a long period, typically between 1 and 2 years at least. The reason why L(i)VID recommends this practice is because a group needs to learn from each other and each member needs to adapt%-% it is really two-way%-%and this is not going to happen overnight. Time is needed for the pastry to come together. How is that again? We have come to value individuals and interactions over processes and tools. This simple statement implies a sort of chain of reactions. For example, if a team is composed by externals, how does the bank will have to try to secure a long term commitment of sourcing partners? How does that affect Change and Run? etc.

Conversely, one must know that a DevOps Squad must gather all the skills necessary for the project to succeed in the true sense of what a cross- functional team is. This brings the question of skills that may not be present (because for example they were not detected during setup) or skills that are no longer necessary at a certain point in time. L(i)VID reacts to these two cases with common sense: bring them aboard when needed and release them if no longer needed. Despite what most alumni of Agile will say, this requires a bit of planning and therefore some Project Management skills.

How Many?

Metcalfe's Law and Project Teams — Keep the team as small as possible. Metcalfe's Law, that « the value of a communication system grows at approximately the square of the number of users of the system, » has a corollary when it comes to project teams: The efficiency of the team is approximately the inverse of the square of the number of members in the team. I'm beginning to think three people is optimal for a 1.0 product release…Start out by reducing the number of people you plan to add to the team, and then reduce some more. Marc Hedlund, entrepreneur-in-residence at O'Reilly Media https://gettingreal.37signals.com/ch03_The_Three_Musketeers.php

Being agile means keeping the size of teams small. Why? Small teams do not have a lot of communication overhead. A team of 5 for instance has 5 * (5 - 1) / 2 = 10 communication lines. A team of 9 has 9 * (9 - 1)/ 2 = 36 ! So, aligning 9 people already starts taking important amounts of time. That's why L(i)VID, unsurprisingly, recommends teams of 7 to 9 people, with a clear preference for 7 ^[6] (see %FORMULA%, %IPC% and %IPI% for more information). That being said, %-XP% recommends other limits: 12 (Team) or 150 (Team of teams). Across these thresholds XP says that you will have hard time keeping the necessary trust for good collaboration. We hold with our number of 7, which we also called the %MAGIC-7%! ^[7]

The first step was to change the composition of teams. Existing teams were organized around functions; the new teams would be interdisciplinary teams of about seven people — Mary and Tom Poppendieck in The Lean Mindset: Ask the Right Questions

Réduction de l'équipe

Une équipe DevOps, assemblée pour un terme long (au moins 1 à 2 ans, voire 3), s'occupe de la mise au point de produits et services ainsi que de leur maintenance et support, en accord avec le principe You build it, you run it institué par Amazon.

Cependant, un produit ou service n'échappe pas à son cycle de vie habituel : les produits / services naissent, vivent et meurent ^[8] .

L'équipe DevOps existe aussi longtemps que les produits ou technologies qu'elle crée et soutient sont utilisés et maintenus dans l'organisation.

Il ne faut donc pas s'étonner qu'aux étapes FSNP — Forming, Storming, Norming, Performing s'ajoute une autre phase qui en est le démantèlement, mais aussi cette autre phase, intermédiaire elle, qui existe tout au long de la vie de l'équipe : sa réduction ^[9] .

Cette phase de réduction s'explique par le simple fait qu'en phase de maturité du produit / service il y a généralement moins de choses à faire. En période de maturité, le produit / service est dans cette phase où il est le plus profitable (ratio coûts / bénéfices). Le marketing et la direction stratégique de l'entreprise ont tendance à investir le strict minimum dans le produit / service, entendez de quoi prolonger sa période de maturité le plus possible, tout en gardant la concurrence à distance. Dans cette période donc, le travail de l'équipe diminue, du moins habituellement, sauf à préparer de nouvelles moutures.

Plusieurs stratégies existent pour prolonger la vie de l'équipe dont l'atout essentiel est d'avoir pu démontrer sa capacité à travailler ensemble et à créer et maintenir des produits / services. Il est par exemple possible d'ajouter d'autres produits / services au portefeuille de l'équipe, surtout ces produits / services qui requièrent des compétences similaires. Une autre stratégie consiste à faire varier la taille de l'équipe dans le temps et lentement pour ne pas la déstabliser. C'est de cette stratégie-là dont je traite ici.

Au fur et à mesure que l'équipe DevOps gagne en maturité, essayez de réduire légèrement et progressivement sa taille (pas plus de 2 membres à la fois maximum). Cela rend les personnes disponibles pour d'autres équipes, en particulier celles qui commencent leur transition (voir aussi le 5e principe du Knowledge Management promu par l'Agilité). N'essayez pas d'occuper l'équipe de manière à ce que tous les membres aient la même charge de travail car c'est simplement, par analogie, une manière de devenir un gaz parfait, un gaz qui occupe tout le volume qui lui est donné. Essayez de déterminer qui peut et veut faire passer le message ailleurs dans l'organisation. Voyez à cet égard ce que j'en dis avec SARA — Send Ambassadors; Receive Ambassadors