L’équipe Agile dans la mise en place d’une organisation Agile
Le framework SAFe décrit 7 compétences fondamentales pour permettre d’atteindre les objectifs de la « Business Agility », c’est à dire de l’agilité d’entreprise. L’une d’entres elles est « Team and Technical Agility ». Cette compétence décrit les principes et pratiques Lean Agile utilisées par les équipes Agiles pour délivrer des solutions ou produits de haute qualité. Le point de vue et retour d’expérience de Thierry, qui accompagne des transformations agiles depuis de nombreuses années.
Team and Technical Agility
La compétence « Team and Technical Agility » est une compétence qui soutient la mise en œuvre opérationnelle et décrit « les compétences clés, les principes et pratiques Lean-Agile, qu’une équipe agile performante (équipe agile unitaire ou équipes agiles coordonnées dans un train) doit déployer pour créer des solutions de grande qualité pour leurs clients. »
Elle se décline sur 3 dimensions. Pour chacune de ces trois dimensions, parmi l’ensemble des prérequis nécessaires, quelles sont les trois prérequis qui me semble les plus importants ?
Commençons par la dimension « Agile Teams »
1. Travailler à l’engagement des équipes
A mon sens, le prérequis pour avoir des équipes performantes est de s’assurer que leurs membres sont engagés. Un premier mécanisme est décrit dans le livre de Vineet Nayar « Employees first, Customers Second» : Pour avoir des clients satisfaits, il est nécessaire que les employés de l’entreprise délivrent des services et produits performants. Pour cela, le management doit être au service des employés étant au contact direct des clients, et non pas l’inverse, afin de leur apporter les moyens nécessaires. Nous retrouvons ce principe dans ce que les Anglo-Saxons appelle le « Servant Leadership ».
2. Avoir des objectifs inspirants
Le livre « Implementing Beyond budgeting », de Bjarte Bogsnes, nous apporte un deuxième mécanisme via le 1er principe de la « Business Agility » : “Purpose – Engage and inspire people around bold and noble causes; not around short-term financial targets”. Personne ne doute que des objectifs financiers sont nécessaires, ils ne sont cependant absolument pas suffisants pour engager les équipes. Quelle est la raison d’être de l’entreprise, en quoi le travail que je fais va contribuer à cette raison d’être ? Telle entreprise contribue à la rénovation d’un hôpital dans un pays en guerre, telle autre investit et participe à l’entreprise à but non lucratif « Time for the Planet ». Telle autre entreprise travaille à la conception d’un produit qui va enthousiasmer ses utilisateurs. En quoi mon entreprise participe à l’accomplissement d’un objectif au-delà de ses résultats financiers ?
Les employés travaillent pour gagner un salaire et recevoir un bonus fait toujours plaisir, ils ont besoin d’un niveau de sécurité, de stabilité, variable suivant les personnes. Au-delà de ces besoins fondamentaux, en tant qu’êtres humains, nous avons également le besoin d’appartenance à un groupe, être reconnu pour ce que nous et notre entreprise accomplissons ensemble.
3. Diffuser les compétences
Une équipe performante est également une équipe dans laquelle l’information et les compétences sont partagées. Il est donc important de travailler sur le « T-Shaping » des compétences (appelé encore compétences en T) : chaque membre de l’équipe possède ses propres expertises, mais doit avoir également un minimum de compétences sur d’autres domaines afin d’augmenter le « Bus factor » de l’équipe : Quel est le nombre minimum de membres de l’équipe qui peuvent soudainement disparaître avant que cette équipe s’arrête par manque de compétence ?
Au-delà du T-Shaping, nous vivons dans un monde en perpétuelle évolution. Il est donc fondamental d’acquérir continuellement de nouvelles compétences afin d’avoir la capacité de fournir aux clients des services et produits évoluant avec leurs besoins. Cet apprentissage continu se fait traditionnellement via des formations, mais aussi par des moyens très divers, en encourageant le feedback entre employés, en expérimentant (« Try, Fail & Learn to succeed ») et via le partage d’expertises.
Faisons le même exercice pour la dimension « Team of Agile Teams », s’ils n’y avaient que 3 prérequis quels seraient-ils ?
1. Donner un cap
Pour commencer, définir un objectif en lien avec la vision de l’entreprise. « Tout objectif flou conduit à une connerie certaine » écrivait Pierre Dac. Si une partie du travail consiste à gérer le « Business As Usual », un but à moyen-long terme doit être défini pour prioriser les développements, motiver les troupes et préparer l’avenir. Rien de tel que le vol à vue pour désengager des équipes. Sur quels sujets les équipes doivent-elles travailler maintenant pour être prêts demain à répondre aux besoins du marché ? Quelle est la stratégie de l’entreprise ? Quels sont les technologies, les méthodes, sur lesquelles les équipes doivent travailler pour s’aligner avec cette stratégie ?
2. Se mettre d’accord sur le chemin à suivre
Associée à cette vision d’entreprise, à ces objectifs, une roadmap est nécessaire pour donner de la visibilité à moyen et long terme aux équipes comme aux leaders, anticiper l’organisation ainsi que les moyens nécessaires autant humains (capacités, compétences) que matériels. Attention à ne pas prendre une roadmap pour un engagement ferme mais pour une prévision dont le but est d’apporter de la visibilité. Une roadmap est établie sur le long terme. Par principe celle-ci va donc évoluer en fonction des évolutions du marché, des expérimentations faites par l’entreprise et les équipes, de ce que les équipes apprennent lors de ces expérimentations.
3. S’assurer que l’organisation ne crée pas des experts
Enfin, éviter de transformer l’une des équipes en goulot d’étranglement. J’ai connu un train SAFe dans lequel une équipe était responsable du développement de l’ensemble des IHM, je vous laisse imaginer le WIP (Work In Progress) et les retards de livraison que cette décision peut entraîner sur le train. Il peut arriver qu’une technologie pointue nécessite d’être associée à une équipe experte dans ce domaine. Dans ce cas, les autres équipes doivent, malgré tout, être capable de traiter des cas simples, aidées des conseils de l’équipe experte pour éviter les blocages. Nous revenons ici sur le principe du T-Shaping mais appliqué au niveau équipes.
Terminons avec la troisième dimension « Build-In Quality »
1. L’informatique est un métier nécessitant de l’expérience
Le développement de logiciel est un métier de plus en plus complexe, nécessitant des compétences robustes. On ne devient pas développeur après une formation de 3 mois aux langages Java et C++. Avec la meilleure volonté du monde, un développeur à peine formé ne fera pas un logiciel robuste. Qui accepterait de faire construire sa maison par un artisan formé en trois mois à la maçonnerie, la plomberie et à l’électricité ? Toute équipe devrait être constituée de seniors jouant le rôle de mentors auprès de juniors.
Dans le Compagnonnage, le Maître est reconnu par sa capacité à transmettre son expertise aux Compagnons et Apprentis. En entreprise, la reconnaissance ne doit pas être uniquement associé au niveau d’expertise de la personne, mais également à la capacité à transmettre cette expertise. Transmettre c’est également apprendre.
2.Un manager qui n’est pas reconnu par ses équipes n’est pas un bon leader
Le management d’équipe informatique doit avoir un minimum de culture informatique. Un manager m’a expliqué une fois qu’il n’y avait pas besoin de testeurs si on avait de bons développeurs, car de bons développeurs produisent du code sans bug. Dans une autre entreprise, le chef de projet était désespéré car son management lui avait retiré le budget pour faire des tests unitaires. Pourquoi dépenser du budget à tester des composants si le produit final fonctionne ? A l’inverse, un bon manager va donner les moyens et encourager les équipes, sponsoriser les initiatives liées à la qualité. Une bonne pratique : consacrer 20% du budget à des « enablers », c’est-à-dire des « features » non liées au développement de nouvelles fonctionnalités, mais à l’amélioration de l’outillage ou du code, la diminution de la dette technique.
3. Un bon testeur ne trouve pas de bugs, il évite qu’ils soient créés
Le rôle d’un testeur n’est pas de trouver les bugs introduits par les développeurs, mais d’éviter au développeur d’en livrer. Pour cela la grande majorité des tests doit être automatisée et exécutée par le développeur avant livraison. Le même principe s’applique lors du déploiement. Lors de cette phase, des tests automatiques doivent permettre de se prémunir de bugs. Le développement de ces tests automatiques a autant de valeur que le développement du code ou le paramétrage de l’application. Les principes du CI/CD (Continuous Integration, Continuous Deployment) sont aujourd’hui incontournables pour permettre un déploiement continu de nouvelles fonctionnalités.
En écrivant ces lignes je suis conscient que bien d’autres prérequis sont liées à « Teams & Technical Agility » et que j’ai été bien subjectif en identifiant ces 3 x 3 prérequis, bien d’autres peuvent être listées. Et vous, quelles seraient les prérequis que vous mettriez en avant ?
Thierry Ventadour, Consultant Agilité à l’échelle