MENU

Podcasts: SCRUM, méthodes agiles et ODM ?

Outils du Manager est-il compatible avec les méthodes agiles ? Oui, et je dirais même indispensable … Mais le plus simple est de demander à ceux qui ont expérimenté le mélange !

Olivier Thelu est un Manager, fervent utilisateur de la méthode SCRUM et des méthodes agiles. Et c’est aussi un manager qui utilise les méthodes de management d’Outils du Manager.

Il m’a semblé intéressant de lui demander de partager avec nous son expérience. Petite immersion dans le monde ésotériques des méthodes agiles … 

Episode 1
Présentation 
Point de vue d’un chef de projet sur les managers 
Décision de devenir un manager

Episode 2
La méthode SCRUM, c’est quoi ? Rugby etc

Episode 3
Le rôle du manager dans la méthode SCRUM
Le SCRUM, ça marche ?
Le choix terrible entre date et perfection
Aspects positifs et négatifs du SCRUM
Burnout, DISC, entreprise libérée 
Individualisation
Intérêt du 1 à 1
Des 1 à 1 mais pas des zeros et des uns !!!

Episode 4
Les effets de la méthode ODM
« Comment j’ai mis en place les 1 à 1 »
La semaine comme fréquence
Se retrouver leader alors qu’on était des collègues
Big bang théorie
Télétravail
Toujours le SCRUM et les 1 à 1
Un peu de « Libération » ?

9 commentaires

  1. Bonsoir,
    pratiquant la méthode agile Scrum depuis plus de 5 ans, j’ai constaté qu’une source d’échec et de frustation des équipes est que l’on confond souvent « Agilité » et « Frénésie ». Sous prétexte d’Agilité, on change tout en permanence et au bout du compte on ne produit plus grand chose avec ce Stop an Go à « haute fréquence ». J’ai vécu des sprints avec un Product Owner qui ajoute des nouvelles histoires en plein milieu du sprint, sans passage par le Backlog, avec l’argument qui « tue » : c’est cela l’agilité : s’adapter !
    Avez-vous vécu ce type de situation ?

    1. La réponse courte est : oui j’ai déjà vécu cette situation plusieurs fois et je pense que je la revivrai encore. Votre hiérarchie « traditionnelle » qui n’a pas pris le temps de comprendre ce que veut dire « pratiques agiles » ou « esprit agile » ni même « Scrum » dans votre cas, ne retient que ce qui l’intéresse. Le mot Agile est du coup assez dangereux car tout seul, il veut tout et rien dire. Il existe d’ailleurs ce site : http://www.la-rache.com/presentation.html qui décrit de manière très amusante, la « non méthode » qui se cache derrière beaucoup d’équipes / entreprises se prétendant « Agile ».
      Comment faire pour éviter de vivre ce genre de situation ? Je ne vais pas me risquer dans une réponse car chaque situation est très particulière. Peut être que Scrum n’est pas adapté à votre métier (il existe d’autres pratiques comme le Kanban par exemple), peut être que vos sprints sont trop longs, peut être qu’il y a trop peu de communication entre le Product Owner et l’équipe de développement etc..
      J’ajouterai juste que même si ça doit arriver le moins souvent possible, Scrum prévoit qu’une Itération soit « cassée » à cause d’une urgence.
      Voici des épisodes d’un autre podcast qui vous donneront peut être des indications
      http://leodavesne.net/2017/12/20/lpa-45-comment-travailler-avec-des-acteurs-externes-qui-ne-respectent-pas-scrum/
      Et à mon tour de vous poser une question, avez vous trouvé une autre méthode où vous arrivez à produire et où ce même « Product Owner » ne vient pas vous changer vos priorités tous les jours ?

    2. Bonjour Eric.

      Vous n’êtes pas le seul à rencontrer ce problème. Je l’ai pour ma part vécu également. Il met en évidence la difficulté de fonctionner en mode itératif dans un contexte (une organisation / entreprise) qui ne l’est pas.

      Un des principes fondamentaux de Scrum est que le périmètre d’une itération est défini lors de son lancement. Les développeurs ne doivent dévier de cette feuille de route qu’en cas d’événement majeur (notamment l’apparition d’un bug parce que le fonctionnement de la production est prioritaire). Cela signifie qu’il faut attendre le début de la prochaine itération pour que le nouveau besoin soit adressé. C’est évident que ce principe représente une contrainte forte pour le product owner.

      Votre product owner souhaiterait que vous soyez plus réactifs. En gros, pour le satisfaire, il faudrait fonctionner au jour le jour. Mais pour l’avoir vécu, on se retrouve vite dans une situation où ça part dans tous les sens, ce qui fait que la productivité est en chute libre. On est plus dérangés, on est moins sereins et moins concentrés sur ce qu’on fait, on ne prend pas le temps de finir les tâches parce qu’il faut tout de suite enchaîner sur quelque chose d’urgent, ça engendre des problèmes de qualité, et sur le long terme tout le monde y perd. Les épisodes de la série « le manager organisé » vont d’ailleurs dans le même sens que Scrum sur cette question-là, notamment au sujet de la gestion des interruptions. En développement les tâches durent très souvent plusieurs heures ou plusieurs jours et du coup l’échelle de temps est juste grossie par rapport à celle du manager.

      En plus de la « protection » de l’efficacité des développeurs pendant les itérations, Scrum permet d’avoir un minimum de visibilité sur le futur pour pouvoir s’engager sur des dates. Avec une équipe rodée (qui sait à peu près estimer le temps que prend chaque tâche et qui donc arrive bien à estimer ce qu’elle est capable de produire en une itération), on peut déjà à peu près compter sur le fait qu’à la fin de l’itération, les tâches qu’elle contenait seront prêtes. Et si le cap est stable (en gros si les priorités ne sont pas remises en question en permanence), on peut espérer une visibilité sur quelques itérations supplémentaires. Quand on fonctionne au jour le jour, peut-on vraiment se projeter dans le futur ? Il y a fort à parier qu’en plus d’une forte capacité d’adaptation, votre product owner attend de vous que vous teniez vos engagements sur les dates. Mais il veut un peu le beurre et l’argent du beurre.

      Le Scrum master est garant de la bonne application de la méthode Scrum et doit justement protéger son équipe des « assauts » du product owner ou de l’extérieur plus généralement. De tout évidence, il y a de temps en temps des événements nouveaux et imprévisibles qui justifient un bouleversement des priorités en cours d’itération. Mais ça ne peut être qu’à titre exceptionnel. Quand c’est fréquent, ça crée des grosses frustrations pour le product owner et le reste de l’équipe. Dans ce cas, il peut être pertinent de réduire la durée des itérations, à une semaine par exemple, pour donner plus souvent la possibilité de traiter des nouvelles tâches. Et si ça ne fonctionne toujours pas, il faut peut-être envisager de passer à une méthodologie encore plus réactive dans laquelle la notion d’itération est moins forte. Je pense par exemple à Kanban que je connais peu mais qui, à ma connaissance, est bien adaptée aux équipes de support ou de production qui doivent réagir rapidement à des événements non planifiables à l’avance.

      La méthode Scrum est en fin de compte une sorte de compromis entre adaptabilité et productivité. C’est appréciable quand on est développeur d’avoir un peu de visibilité sur ce qu’on va faire dans les jours / semaines qui viennent et de pouvoir travailler de manière sereine sur un sujet sans avoir à en gérer 10 autres en parallèle. Je suis persuadé que c’est beaucoup plus efficace et, comme il y a pas mal de profils DISC C chez les ingénieurs (selon l’épisode sur DISC), ça les met en plus dans une situation plus confortable et donc plus favorable. C’est en tout cas mon point de vue de développeur et il est évident qu’un product owner ne l’entendra certainement pas de cette oreille.

      L’équipe de développement doit être aussi réactive, bien sûr, mais dans une certaine limite pour rester productive. Le product manager doit, lui aussi, mettre un peu d’eau dans son vin et essayer d’anticiper ou de planifier davantage. Il m’est arrivé plus d’une fois de devoir arrêter tout ce que je faisais pour traiter d’urgence une tâche et apprendre par la suite que ça faisait un mois qu’on savait qu’on avait besoin de cette tâche pour cette date mais que ça n’avait juste pas été anticipé. La meilleure façon de gérer les crises c’est sans doute de faire en sorte qu’elles n’arrivent pas quand c’est possible.

      On parle là du développement logiciel, mais je suppose que cette question se pose d’une manière bien plus globale dans tous les métiers.

      Voilà pour mon point de vue de développeur. Vous noterez que j’ai eu du mal à maîtriser ma composante C et que j’ai donc écrit un roman…

      Longue vie à Outils du manager !

      Benoit

  2. Bonsoir,

    merci à tous les deux pour ces deux réponses : je ne pensais pas susciter autant de prose !
    Merci également pour la méthode larache (bien connue, mais que j’avais oubliée) et surtout le podcast agile (moins drôle, mais plus utile)
    Mon domaine est également le développement logiciel, dans une entreprise utilisatrice.
    Dans mon environnement de travail, le côté « protection des équipes » des perturbations n’est pas bien très bien vu car c’est compris comme un manque de réactivité par rapport aux autres équipes qui « elles, sont en face du client » : le classique fossé entre les informaticiens et le reste de l’entreprise (voir épisode 3 !). Ce n’est pas parce qu’on est pas en face du client que l’on n’est pas concerné. Pour tout informaticien, l’effet papillon est tout sauf un mythe.
    J’ai eu un temps le même rôle qu’Olivier et pour gérer les perturbations (Bugs, demandes urgentes), je négociais le niveau d’urgence. Il y avait une tâche « urgence » de 2 jours pour chaque équipier (pour un sprint de 3 semaines). Cela marchait pas mal, mais tout est devenu plus ou moins urgent et cela a malheureusement fait perdre tout intérêt au backLog qui permet justement de regrouper et de prioriser les demandes.
    Je pense avoir perdu ce « combat » contre cette frénésie et c’est une source de de stress et de frustration (on est toujours en retard) pour tout l’équipe. Tout le monde n’a pas écouté le podCast « Le sens de l’urgence » !
    Malheureusement, on arrive très vite dans un cercle vicieux : même ce qu’on arrive à délivrer, on n’a pas le temps de le montrer et l’expliquer aux clients (internes ou externes). Cela multiplie les demandes de support (« C’était mieux avant »). Et je ne parle pas des bugs (pas le temps de tester) ou des fonctionnalités qui ne conviennent pas à l’utilisateur (pas le temps d’analyser le besoin)
    Le Scrum Master a maintenant changé et il est plutôt le représentant de la hiérarchie que de l’équipe. Cela ressemble à du management traditionnel « à l’ancienne ».
    J’ai une question. Les équipes Scrum doivent être autonomes et maîtriser leurs outils. Or ceux-ci, notamment en informatique, évoluent sans cesse. Et il est aussi intéressant d’en adopter de nouveaux. Comment faîtes-vous Avez-vous à côté de l’équipe Scrum une autre équipe type « bureau technique » ? Pour chaque sprint, du temps est-il réservé à chacun pour faire de la veille techno ? Avez-vous des histoires « techniques » dans les sprints, afin de rechercher/évaluer/intégrer de nouveaux outils ?

    J’attends avec impatience le #4

    1. Je confirme que dans les grosses organisations, quand le Scrum Master n’est pas affecté à plusieurs projets en paralèlle (ce qui est tout à fait possible), il est souvent délégué au reporting à la hiérarchie et/ou au client. Car les gros clients adorent le forfait, mais aiment choisir les équipes du fournisseur (montrez moi les CV…mais vous avez acheté un livrable?!), adorent faire remonter des KPIs (surtout s’ils sont verts) et adorent que les méthodes agiles s’adaptent à eux plutôt que le contraire. Par exemple, le Product Owner est censé être une personne unique, pas une équipe, mais dans des organisations complexes, c’est souvent un fournisseur qui assure cette tâche, sur les ordres d’un client. Qui lui même est soumis à sa hiérarchie.

      Savoir dire non devient le vrai signe de l’agilité !

    2. Quelques questions me viennent en vous lisant (en espèrant que ça vous aide sur la voie d’une solution): Vous êtes surchargés de travail et les livraisons ne sont pas à la qualité attendue.
      1/ Est-ce que la durée de vos sprints vous parait adaptée à la vélocité de l’équipe?
      2/ Les estimations faites en poker planning sont-elles fiables, discutées par des experts?
      3/ La Definition of Done est-elle assez précise et exigeante pour éviter les demandes au support. Y-a-t’il quelqu’un en charge de la gestion du changement et de la communication ? (Pour éviter le fameux: ça marche pas, c’est un bogue! Non, c’est la fonctionnalité…)
      4/ Si le Scrum master est « du côté de la hiérarchie », on peut lui rappeler qu’il a le rôle d’évangéliste Scrum au sein de la structure et lui demander comment il s’assure que TOUTES les parties prenantes savent comment fonctionne l’Agile…

      Une chose est sûre: en Agile, la Dev team est très motivée et à tendance à vouloir en faire trop, surtout dans les premiers sprints. Mais normalement, c’est géré: si on a pas fini une user story, on la reporte sur le sprint suivant. Or, beaucoup de Product Owner croient que le Sprint backlog est gravé dans le marbre. NON, les premiers sprintss ervent à calculer la vélocité de l’équipe et à calibrer le mode d’estimation être de plus en plus fiable dans ses estimations de charge et donc dans les engagements du sprint.

      Car cela a été dit dans le podcast, pour le métier, c’est compliqué de ne pas avoir un planning « sur et définitif » (comme si c’était jamais le cas :-)) des fonctionnalités qui seront livrées.

      La pression est importante sur le Product Owner, dans ce cas, puisqu’il gère les parties prenantes du Métier, et il ne se gène pas pour la remettre sur la Dev team…parce qu’au final, son évaluation annuelle dépend de la réussite du projet…

    3. Bonjour,
      Une nouvelle fois, je n’ai pas de réponses toutes prêtes pour vous. Je ne suis pas dans votre environnement et je ne suis pas un coach spécialisé de Scrum. Juste un « amateur ».

      Donc, si je comprend bien, Scrum ne se passe pas bien chez vous sans que je tente de juger le pourquoi. Si vous souhaitez en parler de manière plus fluide : @othelu sur twitter ou LinkedIn par exemple et ensuite on trouve du temps pour une discussion. Ce n’est pas mon métier mais j’aime discuter avec les gens, et je le fais avec plaisir pour qu’on tente de mieux vivre dans nos entreprises (service gratuit, donc je le fais aussi si j’arrive à trouver le temps 🙂 )

      Vous avez aussi des questions concrètes, je vais donc tenter de répondre avec une nouvelle fois, uniquement mon expérience personnelle.

      Pour le ScrumMaster qui est en fait un Middle Manager déguisé, je peux en parler, c’est mon cas ! L’important est de bien comprendre à quoi on sert. L’entreprise veut que l’équipe dont je m’occupe produise de la valeur. Et moi je fais en sorte de créer un cadre qui le permet. Ma croyance forte est que j’obtiendrai de la valeur de mon équipe si les humains qui la composent se sentent impliqués et reconnus.
      Ce cadre me demande d’être un vrai ScrumMaster pour eux et non pas un chef. Ce n’est pas tout simple, c’est effectivement une double casquette mais je pense que quand on a bien compris le rôle d’un ScrumMaster alors on n’essaye pas de faire le petit chef. On ne garde le pouvoir d’autorité que pour des cas exceptionnels (cf l’épisode de ODM sur les formes de pouvoir: https://www.outilsdumanager.com/podcasts/les-3-formes-de-pouvoir-dans-lentreprise/, placement produit en passant !). Je ne sais pas comment est votre ScrumMaster mais je sais comment il devrait être : au service de l’équipe.
      La direction a besoin d’un reporting ? il faut la comprendre. Est-ce au ScrumMaster de faire ce reporting ? je ne pense pas. L’équipe peut s’organiser ensemble pour fournir un reporting sur ce qu’elle fait et ainsi libérer le ScrumMaster de cette charge => l’équipe montre qu’elle est responsable et impliquée dans l’entreprise et le ScrumMaster se sent aussi plus intégré à l’équipe.

      Pour les perturbations (et plus particulièrement les bugs), pour nous plus de débat, un bug c’est mal, ça n’a pas le droit d’attendre. Nous nous sommes inspirés de cet article et nous avons mis en place le « zero bug » : https://medium.com/quality-faster/the-zero-bug-policy-b0bd987be684
      C’est une grosse perturbation au début mais ensuite, c’est une discipline régulière mais peu couteuse. Du coup, chez nous, si un bug critique arrive, on s’en occupe immédiatement. Si un bug normal arrive, on s’en occupe dès que possible (au pire un jour plus tard). Ne pas nous en occuper génère au final des perturbations bien plus importantes. Donc c’est de l’investissement.
      Bien entendu, il faut aussi faire du code de qualité pour ne pas produire des bugs tout le temps ! C’est plus facile à dire qu’à faire mais il existe plein de bonnes pratiques pour y arriver.

      Et pour votre dernière question (ou vos dernières questions car je vois au moins deux sujets).
      La veille techno ? Oui c’est important, c’est aussi de l’investissement, donc tout le monde en fait. Comment ? ça dépend des gens, des caractères, de notre manière d’apprendre. L’important c’est d’en faire, les moyens ne manquent pas et les personnes de mon équipe savent qu’elles peuvent prendre du temps pour en faire.
      De plus, on va voir des conférences, on va à des meetups, on se fait des présentations entre nous etc..
      Nos outils ? oui on s’en occupe. On les fait régulièrement avancer en version (ou on les remplace si nécessaire) et dans ce cas, oui ce sont des stories du backlog.

  3. Bonjour
    En fait , en pratiquant SCRUM depuis 3 ans dans mon entreprise de développements de logiciels (+70 ingénieurs ) , j’ai constaté que scrum ne s’adapte pas a toute les situations. J’ai essayer Kanban , c’est aussi Agile, avec moins de règles , et en combinant les 2 méthodes ca marche mieux .
    Actuellement j’ai introduit ODM aussi , et je constate de plus en plus des amelioration dans les équipes de travails

    Merci
    Nizar

Laisser un commentaire
Pour accéder au contenu complet du site (podcasts, videos et documents à télécharger), il faut vous connecter
cc5209788dd0943cc326aa33ec12146f########