Il n’est pas rare dans le monde du développement logiciel que les fameuses transformations agiles malgré une connaissance pointue des méthodes agiles théoriques deviennent des échecs et cela pour de nombreuses raisons. Quoi qu’il en soit, je vais au travers de cet article vous faire un feedback sur les éléments qui peuvent éviter cet échec pour maximiser les chances de transformations et donc que représente pour moi la conduite du changement agile.

Agilité et changement

Comme évoqué dans l’article précédent, les méthodes agiles sont souvent le point de départ des transformations agiles, c’est déjà une première source de difficultés. Effectivement dans transformation agile, il y a agile et donc méthodes agiles bien sûr mais le premier terme reste bien transformation. Il est donc plus efficace de démarrer celle-ci par la capacité et la volonté de changer. Cela passe par des étapes de constats partagés et la communication sur le changement souhaité en indiquant principalement le contexte autour de ces choix, ce qui vous a amené à entrer dans une phase de transformation.

Il faut donc faire preuve d’une grande transparence, démarrer un changement dans l’obscurité ou le mensonge n’a guère de chances d’amener à un résultat positif. Un exercice intéressant est de répondre à quelques questions simples :

1. D’où part-on (contexte et constats) ?
2. Quels sont les éléments qui nous ont convaincus qu’une transformation est nécessaire (déclencheur) ?
3. Quel est l’objectif attendu (donner la vision même si celle-ci est incertaine) ?

Ces trois questions ont des objectifs différents. La première question a pour objectif de partager sur l’état actuel de la situation. Cela a pour effet de limiter la résistance au changement qui est tout à fait naturelle. En expliquant le contexte et les constats qui ont permis de prendre une décision, les personnes se sentent plus concernées par le changement et moins soumises au changement. La deuxième question permet de révéler les déclencheurs (opportunités, mise en place d’indicateurs, concurrences, évolutions du marchés, nouveau projet…) qui sont à l’origine du démarrage de la transformation. Enfin, la troisième question permet aux personnes de comprendre les objectifs et l’intérêt attendus d’un tel changement (financier souvent mais pas que ;), bonheur au travail, humain, efficacité, écologie…), ce point est forcément hypothétique c’est une vision d’entreprise qui sera ou non vérifiée à l’avenir. Si cette vision fait référence aux valeurs des personnes de l’équipe, elle permettra de les faire passer de personnes subissant le changement à personnes moteurs pour amener le changement. Ce qui aura un impact fort sur la réussite du changement agile. L’alignement vers un objectif commun des parties prenantes du changement est un prérequis au bon déroulement de la transformation et lorsque des situations compliquées apparaîtront il sera alors plus aisé de passer à la recherche de solutions plutôt que de coupables.

Une fois le cadre du changement posé et partagé, nous pouvons parlé du contenu et surtout de la mise en place de la transformation agile.

La conduite du changement

Comme évoqué au paragraphe précédent, il existe parfois des résistances au changement. Cette situation peut trouver des explications dans le fait de passer d’un état connu à un état inconnu ou dont les conséquences ne sont pas encore mesurables. Dans un état connu même si celui-ci ne nous convient pas nous avons tendances à se sentir en zone de confort, les mêmes actes ayant les mêmes conséquences. Dans un état inconnu qui pourrait être meilleur pour nous, nous ne connaissons pas encore les conséquences des mêmes actes ou d’actes nouveaux, il faut donc sortir de sa zone de confort pour l’explorer.

Pour éviter de déstabiliser une équipe, un projet et un quotidien en place, il existe des solutions pour amener le changement au sein du quotidien. Nous pouvons par des petits ajustements amener des notions et des pratiques plutôt qu’un chamboulement complet du jour au lendemain. Cette conduite du changement permet aux différents acteurs de pouvoir progressivement monter en compétences sur les nouvelles méthodes de travail sans subir un changement trop brusque qui risquerait d’être perçu comme une douleur.

Pour se faire les principes d’amélioration continue sont une aubaine. L’accompagnement par une personne connaissant les pratiques agiles et leurs apports peut être intéressant afin de pouvoir répondre aux différents axes d’améliorations exprimés. En se basant sur les axes d’améliorations prioritaires, l’équipe décide de mettre en place une nouvelle pratique agile, elle en mesure alors les bénéfices ou non et décide ensuite de l’entériner ou non en fonction des retours.

Cette conduite du changement agile permet une meilleure acceptation du changement et se place clairement dans un principe évolutif à long terme. Le prérequis est de trouver l’inspiration des pratiques agiles adaptées au contexte de l’équipe.

Les méthodes agiles et la culture agile

La mise en place d’une transformation, nécessite une inspiration. Comme nous avons pu le voir précédemment cette inspiration se trouve souvent dans les méthodes agiles prêtes à l’emploi et à appliquer « by the book » or cette application peut avoir plusieurs conséquences néfastes sur la transformation. Par exemple une équipe ne pratiquant pas du tout l’agilité au quotidien et qui devrait utiliser l’entièreté de la méthode Scrum du jour au lendemain pourrait se retrouver dans les écueils suivants :

• Perte de repères sur les responsabilités et de la place de chacun
• Sentiment d’insécurité
• Sentiment d’inefficacité
• Perte de motivation
• Échec de la transformation agile
• …

La conséquence serait un retour arrière rapide aux anciennes méthodes ou pire la méthode Scrum serait imposée et ferait naître un sentiment de rejet et des conclusions hâtives sur l’agilité.

C’est là que la conduite du changement agile et la culture agile ont toutes leur importance. A l’application d’une méthode, il est préférable de mettre en place des pratiques agiles correspondantes aux situations et contextes rencontrés.

Par exemple si vous avez régulièrement des incompréhensions avec le métier sur les fonctionnalités à développer, il peut être intéressant de mettre en place un atelier de co conception de la solution pour répondre aux besoins des utilisateurs finaux en présence des développeurs concernés et sans intermédiaire entre le métier et les développeurs.

Si le métier souhaite régulièrement apporter des changements ou vous indique lorsqu’une fonctionnalité est développée qu’elle n’est plus utile et qu’il ne sert à rien de la mettre en production, il est tout à fait possible de mettre en place un point hebdomadaire pour échanger sur les fonctionnalités et leurs priorités et ainsi retirer les fonctionnalités sans valeur.

Enfin si le métier vous indique régulièrement que la fonctionnalité mise en production ne correspond pas du tout aux besoins, une démonstration avant la mise en production est envisageable.

Sur ces 3 exemples, vous avez un premier pas vers une collaboration plus efficace tout en ne bouleversant pas un équilibre déjà fragile. Dans ces 3 cas, l’agilité arrive sans être nommée mais on retrouve des pratiques agiles (avec des inspirations de SprintReview, d’affinage de backlog…).

Toute nouvelle pratique nécessite appropriation, et donc du temps et de l’entraînement. Nous comprenons alors que le changement du tout au tout est un effort souvent trop lourd et mène à l’abandon. L’amélioration continue et la communication autour des problèmes rencontrés au quotidien afin de trouver les pratiques adaptées est donc une voie beaucoup plus efficace pour un changement agile.

Cet article relate des premiers pas dans l’agilité, une fois le mouvement enclenché il ne tient qu’à vous de le perpétuer tout au long de la vie de votre équipe.

Le changement agile est infini.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image by Antonio López from Pixabay

Une même pratique sous des formes différentes

La pratique sous-jacente à toutes les activités énumérées ci-dessus est la même. Dans tous les cas les personnes souhaitent avoir un partage d’expériences avec l’intervenant. La différence se fait donc au niveau de la forme de l’intervention plus que son contenu. Si nous reprenons l’exemple des termes citées plus haut un coach agile sera en retrait de l’opérationnel et interviendra plus via des conseils auprès des personnes clés de l’organisation. Là où un scrum master ou un facilitateur, interviendra réellement dans l’opérationnel et durant les réunions et autres points d’organisation, il prendra aussi en charge des activités chronophage et qui ne nécessite pas une interruption des équipes opérationnelles. Pour ces deux premiers cas, l’activité est centrée sur une organisation, une entreprise, un contexte donné. Pour le conférencier ou encore le formateur, c’est un peu différent car il intervient auprès de plusieurs organisations et donc plusieurs contextes en même temps. Le partage de l’expérience sera donc plus généralistes comme les cas d’exemple vécu.

Les quiproquos et la souplesse

La méprise entre les termes est légion, l’offre fait état d’un besoin de scrum master mais en fait le client a plus besoin d’un coach agile car il ne souhaite pas créer de dépendances envers l’intervenant. Encore une fois le nom du poste pour un besoin dépend de l’entreprise et il ne faut pas s’y arrêter et savoir rester souple, l’important étant ce qu’on fait et non l’intitulé de la fiche de poste. Je fais depuis quelques temps de plus en plus de café visio (discussion informelle autour d’un café en visio-conférence si ça vous intéresse n’hésitez pas ), lors de ces échanges très intéressants j’ai pu rencontrer différentes personnes du domaine et la tendance à ne plus tenir compte des termes grandies. L’important n’est pas le nom d’un poste mais ce qu’on y fait et comment on le fait. Le reste n’est qu’un mot sur un cv ou une fiche de poste ou encore un profil Linkedin, une notion abstraite qui essaie tant bien que mal de représenter une complexité importante.

Difficile de croire qu’un terme permet de représenter les activités quotidiennes d’une personne, un terme pour 35h par semaine pour 220 jours par an, l’exercice est très difficile notamment dans les métiers où l’adaptation au contexte est permanente et où chaque élément est susceptible de changer à intervalle régulier.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par AJS1 de Pixabay

Dans une organisation qui s’oriente vers l’agilité, la culture reste, les méthodes et process changent.

La culture est composée des valeurs et de la vision que porte une entreprise. C’est un état d’esprit, des convictions humaines, quelque chose de peu palpable et qui ne se transmets que par la proximité et l’exemple concret sur le terrain. Impossible de transmettre une culture de qualité dans le développement logiciel si on interdit aux développeurs de mettre en place des pratiques qui vont avec (par exemple les tests automatiques ou encore le Test Driven Development).

Les méthodes et process sont là pour apporter une organisation pour atteindre un objectif, une vision en fonction d’un contexte donné hors ce dernier ne cesse d’évoluer (textes de lois, concurrence, évènements extérieurs…), il n’est pas sous notre contrôle et par conséquent il est source d’inquiétudes.

S’adapter au contexte, au changement est primordial parce qu’il n’existe pas de solution miracle répondant à tous les contextes, si c’était le cas elle aurait un succès phénoménal, parce que les cadres de travail font intervenir l’humain et chaque personne perçoit les choses différemment. Parce que les méthodes et process qui ont fait les succès d’hier feront peut être l’échec d’aujourd’hui. Ce monde en perpétuel mouvement implique donc d’être en capacité de changer lorsque cela est nécessaire.

Pour changer il faut passer par l’étape de la remise en question de l’existant, on ne peut faire changer une organisation qui lutte de toutes ses forces pour rester dans un état identique. Il faut donc travailler à partir de ce point à constater ce qui fonctionne bien et ce qui fonctionne moins bien aujourd’hui. A partir de ces précieux retours, il faut en saisir l’essence, la cause racine, le point d’action qui aura avec un minimum d’effort le plus de résultats.

Lorsque cette activité de remise en question de l’existant est réalisée suffisamment souvent une amélioration par petite adaptation est envisageable, dans le cas contraire des gros changements peuvent être nécessaires mais les impacts et effets de bords seront plus forts voire dangereux.

« Il n’y a qu’une seule chose dans la vie qui ne change jamais, c’est le changement ». Cette citation de Confucius représente bien l’acceptation du changement nécessaire à l’évolution et l’amélioration continue. Cette notion est plus qu’importante dans la culture agile, elle est même pour moi un des piliers. C’est ce changement de contexte perpétuel qui nous pousse à aller toujours plus loin, à améliorer les choses et à définir les bonnes pratiques à adopter dans ce contexte. Que ce soit d’un point de vue technique ou organisationnel, la base de toutes améliorations reste l’acceptation que le contexte à changer par bien des aspects possibles.

Lors de coaching agiles ou lorsque l’on arrive comme faciliatateur / scrum master au sein d’une équipe, une fois la prise de contexte réalisée, vient le temps de la proposition d’outils et de méthodes permettant de traiter les points de douleurs, d’adapter l’organisation et les process en place pour plus d’efficacité.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par Gerd Altmann de Pixabay

L’agilité était tellement peu formalisée sur les premières années qu’il a fallu décrire la façon de la mettre en place à travers des méthodes agiles dont les plus célèbres : Scrum, Extreme programming, SAFe pour ne citer que celles-ci. Et là c’est produit un phénomène tout à fait classique, les méthodes qui sont des guides très complets on pris le dessus sur les concepts d’agilité eux mêmes. On connaît tous le « Nous on fait du Scrum », ou « On bosse avec la méthode agile (aka Scrum) », … Pourquoi ? Parce que les méthodes ci-dessus laissent moins de liberté d’interprétation et donc réduit le champs des possibles, elles sont donc bien plus aisées à appliquer et à faire appliquer. Cela donne un cadre, des directives à suivre. Ce qui est un bon point de départ mais peut très vite s’avérer être inadapté à votre contexte.

Lors de nombreuses présentations des concepts d’agilité que je peux donner ou auxquelles je peux assister. Une question revient régulièrement : « Au quotidien que mettez vous en place ? ». Cette vision pratique d’éléments théoriques est tout à fait logique dans un processus de changement et donc tout naturellement si quelqu’un a écrit une méthode à appliquer point par point on se tourne dans un premier temps au moins vers celle-ci. Ce que font très bien les dites méthodes agiles, et cette application d’un guide méthodologique agile peut convenir à certaines équipes. Suivre ces méthodes lorsque l’on ne sait pas par où commencer est un exercice tout à fait intéressant, il permet de voir les avantages et inconvénients de certaines pratiques agiles. Mais parfois l’application étant trop contraignante, nous préférons alors arrêter tous le processus de changement plutôt que d’adapter la méthode à son contexte par peur de diverger de la méthode originelle.

Et lorsque ces présentations exprime le quotidien d’équipes agiles certaines réponses sont de l’ordre : « Ah oui mais ça nous on ne peut pas le faire ! ». Toutes les pratiques données sont prises comme les éléments nécessaires d’une méthode à appliquer à la lettre et dans leur totalité le changement paraît impossible. Appliquer les principes agiles de manière identique ou pas n’est pas la question, la question est plutôt comment pouvons-nous nous inspirer de ce qui se fait ailleurs afin de créer notre propre méthode adaptée à notre contexte et qui évoluera au fur et à mesure ? L’idée préconçue qu’on est ou qu’on est pas agile de manière binaire n’est pas réaliste. Aucune équipe passe, après une semaine de formations, d’un mode basé sur le contrôle total à une agilité bienveillante. L’agilité est un chemin qu’il faut tracer en équipe en ayant bien assimilé le sens des principes pour pouvoir après les appliquer au fur et à mesure des situations rencontrées.

Et c’est bien là où réside toute la difficulté, adapter les pratiques agiles aux contextes. Car comme vous l’aurez compris il n’existe alors plus une méthode agile mais autant de méthodes agiles que d’équipes qui la pratiquent. Lors de coaching agiles ou lorsque l’on arrive comme faciliatateur / scrum master au sein d’une équipe, la première étape est donc de comprendre le contexte afin de pouvoir proposer des bonnes pratiques aux bons moments en fonction des difficultés et des situations de chaque équipe.

Des questions sur l’agilité, scrum et leurs mises en application dans votre contexte, n’hésitez pas à me contacter.

Image par Gerd Altmann de Pixabay