J’ai la chance d’accompagner depuis quelques mois maintenant des équipes dans l’industrie. Comme dans beaucoup de grosses entreprises, ces dernières sont régulièrement mises à contribution lors d’audit de certification (ISO par exemple).

Je suis souvent surpris par les réactions des deux côtés de la barrière (auditeur et audité) quand ils en viennent à parler des projets agiles.

Le manifeste, avec la seconde valeur (Un logiciel qui fonctionne devant une documentation exhaustive) est-il en opposition avec les normes? Les normes demandent-elles obligatoirement une flopée de documents et que tout le monde fonctionne de la même manière? Je vous propose mon analyse sur le sujet.

Comprendre la norme, et surtout en montrer le bien-fondé.

J’ai été comme les équipes: j’ai rapidement fait un rejet de la norme… et surtout des audits… j’avais l’impression qu’on allait demander: Peux-tu nous montrer tel document? J’ai besoin de l’indicateur X, je le trouve où?

Et comme beaucoup, je me trompais. Les normes ont évolué. Il est peut-être vrai qu’il y a quelques années, obtenir une certification ISO par exemple tenait à ce que les documents décrits dans la norme soient présentés, complétés, mis à jour… C’est beaucoup moins le cas maintenant.

Je me permets de faire une pause: je n’ai aucune expertise des différentes certifications et normes qui régissent l’industrie et/ou la qualité de production, cependant, j’ai eu beaucoup d’échanges avec des personnes chargées des audits et j’ai moi même participé à un audit de certification dernièrement.

De ma compréhension, ces normes ne demandent plus de documents précis, mais demandent plutôt à ce qu’on prouve, par exemple, que l’entreprise, au travers de ces projets et équipes, a mis en place une gestion de l’amélioration continue par exemple.

Et pour cet exemple, quelles sont nos cérémonies de revue et de rétrospective d’autres que des moment dédiés à l’amélioration continue?

Quand on parle de certification également, il me semble important de faire comprendre aux équipes, et surtout les équipes jeunes et agiles, de la valeur que cette certification apporte pour l’entreprise. Outre le fait qu’elle permette de répondre à des appels d’offres spécifiques ou autres contrats normés, elle est là également pour assurer un niveau de performance et de qualité au sein de l’organisation. Et si l’organisation continue à répondre à des contrats, est performante et produit un travail de qualité, l’équipe doit alors voir la valeur de cette certification.

Une agilité mais pas une descente en roues libres.

La plupart du temps, quand on se place de l’autre côté de la table, côté auditeur, on peut facilement comprendre que la démarche agile fasse peur. Ce qui est souvent entendu tient en ces phrases:

Plus de documentation! Une équipe auto-organisée donc qui ne rend aucun comptes (pas d’indicateurs…)

Or c’est complètement faux… Qui dit agilité ne dit pas bazar… Enfin, pas tout le temps en tout cas, et certainement pas avec des équipes aguerries..

La gestion d’un projet/produit en agilité, qu’on soit en pur SCRUM, en Kanban ou tout autre déclinaison de l’agilité, demande au contraire à ce qu’on mette en place les bons indicateurs afin de promouvoir la transparence et pour donner de la visibilité sur l’efficacité de notre équipe / système.

Ces indicateurs ont alors tout à fait leur place dans un audit de certification, à condition de savoir les présenter et les exploiter correctement.

Rendre notre travail au jour le jour compatible avec les audits?

On ne va pas se voiler la face non plus, un audit n’est jamais un exercice facile. L’entretien se prépare à l’avance, et il est important d’être correctement accompagné. C’est pour cela que la plupart des entreprises qui entrent dans ces normes mettent en place des cellules qualité ou d’audit…

Mais dans nos pratiques au jour le jour nous pouvons mettre en place des réflexes qui nous permettent, en tant qu’équipe, d’aborder ces audits plus facilement…

Voici quelques exemples d’actions qui, de mon expérience, aident à la préparation de ces audits:

1. Garder un historique de vos rétrospectives (tableau de rétro en photo ou export si en ligne), et des actions qui en découlent (mise en place d’un tableau des actions d’amélioration continue). Ceci vous permettra d’aborder le sujet de l’amélioration continue du process de production de l’équipe assez facilement.
2. Sauvegarder vos documents de revue (powerpoint, graph, CR…) afin de pouvoir présenter un historique de vos indicateurs.
3. Utiliser un outil spécialisé de suivi du backlog.
4. Faire un recueil de la satisfaction des parties prenantes au sortir de la revue. Je vous conseille de le faire sur 2 axes: la satisfaction concernant le produit à la sortie du cycle et la satisfaction concernant la manière de produire. Faites le aussi pour l’équipe de production 😀
5. Créer un espace dédié à l’équipe pour sauvegarder les documents et s’assurer qu’il soit organisé et maintenu.

Je vois tout de suite les fourches se lever… ne m’envoyez pas encore au pilori… 

En effet, en regardant ces propositions on pourrait être tenté de dire: pourquoi ajouter du process et de la surcouche pour une équipe agile.. Ne serait-ce pas un anti-patern?

Non et non… je ne pense pas que ces actions soient une surcouche de process pour une équipe agile. N’oublions pas 2 choses:

1. La plupart des équipes le font déjà naturellement
2. L’organisation et l’auditeur doivent être considérés comme des parties prenantes de l’équipe et dans ce sens, ils sont à même de formuler des besoins par rapport à la production de l’équipe, même si ces derniers ne sont pas liés directement au fonctionnel du produit.

Je reviendrais sur cette notion de besoins de l’entreprise vis à vis de l’équipe agile plus tard, notamment dans la notion de Définition de Terminé pour les équipes mais pour le moment je préfère vous laisser sur ces mots et j’espère qu’ils vous donneront quelques idées à explorer…