Description
L'agilité, ça n'a pas toujours été rose pour moi, alors quand un prétendu novice me synthétise l'essence de ce que devrait être à mon sens l'agilité, ça me pose quelques questions. En bonus, la conférence d'Arnaud Lemaire "et si on redémarrait l'agile" et mon twitter : @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à tous, et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, j'avais envie de m'attaquer à un gros morceau, l'agilité. Pour être honnête, quand j'ai commencé à préparer cet épisode, je ne savais pas du tout par quel bout le prendre. Faire comme sur d'autres thèmes et raconter mon vécu en essayant de partager les leçons que j'ai pu en tirer ? Ou bien en faire une présentation très académique avec des plus, des moins ? Ou encore sortir un troll un peu facile sur la vacuité de certaines pratiques ? Les approches ne manquent pas, mais aucune d'entre elles n'a vraiment réussi à me déverrouiller le propos. J'arrivais pas à écrire. Et c'était pas faute de choses à dire, mais plutôt d'un angle d'attaque qui puisse être personnel et pertinent. J'avais même commencé à mettre cette thématique de côté. Un peu un regret. Et puis j'ai récemment pu échanger avec quelqu'un qui a une approche de l'agilité, sobre, mais tellement pertinente. Avant de vous dévoiler le fond de cet échange, on va parler un peu de l'agilité. ou de l'agile avec un grand A, de manière un peu plus générale. Sachez donc, avant toute chose, que j'en veux un peu, voire beaucoup aux agilistes. La première fois qu'on m'a dit on est un projet agile je ne savais pas du tout de quoi il s'agissait. Alors j'ai bêtement cru que ce que j'étais sur le point de vivre, durant de longs mois, c'était ça, l'agilité. Pour résumer un petit peu en vrac, Des specs en post-it, des délits interminables à 15 devs, quand je dis interminables, c'est plus de 40 minutes, des livraisons toutes les 3 semaines, vendredi soir, qui se terminaient systématiquement à 20h, dans la douleur, des réunions récurrentes, des nuées de sens, vraiment on savait pas où on allait. Malheureusement, les expériences suivantes n'ont pas du tout réussi à contredire tout ça. Les post-it sont devenus légions et sont venus tapisser les murs, pour faire plaisir principalement aux directeurs de projet. On nous a sorti un poker planning, pour mieux chiffrer tous ensemble. Autant vous dire que pendant longtemps, j'ai amèrement regretté mon bon vieux cycle en V, dans lequel on livrait 3-4 fois par an, un périmètre connu, défini et stable, les changements de cap restaient à la marge et avec un peu de passif, on pouvait estimer de manière plutôt fiable les devs à venir. Donc non, à ce moment là, l'agilité n'était pour moi ni un progrès, ni même une bonne chose en soi. Il a fallu un paquet d'années. avant que je ne me retrouve dans d'autres contextes pour prendre conscience que ce que j'avais vécu était au mieux ce qu'on appelle de l'évile agile, au pire du chaos passablement désorganisé. A partir de là, j'ai commencé à vouloir me renseigner un peu plus. Et c'est ainsi que j'ai enfin, un peu tard, mais enfin appris l'existence du Manifeste Agile, qu'il avait été créé par des devs, et pour les devs, pour les aider à améliorer un... tant soit peu l'état de l'art plutôt désastreux dans notre profession. J'ai aussi découvert qu'il n'y avait pas que Scrum dans la vie et que même Scrum, adopté de manière pragmatique et intelligente, pouvait apporter plein de choses positives aux équipes. Mais j'ai également pris conscience que l'agilité est surtout devenue un business particulièrement lucratif et que pour maintenir cette manne, on n'hésite plus à complexifier à outrance. Quand je vois des équipes entières, toutes les deux semaines, avoir autour de deux jours... intégralement banalisées pour des rituels, des réunions, je comprends plus. Où est la valeur client dans tout ce temps passé en réunion ? Où est la capacité à accueillir du changement ? Ces temps-là sont facturés, généralement très chers, et quand une objection est faite sur la pertinence d'en avoir autant de ces réunions, la réponse que j'ai le plus souvent entendue a été C'est Scrum, c'est comme ça. Si on le fait pas comme il faut, autant pas le faire. Alors attention, ne me faites surtout pas dire ce que je n'ai pas dit. Les réunions et rétrospectives Scrum peuvent réellement avoir une utilité, mais seulement quand l'équipe dispose de suffisamment de confiance, d'autonomie et de liberté pour pouvoir organiser un petit peu sa progression. Par contre, quand le contexte est moisi et délétère, et que l'équipe n'a aucun moyen d'influencer ce contexte-là, ces réunions n'aboutissent que très rarement sur des solutions applicables. Alors pour combler, pour compenser, on va ajouter d'autres réunions, d'autres rôles. Faire des ateliers de communication bienveillante, essayer de nouvelles méthodes de chiffrage, ajouter des nouvelles colonnes sur le board. Si vous n'avez jamais eu l'occasion de la voir, je vous invite vraiment à jeter un oeil sur la conférence d'Arnaud Lemaire qui s'appelle Et si on redémarrait l'Agile ? Dans cette conf, il y a une phrase qui m'a bien marqué et que j'aime beaucoup, c'est le plus de X pour résoudre X C'est un peu cette situation-là. On a un problème de process, d'organisation dans le projet, et du coup on va rajouter des éléments de process et d'organisation qui vont juste créer un cercle vicieux. de complexité procédurale et organisationnelle. A ce sujet-là, je pourrais facilement troller sur SAFE et ses schémas qui sont absolument stratosphériques, mais ça serait un peu facile. Revenons-en maintenant à la conversation dont je vous parlais au début de l'épisode. Nous avions une discussion sur l'agilité, et je commençais à en parler un peu avec le travers que je viens pourtant de dénoncer, à savoir, je parlais trop du process, avant le reste, et... Je vais essayer de vous paraphraser le plus fidèlement possible ce que m'a répondu mon pertinent interlocuteur. Ah tu sais, l'agilité, moi, j'y connais rien, j'ai rien lu à ce sujet. Mais sur nos projets, je t'assure qu'on est agile. On sait qu'on n'aura jamais un cahier des charges cohérent, alors on se pose autour d'une table et on réfléchit à ce qu'on pourrait sortir comme produit en trois semaines. Quitte à ce que les utilisateurs soient obligés de faire encore quelques trucs à la main. Du coup, en moins d'un mois, on leur met l'outil entre les mains Et tu peux être certain que dans la quinzaine, tu auras des demandes claires, précises, ciblées et mesurables. Et là, je suis resté quoi ? Bon, pas longtemps, parce que je suis bavard, mais... Mais que quelqu'un qui prétende ne rien connaître à l'agilité soit capable de synthétiser à ce point-là ce qui, pour moi, est l'essence même de l'agilité, ça m'a bluffé. Avec toutes ces formations, ces lectures, ces échanges avec des Scrum Masters, des coachs agiles... J'ai fini par intégrer des automatismes avec lesquels je ne suis pourtant pas totalement d'accord dans le fond. La valeur profonde de l'agilité est à mon sens parfaitement résumée dans sa réponse. Livrer de la valeur rapidement, disposer d'une proximité forte avec les utilisateurs finaux, pour pouvoir recueillir du feedback avec le moins de transformations ou de pertes possibles, pour pouvoir livrer à nouveau rapidement et entrer dans une boucle vertueuse. On pourrait ici argumenter qu'il manque une notion d'excellence technique. C'est une notion qui est abordée par Arnaud dans sa conférence, et qui est selon moi, tout comme lui, une condition indispensable pour supporter des changements de cap fréquents. Mais j'estime que quand on s'est livré très fréquemment en production, avec une bonne satisfaction utilisateur sur du moyen à long terme, je vais avoir tendance à présupposer que la qualité elle est là, forcément. L'exigence technique augmentant avec l'âge et la taille du projet, Si on reste capable de livrer rapidement, avec une bonne satisfaction utilisateur, c'est que l'essentiel est fait. En ayant à l'esprit ces valeurs-là, si aujourd'hui on devait vous vendre un poste dans une équipe qui se prétend agile, vous avez deux questions pour moi à poser pour vous assurer que l'équipe l'est vraiment agile. La première serait de savoir quelle est la proximité, la disponibilité, soit des utilisateurs finaux, soit des sachants métiers, ceux qui connaissent le business. La seconde question tourne autour de la fréquence de livraison. A quel rythme est-ce que vous livrez en prod ? Est-ce que vous livrez tous les jours, tous les mois, tous les semestres, deux fois par an ? Si on vous répond que pour avoir un utilisateur final, il faut attendre les trois livraisons par an et que toutes les demandes de l'utilisateur repassent par N couches de responsables, de chefs de projet, d'analystes... À ce moment-là, vous saurez qu'il est difficile, voire presque impossible d'être agile dans des conditions pareilles. Comment connaître le besoin ? Comment récolter du feedback quand il y a autant d'étages et autant de temps entre chaque itération ? Ça me paraît très très difficile. Pour moi, être agile, ce ne sera pas appliquer Scrum ou une autre méthode à la lettre. C'est surtout faire preuve de souplesse et de rigueur tout en gardant la finalité business en ligne de mire permanente. Merci d'avoir écouté cet épisode jusqu'au bout. J'espère vraiment qu'il vous aura plu. Si ce sujet vous intéresse, vous devez absolument voir la conf d'Arnaud Lemaire qui s'intitule Et si on redémarrait l'agile ? Je vous laisse le lien dans la description. J'aurai encore des tas de choses à dire sur l'agilité. Et le plus difficile pour moi était un petit peu de démarrer. C'est maintenant chose faite. N'hésitez pas à vous abonner pour ne rien rater des nouvelles publications. Pour information, Deezer a aujourd'hui quelques soucis et peut parfois avoir jusqu'à 24 heures de retard dans la publication de l'épisode, mais il est dispo sur d'autres providers. Il me reste à vous souhaiter une excellente semaine, à mardi prochain, d'ici là, geekez bien, je dis bien.
Présentez-vous.
Description
L'agilité, ça n'a pas toujours été rose pour moi, alors quand un prétendu novice me synthétise l'essence de ce que devrait être à mon sens l'agilité, ça me pose quelques questions. En bonus, la conférence d'Arnaud Lemaire "et si on redémarrait l'agile" et mon twitter : @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à tous, et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, j'avais envie de m'attaquer à un gros morceau, l'agilité. Pour être honnête, quand j'ai commencé à préparer cet épisode, je ne savais pas du tout par quel bout le prendre. Faire comme sur d'autres thèmes et raconter mon vécu en essayant de partager les leçons que j'ai pu en tirer ? Ou bien en faire une présentation très académique avec des plus, des moins ? Ou encore sortir un troll un peu facile sur la vacuité de certaines pratiques ? Les approches ne manquent pas, mais aucune d'entre elles n'a vraiment réussi à me déverrouiller le propos. J'arrivais pas à écrire. Et c'était pas faute de choses à dire, mais plutôt d'un angle d'attaque qui puisse être personnel et pertinent. J'avais même commencé à mettre cette thématique de côté. Un peu un regret. Et puis j'ai récemment pu échanger avec quelqu'un qui a une approche de l'agilité, sobre, mais tellement pertinente. Avant de vous dévoiler le fond de cet échange, on va parler un peu de l'agilité. ou de l'agile avec un grand A, de manière un peu plus générale. Sachez donc, avant toute chose, que j'en veux un peu, voire beaucoup aux agilistes. La première fois qu'on m'a dit on est un projet agile je ne savais pas du tout de quoi il s'agissait. Alors j'ai bêtement cru que ce que j'étais sur le point de vivre, durant de longs mois, c'était ça, l'agilité. Pour résumer un petit peu en vrac, Des specs en post-it, des délits interminables à 15 devs, quand je dis interminables, c'est plus de 40 minutes, des livraisons toutes les 3 semaines, vendredi soir, qui se terminaient systématiquement à 20h, dans la douleur, des réunions récurrentes, des nuées de sens, vraiment on savait pas où on allait. Malheureusement, les expériences suivantes n'ont pas du tout réussi à contredire tout ça. Les post-it sont devenus légions et sont venus tapisser les murs, pour faire plaisir principalement aux directeurs de projet. On nous a sorti un poker planning, pour mieux chiffrer tous ensemble. Autant vous dire que pendant longtemps, j'ai amèrement regretté mon bon vieux cycle en V, dans lequel on livrait 3-4 fois par an, un périmètre connu, défini et stable, les changements de cap restaient à la marge et avec un peu de passif, on pouvait estimer de manière plutôt fiable les devs à venir. Donc non, à ce moment là, l'agilité n'était pour moi ni un progrès, ni même une bonne chose en soi. Il a fallu un paquet d'années. avant que je ne me retrouve dans d'autres contextes pour prendre conscience que ce que j'avais vécu était au mieux ce qu'on appelle de l'évile agile, au pire du chaos passablement désorganisé. A partir de là, j'ai commencé à vouloir me renseigner un peu plus. Et c'est ainsi que j'ai enfin, un peu tard, mais enfin appris l'existence du Manifeste Agile, qu'il avait été créé par des devs, et pour les devs, pour les aider à améliorer un... tant soit peu l'état de l'art plutôt désastreux dans notre profession. J'ai aussi découvert qu'il n'y avait pas que Scrum dans la vie et que même Scrum, adopté de manière pragmatique et intelligente, pouvait apporter plein de choses positives aux équipes. Mais j'ai également pris conscience que l'agilité est surtout devenue un business particulièrement lucratif et que pour maintenir cette manne, on n'hésite plus à complexifier à outrance. Quand je vois des équipes entières, toutes les deux semaines, avoir autour de deux jours... intégralement banalisées pour des rituels, des réunions, je comprends plus. Où est la valeur client dans tout ce temps passé en réunion ? Où est la capacité à accueillir du changement ? Ces temps-là sont facturés, généralement très chers, et quand une objection est faite sur la pertinence d'en avoir autant de ces réunions, la réponse que j'ai le plus souvent entendue a été C'est Scrum, c'est comme ça. Si on le fait pas comme il faut, autant pas le faire. Alors attention, ne me faites surtout pas dire ce que je n'ai pas dit. Les réunions et rétrospectives Scrum peuvent réellement avoir une utilité, mais seulement quand l'équipe dispose de suffisamment de confiance, d'autonomie et de liberté pour pouvoir organiser un petit peu sa progression. Par contre, quand le contexte est moisi et délétère, et que l'équipe n'a aucun moyen d'influencer ce contexte-là, ces réunions n'aboutissent que très rarement sur des solutions applicables. Alors pour combler, pour compenser, on va ajouter d'autres réunions, d'autres rôles. Faire des ateliers de communication bienveillante, essayer de nouvelles méthodes de chiffrage, ajouter des nouvelles colonnes sur le board. Si vous n'avez jamais eu l'occasion de la voir, je vous invite vraiment à jeter un oeil sur la conférence d'Arnaud Lemaire qui s'appelle Et si on redémarrait l'Agile ? Dans cette conf, il y a une phrase qui m'a bien marqué et que j'aime beaucoup, c'est le plus de X pour résoudre X C'est un peu cette situation-là. On a un problème de process, d'organisation dans le projet, et du coup on va rajouter des éléments de process et d'organisation qui vont juste créer un cercle vicieux. de complexité procédurale et organisationnelle. A ce sujet-là, je pourrais facilement troller sur SAFE et ses schémas qui sont absolument stratosphériques, mais ça serait un peu facile. Revenons-en maintenant à la conversation dont je vous parlais au début de l'épisode. Nous avions une discussion sur l'agilité, et je commençais à en parler un peu avec le travers que je viens pourtant de dénoncer, à savoir, je parlais trop du process, avant le reste, et... Je vais essayer de vous paraphraser le plus fidèlement possible ce que m'a répondu mon pertinent interlocuteur. Ah tu sais, l'agilité, moi, j'y connais rien, j'ai rien lu à ce sujet. Mais sur nos projets, je t'assure qu'on est agile. On sait qu'on n'aura jamais un cahier des charges cohérent, alors on se pose autour d'une table et on réfléchit à ce qu'on pourrait sortir comme produit en trois semaines. Quitte à ce que les utilisateurs soient obligés de faire encore quelques trucs à la main. Du coup, en moins d'un mois, on leur met l'outil entre les mains Et tu peux être certain que dans la quinzaine, tu auras des demandes claires, précises, ciblées et mesurables. Et là, je suis resté quoi ? Bon, pas longtemps, parce que je suis bavard, mais... Mais que quelqu'un qui prétende ne rien connaître à l'agilité soit capable de synthétiser à ce point-là ce qui, pour moi, est l'essence même de l'agilité, ça m'a bluffé. Avec toutes ces formations, ces lectures, ces échanges avec des Scrum Masters, des coachs agiles... J'ai fini par intégrer des automatismes avec lesquels je ne suis pourtant pas totalement d'accord dans le fond. La valeur profonde de l'agilité est à mon sens parfaitement résumée dans sa réponse. Livrer de la valeur rapidement, disposer d'une proximité forte avec les utilisateurs finaux, pour pouvoir recueillir du feedback avec le moins de transformations ou de pertes possibles, pour pouvoir livrer à nouveau rapidement et entrer dans une boucle vertueuse. On pourrait ici argumenter qu'il manque une notion d'excellence technique. C'est une notion qui est abordée par Arnaud dans sa conférence, et qui est selon moi, tout comme lui, une condition indispensable pour supporter des changements de cap fréquents. Mais j'estime que quand on s'est livré très fréquemment en production, avec une bonne satisfaction utilisateur sur du moyen à long terme, je vais avoir tendance à présupposer que la qualité elle est là, forcément. L'exigence technique augmentant avec l'âge et la taille du projet, Si on reste capable de livrer rapidement, avec une bonne satisfaction utilisateur, c'est que l'essentiel est fait. En ayant à l'esprit ces valeurs-là, si aujourd'hui on devait vous vendre un poste dans une équipe qui se prétend agile, vous avez deux questions pour moi à poser pour vous assurer que l'équipe l'est vraiment agile. La première serait de savoir quelle est la proximité, la disponibilité, soit des utilisateurs finaux, soit des sachants métiers, ceux qui connaissent le business. La seconde question tourne autour de la fréquence de livraison. A quel rythme est-ce que vous livrez en prod ? Est-ce que vous livrez tous les jours, tous les mois, tous les semestres, deux fois par an ? Si on vous répond que pour avoir un utilisateur final, il faut attendre les trois livraisons par an et que toutes les demandes de l'utilisateur repassent par N couches de responsables, de chefs de projet, d'analystes... À ce moment-là, vous saurez qu'il est difficile, voire presque impossible d'être agile dans des conditions pareilles. Comment connaître le besoin ? Comment récolter du feedback quand il y a autant d'étages et autant de temps entre chaque itération ? Ça me paraît très très difficile. Pour moi, être agile, ce ne sera pas appliquer Scrum ou une autre méthode à la lettre. C'est surtout faire preuve de souplesse et de rigueur tout en gardant la finalité business en ligne de mire permanente. Merci d'avoir écouté cet épisode jusqu'au bout. J'espère vraiment qu'il vous aura plu. Si ce sujet vous intéresse, vous devez absolument voir la conf d'Arnaud Lemaire qui s'intitule Et si on redémarrait l'agile ? Je vous laisse le lien dans la description. J'aurai encore des tas de choses à dire sur l'agilité. Et le plus difficile pour moi était un petit peu de démarrer. C'est maintenant chose faite. N'hésitez pas à vous abonner pour ne rien rater des nouvelles publications. Pour information, Deezer a aujourd'hui quelques soucis et peut parfois avoir jusqu'à 24 heures de retard dans la publication de l'épisode, mais il est dispo sur d'autres providers. Il me reste à vous souhaiter une excellente semaine, à mardi prochain, d'ici là, geekez bien, je dis bien.
Présentez-vous.
Share
Embed
You may also like
Description
L'agilité, ça n'a pas toujours été rose pour moi, alors quand un prétendu novice me synthétise l'essence de ce que devrait être à mon sens l'agilité, ça me pose quelques questions. En bonus, la conférence d'Arnaud Lemaire "et si on redémarrait l'agile" et mon twitter : @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à tous, et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, j'avais envie de m'attaquer à un gros morceau, l'agilité. Pour être honnête, quand j'ai commencé à préparer cet épisode, je ne savais pas du tout par quel bout le prendre. Faire comme sur d'autres thèmes et raconter mon vécu en essayant de partager les leçons que j'ai pu en tirer ? Ou bien en faire une présentation très académique avec des plus, des moins ? Ou encore sortir un troll un peu facile sur la vacuité de certaines pratiques ? Les approches ne manquent pas, mais aucune d'entre elles n'a vraiment réussi à me déverrouiller le propos. J'arrivais pas à écrire. Et c'était pas faute de choses à dire, mais plutôt d'un angle d'attaque qui puisse être personnel et pertinent. J'avais même commencé à mettre cette thématique de côté. Un peu un regret. Et puis j'ai récemment pu échanger avec quelqu'un qui a une approche de l'agilité, sobre, mais tellement pertinente. Avant de vous dévoiler le fond de cet échange, on va parler un peu de l'agilité. ou de l'agile avec un grand A, de manière un peu plus générale. Sachez donc, avant toute chose, que j'en veux un peu, voire beaucoup aux agilistes. La première fois qu'on m'a dit on est un projet agile je ne savais pas du tout de quoi il s'agissait. Alors j'ai bêtement cru que ce que j'étais sur le point de vivre, durant de longs mois, c'était ça, l'agilité. Pour résumer un petit peu en vrac, Des specs en post-it, des délits interminables à 15 devs, quand je dis interminables, c'est plus de 40 minutes, des livraisons toutes les 3 semaines, vendredi soir, qui se terminaient systématiquement à 20h, dans la douleur, des réunions récurrentes, des nuées de sens, vraiment on savait pas où on allait. Malheureusement, les expériences suivantes n'ont pas du tout réussi à contredire tout ça. Les post-it sont devenus légions et sont venus tapisser les murs, pour faire plaisir principalement aux directeurs de projet. On nous a sorti un poker planning, pour mieux chiffrer tous ensemble. Autant vous dire que pendant longtemps, j'ai amèrement regretté mon bon vieux cycle en V, dans lequel on livrait 3-4 fois par an, un périmètre connu, défini et stable, les changements de cap restaient à la marge et avec un peu de passif, on pouvait estimer de manière plutôt fiable les devs à venir. Donc non, à ce moment là, l'agilité n'était pour moi ni un progrès, ni même une bonne chose en soi. Il a fallu un paquet d'années. avant que je ne me retrouve dans d'autres contextes pour prendre conscience que ce que j'avais vécu était au mieux ce qu'on appelle de l'évile agile, au pire du chaos passablement désorganisé. A partir de là, j'ai commencé à vouloir me renseigner un peu plus. Et c'est ainsi que j'ai enfin, un peu tard, mais enfin appris l'existence du Manifeste Agile, qu'il avait été créé par des devs, et pour les devs, pour les aider à améliorer un... tant soit peu l'état de l'art plutôt désastreux dans notre profession. J'ai aussi découvert qu'il n'y avait pas que Scrum dans la vie et que même Scrum, adopté de manière pragmatique et intelligente, pouvait apporter plein de choses positives aux équipes. Mais j'ai également pris conscience que l'agilité est surtout devenue un business particulièrement lucratif et que pour maintenir cette manne, on n'hésite plus à complexifier à outrance. Quand je vois des équipes entières, toutes les deux semaines, avoir autour de deux jours... intégralement banalisées pour des rituels, des réunions, je comprends plus. Où est la valeur client dans tout ce temps passé en réunion ? Où est la capacité à accueillir du changement ? Ces temps-là sont facturés, généralement très chers, et quand une objection est faite sur la pertinence d'en avoir autant de ces réunions, la réponse que j'ai le plus souvent entendue a été C'est Scrum, c'est comme ça. Si on le fait pas comme il faut, autant pas le faire. Alors attention, ne me faites surtout pas dire ce que je n'ai pas dit. Les réunions et rétrospectives Scrum peuvent réellement avoir une utilité, mais seulement quand l'équipe dispose de suffisamment de confiance, d'autonomie et de liberté pour pouvoir organiser un petit peu sa progression. Par contre, quand le contexte est moisi et délétère, et que l'équipe n'a aucun moyen d'influencer ce contexte-là, ces réunions n'aboutissent que très rarement sur des solutions applicables. Alors pour combler, pour compenser, on va ajouter d'autres réunions, d'autres rôles. Faire des ateliers de communication bienveillante, essayer de nouvelles méthodes de chiffrage, ajouter des nouvelles colonnes sur le board. Si vous n'avez jamais eu l'occasion de la voir, je vous invite vraiment à jeter un oeil sur la conférence d'Arnaud Lemaire qui s'appelle Et si on redémarrait l'Agile ? Dans cette conf, il y a une phrase qui m'a bien marqué et que j'aime beaucoup, c'est le plus de X pour résoudre X C'est un peu cette situation-là. On a un problème de process, d'organisation dans le projet, et du coup on va rajouter des éléments de process et d'organisation qui vont juste créer un cercle vicieux. de complexité procédurale et organisationnelle. A ce sujet-là, je pourrais facilement troller sur SAFE et ses schémas qui sont absolument stratosphériques, mais ça serait un peu facile. Revenons-en maintenant à la conversation dont je vous parlais au début de l'épisode. Nous avions une discussion sur l'agilité, et je commençais à en parler un peu avec le travers que je viens pourtant de dénoncer, à savoir, je parlais trop du process, avant le reste, et... Je vais essayer de vous paraphraser le plus fidèlement possible ce que m'a répondu mon pertinent interlocuteur. Ah tu sais, l'agilité, moi, j'y connais rien, j'ai rien lu à ce sujet. Mais sur nos projets, je t'assure qu'on est agile. On sait qu'on n'aura jamais un cahier des charges cohérent, alors on se pose autour d'une table et on réfléchit à ce qu'on pourrait sortir comme produit en trois semaines. Quitte à ce que les utilisateurs soient obligés de faire encore quelques trucs à la main. Du coup, en moins d'un mois, on leur met l'outil entre les mains Et tu peux être certain que dans la quinzaine, tu auras des demandes claires, précises, ciblées et mesurables. Et là, je suis resté quoi ? Bon, pas longtemps, parce que je suis bavard, mais... Mais que quelqu'un qui prétende ne rien connaître à l'agilité soit capable de synthétiser à ce point-là ce qui, pour moi, est l'essence même de l'agilité, ça m'a bluffé. Avec toutes ces formations, ces lectures, ces échanges avec des Scrum Masters, des coachs agiles... J'ai fini par intégrer des automatismes avec lesquels je ne suis pourtant pas totalement d'accord dans le fond. La valeur profonde de l'agilité est à mon sens parfaitement résumée dans sa réponse. Livrer de la valeur rapidement, disposer d'une proximité forte avec les utilisateurs finaux, pour pouvoir recueillir du feedback avec le moins de transformations ou de pertes possibles, pour pouvoir livrer à nouveau rapidement et entrer dans une boucle vertueuse. On pourrait ici argumenter qu'il manque une notion d'excellence technique. C'est une notion qui est abordée par Arnaud dans sa conférence, et qui est selon moi, tout comme lui, une condition indispensable pour supporter des changements de cap fréquents. Mais j'estime que quand on s'est livré très fréquemment en production, avec une bonne satisfaction utilisateur sur du moyen à long terme, je vais avoir tendance à présupposer que la qualité elle est là, forcément. L'exigence technique augmentant avec l'âge et la taille du projet, Si on reste capable de livrer rapidement, avec une bonne satisfaction utilisateur, c'est que l'essentiel est fait. En ayant à l'esprit ces valeurs-là, si aujourd'hui on devait vous vendre un poste dans une équipe qui se prétend agile, vous avez deux questions pour moi à poser pour vous assurer que l'équipe l'est vraiment agile. La première serait de savoir quelle est la proximité, la disponibilité, soit des utilisateurs finaux, soit des sachants métiers, ceux qui connaissent le business. La seconde question tourne autour de la fréquence de livraison. A quel rythme est-ce que vous livrez en prod ? Est-ce que vous livrez tous les jours, tous les mois, tous les semestres, deux fois par an ? Si on vous répond que pour avoir un utilisateur final, il faut attendre les trois livraisons par an et que toutes les demandes de l'utilisateur repassent par N couches de responsables, de chefs de projet, d'analystes... À ce moment-là, vous saurez qu'il est difficile, voire presque impossible d'être agile dans des conditions pareilles. Comment connaître le besoin ? Comment récolter du feedback quand il y a autant d'étages et autant de temps entre chaque itération ? Ça me paraît très très difficile. Pour moi, être agile, ce ne sera pas appliquer Scrum ou une autre méthode à la lettre. C'est surtout faire preuve de souplesse et de rigueur tout en gardant la finalité business en ligne de mire permanente. Merci d'avoir écouté cet épisode jusqu'au bout. J'espère vraiment qu'il vous aura plu. Si ce sujet vous intéresse, vous devez absolument voir la conf d'Arnaud Lemaire qui s'intitule Et si on redémarrait l'agile ? Je vous laisse le lien dans la description. J'aurai encore des tas de choses à dire sur l'agilité. Et le plus difficile pour moi était un petit peu de démarrer. C'est maintenant chose faite. N'hésitez pas à vous abonner pour ne rien rater des nouvelles publications. Pour information, Deezer a aujourd'hui quelques soucis et peut parfois avoir jusqu'à 24 heures de retard dans la publication de l'épisode, mais il est dispo sur d'autres providers. Il me reste à vous souhaiter une excellente semaine, à mardi prochain, d'ici là, geekez bien, je dis bien.
Présentez-vous.
Description
L'agilité, ça n'a pas toujours été rose pour moi, alors quand un prétendu novice me synthétise l'essence de ce que devrait être à mon sens l'agilité, ça me pose quelques questions. En bonus, la conférence d'Arnaud Lemaire "et si on redémarrait l'agile" et mon twitter : @sylv_coud
Hébergé par Ausha. Visitez ausha.co/politique-de-confidentialite pour plus d'informations.
Transcription
Bonjour à tous, et bienvenue sur ce nouvel épisode du podcast PunkinDev. Aujourd'hui, j'avais envie de m'attaquer à un gros morceau, l'agilité. Pour être honnête, quand j'ai commencé à préparer cet épisode, je ne savais pas du tout par quel bout le prendre. Faire comme sur d'autres thèmes et raconter mon vécu en essayant de partager les leçons que j'ai pu en tirer ? Ou bien en faire une présentation très académique avec des plus, des moins ? Ou encore sortir un troll un peu facile sur la vacuité de certaines pratiques ? Les approches ne manquent pas, mais aucune d'entre elles n'a vraiment réussi à me déverrouiller le propos. J'arrivais pas à écrire. Et c'était pas faute de choses à dire, mais plutôt d'un angle d'attaque qui puisse être personnel et pertinent. J'avais même commencé à mettre cette thématique de côté. Un peu un regret. Et puis j'ai récemment pu échanger avec quelqu'un qui a une approche de l'agilité, sobre, mais tellement pertinente. Avant de vous dévoiler le fond de cet échange, on va parler un peu de l'agilité. ou de l'agile avec un grand A, de manière un peu plus générale. Sachez donc, avant toute chose, que j'en veux un peu, voire beaucoup aux agilistes. La première fois qu'on m'a dit on est un projet agile je ne savais pas du tout de quoi il s'agissait. Alors j'ai bêtement cru que ce que j'étais sur le point de vivre, durant de longs mois, c'était ça, l'agilité. Pour résumer un petit peu en vrac, Des specs en post-it, des délits interminables à 15 devs, quand je dis interminables, c'est plus de 40 minutes, des livraisons toutes les 3 semaines, vendredi soir, qui se terminaient systématiquement à 20h, dans la douleur, des réunions récurrentes, des nuées de sens, vraiment on savait pas où on allait. Malheureusement, les expériences suivantes n'ont pas du tout réussi à contredire tout ça. Les post-it sont devenus légions et sont venus tapisser les murs, pour faire plaisir principalement aux directeurs de projet. On nous a sorti un poker planning, pour mieux chiffrer tous ensemble. Autant vous dire que pendant longtemps, j'ai amèrement regretté mon bon vieux cycle en V, dans lequel on livrait 3-4 fois par an, un périmètre connu, défini et stable, les changements de cap restaient à la marge et avec un peu de passif, on pouvait estimer de manière plutôt fiable les devs à venir. Donc non, à ce moment là, l'agilité n'était pour moi ni un progrès, ni même une bonne chose en soi. Il a fallu un paquet d'années. avant que je ne me retrouve dans d'autres contextes pour prendre conscience que ce que j'avais vécu était au mieux ce qu'on appelle de l'évile agile, au pire du chaos passablement désorganisé. A partir de là, j'ai commencé à vouloir me renseigner un peu plus. Et c'est ainsi que j'ai enfin, un peu tard, mais enfin appris l'existence du Manifeste Agile, qu'il avait été créé par des devs, et pour les devs, pour les aider à améliorer un... tant soit peu l'état de l'art plutôt désastreux dans notre profession. J'ai aussi découvert qu'il n'y avait pas que Scrum dans la vie et que même Scrum, adopté de manière pragmatique et intelligente, pouvait apporter plein de choses positives aux équipes. Mais j'ai également pris conscience que l'agilité est surtout devenue un business particulièrement lucratif et que pour maintenir cette manne, on n'hésite plus à complexifier à outrance. Quand je vois des équipes entières, toutes les deux semaines, avoir autour de deux jours... intégralement banalisées pour des rituels, des réunions, je comprends plus. Où est la valeur client dans tout ce temps passé en réunion ? Où est la capacité à accueillir du changement ? Ces temps-là sont facturés, généralement très chers, et quand une objection est faite sur la pertinence d'en avoir autant de ces réunions, la réponse que j'ai le plus souvent entendue a été C'est Scrum, c'est comme ça. Si on le fait pas comme il faut, autant pas le faire. Alors attention, ne me faites surtout pas dire ce que je n'ai pas dit. Les réunions et rétrospectives Scrum peuvent réellement avoir une utilité, mais seulement quand l'équipe dispose de suffisamment de confiance, d'autonomie et de liberté pour pouvoir organiser un petit peu sa progression. Par contre, quand le contexte est moisi et délétère, et que l'équipe n'a aucun moyen d'influencer ce contexte-là, ces réunions n'aboutissent que très rarement sur des solutions applicables. Alors pour combler, pour compenser, on va ajouter d'autres réunions, d'autres rôles. Faire des ateliers de communication bienveillante, essayer de nouvelles méthodes de chiffrage, ajouter des nouvelles colonnes sur le board. Si vous n'avez jamais eu l'occasion de la voir, je vous invite vraiment à jeter un oeil sur la conférence d'Arnaud Lemaire qui s'appelle Et si on redémarrait l'Agile ? Dans cette conf, il y a une phrase qui m'a bien marqué et que j'aime beaucoup, c'est le plus de X pour résoudre X C'est un peu cette situation-là. On a un problème de process, d'organisation dans le projet, et du coup on va rajouter des éléments de process et d'organisation qui vont juste créer un cercle vicieux. de complexité procédurale et organisationnelle. A ce sujet-là, je pourrais facilement troller sur SAFE et ses schémas qui sont absolument stratosphériques, mais ça serait un peu facile. Revenons-en maintenant à la conversation dont je vous parlais au début de l'épisode. Nous avions une discussion sur l'agilité, et je commençais à en parler un peu avec le travers que je viens pourtant de dénoncer, à savoir, je parlais trop du process, avant le reste, et... Je vais essayer de vous paraphraser le plus fidèlement possible ce que m'a répondu mon pertinent interlocuteur. Ah tu sais, l'agilité, moi, j'y connais rien, j'ai rien lu à ce sujet. Mais sur nos projets, je t'assure qu'on est agile. On sait qu'on n'aura jamais un cahier des charges cohérent, alors on se pose autour d'une table et on réfléchit à ce qu'on pourrait sortir comme produit en trois semaines. Quitte à ce que les utilisateurs soient obligés de faire encore quelques trucs à la main. Du coup, en moins d'un mois, on leur met l'outil entre les mains Et tu peux être certain que dans la quinzaine, tu auras des demandes claires, précises, ciblées et mesurables. Et là, je suis resté quoi ? Bon, pas longtemps, parce que je suis bavard, mais... Mais que quelqu'un qui prétende ne rien connaître à l'agilité soit capable de synthétiser à ce point-là ce qui, pour moi, est l'essence même de l'agilité, ça m'a bluffé. Avec toutes ces formations, ces lectures, ces échanges avec des Scrum Masters, des coachs agiles... J'ai fini par intégrer des automatismes avec lesquels je ne suis pourtant pas totalement d'accord dans le fond. La valeur profonde de l'agilité est à mon sens parfaitement résumée dans sa réponse. Livrer de la valeur rapidement, disposer d'une proximité forte avec les utilisateurs finaux, pour pouvoir recueillir du feedback avec le moins de transformations ou de pertes possibles, pour pouvoir livrer à nouveau rapidement et entrer dans une boucle vertueuse. On pourrait ici argumenter qu'il manque une notion d'excellence technique. C'est une notion qui est abordée par Arnaud dans sa conférence, et qui est selon moi, tout comme lui, une condition indispensable pour supporter des changements de cap fréquents. Mais j'estime que quand on s'est livré très fréquemment en production, avec une bonne satisfaction utilisateur sur du moyen à long terme, je vais avoir tendance à présupposer que la qualité elle est là, forcément. L'exigence technique augmentant avec l'âge et la taille du projet, Si on reste capable de livrer rapidement, avec une bonne satisfaction utilisateur, c'est que l'essentiel est fait. En ayant à l'esprit ces valeurs-là, si aujourd'hui on devait vous vendre un poste dans une équipe qui se prétend agile, vous avez deux questions pour moi à poser pour vous assurer que l'équipe l'est vraiment agile. La première serait de savoir quelle est la proximité, la disponibilité, soit des utilisateurs finaux, soit des sachants métiers, ceux qui connaissent le business. La seconde question tourne autour de la fréquence de livraison. A quel rythme est-ce que vous livrez en prod ? Est-ce que vous livrez tous les jours, tous les mois, tous les semestres, deux fois par an ? Si on vous répond que pour avoir un utilisateur final, il faut attendre les trois livraisons par an et que toutes les demandes de l'utilisateur repassent par N couches de responsables, de chefs de projet, d'analystes... À ce moment-là, vous saurez qu'il est difficile, voire presque impossible d'être agile dans des conditions pareilles. Comment connaître le besoin ? Comment récolter du feedback quand il y a autant d'étages et autant de temps entre chaque itération ? Ça me paraît très très difficile. Pour moi, être agile, ce ne sera pas appliquer Scrum ou une autre méthode à la lettre. C'est surtout faire preuve de souplesse et de rigueur tout en gardant la finalité business en ligne de mire permanente. Merci d'avoir écouté cet épisode jusqu'au bout. J'espère vraiment qu'il vous aura plu. Si ce sujet vous intéresse, vous devez absolument voir la conf d'Arnaud Lemaire qui s'intitule Et si on redémarrait l'agile ? Je vous laisse le lien dans la description. J'aurai encore des tas de choses à dire sur l'agilité. Et le plus difficile pour moi était un petit peu de démarrer. C'est maintenant chose faite. N'hésitez pas à vous abonner pour ne rien rater des nouvelles publications. Pour information, Deezer a aujourd'hui quelques soucis et peut parfois avoir jusqu'à 24 heures de retard dans la publication de l'épisode, mais il est dispo sur d'autres providers. Il me reste à vous souhaiter une excellente semaine, à mardi prochain, d'ici là, geekez bien, je dis bien.
Présentez-vous.
Share
Embed
You may also like