« sauf que comme on part de très loin, c’est déjà une amélioration. »
La réponse elle est un peu là aussi, sans savoir d’où on part difficile de choisir entre du custom et du prepackagé. C’est pour ça qu’il est toujours important d’auditer fréquemment les systèmes pour savoir comment adapter les cadres de travail.
J’aime beaucoup l’idée de remettre de la nuance sur ce sujet qui prend effectivement pas mal de place aujourd’hui ! :)
La manière dont tu décris l’approche « custom » m’a fait penser à Kanban : partir de l’existant en impliquant les personnes dans la démarche de trouver la bonne manière de faire.
Je trouve que Kanban nous invite à transformer les choses de cette façon, en commençant par visualiser l’existant et prendre des décisions sur cette base là pour s’améliorer.
Alors même qu’il serait probablement catégorisé « framework standard » pour bcp ☺️
De mon point de vue, réussir à insuffler une vraie mécanique Kanban, et notamment ses concepts clés de gestion de flux, c'est très difficile. J'ai envie de dire que, by design, Kanban c'est du custom.
Et en même temps, cela illustre bien que faire du custom ce n'est pas non plus partir de zéro, c'est aussi appliquer beaucoup de pratiques déjà existantes piochées de-ci de-là.
Déployer une stratégie Kanban mature avec tous les concepts qui la compose est difficile je te rejoins, mais à mes yeux on obtient des gains bien avant d’en arriver à ce stade (et même sans jamais y arriver finalement).
C’est plutôt dans le point de départ que je fais un rapprochement entre le « custom » et Kanban. On ne touche pas aux rôles, on ne touche pas aux instances. Mais on propose de partir la où on est actuellement, en visualisant le flux de travail.
En ce sens, on a, je crois, moins de résistance à l’adoption d’une approche Kanban qu’à la mise en place de Scrum en général
« sauf que comme on part de très loin, c’est déjà une amélioration. »
La réponse elle est un peu là aussi, sans savoir d’où on part difficile de choisir entre du custom et du prepackagé. C’est pour ça qu’il est toujours important d’auditer fréquemment les systèmes pour savoir comment adapter les cadres de travail.
J’aime beaucoup l’idée de remettre de la nuance sur ce sujet qui prend effectivement pas mal de place aujourd’hui ! :)
La manière dont tu décris l’approche « custom » m’a fait penser à Kanban : partir de l’existant en impliquant les personnes dans la démarche de trouver la bonne manière de faire.
Je trouve que Kanban nous invite à transformer les choses de cette façon, en commençant par visualiser l’existant et prendre des décisions sur cette base là pour s’améliorer.
Alors même qu’il serait probablement catégorisé « framework standard » pour bcp ☺️
De mon point de vue, réussir à insuffler une vraie mécanique Kanban, et notamment ses concepts clés de gestion de flux, c'est très difficile. J'ai envie de dire que, by design, Kanban c'est du custom.
Et en même temps, cela illustre bien que faire du custom ce n'est pas non plus partir de zéro, c'est aussi appliquer beaucoup de pratiques déjà existantes piochées de-ci de-là.
Déployer une stratégie Kanban mature avec tous les concepts qui la compose est difficile je te rejoins, mais à mes yeux on obtient des gains bien avant d’en arriver à ce stade (et même sans jamais y arriver finalement).
C’est plutôt dans le point de départ que je fais un rapprochement entre le « custom » et Kanban. On ne touche pas aux rôles, on ne touche pas aux instances. Mais on propose de partir la où on est actuellement, en visualisant le flux de travail.
En ce sens, on a, je crois, moins de résistance à l’adoption d’une approche Kanban qu’à la mise en place de Scrum en général