Agile : 4 valeurs / 12 principes


Principe 7 : Un logiciel opérationnel (un produit opérationnel)

Principe 7 : Un logiciel opérationnel (un produit opérationnel)
est la principale mesure de progression d’un projet

Lorsque l’on parle d’opérationnel, on entend ici : qui convient au besoins des parties prenantes.  La solution doit donc être facile à prendre en main par les parties prenantes et rapide à tester. 

Remettant en question les indicateurs opérationnels de l’entreprise, ce principe est souvent challengé dans le cadre d’une transformation à l’échelle.  Nous verrons ici son impact selon 3 focus : intensio – d’un point de vue d’équipe, Extensio – d’un point de vue managérial ou organisationnel, Mago – d’un point de vue individuel.

Focus Intensio, d’un point de vue de l’équipe à quoi correspond ce principe 7 ?

C’est un moment privilégié pour l’équipe : la rencontre avec le client. Dans tout démarrage Agile, cet aspect est extrêmement important. Il doit être préparé en amont avec le client.

Rappelez-vous, il n’y a pas de cahier des charges mais des livraisons rapides permettant de valider avec le client que ses besoins sont satisfaits par le produit livré.

C’est une invitation au dialogue sur la solution proposée. L’ultime verdict est quand le client lui-même prend la livraison en main pendant la démonstration. Par sa  simplicité , la livraison est une invitation à utiliser immédiatement. Le client prend ainsi possession de son produit à chaque étape.

Pour que cela fonctionne, il faut déterminer avec son client les critères d’acceptation pour chacune des périodes de livraison. Il faudra également prendre en compte, des périodes pour travailler sur la robustesse des fonctionnalités ou produits remis : en effet, une solution conçue pour 10 personnes n’a rien à voir avec une solution pour 1000 personnes.

Ce principe de validation sur le logiciel lui-même permet la mise en œuvre de la valeur 4 du Manifeste Agile : acceptez le changement à n’importe quel moment dans le développement du projet.

Pour que cela soit rendu possible, il faut que chaque évolution soit facile à installer et à tester, et que les fonctionnalités installées ne soient pas dépendantes de chacune des nouvelles livraisons.

C’est pourquoi les équipes de développement s’engagent dans un processus de qualité dès le départ. Cela a donné naissance à une communauté de software craftmanship, ayant elle-même un manifeste.

Cette communauté est très active et défend la qualité des livraisons effectuées et revendique même un code comme un ARTISANAT d’ART.

Les produits Agile, autre que des logiciels, n’ont à ma connaissance aucun label Qualité.

Nous touchons ici les principaux écueils d’une Agilité à l’échelle. Pour que les livraisons restent de qualité et flexibles, l’équipe devra adopter des règles de fonctionnement clairs tant avec son client qu’avec son management.

Pour les logiciels, bien souvent l’équipe devra intégrer des habitudes intégrant à chaque ligne de codes des tests, et isolant les fonctionnalités les unes des autres. Le Test Driven Development ou le clean code seront renforcés ainsi que la capacité de l’équipe à identifier, puis à anticiper les problèmes.

L’automatisation des tests sera également à challenger afin de permettre aux équipes de continuer à livrer et/ou à se positionner sur d’autres produits à valeur ajouté.

Focus Extensio, d’un point de vue de l’organisation à quoi correspond ce principe 7 ?

En matière d’organisation, ici c’est le contact avec un usage réel des produits livrés ainsi que le contact client qui sera à challenger par le management. En effet, dans les transformation à l’échelle, le contact direct avec le client se perd. Il est remplacé par des Products Owners.

Bien souvent, les organisations ne suivent pas le rythme des livraisons et la livraison devient mécanique. On livre tous les 15 jours coûte que coûte même si il n’y a plus de raison à ce rythme. C’est à ce moment que les problèmes qualité et la résistance à l’Agilité risquent de naître.

Le management doit ici garantir le sens à donner aux équipes et OSER arrêter un projet si ce dernier est entré dans une phase opérationnelle.

Le maintien dans cette phase est possible dès lors que l’entreprise est totalement organisée en mode Agile. La matrice organisationnelle ne pouvant fonctionner car elle génère des lenteurs dues à un processus non fonctionnel et à des activités multiples rendant impossible l’intégration manuelle des fonctionnalités livrées.

Dans ce cas, les équipes sont donc des unités de production autonomes et auto-gérées.

Le modèle SAFEe,  Scaled Agile Framework, permet de mettre en place un processus Agile sans trop remettre en cause l’organisation fonctionnelle des entreprises en transformation. Il faudra veiller malgré tout à ce que  les équipes soient des unités de production autonomes et auto-gérées. (Relire le principe 3 pour en savoir plus)

Focus Mago, d’un point de vue individuel à quoi correspond ce principe 7 ?

Lorsqu’une équipe Agile fonctionne bien,  le Principe 7- Un logiciel opérationnel(un produit opérationnel) est la principale mesure de progression d’un projet, le critère de référence. Le succès de l’équipe est visible et envié. Il est alors possible de penser un Agile à l’échelle.

Cependant, si le succès rend visible l’équipe, l’individu ici voit aussi se pointer de nouveau des critères de mesure de la performance individuelle. Il entre dans une phase de déni car l’individu n’est pas une machine. La livraison sur des périodes courtes n’a de sens que si l’équipe livre de la valeur ajoutée à chaque fois.

Si la valeur ajoutée livrée est maintenue, l’individu entre alors dans un FLOW- High skill+high challenge = flow .

La passion pour son travail se maintiendra alors. Par contre, si l’organisation ne se transforme pas, les livraisons s’empilent et ne font plus sens. L’individu se démotive et arrête progressivement de livrer de manière régulière. Si l’entreprise continue de demander à l’équipe des livraisons continues, l’équipe éclatera alors. Les individus partiront ailleurs. Eux-mêmes transformés par ce FLOW auquel ils auront goûté, acquis individuellement.

L’entreprise sera laissé seule face à ses doutes et à une transformation qui n’en est plus une mais un retour au pragmatisme contrôlant appelé Production, et si bien singé par Charlie Chaplin, les temps modernes

Lire aussi : Essai : Pourquoi les employés aiment Scrum et pas les patrons !

Les leviers de votre transformation d’entreprise

Transformer l’équipe, conversation avec un coach Agile

Cet article a été pensé et rédigé par Dominique Popiolek, transformation leader et coach professionnelle.