On se retrouve pour le deuxième chapitre : les valeurs de l’agilité

Nous allons voir ensemble ce qu’elles sont :

Il y a quatre grandes valeurs et douze principes qui nous ont été donnés dans le manifeste agile.

Quatre valeurs qui sont plutôt des concepts philosophiques et ensuite on va retrouver douze principes de comment appliquer, mettre en oeuvre ses valeurs par des actions concrètes.

Avant de rentrer dans les détails de chaque valeur puis des principes, je te propose d’abord de te les présenter de manière très générale.

Les quatre valeurs 

• les individus et leur interaction plus d’importance que les processus et les outils

• un produit opérationnel a plus d’importance qu’une documentation exhaustive 

                le vrai terme est plutôt un logiciel opérationnel mais j’aime le remplacer par produit parce que ça peut s’appliquer à n’importe quel champ d’activité 

• la collaboration avec le client a plus d’importance que la négociation contractuelle

• l’adaptation aux changements a plus d’importance que le suivi d’un plan 

Dans beaucoup des documents qui parlent du manifeste agile, il y a également une petite phrase, petite mention en dessous très importante qui prend tout son sens ici : nous reconnaissons la valeur des seconds éléments mais privilégions les premiers.

Ça veut dire que ca n’est pas blanc ou noir, c’est pas l’un ou l’autre, c’est ensemble mais par contre on donne plus de priorité, plus d’importance, plus de valeur à l’une des deux composantes de ces valeurs.

Les douze principes je ne les développe pas ici, on les verra en temps et en heure dans une prochaine vidéo.

Alors première valeur :

Les individus et leurs interactions en plus d’importance que les processus et les outils

Essayons de décomposer un petit peu cette valeur et on essaiera d’avoir la même le même principe de fonctionnement sur toutes les valeurs.
les individus et leurs interactions d’un côté les processus et les outils de l’autre.

Je le disais dans la vidéo d’introduction, il ne s’agit pas d’opposer ces deux concepts mais bien de voir dans quelle mesure ils sont complémentaires et ensuite de prioriser, se focaliser sur la première partie à savoir ici les individus et leur interaction.

Les processus et les outils, je vais commencer par cette partie là ,on connaît tous ça, c’est l’e-mail, ce sont les outils de communication : Slack, Trello, Teams et tous les outils qu’on peut mettre en place et il y en a des tonnes. 
Ce sont des outils très important parce qu’ils nous permettent d’échanger de manière asynchrone, sans être tous présents et disponibles au même moment et de garder des traces écrites.
Les processus, je parlais des outils, uniquement de communication mais tous les outils évidemment sont concernés, les processus, c’est également le fait d’écrire ce qu’on fait comment on le fait.

Là où nos rédacteurs du manifeste agile ont mis le point très fort, c’est sur le fait de dire :
– il faut des processus
– il faut évidemment expliquer comment on va travailler
– il faut des outils pour supporter notre façon de travail mais ce qui est vraiment important c’est l’humain.

C’est l’humain qui travaille ; au final, c’est l’humain qui fait et donc on va s’intéresser à l’humain et à ses interactions. Alors, ça prend toutes les formes que l’on veut, les interactions entre les humains, c’est aussi se parler, c’est aussi se rencontrer, c’est aussi être ensemble.

Un biais tout simple : la différence de communication entre l’oral et l’écrit.

Tu l’as certainement vécu, c’est très compliqué, ça devient de plus en plus compliqué. On est en 2021 aujourd’hui, il y a la crise de la COVID qui est passée par là, qui a amené beaucoup de télétravail, qui nous a forcé à utiliser beaucoup d’outils. 
On se rend bien compte que la communication peut parfois devenir un sujet d’ambiguïté, voire de tensions au sein des équipes.

C’est très important donc de trouver comment on s’appuie sur ces interactions humaines : on fait de l’oral, on se croise, on se dit les choses, on reformalise et on reformule.
Tout ceci permet d’améliorer cette première partie sur les individus et leurs interactions, on va essayer également de mettre en place un cadre qui permet aux individus de s’épanouir, on va leur faire confiance, on va leur donner de la responsabilité, on va être bienveillant, on va être exigeant.

Tout ça fait en sorte que notre attention soit portée sur les individus. Elle favorise leurs interactions plutôt que s’intéresser aux processus et aux outils qui sont simplement un moyen, qui ne sont pas un but.

On se retrouve pour parler de la deuxième valeur, on va prendre : 

Un logiciel ou un produit opérationnel a plus d’importance une documentation exhaustive 

Qu’est ce qui nous intéresse ici ?
Encore une fois, on n’est pas dans l’opposition mais plutôt dans la complémentarité 

Dans le monde de l’informatique, quand on veut développer une solution, il faut évidemment que quelqu’un exprime un besoin et écrive sous forme de documentation le besoin, les tenants et aboutissants de ce que l’on veut construire, c’est ce qu’on appelle la spécification, la documentation. 
Et bien là simplement, parce qu’on est focalisé sur le pragmatisme, sur l’empirisme, sur la démonstration et bien nos rédacteurs du manifeste agile ont voulu dire : il faut la documentation, évidemment parce qu’il faut qu’on puisse maintenir, il faut qu’on puisse modifier, il faut qu’on puisse savoir ce qui a été fait, pourquoi ça a été fait, mais surtout avant tout il faut proposer à notre client un produit qui fonctionne.

Rappeles-toi l’exemple que j’avais pris dans cette vidéo : Le skateboard.
Je vais vouloir, à chaque itération, présenter à mon client quelque chose qui fonctionne, quelque chose d’opérationnel, que ce soit un logiciel, un produit ou un service ; je lui montre lors de ma première itération et à chaque itération, quelque chose qui fonctionne, qu’il peut utiliser.
Parce que grâce à ça, il va me donner un retour, il va vous donner son avis et c’est ça qui permet de pouvoir 

• s’adapter 

• incrémenter

• continuer les itérations

Évidemment, ça sous-entend qu’on continue toujours la documentation, on essaye de la faire de la meilleure façon parce que c’est important pour tout ce qui est maintenance, mode d’emploi. Ça ne nous viendrait pas à l’esprit d’acheter un meuble et qu’il n’y ait pas le manuel pour le monter pour autant on peut aussi acheter un meuble qui est déjà monté et on voit à quoi il ressemble.

Troisième valeur dans l’ordre de celles qu’on a listées :

La collaboration avec le client a plus d’importance que la négociation contractuelle 

Alors là, on touche un élément assez central des équipes qui se disent agile et des entreprises qui se disent agiles, c’est comment avec mes interlocuteurs, mes partenaires, mes clients et mes fournisseurs, je fonctionne.

On a un cadre légal qui s’appelle un contrat, un devis, une commande, peu importe le nom qu’on lui donne c’est le cadre de travail.
Il est évident que certains y verront une protection : ce qui est dans le contrat me permet de m’assurer que j’aurai ce que j’ai marqué mon contrat ou que je ne ferai pas plus que ce que j’ai validé dans le contrat. A l’inverse, on peut aussi y voir un cadre très restrictif, très contraignant : 
Si pour une raison x ou y je change d’avis, moi en tant que client, est-ce que je peux vraiment revoir mon contrat et quelles seront les conséquences ? 
Si moi fournisseur, j’ai une autre proposition à faire, est ce que j’ai le droit contractuellement de faire ça ? 
Et donc, là encore, ce qu’on nous propose c’est de sortir un petit peu de ce schéma parfois d’opposition entre un client et un fournisseur mais d’essayer plutôt d’être dans la collaboration, la coopération avec le client 

Qu’est ce que ça veut dire ?
Ça peut vouloir dire plein de choses. Les exemples que j’aime prendre sont par exemple de dire qu’on va pas faire un contrat sur l’intégralité du projet ou de l’action qu’on a imaginé avec notre client mais qu’on va faire un contrat par itération.
On s’engage à travailler sur une itération ensemble et à la fin de cette itération, on fera le bilan pour savoir si on continue ou si on ne continue pas. 
Ça peut être un exemple comme ça.
Je sais qu’il existe de plus en plus de contrats dits agiles qui permettent justement aux parties prenantes de négocier, de revoir, de s’adapter y compris sur le contrat. On sait à quel point ça peut être lourd de revoir un contrat qui serait figé, on va faire des avenants, on va avoir des processus de signature qui peuvent être parfois longs, contraignants ou engager des responsabilités qui ne sont pas forcément nécessaire d’engager ou déranger pour une modification x ou y.

Le vrai but ici, c’est de se dire « Ne soyons pas dans quelque chose de fermé, de strict qui parfois nous enferme mais essayons d’avoir un esprit ouvert dans la relation qu’on a avec notre client »

Et enfin on se retrouve pour la dernière valeur 

L’adaptation aux changements a plus d’importance que le suivi d’un plan 

Là, pas vraiment d’interprétation compliquée à avoir :
il est important d’avoir un plan en tête, d’avoir une vision.
Est-ce qu’il est pertinent d’avoir un plan détaillé de chaque action ?
Est ce qu’il est pertinent d’avoir un plan à dix ans dans une société mouvante, dans une entreprise, dans un société de consommation, dans un écosystème mouvant, dans une période incertaine comme peut l’être en ce moment la période que l’on vit ?

Ce sont les questions qu’on peut légitimement se poser et on va revenir à un des mots clés que je vous donnais en introduction qui est l’adaptation.
L’adaptation au changement, c’est l’adaptation aux changements du client, c’est l’adaptation aux changements internes ; mon équipe change, mes compétences changent, la société change, les technologies changent…
Tout ça je vais pouvoir m’adapter pour m’améliorer à chaque fois.
Je vais faire un petit pas de recul, prendre une vision plus large et m’adapter par rapport au retour et à l’expérience que je tire de tout ce que je viens de vivre.
On est vraiment là dedans :
Il pleut j’avais prévu de sortir, est-ce que je vais sortir sans manteau ? 
Non, je vais m’adapter au changement, je vais prendre un parapluie, je vais prendre un manteau.
C’est un exemple hyper basique hyper simpliste, mais on est vraiment là dedans et on se rend bien compte, malheureusement, que bien souvent on imagine un plan dès le début d’un projet où dès le début d’un travail et que finalement on ne prend jamais la capacité de faire un pas de côté et de changer ce plan.
On avait signé ça, on s’engage, on y va coûte que coûte ! Et bien, l’agilité, ici, nous dit : ne soyez pas fermés ; de la même façon que sur la valeur d’avant on parlait de ne pas rester sur un schéma d’opposition avec notre client ; et bien ici, c’est pareil, ne soyons pas fermés sur un plan qu’on aurait fait il y a trois ans, adaptons-nous aux changements qui ont eut lieu depuis, adaptons-nous aux changements du client, adaptons-nous aux changements d’idées.

J’espère que, encore une fois, cette valeur devient un peu plus claire pour toi.

On se retrouve pour la partie peut-être la plus importante du manifeste agile.

On vient de voir les quatre valeurs ensemble, ce qu’elles voulaient dire. 
Maintenant, au quotidien, comment peut-on transcrire ces concepts un peu philosophiques dans quelque chose qu’on va pouvoir appliquer ?
Et bien, très simplement, les rédacteurs du manifeste Agile nous ont proposé douze principes.
Douze mises en oeuvre concrètes d’action pour qu’on puisse être agile, devenir agile.
Je te propose qu’on les parcourt ensemble avec un peu d’explications à chaque fois . 

Le premier il s’agit de :

Prioriser la satisfaction client

Ça veut dire quoi ? Ça veut dire que dans tout ce qu’on fait, il va falloir qu’on s’intéresse surtout à ce que notre client veut.
Rappeles-toi qu’on se focalise surtout sur son besoin, mais pour qu’il soit satisfait, ça ne doit pas s’arrêter là. On va l’impliquer avec nous dans le processus de création, de développement, de production. On va écouter son retour, on va s’adapter à ses besoins pour vraiment, à chaque fois, lui apporter le plus de valeur possible.

Deuxième principe 

Accepter les changements 

Alors « accepter les changements », ça va un peu de pair avec le premier principe.
Ça veut dire qu’on est capable d’écouter et de s’organiser pour qu’un changement ne vienne pas casser tout ce qu’on a mis en oeuvre.
C’est un des principes fondamentaux l’agilité : l’adaptation au changement, on l’a vu ensemble, c’est l’une des valeurs principale donc c’est forcément comment, au quotidien, j’accepte les changements.

Le troisième principe
dans les termes qui sont donnés on est très proche du langage informatique mais on peut l’appliquer à n’importe quoi 

Livrer en permanence des versions opérationnelle d’une application 

On pourrait le dire également : livrer régulièrement un produit opérationnel
quel qu’il soit.
Qu’est ce que ça veut dire ? Ça veut dire que à chaque fois qu’on livre ou qu’on produit quelque chose que l’on donne à notre client, je vous l’ai dit déjà, il faut que ça fonctionne pour que nos clients puissent le tester. 
Mais en plus, il faut qu on ajoute une vitesse, il faut qu’on ajoute un rythme à tout ça. 
Si on fait régulièrement cette livraison de quelque chose d’assez simple finalement, on va aussi être plus capable de s’adapter aux changements.

Prenons un exemple très concret : un mur de lego.
J’ai besoin de livrer un mur en lego à mon client.
Et bien, Qu’est ce que je vais faire ? 
Je vais poser la première brique et je vais dire : « Client, voici la première brique »
Evidemment, ça ne remplit pas le besoin fondamental du mur en lego mais j’ai posé une première brique. C’est opérationnel, le client peut tester.
Je vais poser une deuxième brique : « Client, voici ma deuxième brique »
Déjà on va pouvoir interagir avec notre client. Est-ce que ça correspond bien à ce que notre client voulait ? 
J’ai mis deux briques de la même couleur ou j’ai mis deux briques différentes, alors que mon client voulait une couleur unie. 
Voilà le genre de réflexions, discussions qu’on va pouvoir avoir très rapidement

Le troisième point, très intéressant dans ce phénomène d’itérations très court et très simple, est que si le client me dit « Non, c’est absolument pas ce que je veux », je peux jeter ça à la poubelle. 
Ça m’a coûté deux briques de lego. 
Je n’ai pas construit un mur entier en lego que le client a rejeté en bloc. 
Non, j’ai mis deux briques et au bout de deux briques il m’a dit « Non, ça n’est absolument pas ce que je veux »
Donc il y a vraiment un sujet très important sur la valeur du client

Quatrième principe 

Assurer le plus souvent possible une coopération entre l’équipe du projet et les gens du métier

On va ici parler de structuration, d’organisation. 
Il faut qu’on échange, qu’on collabore, qu’on coopère – peu importe le terme qu’on y met – avec notre équipe. Depuis le client qui exprime son besoin jusqu’aux testeurs qui testent ou qui s’assurent que ce qui a été produit correspond aux besoins et répond au cahier des charges. il faut qu’on échange, il faut faut qu’on clarifie, il faut qu’on demande.

Cinquième principe 

Construire les projets autour de personnes motivées

Construire une équipe agile, C’est aussi faire preuve, dans son management,d’autres approches. On va arrêter le micro management. Là où on décide de toutes les tâches pour toute l’équipe. 
On va être dans la confiance
On va être dans la délégation, vers dans la responsabilisation de notre équipe
Ça ne se fait pas comme ça. L’équipe doit apprendre à se connaître, l’équipe doit apprendre à travailler ensemble, mais en tout cas, il faut absolument qu’on aille vers cette structure et cette organisation pour devenir agile. 
Et si on arrive à faire ça, on va avoir une équipe qui va devenir motivée.

Sixième principe 

Favoriser le dialogue direct

Qu’est ce que ça veut dire ça veut dire ?
Si je reprends une des premières valeurs : les individus et leur interaction plus d’importance que les processus et les outils.
Evidemment, on va faire de l’écrit. 
Evidemment !
Mais parlons nous, parlons nous à l’oral, levons les ambiguïtés, levons les sous-entendus et rien de mieux pour ça que le face à face.

Septième principe 

Mesurer l’avancement du projet en fonction de l’opérationnalité du produit

Autrement dit, on va sortir du mode de suivi des projets sur le budget dépensé, sur les ressources allouées, sur le temps dépensé.
On va jouer sur autre chose : on va jouer sur le produit.
C’est ça notre variable d’ajustement. 
Notre but étant d’amener le plus de valeur possible à notre client, on va mesurer l’avancement de notre projet en fonction de la valeur qu’on a amenée et des fonctions qu’on a proposées à notre client.
Parce que, encore une fois, le but d’un fonctionnement en mode agile c’est – rappelez vous cette image – à chaque fois de proposer quelque chose qui fonctionne, ce soit un logiciel ou un produit peu importe. 
On veut quelque chose qui fonctionne et donc on est capable de mesurer les fonctions qu’on a apportées à notre client. Même si ça s’adapte, même si ça évolue, même si on n’avait pas imaginé toutes les fonctions dès le début, on est capable de montrer et de mesurer ça.

Huitième principe 

Adopter un rythme constant et soutenable par tous les intervenants du projet

Le but c’est quand même d’avoir quelque chose de constant : une cohérence une consistance dans le temps.
Ça veut dire qu’on ne s’adapte pas à chaque fois que le client change d’avis y compris en cours de route.
Ça veut dire qu’il y a des organisations bien précises.
Scrum (on verra peut être une prochaine fois Scrum) est une méthode très appliquée dans le monde des méthodologies agiles qui définit un certain nombre de structures et d’organisation et de rituels. 
Et bien dans chacune des méthodes on a ce genre de fonctionnement. Et donc, on a des cycles, on a des sprints et le principe est qu’on fournit à la fin d’un cycle,d’une itération, un produit qui fonctionne et à ce moment là, notre client nous donne son avis. Et change d’avis si ça lui plaît ou fait un retour. 
Mais entre chaque cycle, on a défini quelque chose avec le client, les parties prenantes on s’engage à le faire et on va jusqu’au bout. 
C’est pour ça qu’on fait des cycles courts : Pour ne pas laisser notre client dans le vague.
C’est pour ça qu’on fait quelque chose qui fonctionne : Pour que le client puisse tester et faire un retour.
Mais on a des choses carrées, ça n’est pas le chaos.
Et donc on veut que ce rythme soit constant, soit soutenable. 
C’est à dire que chaque équipe ne se tue pas à la tâche pour mettre en oeuvre ce produit ou ce logiciel ou ce qu’on est en train de produire entre.

Neuvième principe 

Contrôler continuellement l’excellence de la conception de la bonne qualité technique 

Là on parle de bonnes pratiques, d’excellence de conception de qualité.
Parce que là encore, ça n’est pas parce qu’on fait quelque chose de rapide qu’il faut le faire dans l’urgence. Ce qu’on veut, c’est faire quelque chose de rapide, qui fonctionne même si c’est tout petit. 
Par contre, on veut être dans les bonnes pratiques. On veut respecter les règles. Donc il faut que nos équipes soient claires dans l’organisation qu’elles ont ensemble, pour faire appel peut-être à des experts. Il faut que nos règles de travail soient claires :
Qu’est ce qu’on considère comme terminée et qu’on peut montrer un client ?
Est-ce que c’est quelque chose qu’on a produit, testé, simplement développé ?
 il faut que tout ça soit très clair y compris dans la communication, pour que notre conception soit digne des bonnes pratiques.

Dixième principe 

Privilégier la simplicité en évitant le travail inutile

On se rapproche de celle qu’on vient de voir ensemble.
Il faut simplifier !
Il faut simplifier !
Il faut penser, y compris dans sa conception, simple.
Simple et adaptatif.
C’est parfois très difficile de prendre du recul, parce qu’on a une façon de travailler qui est particulière. Là on veut vraiment penser simple, découper simple
Ça n’est parce qu’on a la vision de là où on veut aller, qu’il faut absolument la faire dès la première étape. Il faut découper ça en étapes incrémentale qu’on va pouvoir ajuster et améliorer au fur et à mesure .

On arrive sur les deux derniers principes qui sont très liés à l’équipe et son comportement.

Onzième principe 

Auto-organiser et responsabiliser les équipes 

Ici le principe parle de lui-même : on veut que les équipes s’auto-organisent et deviennent responsables de leurs engagements.
Ça sous-entend beaucoup de confiance. 
Ça sous-entend moins de contraintes, de la délégation, de la communication.
On va expliquer une vision, on va expliquer les objectifs,les enjeux et l’équipe – en connaissance de cause, et parce qu’on les a choisis pour travailler avec nous – va pouvoir, va devoir s’engager et va s’engager et prendre ses responsabilités.

Dernier principe toujours autour de l’équipe 

Améliorer régulièrement l’efficacité de l’équipe en ajustant son comportement 

C’est ce qu’on appelle dans beaucoup de méthodologie les rétrospectives.
Par exemple, c’est faire un pas de recul, prendre le temps de faire le bilan : 
Ce qu’on vient de faire
Comment on l’a fait ? 
Est-ce que ça s’est bien passé ?
Est-ce qu’on a des choses à améliorer ?
Est-ce qu’on a des choses qu’on veut continuer à faire ? qu’on veut arrêter de faire ?
Voilà, c’est s’améliorer dans une boucle qui ne s’arrête jamais. Et donc à la fin de chaque itération potentiellement, certaines méthodes le préconisent, la fin de chaque itération, on va prendre un temps dédié à l’amélioration continue et à faire ce bilan.

Voilà, j’ai fait le tour de ses douze principes.

J’espère que les explications te paraissent claires pour que tu puisses imaginer comment les appliquer au quotidien.
Les termes sont assez faciles à appréhender. Je pense qu’elles permettent assez bien de visualiser comment on passe de ces quatre valeurs comme je disais, comme je le répète souvent, un peu philosophiques, à une application dans le quotidien.