Avancé Intermédiaire

Transition Agile Bottom-up : toute évolution ne nécessite pas de révolution

RevolutionLes plaintes sur l’environnement de travail et les méthodologies utilisées font partie du quotidien d’une équipe de développement. On les entend, on les répète, on les oublie et on recommence. Pourtant, cette énergie, utilisée à bon escient et dans le bon contexte, pourrait permettre aux équipes de changer leurs environnement de travail, et notamment la méthodologie utilisée.

Voyons comment une équipe motivée peut passer à l’Agilité, sans pour autant rejouer la Prise de la Bastille.

Une transition Agile, c’est quoi ?

Avant d’entrer dans le vif du sujet et la mise en place d’une transition Agile, il est nécessaire de préciser ce qui se cache derrière ce terme et de quel type de transition nous allons discuter ici.

 

Différencier une transition d’équipe d’une transition globale

Quand on parle de transition Agile, on parle d’un changement de méthodologie au sein d’une équipe, d’un service ou d’une organisation de taille plus ou moins importante. La “méthodologie Agile” n’existant pas, on parle évidemment de s’orienter vers une ou plusieurs des méthodologies regroupées sous la coupe de l’Agilité, comme le Lean, le Scrum ou encore le Kanban.

Malgré la possibilité pour une entreprise de changer tout son fonctionnement pour se conformer à une méthodologie ou une combinaison de plusieurs méthodologies, nous n’aborderons ici que la transition d’une équipe travaillant sous une méthodologie quelconque – telle que le Cycle en V ou le Waterfall – vers une méthodologie agile – Scrum, par exemple.

Dans la majorité des cas, les leviers nécessaires pour faire basculer une organisation de large taille vers l’Agilité sont inaccessibles à l’équipe de développement et se trouvent plusieurs niveaux hiérarchiques au-dessus. Par contre, la transition au sein de l’équipe peut, généralement, être effectuée une fois l’accord du manager local acquis. On va donc convaincre en partant du bas de l’échelle, en bottom-up.

 

Comprendre le bottom-up

Le bottom-up, par opposition au top-down, consiste à initier le changement en bas de la hiérarchie et de remonter progressivement les échelons. On n’utilisera donc pas ici l’imposition, mais la proposition et la démonstration, dans le but de convaincre. En effet, l’équipe de développement ne possède que peu de pouvoir de décision sur son organisation.

La transition bottom-up doit donc être progressive et faire ses preuves, pour que l’accord du manager persiste et qu’il soit convaincu des bienfaits qu’elle apporte. Pour ce faire, votre premier atout pourrait être le contexte actuel dans lequel votre équipe évolue.

 

Contexte de mise en place

On ne le répétera jamais assez, une équipe qui fonctionne bien et qui est satisfaite n’a pas besoin de changer de méthodologie, qu’elle travaille en Agile ou pas. Bien sûr, une équipe peut vouloir changer de méthodologie pour essayer, mais convaincre deviendra un challenge encore plus imposant, compte tenu de l’état actuel déjà satisfaisant. Une transition part donc généralement d’une situation insatisfaisante, notamment sur le plan de la méthodologie.

Après des mois, voire des années, de travail en cycle en V – ou n’importe quelle autre méthodologie non-Agile -, votre équipe est lassée de n’avoir aucune visibilité sur ce qu’il s’y passe, de ne plus voir la moindre amélioration de son environnement de travail, de devoir faire face à la perpétuelle insatisfaction du client… et cela commence à se ressentir sur son efficacité.

TagsCloudAgiliteEn tant qu’initié à l’Agilité, vous aimeriez changer cela en proposant de migrer vers une méthode de travail différente, et vous vous sentez de taille à guider vos collègues vers un jour meilleur. C’est là que commencent les choses sérieuses.

Mettre en marche la transition

Il ne faut pas se leurrer, la transition Agile bottom-up n’est pas réalisable dans tous les environnements et tous les contextes. Bien qu’ils ne soient pas tous indispensables, certains éléments vont favoriser cette entreprise et vous permettre de faire avancer les choses.

 

Environnement nécessaire

Comme le met en avant le chiffre du Dunbar, que mentionne Thomas dans son retour sur la conférence La Horde Agile, la cohésion d’un groupe peut-être mise à mal lorsque la taille de celui-ci dépasse la douzaine d’individus. Or, pour pouvoir démontrer l’efficacité de votre nouvelle méthodologie, vous aurez besoin d’une équipe soudée autour d’un objectif commun. Le changement s’opérera donc de façon plus fluide dans une équipe de taille réduite que dans une équipe dépassant la douzaine de personnes.

Seulement, le nombre d’individus n’est pas forcément un facteur-clé de votre réussite. L’un des éléments indispensables au succès de votre démarche sera d’avoir une équipe motivée à l’idée d’effectuer une transition agile. En effet, que ce soit lors de sa mise en place ou lors de son application, l’Agilité ne doit jamais reposer sur autre chose que sur la volonté de l’équipe. La phase d’explication et de motivation de celle-ci sera donc la première étape de la transition. La présence d’une personne expérimentée et capable de répondre aux questions et d’éclaircir les points de doute auprès des membres de l’équipe sera donc un atout conséquent.

Selon le contexte, vous aurez à convaincre votre manager local avant ou après avoir convaincu l’équipe. En effet, certains managers ne vous donneront leur accord que si la volonté de l’équipe est uniforme, tandis que certains verrons le fait de convaincre l’équipe avant de leur en parler comme une prise officieuse de pouvoir. Vous aurez donc à présenter les choses de la bonne façon, pour rester dans la proposition et ne pas dériver vers un statut d’opposition. La nécessité d’un sponsor fort est d’autant plus importante que, dans le cas d’une transition bottom-up, une opposition du manager suffira à la tuer dans l’œuf.

 

Quelle approche adopter ?

S’il n’y a qu’une seule chose à retenir de la démarche à adopter, c’est qu’elle doit être basée sur la négociation et non sur l’imposition. En effet, vous ne serez pas en position de force et devrez faire vos preuves pour proposer un changement de méthodologie. Ainsi, il vous faudra faire preuve d’humilité et ne pas focaliser votre argumentaire sur les défauts du système actuel, mais bien sur les avantages de la nouvelle méthodologie. Rappelez-vous ce principe élémentaire de rétrospective : pour chaque post-it négatif, un post-it de proposition.

En bon agiliste, je ne vous surprendrai pas en disant que le changement doit être progressif et que les actions à entreprendre doivent être priorisées par retour sur investissement. En effet, ici, votre client sera votre sponsor. Vous aurez donc à lui “livrer” quelque chose de satisfaisant dans les délais les plus courts possibles, avec un coût moindre.

 

Great! Where are we going?

pippin Comme à chaque fois que vous voudrez fournir quelque chose de satisfaisant, vous aurez à vous mettre à la place du client. Pensez donc à ce que vous pouvez proposer qui apportera de la satisfaction à votre sponsor et qui permettra à votre équipe de faire un pas en avant dans la transition.

Dans un premier temps, n’hésitez pas à entreprendre des actions dont les résultats sont visibles de tous : mise en place d’un tableau agile, formalisation et affichage des bonnes pratiques, … Le coût initial sera très faible, tandis que vous, votre équipe et votre sponsor gagnerez grandement en visibilité sur l’état du projet. Comme lors de l’établissement du plan d’actions qui découle d’une rétrospective, gardez bien à l’esprit que les changements que vous entreprenez doivent être réalisables et accessibles à l’équipe. Si votre équipe est novice en Agilité, certains changements s’avèreront trop compliqués à intégrer et risqueront de la décourager. La facilité de réalisation sera donc un paramètre important à prendre en compte dans votre démarche.

 

Not quite my tempo !

Proposer des changements, c’est bien. Mais à quel rythme? Comme tout système, votre équipe aura besoin d’un certain temps pour intégrer chaque modification que vous apporterez à son fonctionnement. Ainsi, il n’y a pas de réponse absolue à la question du rythme à tenir lors de votre transition, puisqu’il dépendra essentiellement de l’expérience de votre équipe et du contexte dans lequel vous évoluez.

whiplashUne chose est sûre, il vous faudra vous armer de patience car, entre l’apprentissage de l’équipe et l’acceptation de votre sponsor, vous n’avancerez probablement pas à la vitesse que vous voudrez. En effet, il vous faudra composer entre la vitesse d’apprentissage de votre équipe, la quantité et la complexité des changements proposés, et la confiance que vous accorde votre sponsor pour mettre en place ces changements.

 

Les freins potentiels

Que serait le challenge sans obstacle ? Rassurez-vous, vous rencontrerez votre lot de freins au cours de votre transition agile. Etant donné qu’ils sont très liés au contexte dans lequel évolue votre équipe, il est quasiment impossible de donner une liste exhaustive de ces derniers. Voici tout de même quelques-uns des plus courants.

 

Le matériel

On y pense assez rarement, mais plusieurs éléments des différentes méthodologies réunies sous la coupe de l’Agilité demandent du matériel plus ou moins difficile à obtenir. Un tableau, des post-its, des marqueurs, du scotch, des feuilles, des cartes et j’en passe. Si certains sont généralement triviaux à obtenir, d’autres peuvent demander un certain temps, ce qui ralentira votre mise en place de la nouvelle méthodologie. Commander un tableau, par exemple.

Je ne peux que vous conseiller d’être débrouillards. Vous n’avez pas de tableau ? Utilisez un mur. Vous n’avez pas de mur ? Utilisez une fenêtre. Vous n’avez pas de fenêtre ? Dans ce cas, vous êtes probablement en weekend en train de tondre la pelouse, et vous n’avez pas besoin d’une nouvelle méthodologie pour cela.

 

Le manque de temps

Vous l’aurez probablement compris au fur et à mesure de cet article, entreprendre une transition agile demande beaucoup d’investissement et d’organisation de la part des personnes qui en seront moteurs. Ainsi, allier sa tâche principale – le développement, par exemple – et la mise en place d’une nouvelle méthodologie peut s’avérer extrêmement chronophage.

Il vous faudra donc faire preuve de beaucoup d’organisation et d’une bonne préparation avant même d’avoir entrepris le moindre changement. Essayez de conserver une étape d’avance sur votre transition, pour ne pas être pris de court par les imprévus.

 

L’organisation globale image001-200x300

Comme expliqué au tout début de cet article, nous parlons ici d’une transition agile au sein de l’équipe. Si cette configuration limite votre champ d’action, elle implique toutefois que vous serez tôt ou tard confrontés à l’organisation en dehors de votre équipe.

Le soutien de votre sponsor sera ici un atout primordial, que vous pourrez renforcer vous-mêmes en permettant aux différentes parties prenantes du projet de bénéficier de la visibilité qu’offre l’Agilité au sein de votre équipe. Si le contexte s’y prête et que vous présentez les choses de la bonne manière, vous pourriez même engendrer un intérêt pour la méthodologie dans d’autres équipes et les voir amorcer une transition de leur côté.

 

C’est à vous de jouer !

Vous l’aurez probablement remarqué tout au long de cet article, effectuer une transition agile bottom-up dépend énormément du contexte de votre équipe. Toutefois, j’espère vous avoir donné suffisamment de matière pour que vous puissiez l’envisager de façon plus claire.

Il ne me reste qu’à vous souhaiter bonne chance et bonne route sur la voie de l’Agilité !

Nombre de vue : 126

COMMENTAIRES 1 commentaire

AJOUTER UN COMMENTAIRE