j'avoue ne pas comprendre l'article : le titre c'est "ne pas vouloir du framework", et s'en suit un débat entre custom et standardisé... comme si un framework était un standard!
Que ce soit Scrum, ou Kanban, ou même SAFe qui est plus prescriptif, quand tu suis ce que dit le framework tu es à 50% défini : tu es encore à un niveau général qui nécessite d'être concrétisé.
Il y a généralement, un sujet de culture indispensable à traiter, rien n'est dit sur comment faire.
Prenons le refinement : c'est un mot lâché comme ça, mais qui cache une montagne pas vraiment décrite sur la façon de mener cette activité. Et le passage en sprint, moment charnière crucial entre le refinement et le dév... rien n'est dit pour construire une fiabilité suffisante.
La seule limite, il me semble, pour Scrum par exemple, c'est l'application des valeurs agile et Scrum, très souvent incompatibles avec la culture d'entreprise : ça impose en général un tech lead "chef d'équipe", qui va compenser une implication plus faible des autres membres. Mais on reste tjs dans le process Scrum. Pas de quoi parler de custom!
Ou alors, j'ai rien compris!.... c'est possible aussi. 😂 (je comprends vite mais faut m'expliquer longtemps!)
« 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
j'avoue ne pas comprendre l'article : le titre c'est "ne pas vouloir du framework", et s'en suit un débat entre custom et standardisé... comme si un framework était un standard!
Que ce soit Scrum, ou Kanban, ou même SAFe qui est plus prescriptif, quand tu suis ce que dit le framework tu es à 50% défini : tu es encore à un niveau général qui nécessite d'être concrétisé.
Il y a généralement, un sujet de culture indispensable à traiter, rien n'est dit sur comment faire.
Prenons le refinement : c'est un mot lâché comme ça, mais qui cache une montagne pas vraiment décrite sur la façon de mener cette activité. Et le passage en sprint, moment charnière crucial entre le refinement et le dév... rien n'est dit pour construire une fiabilité suffisante.
La seule limite, il me semble, pour Scrum par exemple, c'est l'application des valeurs agile et Scrum, très souvent incompatibles avec la culture d'entreprise : ça impose en général un tech lead "chef d'équipe", qui va compenser une implication plus faible des autres membres. Mais on reste tjs dans le process Scrum. Pas de quoi parler de custom!
Ou alors, j'ai rien compris!.... c'est possible aussi. 😂 (je comprends vite mais faut m'expliquer longtemps!)
« 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à.
Kanban, custom by design, c'est ce que je dis! comment y voir un standard?!
Non, le truc, le standard, c'est le film que ce font du framework, les gens qui attendent une méthode...!
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