Mise en place de l’agilité : et le business dans tout ça ?

L’idée d’origine était de travailler plus efficacement. Mettre le client au coeur des échanges et avoir un maximum de feedbacks pour adapter constamment ce qui est produit à ce dont on a vraiment besoin. La mise en place d’une approche agile dans la manière de travailler n’est plus vraiment une nouveauté, c’est même plutôt l’inverse. De nos jours mêmes les grands groupes, qui ne sont pas les plus faciles à faire bouger, s’y sont mis.

Cependant, en général, on commence par changer le travail d’une ou plusieurs équipe(s) côté IT (en utilisant Scrum par exemple) puis on regarde ce qui se passe. Et le résultat est souvent le même : les stakeholders sont perdus. On parle souvent de résistance au changement mais je ne suis pas sûr que ce soit le cas, le vrai soucis ne serait-il pas que l’on a oublié de considérer les contraintes business dans notre approche ? Restez avec moi, on va regarder ça de plus près 🕵️

Objectif et contraintes

Ok, je sais, améliorer les processus côté IT permet souvent d’avoir des impacts sur tout le reste (livrer plus souvent donc apprendre plus vite donc adapter la solution au besoin donc obtenir plus de valeur), mais avant de décider de faire des itérations, de choisir la durée de ces dernières et de lancer des invitations à tout un tas de cérémonies il serait tout de même intéressant de discuter de tout ça avec les personnes du business. Voici quelques questions à se poser :

• Quelle réactivité est aujourd’hui nécessaire par rapport au marché et à notre concurrence ?
• Quelle périodicité est-elle souhaitable / acceptable en terme de feedback ?
• Quelle est notre capacité d’apprentissage ?
• Sur quelle période peut-on accepter de prendre du risque lié à l’incertitude ?
• À quel niveau de la ligne prédictibilité / innovation a-t-on besoin de se placer ?

Le sujet central est toujours le même : faut-il mettre en place des itérations et si oui de quelle durée ? Il n’existe pas de réponse unique à cette question. Les principes du développement agile de logiciel et l’expérience montrent qu’il est généralement préférable de faire des itérations courtes et que, si vous avez l’impression que vous ne vous en sortez pas et n’arrivez pas à livrer de valeur c’est peut-être qu’il faut réduire encore un peu la durée 😧 Pourquoi me direz-vous ? Et bien parce que le problème vient certainement du scope. On voit trop gros, trop grand alors qu’il faudrait essayer de découper plus, chercher le plus petit incrément possible qui permette d’apporter de la valeur et d’apprendre, de s’assurer que l’on prend la bonne direction…Quelle que soit la décision elle doit embarquer tout le monde.

Et si on arrêtait les silos 🤔

Promis, à partir de maintenant on travaille tou(te)s ensembles !

Oui sauf que pas vraiment en fait…Je vous propose 2 situations :

1. Le business identifie des problèmes ou opportunités, les analyse et sort une roadmap qu’il envoi au produit. Le PO prend la main pour traduire la roadmap en Product Backlog Items (généralement des User Stories ou un truc qui y ressemble) qu’il présente à l’équipe de développement. On fait du refinement pour s’assurer que tout est compris, estimer (en points de complexité de préférence) et découper en tâches techniques et on met le tout dans la prochaine itération. Là pour le coup on est toujours sur du cycle en V, sur des cycles courts et avec plus d’échanges peut-être mais c’est pas encore ça…
2. Le business identifie des problèmes ou opportunités et les partage avec le produit. Business et PO travaillent ensembles pour définir des indicateurs (où en est-on aujourd’hui, où souhaite-t-on aller et comment sait-on qu’on a réussi) et prioriser les sujets. Le PO se rapproche de l’équipe de développement pour lui présenter les sujets et travaille avec elle pour définir des solutions possibles, autrement dit ils construisent les PBI ensembles (le PO apporte du savoir sur les contraintes fonctionnelles et l’équipe de développement les contraintes techniques). Les différentes solutions sont macro estimées, découpées en tâches techniques et intégrés dans une itération selon les priorités. On a fait un gros pas en avant, on fait de la co-construction et on utilise au mieux les compétences et l’expertise de chacun.

Laquelle apporte le plus de valeur ? La première méthode découle souvent d’un manque de remise en question des processus en place et/ou d’un manque de confiance (business 👉 produit 👉 IT). Cependant il est important de guarder en tête que personne ne fait les choses dans le but de vous embêter. Chacun à ses contraintes et réagit en fonction de celles-ci et le meilleur moyen de mieux se comprendre et travailler ensembles est de les partager ouvertement.

Vous voulez que je vous dise un secret ? Dans la deuxième approche on a pas encore supprimé les silos (vous l’aviez remarqué pas vrai ?). Oui, il existe évidemment une troisième approche, on met tout le monde ensemble pour construire la backlog, business, produit et IT !

On obtient des réponses aux questions de suite car tous les sachants sont là, on peut mettre en place un plan d’action sans délais, prendre des décisions et aligner tout le monde directement. Pas facile me direz-vous ? Comment s’assurer que les échanges soient constructifs ? Ne risque-t-on pas d’avoir des discussions interminables ? C’est vrai, pas toujours facile mais encore une fois la clé est de se concentrer sur de petits objectifs à court terme en cherchant sur ce qui apporte le plus de valeur. Et si vous avez un peu de mal à lancer la dynamique faites vous accompagner d’un coach agile, ils sont aussi là pour ça 😉

Le mot de la fin

Historiquement les approches agiles ont majoritairement été pensées, proposées et mise en place par des personnes venant de l’IT ce qui explique que le métier est souvent un peu oublié. Cependant, pour être vraiment efficace et améliorer la façon de travailler l’inclusion de toute l’organisation est primordiale. Supprimer les silos n’est pas choses facile et prendra du temps alors soyez patient, assurez-vous à chaque nouvelle étape de n’avoir perdu personne en route et n’oubliez pas :

Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.

Norm Kerth

Vous avez aimé cet article ? Montrez-le

Mettez un commentaire, likez sur LinkedIn 👍 et partagez ! Votre aide et feedback sont important, c’est ça qui me permet d’apprendre et de continuer la réflexion, merci beaucoup 😀