A partir d'une méthode de développement "agile" et devant l'incapacité de nombre d'acteurs à comprendre les mutations en cours ... et donc l'impossibilité pour eux d'inventer demain et donc de définir un plan d'actions adapté aux enjeux ... certains se sont dit que s'il avaient la capacité à bouger vite, dans tous les sens, il pourraient s'adapter au fur et à mesure qu'ils découvriraient les enjeux ...
D'où le développement de nombreux avatars des méthodes agiles qui passent par le lean ... et vont jusqu'au coach ... là où il faut commencer à se méfier, c'est lorsque certains peuvent vous aider à définir le plan d'actions alors que les objectifs ne sont pas fixés ... et les enjeux mal (voire pas du tout) cernés !
Bouger c'est se réchauffer dit l'électron dans le four à micro-ondes ... et il bouge tellement qu'il se télescope avec les voisins ... c'est pas celui qui cause le mieux ... ni celui qui brasse le plus d'air ....
Agile ou à Gilles?
il y a 8 ans
par
PascalW
Je croise beaucoup de choses agiles aujourd'hui, à croire qu'il s'agit de la nouvelle panacée.
Pourtant mes rencontres avec ceux qui prônaient l'agilité (hors du monde du développement applicatif, bien entendu) ne pas toujours convaincu. Pour être honnête, j'ai dû me frotter à des personnes qui construisaient l'avion en plein vol sous couvert d'être agile et ma conclusion est simple quand on sais pas où on va, peu importe comment...
Ma question: Projets, entreprises, changements, management, quelle sont pour vous les limites concretes à toute cette agilité?
Je ne vise aucun Gilles particulier (même pas un Process Manager d'un ancien client que je salue amicalement)
12
7
4 réponses
J'aime beaucoup l'image de l'agitation thermique de l'electron et , oui c'est colle assez avec certaines réalités.
Je note que nous sommes d'accord sur la nécessité de fixer des objectifs clairs à priori. Merci pour avoir identifié cette première limite surtout que par expérience c'est pas toujours aussi intuitif que cela peut paraître.
Je note que nous sommes d'accord sur la nécessité de fixer des objectifs clairs à priori. Merci pour avoir identifié cette première limite surtout que par expérience c'est pas toujours aussi intuitif que cela peut paraître.
Pour ma part, je n'ai vu appliqué cette méthode que dans le cadre de projet de développement applicatif.
D'un point de vue management j'y ai vu de nombreux intérêts notamment en terme de gestion des interactions entre acteurs (scrum cérémonies, visual management...). En revanche je suis resté dubitatif sur le réel empowerment des équipes et leur capacité à prendre des décisions en toute autonomie (j'entends pas "prendre" le pouvoir de prendre des décisions importantes). En effet assez rapidement j'ai revu se mettre en place des instances de pilotage à étage (à l'ancienne...) avec foison de Copil, codir, Coproj, coqqch qui viennent assez vite casser la dynamique de l'équipe "auto gérée". Mais cela dépend certainement de la culture d'entreprise des grands groupes qui est parfois loin du management démocratique et qui a besoin de retomber sur un mode de gouvernance plus classique.
D'un point point de vue delivery, j'ai trouvé que c'est un mode qui livre rapidement et plutôt en qualité le fameux Minimum Valuable Product (MVP). En revanche étant donné l'intensité du mode de travail, je sensibilise sur le fait qu'il est dur de faire tenir à une équipe plus de 5 à 7 sprints de 3 semaines (le terme est bien choisi) et qu'il faut assez vite revenir à des process de release management plus standard.
D'un point de vue gestion du changement, on retrouve toute la valeur de disposer du MVP assez rapidement et du coup de bien anticiper les enjeux du déploiement. Cela facilite par ailleurs la conception à partir d'un support concret. Cela a aussi un travers en terme de gestion du scope (donc du budget) qui peut évoluer au fil du temps.
D'un point de vue management j'y ai vu de nombreux intérêts notamment en terme de gestion des interactions entre acteurs (scrum cérémonies, visual management...). En revanche je suis resté dubitatif sur le réel empowerment des équipes et leur capacité à prendre des décisions en toute autonomie (j'entends pas "prendre" le pouvoir de prendre des décisions importantes). En effet assez rapidement j'ai revu se mettre en place des instances de pilotage à étage (à l'ancienne...) avec foison de Copil, codir, Coproj, coqqch qui viennent assez vite casser la dynamique de l'équipe "auto gérée". Mais cela dépend certainement de la culture d'entreprise des grands groupes qui est parfois loin du management démocratique et qui a besoin de retomber sur un mode de gouvernance plus classique.
D'un point point de vue delivery, j'ai trouvé que c'est un mode qui livre rapidement et plutôt en qualité le fameux Minimum Valuable Product (MVP). En revanche étant donné l'intensité du mode de travail, je sensibilise sur le fait qu'il est dur de faire tenir à une équipe plus de 5 à 7 sprints de 3 semaines (le terme est bien choisi) et qu'il faut assez vite revenir à des process de release management plus standard.
D'un point de vue gestion du changement, on retrouve toute la valeur de disposer du MVP assez rapidement et du coup de bien anticiper les enjeux du déploiement. Cela facilite par ailleurs la conception à partir d'un support concret. Cela a aussi un travers en terme de gestion du scope (donc du budget) qui peut évoluer au fil du temps.
Pour ce qui est du monde applicatif, je le conçois sans difficulté.
Je suis également d'accord sur les limitations des sprints. C'effectivement c'est particulièrement les équipes s'épuisent vite. Pour moi, chaque sprint est à considérer comme du "best effort" et ne doit pas devenir unmode de travail standard. Pour ce qui est des Copils, ils me semblent necessaire en tant que réunion de cadrage entre le métier et le prestataire technique, le choix d'une méthode (agile ou autre) ne me semble pas devoir être son problème. (mais c'est discutable selon les projets).
Merci de mettre en avant l'importance de release management et je suis convaincu de la valeur d'une approche orientée DevOps sur ce point.
En tout cas merci pour cette avis très intéressant
Je suis également d'accord sur les limitations des sprints. C'effectivement c'est particulièrement les équipes s'épuisent vite. Pour moi, chaque sprint est à considérer comme du "best effort" et ne doit pas devenir unmode de travail standard. Pour ce qui est des Copils, ils me semblent necessaire en tant que réunion de cadrage entre le métier et le prestataire technique, le choix d'une méthode (agile ou autre) ne me semble pas devoir être son problème. (mais c'est discutable selon les projets).
Merci de mettre en avant l'importance de release management et je suis convaincu de la valeur d'une approche orientée DevOps sur ce point.
En tout cas merci pour cette avis très intéressant
Normalement, le manifeste agile prône « un rythme soutenable indéfiniment ». Le terme de sprint est donc particulièrement inapproprié. S'il y a épuisement, c'est certainement parce que les valeurs ne sont pas comprises ou admises par tous, et c'est généralement du côté du métier que cela pêche (oui, car une équipe agile comprend tout le monde : le développeur, le testeur, le métier...).
Pour moi, l'agilité c'est surtout avoir une vision sur l'objectif à long terme, et travailler sur le court terme pour avancer dans la bonne direction. La priorisation régulière des tâches offre la possibilité de découvrir des alternatives pour couvrir un besoin, ou de ne jamais faire les choses les moins prioritaires (ce qui évite un gaspillage).
Le manifeste : www.agilemanifesto.org/iso/fr/
Les principes : www.agilemanifesto.org/iso/fr/principles.html
Pour moi, l'agilité c'est surtout avoir une vision sur l'objectif à long terme, et travailler sur le court terme pour avancer dans la bonne direction. La priorisation régulière des tâches offre la possibilité de découvrir des alternatives pour couvrir un besoin, ou de ne jamais faire les choses les moins prioritaires (ce qui évite un gaspillage).
Le manifeste : www.agilemanifesto.org/iso/fr/
Les principes : www.agilemanifesto.org/iso/fr/principles.html
Bonjour, je ne remet pas en cause la méthode agile dans le cadre d'un projet applicatif. La méthode a fait ces preuves.
Ma question est sur les limites ce qui ressemble à une transposition de la méthode pour de la gestion ou du management de ... un peu tout sauf du développement logiciel.
Ma question est sur les limites ce qui ressemble à une transposition de la méthode pour de la gestion ou du management de ... un peu tout sauf du développement logiciel.
Le Lean Startup fait-il parti de ce que tu décris comme « construire l'avion en plein vol » ?
Cette pratique, qui prône de valider au plus tôt les hypothèses, a beaucoup de qualités pour définir une offre de service innovante. Le principe est d'être en relation très rapidement avec les vrais futurs utilisateurs / bénéficiaires du service, et d'adapter l'offre pour répondre au besoin réel (et non supposé). Tout cela en utilisant le minimum de moyens : on ne réalise pas le produit avant de le proposer, car parfois un croquis ou une discussion suffisent à éliminer une piste.
Cette pratique, qui prône de valider au plus tôt les hypothèses, a beaucoup de qualités pour définir une offre de service innovante. Le principe est d'être en relation très rapidement avec les vrais futurs utilisateurs / bénéficiaires du service, et d'adapter l'offre pour répondre au besoin réel (et non supposé). Tout cela en utilisant le minimum de moyens : on ne réalise pas le produit avant de le proposer, car parfois un croquis ou une discussion suffisent à éliminer une piste.
Bonjour, je ne connais pas le Lean Startup mais le mot "Lean" me fait un peu froid dans le dos s'il ne s'applique pas à de la production industrielle.
J'ai déjà vu des gens arriver avec des concepts de Lean IT et aujourd'hui ce sont les premiers à expliquer combien ce système est insupportable pour les équipes prestataires.
Quand je lis l'article de Wikipedia sur le sujet, je ne peux m'empêcher de repenser aux blagues qu'on faisait sur Windows 95: "Valider des tests? pourquoi faire? tu n'as pas d'utilisateurs?"
Plus sérieusement, comme je ne connais pas j'ignore si cela fait effectivement parti de la "construction d'avion en plein vol".
Je vais être très transparent sur mon opinion sur Agile. Pour intervenir régulièrement sur des problématiques de support, d'intégration ou mise en production de projets applicatifs, je regrette que cette méthode (ou certaines équipes "projet" qui la prônent) fasse passer le besoin de documentation pour une maladie honteuse (c'est ingrat et sans valeur ajoutée selon eux). Au mieux les projets ne sont jamais terminés (surtout quand les utilisateurs ne sont pas les clients) au pire je me retrouve dans l'impossibilité de faire la moindre analyse d'impact en cas de monter de version de l'architecture ou des middlewares.
Ma question n'est pas à charge contre les méthodes agiles mais une interrogation sur les éventuelles limites de celles ci en particulier lors de leurs déclinaisons sur des sujets comme le management, l'entreprise,... bref tout ce qui n'est pas développement logiciel
Je serai par contre interloqué que quelqu'un me dise qu'il n'y a aucune limite à Agile!
Merci donc de ne pas croire que je souhaite remettre en cause le sérieux des concepts ou de ceux qui les suivent. Je pensais que comme de très nombreux échanges ont eu lieu sur Skiller sur ce thème, il était cohérent de poser ici la question des limites. Pas pour chercher une polémique inutile mais pour avoir un retour sur les nombreux experts de ce sujet.
J'ai déjà vu des gens arriver avec des concepts de Lean IT et aujourd'hui ce sont les premiers à expliquer combien ce système est insupportable pour les équipes prestataires.
Quand je lis l'article de Wikipedia sur le sujet, je ne peux m'empêcher de repenser aux blagues qu'on faisait sur Windows 95: "Valider des tests? pourquoi faire? tu n'as pas d'utilisateurs?"
Plus sérieusement, comme je ne connais pas j'ignore si cela fait effectivement parti de la "construction d'avion en plein vol".
Je vais être très transparent sur mon opinion sur Agile. Pour intervenir régulièrement sur des problématiques de support, d'intégration ou mise en production de projets applicatifs, je regrette que cette méthode (ou certaines équipes "projet" qui la prônent) fasse passer le besoin de documentation pour une maladie honteuse (c'est ingrat et sans valeur ajoutée selon eux). Au mieux les projets ne sont jamais terminés (surtout quand les utilisateurs ne sont pas les clients) au pire je me retrouve dans l'impossibilité de faire la moindre analyse d'impact en cas de monter de version de l'architecture ou des middlewares.
Ma question n'est pas à charge contre les méthodes agiles mais une interrogation sur les éventuelles limites de celles ci en particulier lors de leurs déclinaisons sur des sujets comme le management, l'entreprise,... bref tout ce qui n'est pas développement logiciel
Je serai par contre interloqué que quelqu'un me dise qu'il n'y a aucune limite à Agile!
Merci donc de ne pas croire que je souhaite remettre en cause le sérieux des concepts ou de ceux qui les suivent. Je pensais que comme de très nombreux échanges ont eu lieu sur Skiller sur ce thème, il était cohérent de poser ici la question des limites. Pas pour chercher une polémique inutile mais pour avoir un retour sur les nombreux experts de ce sujet.
Clairement, "Lean" et "Lean Startup" n'ont pas grand chose à voir. Le dernier propose de découvrir la meilleure solution à un besoin émergent. Ce n'est absolument pas une démarche d'amaigrissement des processus de l'entreprise.
Par ailleurs, "Agile" est un mot à la mode (non je n'ai pas dit "buzz word" !) un peu fourre-tout, qui ne dit rien du "comment". Il y en a qui font un beau cahier des charges pendant 6 mois, et qui décident pour faire joli qu'on le réalisera "en agile" !
Dans un contexte managérial, est-ce que ta question ne s'apparente pas également à la libération de l'entreprise ??
Par ailleurs, "Agile" est un mot à la mode (non je n'ai pas dit "buzz word" !) un peu fourre-tout, qui ne dit rien du "comment". Il y en a qui font un beau cahier des charges pendant 6 mois, et qui décident pour faire joli qu'on le réalisera "en agile" !
Dans un contexte managérial, est-ce que ta question ne s'apparente pas également à la libération de l'entreprise ??
Merci d'avoir l'ambiguïté sur Lean et Lean Startup.
Effectivement, certains utilisent " Agile" dans le contexte de liberation de l'entreprise.
Merci encore de prendre de ton temps pour échanger
Effectivement, certains utilisent " Agile" dans le contexte de liberation de l'entreprise.
Merci encore de prendre de ton temps pour échanger
Agile, growth hacking, crypto monnaie, lead nurturing ...
J'aime pas trop les termes à la mode :)
Pour ma part, c'est s'adapter, se confronter tôt au marché, tout simplement.