5 faits sur la transformation agile

Je n'ai jamais été fan des films d'horreur. Mais j'ai toujours adoré Halloween. Enfant, j'adorais enfiler des costumes effrayants pour faire peur à mes amis et aux autres. Et j'avoue que j'aime le frisson de visiter une maison hantée bien décorée à Halloween.

Cependant, chaque transformation agile comporte aussi des aspects qui peuvent te donner des frissons dans le dos – et ces moments-là ne sont pas vraiment exaltants.

Alors, ensemble, démystifions ces cinq choses et parlons de ce qu'elles sont exactement et pourquoi elles ne sont pas si effrayantes une fois qu'on les a vraiment comprises.

1) Ahhh ! En Agile, il n'y a pas de phase de conception !

Les architectes et les collaborateurs du département développement sont souvent inquiets, car il n'y a pas de phase de conception explicite en Agile. Même s'il est vrai que les équipes agiles évitent les phases de conception au début d'un projet, cela ne signifie pas que la conception est négligée.

La conception dans un projet agile se caractérise par deux aspects : elle est émergente et intentionnelle.

La conception émergente se développe avec le temps. Au lieu d'une phase de conception initiale, la conception est un processus continu. Elle émerge lors de la création du logiciel.

Mais la conception est aussi intentionnelle. Cela signifie qu'elle ne se produit pas par hasard. Elle est guidée par les responsables techniques d'un projet, voire par un architecte dédié.

Si ces personnes s'inquiètent d'une partie spécifique du système, le Product Owner devrait prioriser un ou deux [Product Backlog Items]( "Product Backlog Item") de ce domaine. Cela donne à l'équipe l'occasion de mieux connaître cette partie du système en en développant une petite portion. Cela aidera à trouver la bonne conception.

Quand la conception émerge ainsi des décisions de l'équipe, le fait qu'il n'y ait pas de phase de conception explicite en Agile n'est plus si effrayant.

2) À l'aide ! Je deviens généraliste !

L'un des mythes les plus répandus en Agile est que les équipes agiles ne veulent pas de spécialistes et préfèrent que chaque membre de l'équipe soit généraliste.

Cela fait peur à beaucoup de gens pour deux raisons : premièrement, tout le monde n'aime pas faire tous les types de travail. Deuxièmement, on craint souvent que savoir faire quatre choses à moitié bien plutôt qu'une seule chose extrêmement bien puisse avoir des conséquences sur l'employabilité future.

L'idée que chaque membre d'une équipe agile doit être généraliste est fausse. Si je coache une équipe qui compte le meilleur expert JavaScript au monde, je veux que cette superstar fasse des choses formidables avec JavaScript, pas qu'elle apprenne à devenir administrateur de base de données.

Oui, dans les équipes agiles, on souhaite avoir des membres aux compétences variées : par exemple, un testeur qui sait aussi un peu coder. La solution la plus simple est d'avoir quelqu'un qui maîtrise aussi bien les deux types de travail. Si votre équipe a par exemple un déséquilibre entre les tâches de programmation et de test, il est utile d'avoir quelqu'un capable de programmer et de tester.

Un objectif en Agile est de former des équipes pluridisciplinaires. Cela signifie qu'une équipe possède toutes les compétences nécessaires pour créer un incrément de produit fini et fonctionnel en une itération. Mais cela ne veut pas dire que chaque membre de l'équipe doit posséder toutes les compétences requises dans une équipe pluridisciplinaire.

Si l'idée de devenir généraliste vous hérisse, vous serez soulagé d'apprendre que les spécialistes sont également les bienvenus dans les équipes pluridisciplinaires.

3) Oh non ! Nous n'avons ni plans ni prévisions !

Les managers frémissent souvent à l'idée qu'une équipe agile ne puisse pas faire de plans ou de prévisions au-delà de l'itération ou du sprint en cours.

Heureusement, ce n'est pas tout à fait vrai.

Oui, les équipes agiles renoncent au faux confort des projets surplanifiés avec des diagrammes de Gantt illisibles et des calendriers précis projetés loin dans le futur. Cela ne signifie pas pour autant que les équipes agiles sont incapables de planifier et de prévoir l'avenir.

Un grand avantage des méthodes agiles est que l'équipe examine et ajuste l'ensemble du processus de développement à chaque itération. Elle prend une idée sous forme d'une simple User Story et implémente cette fonctionnalité. Cela signifie que les équipes peuvent mesurer leur progression toutes les quelques semaines. Elles découvrent ainsi quelle quantité de travail elles accomplissent.

Comparons cela avec un projet de développement traditionnel qui comporte peut-être une phase d'analyse, une phase de conception, une phase de codage et enfin une phase de test. Lorsque ces équipes veulent mesurer leur progression, elles ne peuvent constater que la vitesse à laquelle elles accomplissent une (ou peut-être deux) de ces tâches. La rapidité d'une équipe en conception ne dit rien sur sa rapidité en codage ou en test.

Le plus important dans la transformation agile est d'accueillir l'incertitude – d'admettre qu'il est impossible de connaître toutes les fonctionnalités avant le début du projet – puis de choisir l'une des nombreuses façons de s'y adapter. Quand les équipes ont compris cela et mesurent la quantité de travail à chaque itération, cela devrait rassurer le management et conduire à une planification fiable.

4) Au secours ! Je vais perdre mon emploi !

L'idée d'une transition agile d'une équipe ou d'une entreprise entière peut effrayer plus d'un manager, car beaucoup craignent que leur poste devienne superflu après la transition.

C'est compréhensible. Bien sûr, ce serait terrible de lancer une transition en sachant que cela rendra son propre rôle obsolète.

Cependant, je n'ai jamais aidé une entreprise dans sa transformation agile et entendu dire : « Bon, les personnes avec tel ou tel rôle, on n'en a plus besoin. Elles sont toutes virées. » Ça n'arrive pas. Certes, il peut arriver qu'un certain intitulé de poste ne soit plus nécessaire ou plus adapté, mais ces personnes ont toujours un emploi. Je pense même que dans la plupart des cas, elles se retrouvent ensuite avec de meilleurs postes, plus adaptés qu'avant. Il est vrai que certaines personnes peuvent avoir moins de contrôle direct sur les collaborateurs et les décisions, ce qui les frustre – parfois au point de quitter l'entreprise.

Comme je n'ai jamais vu de personnes occupant certains rôles ou possédant certaines compétences être simplement licenciées lors d'une transformation agile, je pense que cette peur est aussi déplacée que celle d'une apocalypse zombie.

5) Ouf ! Il y a trop de réunions dans Scrum !

Comme la plupart des gens, je déteste les réunions. Dans l'ensemble, ce qui compte pour moi, c'est pourquoi je fais ce que je fais. La plupart des jours, je n'ai aucune réunion. Quelle chance.

Pourtant, même moi je peux admettre que certaines réunions sont importantes et utiles. Cela inclut les quatre réunions standard de Scrum : le Sprint Planning, le Daily Scrum, la Review et la Rétrospective.

La simple pensée de toutes ces réunions fait transpirer certaines personnes.

Et le problème avec les réunions Scrum : elles ont un nom. Quand quelque chose a un nom, on peut mieux l'attaquer. D'après mon expérience, la plupart des équipes avaient plus de réunions avant Scrum. Mais ces réunions n'avaient pas de nom et étaient généralement organisées spontanément pour clarifier certaines choses.

Tu peux vérifier cela rapidement avec une expérience. Cherche dans ton calendrier n'importe quel mois où tu ne travaillais pas encore en Agile. Additionne le temps que tu as passé en réunions ce mois-là. Puis additionne le temps que tu passes maintenant dans les réunions Scrum et compare les deux chiffres.

Je pense que tu seras surpris par le résultat. Comme les réunions avant la transformation agile n'étaient pas régulières et récurrentes, elles n'avaient pas de nom et ne restaient pas en mémoire comme par exemple un « Sprint Planning ».

Le conseil le plus important pour ne plus avoir peur de passer trop de temps en réunions est de les garder courtes. De temps en temps, je travaille avec des équipes que je dois encourager à prendre un peu plus de temps pour leurs réunions.

Cependant, la plupart des équipes passent trop de temps dans les réunions Scrum. Dès qu'on réussit à les garder courtes et concises, elles ne devraient plus effrayer personne.

Conclusion : Détends-toi… ces fantômes ne sont pas réels !

Traverser une maison hantée et se déguiser, c'est amusant, car nous savons tous que tout cela n'est qu'apparence. Les fantômes, monstres, vampires, loups-garous et fous à la tronçonneuse ne sont pas réels.

Et les cinq mythes agiles décrits ici ne le sont pas non plus. Il n'y a rien de mal à avoir un peu peur au début. L'information et l'expérience démystifieront rapidement ces mythes et te donneront un sentiment de sécurité.

Mais si tu veux te faire ta propre idée de la réalité Agile et des mythes autour de Scrum & Co, jette un œil à notre Agile Journey, où nous te présentons les rôles en détail, ou deviens maintenant Scrum Master certifié ou participe à notre formation Agile Leadership.

Ce texte provient du blog de Mike Cohn et a été traduit par nos soins en allemand.

L'innovation en entreprise

=> Qu'est-ce qui caractérise les entreprises innovantes ?

Stratégie vécue

=> Découvre comment faire passer ta stratégie d'entreprise au niveau supérieur.

Entreprises invincibles

=> À quoi ressemble la gestion moderne de l'innovation en entreprise ?