La qualité… classe affaire ou économie?

Agile tour Montreal. Une belle opportunité pour partager, écouter, prendre du recul, se rappeler… C’est ainsi que j’ai eu la chance de voir ou d’échanger avec ceux qui coachent ouvertement, ceux qui « lego-tisent » pour faire du sens, ceux qui testent en rouge et en vert, ceux qui scriptent, ceux qui osent le changement, ceux qui « jeopardisent » les bases agiles, ceux qui se disciplinent… Parmi toutes ces approches, j’y ai perçu un point commun : la recherche de la qualité, tant interne, qu’externe, d’affaire, de communication, de processus ou d’outils.

Peut-être la fatigue a influencé mon comportement, mais malgré toutes ces belles énergies, j’ai eu le blues du ScrumMaster. Parce que la qualité a un coût et qu’en informatique de gestion, notre tolérance aux dysfonctionnements est très élevée… ce qui génère une motivation très moyenne pour investir dans l’amélioration de la qualité.  Ce qui provoque le blues du ScrumMaster certains jours…

Dans les domaines automobile, aérospatial ou médical, les erreurs ne sont pas permises, en toute logique, car les conséquences pourraient impacter des vies humaines. En informatique de gestion, notre comportement en entreprise s’apparente à celui que nous avons chez nous le soir, face à notre ordinateur. Que se passe-t-il si une transaction sur internet échoue? Combien d’entre nous vont juste vérifier sur leur compte en banque que la transaction n’a pas été complétée, et réessayent une heure plus tard? Oui, on est un peu frustré …. Mais on l’accepte quand même, on retente, on finit par compléter, et on passe à autre chose, oubliant l’incident.

Quelle est notre situation aujourd’hui en entreprise?

Je trouve intéressant le billet de W.Pietri, qui reprend la théorie de G.Moore, « crossing the chasm ». En combinant cette approche avec le Hype Cycle de Gartner, voici une estimation de là où nous nous trouverions aujourd’hui, dans l’approche agile.

Sans reprendre le détail du blog de M.Pietri, force est de constater que nous sommes dans une phase difficile pour l’agilité. Mais nos problématiques actuelles sont-elles liées à la méthodologie ou à la qualité des produits livrés?Dans quelle mesure la méthode de travail, agile ou traditionnelle, n’est-elle pas seulement un moyen pour favoriser cette qualité? C’est la raison pour laquelle je dirais plutôt que nous sommes aujourd’hui dans une phase difficile pour l’atteinte de la qualité dans le développement d’applications de gestion.

Quelques raisons qui, à mes yeux, sont des freins à la qualité :

• L’urgence du Time-to-Market, pour ne pas manquer un marché éphémère et chaotique. Cela favorise une vision à court terme, et un manque d’intérêt pour investir dans une qualité à long terme.
• Le gap technologique : plus le système existant est ancien, plus la courbe d’apprentissage pour appréhender les nouvelles technologies est abrupte, longue et couteuse.
• Le cœur de métier : pour beaucoup d’entreprises, l’informatique est un moyen pour atteindre une clientèle, mais la transaction se passe généralement encore dans le réseau physique (ex : vendeur de voiture, immobilier, …). D’ailleurs, notons que dans ce cas, la méthodologie de travail devient le moyen du moyen… Tout un défi pour la faire valoir! Notons également que le gap technologique est souvent présent chez ces client (logique, étant donné que l’informatique n’est pas (encore) une priorité pour eux).

Il y en a surement beaucoup d’autres, mais je m’arrêterai à ces trois qui me viennent spontanément à l’esprit, car ils ont un même effet de bord : contorsionner notre cher triangle… Nous avons beau le tourner dans tous les sens selon nos méthodologies, il se  métamorphose  malgré lui en un carré à coins ronds…. Le budget est serré, la date est Q1 2012, le scope est déjà au périmètre minimal obligatoire… réponse « Jeopardy » à $100: le 4^e levier non négociable. Je vous laisse trouver la question.

Ce qui m’importe maintenant, c’est ce qu’on peut faire avec toutes ces données pour aider nos clients, et améliorer la qualité globale des produits.

Une proposition d’approche en 4 étapes :

1. Analyser la situation actuelle. Par exemple, le diagnostic PATH peut être utilisé pour inspecter la qualité des Processus, des Affaires, de la Technologie (qualité interne et externe), et des relations Humaines.
   • L’objectif est de produire des recommandations évaluées (en gain & effort)
2. Définir la cible souhaitée idéale, en la confrontant aux bonnes pratiques de développement logiciel, aux recommandations du diagnostic initial, et aux spécificités de l’organisation. L’objectif ici est de produire
   • la définition de terminé courante (la qualité qu’on peut atteindre de façon réaliste à court terme),
   • la définition de terminé cible (associée à un plan d’action SMART et jalonné dans le temps pour chaque item)
   • le suivi des risques liés à chaque manquement dans la situation actuelle (avec plan de mitigation) (i.e. la gestion de la dette).
3. Suivre et mesurer à chaque itération :
   • la conformité à la définition de terminé courante (chaque item doit être mesurable),
   • la progression vers la définition de terminé cible
   • les risques associés aux manquements, et les mitigations
4. Choisir de nouvelles actions, soit pour stabiliser la situation actuelle, soit pour l’améliorer et se rapprocher de la cible.

Cela n’a rien de révolutionnaire, mais demande de la patience et de la persévérance. Un de nos beaux défis, en tant que défenseurs de la qualité, est de faire valoir et rendre visible le retour sur investissement de la qualité, autant pour l’entreprise que pour les individus.

Non, la qualité n’est pas un luxe. C’est une économie de 1ere classe, ne l’oublions pas!