Dessine-moi un CTO

Les défections se succèdent dans l'équipe, chaque jour votre crainte augmente : que le dernier développeur qui connaît l'application vous quitte.

Le dernier des mohicans
Certes, vous avez entamé un plan de Knowledge Management qui pourrait aider à limiter la casse.
Vous avez demandé de consigner soigneusement dans le wiki toutes les connaissances sur cette application critique pour votre entreprise :

• Architecture de l'application,
• maintenance à effectuer régulièrement,
• mots de passe et autres accréditations nécessaires,
• principales pannes courantes,
• modes opératoires complets pour des pannes graves,
• contacts à solliciter,
• inventaire complet des risques priorisés avec MoSCOW.

Mais tout-le-monde sait que la montée en compétence d'un éventuel successeur serait rude, surtout si vous ne parveniez pas à réaliser un transfert efficace avant son départ.
Le best case scenario serait quand même de parvenir à le garder.

Un nouvel espoir
L'enjeu étant cerné, reste à bâtir un plan de reconquête.

Dans un contexte où les départs se multiplient, ceux qui restent sentent le poids des responsabilités peser de plus en plus sur leurs épaules.
Au fil du temps leur stress augmente, et avec lui les risque de burn out ou départ, même pour une offre moins attractive que leur position actuelle.
Ce n'est pas juste une question de rémunération, c'est d'abord une question de pression.

Il ne suffira pas seulement d'embaucher pour combler les pertes. Il va falloir sécuriser et re-motiver toute cette équipe.

Renégocier pour restaurer la confiance
La première tâche nécessaire est la sécurisation du backlog. Avec une todo list longue comme un jour sans pain, pas étonnant que les développeurs se démotivent.
Il va falloir prendre votre bâton de pélerin et aller négocier avec chaque partie prenante :

• mettre les stakeholders face aux enjeux (capacité à faire, risque de défaillance des systèmes, risque de départs dans l'équipe, etc.) ;
• re-prioriser avec eux les demandes, en alignant les priorités sur la stratégie d'entreprise ;
• rendre visible de tous la nouvelle roadmap négociée (donner 2-3 mois de visibilité, pas plus) ;
• annoncer clairement les demandes qui devront être abandonnées.

Repartir sur de meilleures bases
Ce type de crise est une excellente opportunité de changer les façons d'aborder les problèmes :

• obtenir plus d'implication au quotidien des parties prenantes, pour une meilleure définition des besoins, avec une spécification juste à temps (plutôt qu'une longue phase de spécification) ;
• simplifier les cahiers des charges pour raccourcir les délais de livraison grâce à une approche frugale du logiciel ;
• refactoriser souvent plutôt que de chercher à concevoir du code générique/évolutif ;
• abandonner les demandes de correction pour des défauts mineurs, adopter une approche "qualité suffisante" ;
• proposer de transformer en paramètres applicatifs, des demandes qui étaient jusque-là satisfaites par du développement et donnaient lieu à des modifications fréquentes du code ;
• déporter des fonctionnalités vers des petits logiciels dédiés, plutôt que d'augmenter la complexité du logiciel principal ;
• troquer des logiciels trop lourds à maintenir en interne, pour des logiciels SAAS ;
• troquer des logiciels sur mesure trop lourds à configurer et/ou maintenir, pour des logiciels génériques (open source ou propriétaires).

Changer de vocabulaire pour rendre le changement visible
Beaucoup d'équipes ont souffert d'une implémentation incomplète de Scrum (culte du cargo, "scrum but"...).
Cela conduit au rejet de l'agilité. Pour que les nouveaux process soient mieux acceptés par l'équipe, changez de méthode (au moins en apparence).
Il ne s'agit pas de duper les développeurs, mais au contraire de rétablir la vérité. Ce qui fait l'efficacité de Scrum, ce n'est pas les sprints, les daily, et les planning pokers. C'est la mise en œuvre constante des 3 piliers de l'empirisme (transparence, inspection, adaptation). Un reboot de Scrum s'impose.

En annonçant que vous allez vers une autre méthode (Kanban, eXtreme Programming, AgileUP, Heart of Agile...), vous déplacez l'angle de la caméra pour permettre aux parties prenantes de repartir sur de meilleures bases, en mettant cette fois-ci en œuvre les bases qui rendent l'agilité vivante.

Si vous pratiquez le cycle en V, mais qu'aucun projet n'est autorisé à revenir dans une phase précédente pour corriger les défauts logiciels, vous êtes également victime d'une erreur méthodologique grave. Pour remettre les choses d'équerre, il peut aussi être utile de changer de vocabulaire. Adoptez RUP, Prince2, ou le PMbok, pour aider l'entreprise à respecter les règles de base de la gestion de projet.

Rétablir un delivery fluide
Paradoxalement, si vous n'arrivez pas à livrer, c'est en livrant plus souvent que vous améliorerez la situation !

Les sprints d'un jour sont d'une efficacité redoutable pour obtenir ce changement :
chaque matin au daily meeting, demandez au développeur ce qu'il pense qu'il peut raisonnablement livrer pour le lendemain. Ne négociez pas son estimation. Le but est d'amener l'équipe à s'engager uniquement sur des choses tenables. En constatant jour après jour, qu'elle arrive à tenir ses engagements et surtout qu'elle voit ses progrès vers le but annoncé, l'équipe va reprendre confiance en elle.

Du côté des parties prenantes, en communicant chaque semaine ou toutes les 2 semaines sur les objectifs concrets atteints par l'équipe, les stakeholders vont également reprendre confiance dans la capacité de l'équipe à atteindre ses engagements. Les estimations de l'équipe seront moins challengées, ses refus seront mieux acceptés. Le respect mutuel sera restauré.

Kanban comme méthode universelle ?
L'intérêt de Kanban, est que cette méthode s'adapte aussi bien à des contextes agiles comme waterfall, pour visualiser le flux de travail et réduire le WIP (Work In Progress). En temps de crise, cesser de paralléliser et ne plus faire qu'une seule seule chose à la fois, permet de rendre visible les progrès et de rétablir la confiance.

Une fois qu'on a goûté à ce confort de travail, il est impossible de revenir en arrière.
Pour démarrez, un guide Kanban illustré est disponible gratuitement en ligne et en français.