L’Agilité est comme ces tartines : réussie ou cramée. Voici les secrets de certaines équipes agiles que je connais qui réussissent fièrement, en respectant l’esprit des douze principes de l’Agile Manifesto ; et comment d’autres que je connais aussi, ratent brillamment en réinterprétant comme cela les arrange ces mêmes principes agiles que voici.

1-Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée

Les équipes agiles qui réussissent ont compris comment identifier la valeur ajoutée : non seulement elles demandent leur avis aux clients à chaque livraison, mais de plus elles vont voir comment les clients utilisent le produit en s’asseyant à côté d’eux. Clients qui définissent eux-mêmes leurs priorités. Evidemment, elles suivent le NPS client chaque semaine. Le NPS client, pas celui du co-contributeur qu’est le Product Owner.

Celles qui ratent se contentent d’essayer de livrer à l’heure, sans un retour client, ou pire, sans analyser ni tenir compte de ces retours, selon une drôle de priorisation issue de rapports de force souterrains et synthétisée par le seul cerveau du PO. Sans jamais réussir à satisfaire ces mêmes clients…

2-Accueillez positivement les changements de besoins, même tard dans le projet. Les processus agiles exploitent le changement pour donner un avantage compétitif au client

Les équipes agiles qui réussissent produisent un véritable MVP itératif. En production dès le début. La tranche de cake plutôt que la couche de gras. En outre, certaines poussent la vertu jusqu’à tenter le concurrent engineering pour valider certains choix d’architecture, de framework ou de service particulièrement impactants à terme. Les modifications en cours de sprint sont évitées par un statut des US « ready to dev » exclusivement validé par les dev.

Celles qui ratent se contentent de renommer « Lot x » en « MVPx » ou « Sprint x » et cherchent à délivrer le plus possible le plus tôt possible, coûte que coûte. Quitte à devoir recommencer, ou à se trainer une dette technique pour des années…Tout en se battant contre les conséquences de modifications incessantes en cours de sprint, dues à des US bâclées en deux lignes et ainsi poussées en Dev, en dépit du bon sens.

3-Livrez fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts

Les équipes agiles qui réussissent se sont organisées pour livrer en production, à chaque sprint, d’une à trois semaines. Sans revert, ni roll-back, ni incident en production. En travaillant la qualité avant la vitesse. Quitte à ne rien livrer du tout tant qu’on n’est pas au niveau. Les plus performantes ont basculé dans un véritable CI/CD effectivement continu, après des années d’améliorations elles aussi continues.

Celles qui ratent sont tellement en retard, tellement écrasées par le volume de correctifs à livrer, qu’il n’est pas question de consacrer une seconde de trop à la qualité. Inversant ainsi le résultat avec la cause. Quant aux améliorations, elles s’en occuperont dès qu’elles en auront le temps…

4-Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet

Les équipes agiles qui réussissent embarquent dans leurs instances, quotidiennes ou hebdomadaires, de vrais clients ou utilisateurs, dont le principal job est de définir tout ce qu’on ne va PAS développer. Et d’expliquer l’importance des petites évolutions. Petites en complexité, énormes en valeur. Tout le long du projet, et même au-delà.

Celles qui ratent prennent leurs ordres d’un « représentant client » qui n’a jamais exercé le métier, ni utilisé une application pour ce faire. Un PO ou une AMOA qui compense son ignorance des contraintes opérationnelles du métier par ses très nombreuses « bonnes » idées, stockées dans de nombreux backlogs bien saucissonnés qui réclameraient des années à écluser.

5-Réalisez les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont elles ont besoin et faites-leur confiance pour atteindre les objectifs fixés

Les équipes agiles qui réussissent définissent leurs objectifs opérationnels selon les attentes de leurs clients, en suivent les mesures, identifient les causes racines qui les empêchent de les atteindre, et prennent le temps de partager les connaissances ainsi acquises et formalisées avec l’ensemble de l’équipe. Leur réussite renforce leur motivation. Leurs PO ont bénéficié de véritables formations étalées dans le temps, pratiques et assorties de coaching individuel pour disposer de toutes les clefs de ce qui se trouve être l’un des métiers les plus exigeants de l’IT. On reconnait ces équipes à leur stabilité, à leur cohésion et à leur engagement.

Celles qui ratent ne mesurent rien, n’identifient pas de causes racines, ne formalisent jamais leur savoir et se contentent de faire répéter inlassablement à leurs experts les mêmes explications à de nouveaux nouveaux. Tout en demandant « qu’on leur fasse un peu confiance », elles ne s’engagent jamais sur rien, « Tu comprends on est agiles nous ». Leurs PO ont été balancés dans le job après une vague formation en salle de deux jours. On reconnait ces équipes à leurs plaintes, à leur immobilisme et à leur turn-over.

6-La méthode la plus simple et la plus efficace pour transmettre de l’information à l’équipe de développement, et à l’intérieur de celle-ci, est le dialogue en face à face

Les équipes agiles qui réussissent visualisent leur avancement sur un affichage qui représente les étapes réelles du flux de leur activité, conçu par eux et mis à jour par chacun au fil de l’eau avant le daily ; elles demandent facilement de l’aide, se coordonnent autour des livraisons intermédiaires, prennent des décisions et se félicitent de leurs succès.

Celles qui ratent s’épanchent en daily sur la nature de leurs activités en cours et sur leur avancement, sans autre support visuel qu’un simple tableau trois colonnes Todo-Wip-Done mis à jour par le tech lead, le team leader ou le scrum master, sans mesures, et avec très peu d’actions ou de décisions prises.

7-Un logiciel opérationnel est la principale mesure d’avancement

Les équipes agiles qui réussissent se préoccupent autant de l’exploitation que du build. Elles mesurent, d’une part, le nombre d’incidents en production, dont elles cherchent à réduire le volume d’occurrence ; et d’autre part la durée d’indisponibilité du SI du point de vue des utilisateurs concernés, qu’elles cherchent également à réduire. Pour ce faire elles cherchent, et trouvent, comment modifier le système pour éviter les réitérations d’incidents. Elles visent un taux de disponibilité ou de qualité à au moins 4 sigmas, soit 99,85 %. Soit 4 minutes 30 secondes d’indisponibilité par semaine de 50 heures de plage de fonctionnement.

Celles qui ratent ne cherchent, dans le meilleur des cas, qu’à accélérer la remise en service du système, sans jamais chercher à en comprendre les causes de réitération, ni à les corriger. Elles n’en ont pas le temps, pas plus que de mesurer leur taux de défaut, souvent largement supérieur à 15 %, ou leur stock d’incidents non résolus du point de vue du client / utilisateurs, qui peut atteindre des centaines d’anomalies en attente.

8-Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant

Les équipes agiles qui réussissent savent estimer correctement, donc tenir leurs engagements. Pour ce faire, elles découpent leurs US en tickets élémentaires dont aucun n’excède une demi-journée, voire deux heures. Chaque sprint produit le même volume stable d’US de taille homogène, au même titre que la cible.

Les équipes qui ratent ne perdent pas de temps, ni au découpage, ni aux estimations, trop chronophages. Elles courent après leur retard de chaque sprint qui s’accumule, et délivrent très irrégulièrement un nombre d’US par sprint variable d’un facteur 1 à 15 ; US dont la taille varie aussi d’un facteur un à vingt ou plus.

9-Une attention continue à l’excellence technique et à une bonne conception renforce l’Agilité

Les équipes agiles qui réussissent pratiquent le peer-programming et effectuent des revues de codes qui sont autant d’occasions de montée en compétence de novices mentorés par les experts. Elles disposent de Users Stories claires, documentées, enrichies de cas de tests passants et non passants, découpées en petites tâches.

Les équipes agiles qui ratent pratiquent éventuellement aussi le peer-programming et effectuent aussi des revues de codes, qui sont autant d’occasions pour les experts de corriger eux-mêmes rapidement les erreurs que les novices continuent de produire de manière répétée, jusqu’à ce qu’ils soient remplacés. Leurs US ne sont ni décrites, ni documentées, ni découpées, ni estimées.

10-La simplicité, c’est-à-dire l’art de minimiser la quantité de travail inutile, est essentielle

Les équipes agiles qui réussissent exécutent des milliers de tests automatisés chaque soir, à l’issue de chaque commit, sur des données copies de celles de production à fréquence élevée. Elles cherchent à merger leurs branches à une fréquence la plus élevée possible, idéalement quotidienne, afin de limiter au maximum la génération de conflits.

Celles qui ratent ne disposent ni des budgets ni du temps ni de la volonté réelle de construire un système d’autocontrôle quotidien du code produit. Elles repoussent les merges le plus tard possible, de plusieurs semaines, du fait des nombreux conflits très chronophages qu’ils génèrent systématiquement.

11-Les meilleures architectures, spécifications et conceptions émergent d’équipes auto-organisées

Les équipes agiles qui réussissent ont fixé pour règle que c’est l’étape « aval » qui valide le caractère recevable ou non du livrable produit par l’étape « amont ». Quand ce n’est pas bon, ce n’est pas bon. Inutile de créer plus de problèmes à l’étape suivante.

Les équipes agiles qui ratent peuvent bien avoir défini des standards de statuts comme Ready To Dev, Done ou Done-Done, dans les faits c’est le PO, ou le manager, ou le métier qui décide. Au besoin en rappelant que « on est une équipe agile, les gars, et donc que ça serait cool si vous vouliez bien faire un effort. » Poussant ainsi le long du processus des packages bancals, du code non testé, des specs sans use case, des idées sans besoin, jusqu’aux inévitables bugs en prod si chronophages à traiter.

12-À intervalles réguliers, l’équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence

Les équipes agiles qui réussissent investissent chaque semaine entre 5 et 10 % de leur temps de travail à chercher comment éviter la réitération de petits irritants ou de gros problèmes, au choix de chacun. Soit entre 2 et 4 heures par personne, chaque semaine de l’année. Soit entre 92 et 184 heures par personne. Soit encore entre 13 et 25 jours par an et par personne. Avec le soutien de leur hiérarchie activement engagée dans cette pratique de résolution de problèmes. Au bout d’un an, on en a ôté, des cailloux, parmi lesquels quelques dolmens au milieu du chemin.

Celles qui ratent font déjà, en principe, une rétrospective d’une heure à la fin de chaque sprint de trois ou quatre semaines. Au total, un jour et demi par personne et par an, sauf grosses engueulades.
Chacun vient poser son « Stop ou Encore », en attendant son tour. D’autres établissent rituellement leur liste de vœux pieux, tous pertinents mais dont aucun ne sera suivi du moindre effet. A moins qu’à la prochaine rétro… Au bout d’un an, rien n’a changé, à part le Tech Lead qui est parti.

En conclusion, les équipes agiles qui réussissent se préoccupent de quatre choses :

1. comprendre vraiment les attentes de leurs clients,
2. organiser un système de montée en compétence technique spécifique à chacun,
3. améliorer et mesurer continument leur performance en trouvant des moyens pour éviter la réitération de problèmes évitables,
4. former et accompagner en interne leurs PO et tech leads.

Les équipes agiles qui ratent se préoccupent de :

1. appliquer rigoureusement les cérémonies,
2. savoir si elles sont suffisamment agiles ou pas déjà un peu trop Lean,
3. négocier avec les métiers et la direction pour qu’on leur fasse enfin un peu plus confiance,
4. chercher à recruter en externe leurs sauveurs.

Et vous dans votre équipe, vous êtes plutôt quel type de tartine ?

Chez Operae Partners, nous travaillons depuis 18 ans avec des équipes agiles qui veulent aller au bout de leurs rêves d’agilité. On ne va pas vous mentir, il y a beaucoup de travail pour y arriver… mais elles y arrivent. Contactez-nous !