Oui, savoir pourquoi les choses sont faites me semble indispensable. Merci d'avoir appuyé ce message ! Le risque sinon est de tomber dans le culte du cargo.
Bonjour @@ScrumLife ! Oui, quand il y a un problème ou un blocage arriver à sa racine permet de savoir où et comment agir pour le résoudre. Par exemple, en utilisant la technique des 5 pourquoi. Quand l'équipe, et le management, sait pourquoi elle veut travailler d'une certaine manière, il est possible de suivre un tel processus. Ainsi il m'est arrivé de comprendre, et de pouvoir démontrer ! que ce qui semblait être un problème de qualité venait en réalité de défauts dans la collaboration avec une autre équipe (la production en l’occurrence) ou qu'un problème soi-disant d'organisation relevait en fait du comportement d'un membre de l'équipe dont les valeurs n'étaient pas en phase avec Scrum.
Hello Jean-Pierre, Super vidéo ... Je suis partisan du slogan "Tatoueurs, tatoués" (:D) . Un coach Agile qui ne tient pas compte du contexte de son client, des envies de son client, des capacités de son client, du budget de son client (je rajoute à chaque fois "client", pour éliminer toute ambiguïté avec le contexte du coach, ses envies ...) n'est pas un Coach dit "Agile". A force de vouloir se faire plaisir et de suivre "une bible" sans compromis, on peut oublier le sens de la démarche et le POURQUOI (ainsi que le POUR QUOI) du client ! AGILE = (allez, j'ose) remettre le besoin client au centre d'une démarche de création de valeur en respectant l'Homme. Bref ... tout à fait ok avec toi. FranckC
Merci Franck ! Au final dans ce que tu dis on est pas loin du "PO" qui doit comprendre ses utilisateurs. Mais que penses-tu qu'un coach doivent faire de ses propres intuitions (à l'image d'un PO qui a des idées pour le produit) ? Ne pas les écouter ? Quand tu es sûr que le client se trompe, tu fais quoi ?
@@ScrumLife Bonjour bonjour :) Selon moi, un coach n'est ni un consultant, ni un formateur. C'est un peu tout à la fois mais, pas en même temps. La casquette "coach" permet de faire prendre conscience. Celle de "consultant", d'apporter des solutions et d'aider à les mettre en place. Tandis que celle de "formateur" permet d'expliquer. Maintenant, comme dit un peu plus haut, dans les prestations d'accompagnement (et non de "coaching"), l'intervenant (que j’appellerai "facilitateur" par la suite) doit sans arrêt, changer de casquette et être en permanence à l'écoute de son client. Il sera ainsi en mesure de lui proposer des solutions (casquette "consultant") mais aussi, lors des phases de coaching, de jouer "l'avocat du diable" et de le challenger dans ces réflexions et sur son "désir" d'Agilité (le POURQUOI et le POUR QUOI). Donc, pour répondre à la question du client qui se trompe de cible/stratégie..., la casquette "coach" doit, sans imposer ses idées (son intuition), expliquer et faire prendre conscience à son client de son "erreur". Si le client persiste, que c'est dangereux pour son équipe et son entreprise et que cela va à l'encontre des principes moraux du facilitateur, ce dernier devrait, selon moi, se retirer du projet en expliquant pourquoi. Si le facilitateur décide de rester, alors il devra lui-même être agile en aidant à la mise en place de la solution du client mais en levant les alertes au PLUS TOT afin de corriger rapidement (interprétation personnelle de l'Agile : "Se planter avant que cela ne devienne grave et apprendre !"). Il est évident que le facilitateur, à ce moment-là, devra éviter les "je l'avais bien dit !" et devra se concentrer sur : l'apprentissage du client ("Qu'avons-nous appris de cette expérience ?") et sur le futur ("Que pourrions-nous tenter maintenant ?"). Dans le cas où le client n'aurait pas d'autre "bonne" idée pour la suite, le facilitateur endossera alors le rôle de "consultant" (si le contrat passé avec le client l'y autorise, bien entendu !) et proposera sa solution. Voilà ma réflexion du matin :) Merci beaucoup à vous pour la question "retour" :) Franck
Ce que j'aime bien dans ce modèle, ce sont les temporalités de chaque étapes. On comprends que plus on choisi d'atteindre un niveau élevé d'Agilité, plus ça prends du temps. C'est une transformation a long terme
J'adore vos vidéos!!!! Je n'arrive pas à trouver une vidéo sur le rôle du Project Manager? La question revient souvent dans les transformations Agile et on indique souvent que ce rôle doit être conservé. Je me demandais quel était votre opinion sur le sujet?
Bonjour Marie-Claude, Je suis assez curieux de savoir qui vous indique que le rôle doit être conservé ! Les personnes oui, mais le rôle se retrouve rarement voire jamais dans les modèles agiles. En pratique, il y a des cas de figure où on travaille avec beaucoup de fournisseurs externes et on peut alors être content d'avoir un chef de projet qui s'occupe de la coordination avec ces différentes entités. Mais pas vraiment besoin de chef de projet pour accompagner l'équipe elle-même. Quelle est votre expérience ? -- JP
Une possibilité est justement d'utiliser le modèle proposé par Agile Fluency. Le premier niveau, "l'agilité 1 étoile" c'est "Focus on Value". En général l'imposture de Scrum ou d'agilité se focalise plutôt sur la productivité.
Découvre toute la communauté Scrum Life ! 👉 sl.run/kLltsV
Top ! Complètement d'accord sur ta recommandation de fin.
Vidéo au réveil comme d'hab' ;) Jérôme
Ca aurait dû être le scrum life #1 ... Merci JP !
Si je l'avais fait en premier il aurait été tout moche et moins impactant !
Oui, savoir pourquoi les choses sont faites me semble indispensable. Merci d'avoir appuyé ce message ! Le risque sinon est de tomber dans le culte du cargo.
Merci Eric ! Est-ce que cela fait écho à vos propres expériences ? Accepteriez-vous de partager avec nous ?
Bonjour @@ScrumLife ! Oui, quand il y a un problème ou un blocage arriver à sa racine permet de savoir où et comment agir pour le résoudre. Par exemple, en utilisant la technique des 5 pourquoi. Quand l'équipe, et le management, sait pourquoi elle veut travailler d'une certaine manière, il est possible de suivre un tel processus. Ainsi il m'est arrivé de comprendre, et de pouvoir démontrer ! que ce qui semblait être un problème de qualité venait en réalité de défauts dans la collaboration avec une autre équipe (la production en l’occurrence) ou qu'un problème soi-disant d'organisation relevait en fait du comportement d'un membre de l'équipe dont les valeurs n'étaient pas en phase avec Scrum.
Hello Jean-Pierre,
Super vidéo ...
Je suis partisan du slogan "Tatoueurs, tatoués" (:D) .
Un coach Agile qui ne tient pas compte du contexte de son client, des envies de son client, des capacités de son client, du budget de son client (je rajoute à chaque fois "client", pour éliminer toute ambiguïté avec le contexte du coach, ses envies ...) n'est pas un Coach dit "Agile".
A force de vouloir se faire plaisir et de suivre "une bible" sans compromis, on peut oublier le sens de la démarche et le POURQUOI (ainsi que le POUR QUOI) du client !
AGILE = (allez, j'ose) remettre le besoin client au centre d'une démarche de création de valeur en respectant l'Homme.
Bref ... tout à fait ok avec toi.
FranckC
Merci Franck ! Au final dans ce que tu dis on est pas loin du "PO" qui doit comprendre ses utilisateurs. Mais que penses-tu qu'un coach doivent faire de ses propres intuitions (à l'image d'un PO qui a des idées pour le produit) ?
Ne pas les écouter ? Quand tu es sûr que le client se trompe, tu fais quoi ?
@@ScrumLife
Bonjour bonjour :)
Selon moi, un coach n'est ni un consultant, ni un formateur. C'est un peu tout à la fois mais, pas en même temps.
La casquette "coach" permet de faire prendre conscience.
Celle de "consultant", d'apporter des solutions et d'aider à les mettre en place.
Tandis que celle de "formateur" permet d'expliquer.
Maintenant, comme dit un peu plus haut, dans les prestations d'accompagnement (et non de "coaching"), l'intervenant (que j’appellerai "facilitateur" par la suite) doit sans arrêt, changer de casquette et être en permanence à l'écoute de son client.
Il sera ainsi en mesure de lui proposer des solutions (casquette "consultant") mais aussi, lors des phases de coaching, de jouer "l'avocat du diable" et de le challenger dans ces réflexions et sur son "désir" d'Agilité (le POURQUOI et le POUR QUOI).
Donc, pour répondre à la question du client qui se trompe de cible/stratégie..., la casquette "coach" doit, sans imposer ses idées (son intuition), expliquer et faire prendre conscience à son client de son "erreur".
Si le client persiste, que c'est dangereux pour son équipe et son entreprise et que cela va à l'encontre des principes moraux du facilitateur, ce dernier devrait, selon moi, se retirer du projet en expliquant pourquoi.
Si le facilitateur décide de rester, alors il devra lui-même être agile en aidant à la mise en place de la solution du client mais en levant les alertes au PLUS TOT afin de corriger rapidement (interprétation personnelle de l'Agile : "Se planter avant que cela ne devienne grave et apprendre !").
Il est évident que le facilitateur, à ce moment-là, devra éviter les "je l'avais bien dit !" et devra se concentrer sur :
l'apprentissage du client ("Qu'avons-nous appris de cette expérience ?") et sur le futur ("Que pourrions-nous tenter maintenant ?").
Dans le cas où le client n'aurait pas d'autre "bonne" idée pour la suite, le facilitateur endossera alors le rôle de "consultant" (si le contrat passé avec le client l'y autorise, bien entendu !) et proposera sa solution.
Voilà ma réflexion du matin :)
Merci beaucoup à vous pour la question "retour" :)
Franck
Merci pour cette très bonne vidéo !
Ce que j'aime bien dans ce modèle, ce sont les temporalités de chaque étapes. On comprends que plus on choisi d'atteindre un niveau élevé d'Agilité, plus ça prends du temps. C'est une transformation a long terme
Merci Vincent ! Dans ton expérience, tu saurais placer l'état actuel de l'entreprise où tu es aujourd'hui ? Ou d'une autre ?
J'adore vos vidéos!!!! Je n'arrive pas à trouver une vidéo sur le rôle du Project Manager? La question revient souvent dans les transformations Agile et on indique souvent que ce rôle doit être conservé. Je me demandais quel était votre opinion sur le sujet?
Bonjour Marie-Claude,
Je suis assez curieux de savoir qui vous indique que le rôle doit être conservé ! Les personnes oui, mais le rôle se retrouve rarement voire jamais dans les modèles agiles.
En pratique, il y a des cas de figure où on travaille avec beaucoup de fournisseurs externes et on peut alors être content d'avoir un chef de projet qui s'occupe de la coordination avec ces différentes entités. Mais pas vraiment besoin de chef de projet pour accompagner l'équipe elle-même.
Quelle est votre expérience ?
-- JP
For more about the Agile Fluency Model, see the eBook at www.agilefluency.org/ebook.php
Thanks for the info!
Attention a l'agilité bas de gamme qui me fait pence au "scrum but". comment en faire la distinction?
Une possibilité est justement d'utiliser le modèle proposé par Agile Fluency. Le premier niveau, "l'agilité 1 étoile" c'est "Focus on Value". En général l'imposture de Scrum ou d'agilité se focalise plutôt sur la productivité.