Je prépare une formation pour introduire l’agile à un milieu qui ne le connait presque pas, le bâtiment (architecte, constructeur, ingénieur…). Dans l’un des modules, je parle du choix du projet pour expérimenter l’agile. Est-ce que vous auriez des idées là-dessus ?
Quel type de projet est le plus propice pour une première utilisation de l’agile (Scrum par exemple), donc un projet non informatique. Par exemple un petit ? avec une petite équipe ?
Est-ce que c’est bien de se donner des moyens d’évaluer le succès ou non de l’opération pour comparer avec la méthode traditionnelle ? Ou ce n’est pas en pratique possible…
Je sèche sur cette partie, conduite du changement et démarrage.
Je me situe dans le cadre d’une entreprise qui ne connait pas ou peu l’Agile. Et qui a plusieurs projets en cours (de bâtiment dans mon cas).
Comment choisir le projet sur lequel commencer pour tester l’agile sans passer l’ensemble des projets de l’agence d’un coup à l’Agile.
Je sais la structure de boites entre l’IT et le bâtiment est assez différentes.
Mais je ne sais pas si dans les cas que tu connais, tu as le cas de boites qui veulent ainsi passer progressivement à l’agile. Et dans ce cas, quel type de projet, ils choisissent parmi tous leurs projets ?
Ma deuxième question, c’est imagine, tu as choisi 1 projet parmi tes 20. À la fin de l’expérimentation Agile (la fin d’une phase par exemple), ils voudront savoir si ç’a réussi ou pas.
J’imagine qu’au-delà du ressenti des équipes, ils voudront avoir des métriques pour estimer si le passage à l’Agile a été bénéfique. Dans ce cas, quelle KPI / métrique suivre.
Pour décider d’utiliser l’agile sur plus de projets.
Bonjour, le framework Scrum adresse les ‹ projets › qui sont plus dans un contexte complexe (entre compliqué et complexe) au sens Cynefin du terme.
Faire de l’agilité juste pour faire de l’agilité n’a pas de sens. Dans des contextes clairs à compliqués, le choix de Scrum n’est probablement pas judicieux, le waterfall n’est pas le mal incarné
Pour qu’elles raisons conduire ce changement ? A quelles problématiques essayent t’ils de répondre ? Ce sont des indicateurs qui vont montrer que ces problèmatiques ont bien trouvées des solutions au travers de l’agilité qu’il me semble intéressant à suivre.
Peut être serait il intéressant de regarder du côté de ce que Kanban peut apporter pour optimiser le flux de création valeur entre plusieurs services ?
Pleins de questions se posent, mais comme dit avant : « pourquoi passer en mode agile » ? Certes, ça a des gains, mais aussi des questions qui se posent et des nouveaux problèmes qui émergent.
J’irais plutôt voir du côté du Lean, du Kanban façon Daniel Vacanti ou David J Anderson (choisissez votre camp ), du « Leadership Agile ».
Donc la question : quel projet choisir ? Je suis chiant : comme je ne sais pas quels sont les critères de l’entreprise que tu formes, il faudrait voir quels sont les critères d’après eux, quand on leur explique rapidement l’agilité ?
Et pour la mesure, pareil, je leur renvoie la responsabilité : quelles seraient les 3 métriques principales qui vous permettrait de mesurer le succès, sachant la formation que vous venez d’avoir ?
Je ne connais pas le framework que tu cites, c’est intéressant, je vais me renseigner.
Oui je suis d’accord que le scrum n’est pas la panacée, et que le waterfall est parfois aussi toujours utile (d’ailleurs vous diriez comment en français en cascade ? Je sais pas si ça s’utilise en Français)
Kanban, Scrum… je m’adresse à des novices, qui n’ont pas de culture de l’agile, donc pour commencer, et prendre pas trop de risques, c’est bien à mon avis de partir sur un projet pas trop complexe ?
Du moins c’est mon intuition pour tester à petite échelle ce qu’on faire à plus grande.
En fait, ce n’est pas un client précis, mais une formation que je suis en train de faire avec ce type de client en tête.
J’aime bien l’idée de laisser la métrique au choix, après, je peux leur en suggérer. Perso, j’aime bien les formations framework opiniated comme on dit dans le développement, c’est-à-dire avec un parti pris sur les bonnes pratiques. C’est plus facile, je trouve en tant que débutant et rassurant.
Vu que ce je « vends », c’est de pouvoir travailler sur les choses les plus importantes grâce à la priorisation par exemple, la meilleure coordination, le desilotage des équipes. Peut-être, je peux suggérer alors des métriques liées au temps passé, aux heures travaillés le week-end et le soir…
Aussi peut être de moral de l’équipe donc plus sur du ressenti…
Merci pour les refs je ne connais pas Vacanti ou Anderson.
Clairement, pour commencer en douceur (ce qui semble ton critère principal) :
tu prends un sujet où il y a de la motivation, envie de changement sans pour autant être trop dangereux pour le contexte (là tu es le seul a savoir ce qui corresponde le mieux)
approche Kanban qui invite a commencer par là où vous en êtes et d’ameliorer / eclaircir / adapter au fur et a mesure. Attention, Kanban ca parait facile mais cen vrai ca demande, a mon sens, plus de profondeur et de maitrise que Scrum. Maintenant, même sans etre un expert, il faut s’autoriser a tester
Merci @Fwedou, ca me semble effectivement une bonne approche.
À propos de la complexité « cachée » de la méthode Kanban. Tu as des éléments pour expliciter ça ? Ou un lien vers la bible du Kanban. Car autant le scrum a son guide, le Kanban, a-t-il l’équivalent ?
D’ailleurs ce qui marche déjà pas mal dans la construction a la phase construction, c’est le Lean construction. Qui me semble aussi une approche pragmatique et terre à terre qui demande moins de changements initiaux que le Scrum (que par ailleurs je connais beaucoup plus).
Kanban correspondrait plus a de la phase « compliquée » du framework Cynefin. En gros pour une cause A on sait anticiper le resultat B, mais cela demande de l’expertise et de l’expérience. Le monde de lz construction a plus cetre adn là.
Bible a mon gout, même si c’est tourné IT, Kanban pour L’IT OU Kanban une approche en flux pour l’entreprise.
Complexité car l’idée etant d’ameliorer la performance de la chaine de fabrication, cela demande de comprendre le flux, de travailler sur sa simplification et sa coherence, de s’appuyer sur de la data, etc. Bref, pour atteindre cet objectif cela demande une compréhension profonde de la methode et une bonne dose de rigueur pour etre drivé par les données récoltés au quotidien.
Les puristes diront que pour Scrum c’est pareil. Je rejoins tout en rappelant qu’un framework te laisse de la liberté dans la manière de le faire vivre avec des pratiques choisies dans votre contexte. Kanban comme une methode demande de respecter les etapes de modélisation du flux, de l’expliciter, de suivre sa performance, etc.
Kanban est une stratégie d’optimisation du flux de valeur à travers un processus utilisant un système de visualisation des systèmes de flux-tirés (Pull-based System).
Il pourrait y avoir plusieurs manières de définir la valeur, incluant la considération des besoins du client, de l’utilisateur final, de l’organisation et de l’environnement, par exemple.
), du « Leadership Agile ».
Je sais que Scrum Life en a fait une vidéo ici : 
mais cen vrai ca demande, a mon sens, plus de profondeur et de maitrise que Scrum. Maintenant, même sans etre un expert, il faut s’autoriser a tester