Bonjour à tous,
Pouvez-vous me citer des exemples concrets où la mise en place de l’Agilité est impossible ?
C’est à dire que toute tentative d’éloignement du cycle en V empire la situation.
Hello Manu,
Alors tout d’abord, de quoi parle-t-on ? Si l’on parle d’une méthode type « Scrum », ou Kanban, en effet, il y a des situations où ces framework ne s’appliquent pas ou que partiellement.
Pour l’agilité, par contre, je ne vois aucun exemple où l’on ne pourrait pas l’appliquer. Être agile, c’est « juste » souscrire à, et respecter, quatre valeurs et douze principes.
De mon point de vue, ces valeurs et principes s’appliquent à absolument tout, sans exception.
Sinon, pour Scrum, c’est utilisé dans l’industrie, et notamment l’industrie aéronautique, et je ne parle pas de l’IT mais vraiment de la partie industrielle, dans le nucléaire, dans les RH, et de nombreux autres métiers.
Pour moi, on peut toujours adapter un framework agile pour coller aux besoins d’un sujet.
Il n’y a pas d’exemple où l’agilité ne peut pas être mise en place, de mon point de vue. Par contre, tu peux rencontrer des personnes tellement réfractaires qu’il sera impossible de mettre en place des cadres de travail agiles. Et même là, si on évite le terme agilité, on peut mettre en place des process qui sont agiles (sans le dire) et qui vont faire mieux marcher le projet.
1 « J'aime »
Le cycle en V n’est pas la seule alternative à l’agilité. Il y a des situations où ni l’agilité ni le cycle en V ne s’appliquent.
Pour y voir plus clair, il faut s’appuyer sur le cadre Cynefin qui distingue différents types de contexte et des modes opératoires selon le contexte. Selon Cynefin, le cycle en V se prête bien aux situations claires où tout le monde sait ce qu’il faut faire et comment le faire. Le Lean s’applique aux contextes compliqués. L’agilité s’applique aux situations peu complexes (on a une vague idée de l’objectif à atteindre) et permet de faire la transition vers le compliqué où on peut passer à l’échelle. Les situations très complexes nécessitent de stimuler l’innovation de rupture, l’agilité ne s’y prête pas vraiment. J’utilise souvent le jeu Try or Die pour sensibiliser à ce genre de situation et on voit très bien que l’agilité ne s’y applique pas. Enfin, dans les situations chaotiques, il faut évacuer et mettre en sécurité. Par exemple quand il y a une intrusion de sécurité, ce n’est pas le moment de faire de l’agilité.
3 « J'aime »
Hello,
merci pour vos réponses.
Pour parler plus concrètement voici un exemple:
Développement du logiciel Command & Control des missiles pour les navires de guerre.
- Client DGA
- Requirements inflexibles définis en amont
- Coûts et Délais encadrés par des closes de pénalités de retard
- Cadre réglementaire et documentation extrêmement lourd
Au final, n’y a-t-il pas une limite à l’adaptation des principes et méthodes Agiles à partir de laquelle la démarche est contre-productive ?
Hello,
J’imagine qu’il ya des prototypes avant la validation de la version finale. A mon avis la defense doit être la plus agile de toutes les industries, meme si les spécifications sont définis à l’avance, le besoin d’apporter les modifs rapide reste necessaire.
Tout dépend de la nature des requirements en fait.
S’ils sont décrits dans l’espace de la solution (description IHM, « quand je clique sur bouton vert ça fait boom »), alors oui on est dans une demande prestation consistant à implémenter une spécification. Dans ce contexte, une démarche agile n’a pas de sens.
Mais si les requirements sont fonctionnels (« le logiciel permet à tout moment de faire feu sur la dernière cible verrouillée », « l’opérateur de maintenance dispose d’un moyen de déclencher l’auto-test des missiles et d’en obtenir les résultats par message électronique sécurisé »), alors une approche agile est possible. Il faut toutefois arriver à se mettre d’accord avec le client sur les objectifs et critères permettant de déterminer ce qui est satisfaisant et ce qui ne l’est pas, pour le déclenchement des pénalités.
Mais bon, en général ce genre de logiciel s’intègre dans un ensemble plus vaste (ici le système de tir du navire - je parle de la partie mécanique et pyrotechnique). Il a probablement déjà fait l’objet d’une démarche d’ingénierie, et donc de spécification. Les ingénieurs étant ce qu’ils sont (j’en suis un moi même) je serais surpris que tu sois dans le second cas.
1 « J'aime »
Oui, il y aura des situations où l’agilité sera contre-productive.
Il faut tout de même prendre en compte la nature fractale de la plupart des contextes : l’agilité ne se prête peut-être pas à la totalité, cela n’empêche pas de l’appliquer à certaines parties.
2 « J'aime »
Mon avis est que l’agilité ne peut pas être mise en place si l’écosystème et ses membres qui doivent apporter de la valeur n’y sont pas favorables.
Ce sont bien les humains qui vont être les ingrédients du bon ou mauvais déploiement d’une agilité efficace.
Il est bien entendu que dans un contexte particullièrement prédictible simple clair et précis l’agilité n’a pas grand intérêt limite elle serait un gaspillage.
Mais à nouveau c’est l’humain qui va décider de cette perception. Bardé d’étude, d’ego, d’expérience, de réputation,… Il est honteux d’avouer qu’il ne sait pas !
Et il va démentir le monde vuca.
3 « J'aime »
L’équipe Scrum détermine un intérieur (SM, PO, dev) et un extérieur. En général l’intérieur fait l’objet de toutes les attentions, et il est important de s’assurer que tout le monde comprenne ce que ça implique de fonctionner en Agile et adhère à la philosophie.
Mais ça dépend aussi de l’extérieur (ce que tu appelles écosystème), et là on a tendance à mal évaluer le pouvoir de nuisance que ça représente. Pour certaines équipes, faire de l’agile c’est déjà difficile en soi, alors quand en plus on vient leur mettre des bâtons dans les roues, c’est carrément l’enfer. C’est une chose de dire qu’un mauvais équipier peut torpiller l’équipe. Mais quand en plus ça dépend de facteurs externes à l’équipe, ça donne un sacré sentiment de vulnérabilité.
Mais finalement, quand l’organisation place une équipe dans un écosystème peu adapté à l’agile, n’est-ce pas - à un certain niveau plus haut - l’échec de la capacité de l’organisation à mettre l’équipe dans le bon contexte ?
Merci Sélim pour ta réponse.
Dans l’exemple de contexte explicité plus haut, l’équipe développe un sous-système logiciel (Combat Management System) qui interface une un poste de commande stratégique de guerre à des missiles. On peut généraliser cela à tout contexte à forte régulation, ou ce que j’appelle à « Grande Inertie »
Je reprends le manifest Agile:
Through this work we have come to value:
1- Individuals and interactions over processes and tools
2- Working software over comprehensive documentation
3- Customer collaboration over contract negotiation
4- Responding to change over following a plan
Dans le contexte en question:
1- ni Oui ni Non → le manquement au process disqualifie totalement la valeur du produit
2- ni Oui ni Non → les bugs ne sont pas une option, ni la documentation détaillée
3- Faux → les relations avec la DGA sont de type « Client/Fournisseur »
4- Faux → Toute demande de changement déclenche un processus lourd et et coûteux
Il est difficile pour nous, les « enthousiastes de l’agilité », de prêcher contre notre propre paroisse.
Nous sommes émotionnellement investis sur le sujet et souhaitons naturellement que les environnements évoluent vers quelque chose qui pour nous fais plus de sens.
Cependant, je pense qu’il est de notre devoir de savoir détecter et de refuser de participer à son implémentation (ou plutôt sa distorsion) dans les contextes inappropriés.
Le cas échéant, nous nous rendons responsables de sa mauvaise réputation:
« C’est encore plus le bordel qu’avant »
« Le monde des bisounours »
« Un truc de hippie »
1 « J'aime »