Introduction
Chapitre 1
Chapitre 2 :
Chapitre 3 :
Conclusion
Salut et bienvenue dans cette session expérimentale pour découvrir l’agilité !
Si tu es là avec moi, c’est que tu as envie de comprendre ce que c’est que l’agilité et donc je te propose de faire un petit récap de ce qu’on va voir ensemble :
Trois chapitres
D’abord on va avoir trois grands chapitres :
une introduction à l’agilité les origines de l’agilité, d’où est-ce que ça vient.
Puis ensuite on verra en détails les valeurs et les principes de l’agilité et on terminera sur l’application au quotidien de ce concept d’agilité.
L’organisation
Chaque chapitre va être restructurée de la même façon :
On va retrouver des vidéos ainsi qu’une transcription sous forme de textes parfois illustrés pour que tu puisse travailler comme tu le souhaites.
Et puis à la fin de certains des chapitres, je te propose un exercice, une question avec des réflexions que tu vas essayer d’apporter par rapport à ce que les vidéos et les textes ont provoqué chez toi.
Un temps d’échange
A l’issue de cette session, ce que je te propose pour vraiment clore en beauté, c’est d’avoir un échange. Toi et moi, directement, de 30 minutes, on va s’appuyer sur les réflexions que tout ce que ça aura provoqué, les réponses aux formulaires que tu m’auras envoyées et on essaiera de voir ensemble ; et bien d’aller plus loin, en fait, tout simplement, de voir ce qu’est l’agilité, de comprendre qu’elle peut être, des difficultés, les leviers, ce que tu as fais, ce que tu n’as pas fait et avoir un échange constructif et bienveillant.Allons-y !
Pour commencer je te propose un petit jeu, un petit quizz, que j’appelle le kikadiça : des phrases, à toi de retrouver qui a pu dire chacune des phrases et puis on se retrouve juste après.
Trois phrases très simples, mais qui pourraient, je pense, représenter assez bien l’état d’esprit Agile.
Reprenons les ensemble une par une :
Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu : des chevaux plus rapides
Que veut nous dire Henri Ford ici ?
Simplement, avec cette expression, que les clients, comme nous tous, n’ont pas la capacité à se projetter, mais répondent à nos questions – ou imaginent des solutions – par rapport à leurs connaissances et compréhensions.
Et donc, ça n’aurait pas de sens de demander aux clients de se projeter sur une solution possible. Ce qu’on veut, c’est que ces clients expriment leurs besoins.
Je veux un velo n’a pas le même sens que Je veux me déplacer rapidement d’un point A à un point B et peut sous-entendre de grosses différences en termes de produit final.
Donc pour résumer : Quel est le besoin ?
Deuxieme phrase :
Ce n’est pas le rôle du client de savoir ce qu’il veut
Cette phrase paraît tellement provocante !
Mais en fait, si on l’analyse un peu, rien n’est plus vrai !
De la même façon que nos clients nous exposent bien souvent leurs solutions / fantasmes, ils ont bien souvent projeter ce qu’ils attendaient, sans prendre conscience de la réalité.
Et ici, Steve Jobs nous emmène vers cette prise de conscience :
Commençons par montrer quelque chose à nos clients, pour qu’ils revoient cette proposition au regard de leur besoin, et que l’on commence à affiner tout ça ensemble.
Si l’on résume : Produire quelque chose pour le client est plus important que de discuter du besoin.
Pour finir :
Cela ne fait aucun sens d’embaucher des gens intelligents puis de leur dire ce qu’ils doivent faire. Nous enrôlons des gens intelligents afin qu’ils nous disent ce que nous devons faire.
On touche ici plutôt au travail en équipe et au pouvoir que l’on confie aux équipes.
Et là encore, bien que ce soit surprenant, Steve Jobs nous incite à nous poser une question :
– Est-ce que les gens que l’on a choisi pour travailler avec nous ont besoin qu’on leur explique comment travailler ?
Et sa propositon de réponse est : NON !
Les gens que l’on recrute ont des compétences, et c’est d’ailleurs pour ça qu’on les a choisit. Notre devoir en tant que manager, chef d’equipe, pilote, c’est de donner le cadre de travail, de donner les règles de travailet la vision. L’équipe, en toute autonomie est capable de travailler pour atteindre les objectifs.
On se retrouve pour le premier chapitre concret autour de l’agilité.
On va d’abord parler un peu de l’histoire des méthodes agiles et d’où ça vient, ce concept d’agilité?
On va reprendre un peu le cours de l’histoire.
Il faut savoir que ce mot agile, il apparaît vraiment en 2001, lorsque des équipes de développeurs se sont réunies.
Alors, ils sont en montagne, ils font du ski. Et puis, un soir, à l’apéro, ils se réunissent et ils décident de poser noir sur blanc un manifeste : Le Manifeste du développement agile
Evidemment, ce sont des gens issus du monde de l’informatique qui amènent non pas des techniques d’informaticiens, mais des concepts plutôt philosophiques.
Qu’est ce que ça veut dire Faire quelque chose de façon agile?
Ce qui est très intéressant, c’est de se rendre compte que tout ce qui est amené autour de cette agilité, ce ne sont pas des choses forcément novatrices.
Par contre, ce sont des choses qui n’étaient absolument pas vues ensemble à cette époque là. Si on se plonge dans les livres de gestion de projets des années 70, on va retrouver tous les éléments qui sont amenés dans les méthodes agiles d’une façon générale, mais ils sont tous amenés individuellement.
Et la force, la nouveauté ici, c’est qu’on les a regroupées et qu’on a appelé ça l’agilité.
Donc, ils nous ont proposés un manifeste du développement agile.
Qu’est ce qu’il faut retenir de ça?
Il faut retenir que, évidemment, c’est quelque chose qui est issu du monde de l’informatique. On ne va pas se mentir, mais qui tend à se déployer sur tous les secteurs d’activité.
C’est une méthode, une philosophie qui est basée sur le pragmatisme, la pratique, l’expérimentation plutôt que la théorie.
Et c’est un principe. C’est une méthode qui met en avant trois grands mots clés.
S’il y avait une chose à retenir, c’est ces trois mots clés :
itération
incrémentation
adaptation,
Itération. Ça veut dire qu’on va produire de façon successive des éléments qu’on va pouvoir proposer à un client. Un utilisateur
Incrémentation. Ça veut dire qu’à chaque itération, on va augmenter la valeur de ce qu’on a produit. On va amener des nouvelles fonctionnalités, on va augmenter la valeur pour le client.
Et enfin, Adaptation. Ça veut dire qu’entre chaque itération, incrémentation, on va chercher à s’adapter, parce que le client ne sait pas ce qu’il veut et donc lui même va peut être revoir ses besoins et ses désirs. Et il va nous exprimer tout ça. Et nous, on va s’adapter.
Itération, incrémentation, adaptation.
Il y a peut être une image que tu as souvent vue. C’est celle-ci que l’on présente régulièrement dans les cours sur les méthodes agiles.
On a ici une proposition avec le schéma du haut :
on parle d’un pneu et on va jusqu’à une voiture et on rajoute quelque chose.
Évidemment, ce n’est pas très agile.
Pourtant, on a bien des itérations successives, on a bien des incrémentations, on rajoute de la valeur à chaque fois et on a bien une adaptation parce qu’on peut imaginer qu’on s’est adapté à chaque étape.
Mais il manque un dernier élément pour que notre client puisse percevoir et sentir ce qu’on a produit.
Pour lui, il faut que chaque itération produise quelque chose utilisable.
Et c’est là qu’on retrouve la ligne du dessous que tu vois ici, qui part d’un skate board et qui va lui aussi jusqu’à une voiture, mais qui répond à chaque fois à un besoin et qui permet aux clients de tester quelque chose.
– Quel est ton besoin?
– Je veux me déplacer
– Très bien, voici un skate board, tu peux te déplacer.
– C’est pas ce que j’avais imaginé.
– Effectivement, parce que tu as un biais dans ton cerveau qui est celui de la voiture.
– Mais si tu veux simplement te déplacer, un skateboard fait très bien l’affaire.
– Mais pour me diriger, c’est pas très pratique
– C’est un nouveau besoin.
On va donc incrémenter le produit qu’on a livré et on va rajouter un guidon. Ça devient une trottinette.
Alors évidemment, l’exemple ici est biaisé, tu comprends?
Mais c’est pour illustrer vraiment le propos.
Donc, il faut faire attention aussi à ce qu’on met derrière l’agilité. Ça n’est pas simplement des itérations, ça n’est pas simplement des incrémentation et adaptations.
C’est aussi proposer à nos clients quelque chose d’utilisable, de testable pour que lui même puisse nous faire un retour et qu’on puisse vraiment s’adapter et comprendre de mieux en mieux son besoin, voire que le client comprenne de mieux en mieux son besoin.
Ce que je te propose, c’est de passer à l’étape d’après, qui est un petit exercice dans lequel je te demande simplement qu’est-ce que l’agilité pour toi ?
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.
Alors on se retrouve maintenant pour parler de
Comment devenir agile au quotidien
Il ne s’agit pas simplement d’appliquer bêtement une recette, on l’a vu, parce qu’il n’y a pas de recette de base, il y a certaines méthodologies.
Scrum en est une, mais il y en a plein d’autres qui ont des cadres biens définis, des choses à mettre en oeuvre, à faire, qui permettent d’être agile.
Mais si l’on veut devenir agile, peut-être qu’on peut se poser quelques questions.
J’ai identifié quatre grandes thématiques que je vais partager avec toi sur l’agilité au quotidien.
Je parle d’un quotidien professionnel évidemment, mais tu vas transposer, je pense assez facilement, sur un quotidien pourquoi pas personnel.
Dans un premier temps je vais m’intéresser à la partie Management
Quand on doit gérer et aider une équipe à travailler, on va essayer d’arrêter le micro management. Le micro management c’est le fait de donner la moindre tâche et de la définir jusqu’au détail près de ce qu’il faut faire, à chacun des collaborateurs et c’est également un micro contrôle. On va arrêter ça.
On va donner une vision et une stratégie, un cadre et l’équipe va travailler parce que l’équipe sait travailler.
Ça veut dire quoi, ne serait-ce que ça ?
Ça induit beaucoup de choses. Ça veut dire qu’on va travailler sur notre capacité à déléguer : Est-ce que moi en tant que chef d’équipe, pilote, manager, coordinateur je suis capable de déléguer ?
C’est parfois quelque chose qu’il faut travailler personnellement.
On a tous un ego qui est là.
Est-ce qu’on est prêt à l’abandonner pour le bien commun ou le bien de l’entreprise ?
Ça n’est pas forcément sûr donc ça se travaille ces parties de délégation.
On va ensuite avoir la partie autour de du management en lui-même :
Est-ce qu’on est dans un management directif ou dans un management plus participatif ?
Est-ce qu’on laisse le choix à l’équipe et aux membres de l’équipe de se positionner sur des décisions ou est-ce qu’on prend tout pour elle, pensant, bien souvent à tort, savoir ce qui est mieux pour l’équipe que l’équipe elle-même ? (ou en tout cas on pourrait l’appréhender comme ça).
On va donc essayer de travailler sur la co-construction, sur le fait de laisser le choix, sur mettre plus de participatif et de collaboratif au sein de sa propre équipe.
Et puis un dernier point sur lequel, je pense, il faut insister sur l’agilité, autour d’un rôle de manager, ou de pilote, c’est le droit à l’erreur :
Est ce que votre équipe se sent assez en confiance pour oser se tromper ?
Est-ce qu’ils osent se tromper ?
C’est vraiment un des sujets qui pour moi est très important sur l’agilité au quotidien.
Deuxième pan que j’aimerais appréhender avec toi c’est le Client
Le client c’est pour lui qu’on travaille finalement et là aussi les méthodes agiles nous invitent à prendre une posture un peu différente.
Là où peut-être avant, on était dans une négociation, dans quelque-chose de contractuel et donc parfois une opposition avec notre client, on va essayer de l’impliquer, d’en faire une partie prenante au sein du projet ou du produit sur lequel on travaille.
Ça sous-entend beaucoup d’échanges, cela sous-entend que, comme Steve Jobs aime à le dire, le client ne sait pas ce qu’il veut, ne sait pas ce dont il a besoin et donc on va travailler avec lui sur l’expression de son besoin pour identifier ce qui a de la valeur pour lui et donc lui proposer des éléments qui lui amène de la valeur, lui amener des fonctionnalités qui répondent à son besoin de valeur.
Et puis parce qu’on veut l’impliquer, pourquoi pas, on lui fera valider ce qu’on est en train de faire.
Bien souvent, trop souvent, on entend dans les équipes projets :
Mais est-ce qu’on veut faire comme ci ?
Est-ce qu’on veut faire comme ça ?
Est-ce qu’on a besoin de ci ?
Est-ce qu on a besoin de ça ?
En fait on oublie de poser la question tout simplement.
On n’est pas le client, nous on est un représentant d’un utilisateur ou d’un groupe d’utilisateurs mais allons voir le client.
Qu’est-ce qui nous en empêche finalement si ce n’est notre propre limite ou notre propre confort parfois qui nous restreint ne pas bouger ?
Allons voir ce client allons voir cet utilisateur et posons lui la question :
Est-ce que tu as besoin de ceci ?
Est-ce que tu as besoin de ça ?
Qu’est-ce qui t’apporte de la valeur ?
Voilà et c’est dans les échanges qu’on va trouver et parfois même orienter différemment ce qu’on avait prévu de faire
Troisième chose qui me semble importante d’appréhender avec toi et de parcourir avec toi c’est tout ce qui tient l’Equipe non pas au sens management on l’a déjà vu mais plutôt au sens je fais partie d’une équipe
Quand je fais partie d’une équipe et que je veux être dans une dynamique agile et bien il y a beaucoup de choses à mettre en oeuvre.
D’abord de la collaboration.
La collaboration, c’est travailler tous ensemble sur un but commun, pour atteindre un but commun.
Mais c’est pas chacun dans son coin, c’est tous ensemble, en tant qu’entité unique qui s’appelle l’équipe.
Ça veut dire que dans une équipe informatique il n’y a pas les développeurs et les testeurs, dans une équipe du bâtiment il n’y a pas les maçons et les carreleurs.
On est tous ensemble pour produire quelque chose.
Donc on va définir ensemble ce qui est le plus petit morceaux qu’on peut fournir à notre client, qu’on aura produit ensemble et on va le produire ensemble.
On va le fournir à notre client et ça fonctionne
Donc beaucoup de collaboration.
Pour beaucoup de collaboration, pour que cette collaboration soit efficace, il faut évidemment beaucoup de communication, parce qu’il faut être transparent, parce qu’il faut se dire les choses, parce qu’il faut lever les ambiguïtés, parce qu’il faut oser se dire les choses.
Ce qui n’est pas toujours facile évidemment quand on est membre d’une équipe.
Parfois, on n’ose pas, parfois il y a des non-dits, parfois il y a des habitudes qui font qu’on ne se dit pas certaines choses ou qu’on ne sait pas les dire.
Deuxième point pour les équipes qui me semble très important, c’est la notion de responsabilité.
On en parle souvent, il faut responsabiliser les équipes. Il faut que les équipes se sentent responsables. Il faut que les équipes soient capables de prendre des engagements.
Pour arriver à prendre des engagements, ça veut dire que l’équipe doit se sentir à l’aise, se sentir soutenue.
Elle doit se sentir comme ayant le droit de faire des erreurs, le droit de se tromper parce qu’elle a fait une estimation est que ça ne correspond pas à ce qu’elle avait estimé parce qu’elle avait pensé qu’elle y arriverait et elle n’y a pas réussi.
Il faut tenter de prendre des engagements et il faut tirer des leçons des engagements qu’on n’aurait pas réussi à tenir ou des erreurs qu’on aurait faites.
Le troisième point autour de l’équipe c’est l’amélioration continue.
Il s’agit pas simplement de savoir travailler ensemble, il s’agit pas simplement de prendre des engagements, il s’agit aussi à un moment d’être en capacité de faire des bilans sur ce qu’on a fait qui était bien et sur ce qu’on a fait qui n’était pas bien.
Pourquoi n’at-on pas réussi à produire ça pour nos clients ?
Pourquoi n’at-on pas réussir à développer, à tester, à mettre en place quelque chose ?
Qu’est-ce qui nous en empêche ?
Est-ce que c’est de l’organisation ?
Est-ce que c’est un outil ?
Est-ce que cette compétence ?
Est-ce que c’est un manque de communication ?
Parfois, pointer du doigt tout ça fait partie de l’amélioration continue.
Conclusion
Si je devais finir un petit peu cette partie agilité au quotidien j’aimerais partager avec toi les grands mots clés :
Itération
On va travailler par étapes, de vraies étapes régulières avec un rythme. On va faire des étapes courtes pour ne pas avoir produit de choses qui, si on devait les jeter, nous coûteraient trop cher mais pour pouvoir régulièrement montrer quelque chose à un client.
Incrémental
Ça veut dire qu’à chaque fois on va tenter d’améliorer notre produit ça sous-entend évidemment que dans la partie conception bien en amont on a pensé ça comme pouvant être fait de façon incrémentale.
Adaptation
Troisième mot clé, parce qu’on va tenter à chaque fois de s’adapter et donc, plus souvent on montre à notre client, plus souvent on fait evoluer notre produit, plus souvent notre client nous fait un retour et donc on est en capacité de s’adapter. Et lui aussi est en capacité de s’adapter par rapport à ce qui techniquement est faisable, n’est pas faisable, lui convient, ne convient pas.
J’espère que tu y vois un petit peu plus clair. C’est ma vision d’une agilité au quotidien, évidemment, tu es en capacité de te faire la tienne et beaucoup de bibliographie également sur internet disponible.
Je te propose un petit exercice par rapport à tout ce qu’on vient de se dire que tu vas pouvoir retrouver dans la page suivante.
Faisons une Conclusion
Alors, ça y est !
On est à la conclusion de cette session expérimentale.
J’espère désormais que pour toi c’est plus clair, ce que veut dire l’agilité, les méthodes agiles, ce concept philosophique, les valeurs, les principes, etc.
Voilà, j’espère que c’est vraiment plus clair.
Ce que je te propose pour terminer en beauté, c’est donc de prendre rendez-vous avec moi.
Il ya le lien directement en bas, pour qu’on puisse débriefer, échanger comme je le disais en introduction, s’appuyer sur les réponses que tu m’as envoyées par le biais des formulaires pour aller plus loin dans l’agilité, dans ta compréhension et peut-être l’application que tu peux en faire au quotidien.
A très vite !
Prenons le temps d’en parler
Réserve un créneau de 30 minutes en cliquant sur ce lien