DevOps Rex

Après quelques années à accompagner nos clients sur les transformations agiles et DevOps, l’heure du Devops Rex (Roi, ou retour d’expérience) commence à sonner. Retrouvez les dix erreurs les plus courantes pour rater son passage vers l’agilité à grande échelle et les bonnes pratiques pour les éviter !

1. Plutôt que de dire avec humour « Chez nous, tout le monde fait du DevOps, les Dev font du DevOps, les Ops font du DevOps, mais on ne le fait pas  ensemble », mettre en place une gouvernance globale pour changer ensemble.

2. Plutôt que de faire un grand programme côté production, avec des ateliers thématiques (les tests, la mise en production, etc) sans pour autant expérimenter, ni essayer pragmatiquement de nouvelles façons de travailler entre une équipe agile et ses correspondants de production, pour voir, pour apprendre, adopter le parti pris de l’action.

3. Plutôt qu’adopter par voie hiérarchique le modèle Spotify en squad et tributs, aller vers le management de soutien qui évite l’injonction d’être agile.

4. Plutôt que de soutenir les équipes agiles qui veulent aller jusqu’à la mise en production (sans avoir  convenu en même temps qui fera quoi, lorsqu’à trois heures du matin, la solution tombera) et plutôt que de conserver à l’exploitation, des incitations et des primes orthogonales au fonctionnement demandé aux développeurs,  lever au plus tôt les freins organisationnels.

5. Plutôt que de détacher un intégrateur de production dans chaque équipe agile, sans lui dire de sensibiliser ses collègues à la sûreté de fonctionnement, à la supervision, à la résilience,  construire ensemble et partager la vision globale de la qualité DevOps.

6. Plutôt que de faire du digital, des MVP, des parcours utilisateurs semés de roses dans le nouveau silo d’une DSI bimodale, réfléchir à une DSI inclusive, étendant les vertus agiles à l’ensemble de l’IT.

7. Plutôt que de faire de l’agilité à grande échelle avec des équipes organisées à leur convenance, du moment qu’elles travaillent en sprint de 10 jours, en release de 50, avec une vélocité de 100 et pratiquent un reporting d’avancement quotidien, établir par la délibération et revoir périodiquement, les modalités de travail agile avec les métiers, au sein de chaque équipe projet et entre chaque chaque Squad, pour le Build et le Run.

8. Plutôt que d’imposer, pendant un programme agile, des installations automatiques du logiciel dans tous les environnements, sans pour autant faire de mise en production avant six mois de développement, et découvrir alors que l’on ne sait déployer automatiquement que l’ensemble du logiciel à l’issue d’un arrêt de services qui se compte en heures, vérifier tout de suite que la sûreté de fonctionnement est efficiente, et penser la feuille de route en termes d’activation des fonctionnalités en production.

9. Plutôt que se demander comment faire pour que les Product Owner arrivent à prioriser leurs besoins et que les projets ne consomment pas systématiquement tout leur budget, découpler budget annuel et engagements de dépenses, agiliser la gestion budgétaire, et lisser les « projets » sur plusieurs exercices.

10. Plutôt que d’expérimenter trop lentement, de risquer de décevoir les attentes et de partir naïvement dans une initiative DevOps sans lendemain, cadrer franchement, mobiliser le management et s’appuyer sur des experts ayant affronté ces transformations et capables de partager leur DevOps REX. Reste à bien les choisir !