lundi 25 juillet 2011

Chef de projet ScrumMaster ... Arg !

Mission "Chef de projet ScrumMaster"

Il y a plusieurs semaines, j'ai vu passer une annonce de mission intitulée "Chef de projet ScrumMaster". Interpellé par l'intitulé, j'ai consulté l'annonce. La personne recherchée devait :
  • piloter l'équipe
  • faire l'interface entre l'équipe et les clients
  • faire du reporting à la hiérarchie
  • etc ...
Bref, toute la panoplie d'un "Chef de projet" et rien à voir avec un ScrumMaster

"En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?"

Lors de récentes formations, ou plutôt "informations" (je préfère ce terme) sur l'Agilité et Scrum, systématiquement, la question ressortait : "En fait, le ScrumMaster c'est l'équivalent d'un chef de projet ?" ...

STOP !

Et oui, STOP ! Arrêtons de chercher des comparaisons avec les méthodes classiques. Le rôle de ScrumMaster n'a pas d'équivalent dans ce que nous pouvions connaitre avant l'agilité.

Le ScrumMaster s'assure que le cadre Scrum est respecté, que l'équipe est opérationnelle, fonctionnelle, productive, que l'équipe met et peut mettre en oeuvre tous les moyens d'organisation et techniques pour assumer ses engagements de production, c'est un facilitateur, un accompagnateur, un protecteur, il anime les différentes réunions, il s'assure de la collaboration étroite entre les intervenants, il veille au respect des rôles de chacun, il intervient dans l'organisation pour accompagner le changement, il expose les contraintes et les problèmes de mutation, etc ...

Il n'est pas question de diriger l'équipe, de distribuer les tâches de développement, de faire les choix techniques et technologiques, de faire du reporting, de faire l'interface avec le client pour évaluer ses besoins, etc ...

Certes, le ScumMaster peut également être un développeur et faire partie des équipiers, il intervient alors au même titre que les autres membres de l'équipe pour les estimations, les choix, la vision d'architecture, etc ... Il peut prendre en charge la mise à jour du Scrum Board (Sprint backlog, burndown chart, etc ...) mais à titre "moteur", ça n'est pas forcément à lui de faire cela !

Donc, le ScrumMaster n'a rien à voir avec un chef de projet.

Pour conclure, et pour ceux qui se demanderait ce que devient le chef de projet lors d'une transition vers l'agilité, certes il peut devenir ScrumMaster, mais en oubliant son rôle précédent, et à condition d'avoir de bonnes aptitudes pour ce nouveau rôle très orienté sur les aspects humains. Personnellement, je constate que bon nombre de chefs de projet feraient plutôt de bons (Proxy) Product Owner par leur connaissances du métier, leur relationnel avec le client et les utilisateurs !

17 commentaires:

  1. Finalement, cela n'est-il pas très révélateur (on change juste les titres pour dire qu'on fait de l'agilité parce que cela fait bien, sans changer le fond) ?

    Est-ce qu'un ScrumMaster (comme tu le définies) peut travailler dans une organisation qui n'a évoluée (dans le même sens) ?

    RépondreSupprimer
  2. Bonjour Rémy et merci pour ta réaction !

    Oui, malheureusement, cette approche fait partie de pratiques laissant croire à un contexte agile : nous sommes agiles parce que nous avons un (chef de projet) ScrumMaster, parce que nous avons un tableau blanc avec des post-its, parce que nous faisons un standup tous les matins, etc ... Mais ceux qui ont l'expérience de l'agilité réussie le savent : c'est tout autre chose !

    Anecdote : lors d'une formation ScrumMaster que je suivais, il y avait un groupe de "chefs de projets" envoyés par leur boite, ils arrivaient sans aucune idée de ce dont il était question, leurs discussions "pause café" laissaient comprendre leur mépris pour ces geeks de développeurs, et en fait, leur boite les avait envoyés là pour que tous les projets passent en mode agile au 1er du mois suivant .... :-(

    RépondreSupprimer
  3. Est-ce que le ScrumMaster peut vraiment être un developpeur ? Il me semble qu'il peut y avoir conflit d'intérêt dans le cadre de certaines activités (je pense en particulier au planning poker)

    RépondreSupprimer
  4. Salut Jean et merci pour ta réaction,

    C'est effectivement une bonne question. Idéalement, non, il est préférable de bien séparer les rôles.

    Toujours idéalement, le ScrumMaster n'a aucun autre rôle dans l'équipe, et il est dédié à cette équipe, il passe tout son temps avec elle, dans la salle commune de travail, pour entendre et suivre ce qui se passe, y compris au niveau relations humaines entre les équipiers. Il peut alors animer au mieux les sprints plannings, les revues, et surtout, les rétrospective avec une position neutre.

    Mais concrètement, un tel ScrumMaster ne sera pas occupé à temps plein, sauf peut-être en début de projet. Il ne va donc pas rester les bras croisés, certains n'apprécieraient pas ... ;-)

    Il peut donc suivre plusieurs projets, mais cela présente des inconvénients. C'est tout de même une solution gérable.

    Et pour répondre à ta question, le ScrumMaster peut également être un équipier, mais comme tu le soulignes, ça peut présenter des difficultés. Pour moi, ce sont les 2 seuls rôles cumulables de Scrum, ScrumMaster et équipier, mais attention, ça n'est pas facile et demande du recul pour bien distinguer son rôle lors de ses différentes interventions. J'ai moi même été dans cette situation, c'est faisable, mais à gérer avec précautions ...

    RépondreSupprimer
  5. Jean, je ne crois pas qu'il puisse y a avoir de conflit d'intérêt. Et surtout pas lors du planning poker.
    Ton commentaire laisse à penser que le scrum master aurait intérêt à diminuer les estimations, par exemple. Ce n'est pas le cas. Tous les membres de l'équipe devraient avoir le même intérêt, le même objectif : faire aboutir le projet, dans les meilleures conditions possibles. Il faut à tout prix sortir de la logique : le chef, le scrum master, le product owner veut moins de jours hommes, les développeurs en demandent/consomment plus.
    Un des avantages du SM équipier, c'est qu'il comprend bien les problèmes de l'équipe. L'inconvénient, c'est qu'il a peu de recul.
    Je crois qu'il n'y a pas de règle. Cela dépend des projets, des SM et des équipes. Des hommes, quoi...

    RépondreSupprimer
  6. Effectivement, pas vraiment "conflits d'intérêts", mais de réelles difficultés je pense, le ScrumMaster a un véritable rôle "humain", intervenant entre autre sur les relations entre les personnes, pour que "ça roule", et s'il est partie pris, ça peut être compliqué ...

    Par exemple, j'ai animé des rétrospectives dans les 2 situations, ScrumMaster équipier ou non. C'est clair, le fait de ne pas être équipier facilite le rôle et permet vraiment de prendre du recul, et d'animer les échanges de façon totalement neutre !

    Par contre, concernant les chiffrages, le "pure" ScrumMaster n'a qu'un rôle d'animation pour aider les équipiers à estimer, et, avec le Product Owner, planifier correctement chaque itération avec un véritable engagement ! Comme le dit Thierry, le SM n'a aucun intérêt dans les estimations, ni dans un sens, ni dans l'autre, neutralité totale : ça n'est pas un chef de projet !!! ;-)

    Jean, à quoi pensais-tu concrètement ?

    RépondreSupprimer
  7. Bonjour Xavier,

    Je partage bien sûr la conclusion générale et les arguments présentés : la posture du ScrumMaster est différente de celle du chef de projet (traditionnel).

    Pour autant, à la simple lecture du post, il est difficile de comprendre précisément le contexte de l'annonce : la personne en charge du recrutement a-t-elle été briefée sur le rôle du SM ? L'organisation autour de l'équipe projet est-elle aussi en cours de transition vers l'agilité ? Ou est-ce purement et simplement du "marketing agile" ?

    Il est d'expérience très compliqué de transformer d'un seul coup l'environnement autour de l'équipe projet, dès le premier jour du premier sprint. Les interactions avec cet environnement (interface client, reporting mgmt ...) doivent continuer d'être assurées. Une solution triviale est en effet d'en confier la responsabilité au SM.

    Les commentaires de blog ne sont malheureusement pas le meilleur endroit pour développer un argumentaire approfondi. Mais voilà une idée à creuser pour un de mes prochains posts.

    Romain Vignes
    @rvignes

    RépondreSupprimer
  8. Obligé de faire en 2 commentaires : c'est trop long :)

    Pour commencener, je me considère comme un développeur, donc un équipier, plutôt qu'un Product Owner. J'ai beaucoup lu sur les sujets agiles et j'ai reçu deux formations sur scrum, dont la certif scrum master avec Sutherland(la certif vaut ce qu'elle vaut,mais il y a des choses à apprendre). Par contre je n'ai encore jamais réussi à pratiquer pour l'instant, mes remarques sont donc spéculatives.

    Cependant elles se basent aussi sur des observations : ans mon expérience, dans tous les groupes humains que j'ai vus, travail ou pas travail, un ascendant naturel émerge. Cet ascendant aura des tendances dominantes sur le reste du groupe. Je considère que même si scrum inclus des mécanismes contre l'émergence d'un tel ascendant, il finira quand même par venir.
    D'autre part, il est très difficile de se remettre en cause sans influence extérieure et nous ne sommes pas des êtres parfaitement rationnels.
    Un developpeur prends en permanence des décisions ( plus ou moins importantes) lorsqu'il travaille c'est une personne de jugement.

    A partir de là, en partant de l'hypothèse que le scrum master est un membre de l'équipe.

    Lors d'une phase de planning poker, l'équipe a reçu le backlog, détaillé les story avec la priorité la plus haute en fonction de sa compréhension. Mais la communication humaine quelque soit sa forme reste désespérément imprécise. L'équipe a donc une certaine vision de la tâche qui lui est demandée. Le product owner potentiellement une toute autre.

    - Si le scrum master est l'ascendant, la vision de l'équipe est probablement assez proche de la sienne, il sera donc très difficile pour lui de remettre cette vision en cause lorsque le product owner demandera pourquoi le chiffrage est si important alors que la fonctionnalité lui paraissait simple.
    Un SM extérieur et neutre aurait pu servir de référentiel de bon sens en penchant dans un sens ou dans l'autre. Il peut servir d'arbitre lorsqu'il y a un conflit entre la vision du PO et celle de l'équipe.

    - Si le SM n'est pas l'ascendant de l'équipe, dans le même cas que ci-dessus, il aura peut être un vision différente de celle de l'ascendant. Cependant si il penche dans le sens du PO en remettant en cause cette vision, il viole la hiérarchie implicite qui s'est formée dans l'équipe. Je pense que cela peut mener a des conflits larvés dévastateurs.

    - en dehors de la notion d'ascendant : si le PO remet en cause la vision de l'équipe et que le SM est un membre de l'équipe, il sera difficile de ne pas considérer que le PO remet en cause la vision du SM en plus de celle de l'équipe. le SM perd donc sa neutralité.

    - Enfin : imaginons que l'équipe ait une story technique a pousser, sans valeur fonctionnelle immédiate. Potentiellement sans valeur tout court, mais super "cool" à faire saliver tous les membres de l'équipes (donc y compris le SM). Que peut faire le PO alors que la loyauté du SM est déjà acquise à la story ? il se retrouve a challenger l'équipe et le SM, sans avoir le filet d'un arbitre neutre entre les deux.

    RépondreSupprimer
  9. J'ai pris les exemples de la vision lors du chiffrage mais ces problèmes peuvent se retrouver dans plusieurs activités. Dernier point : pour moi le SM a un rôle important dans l'élaboration du backlog, dans la plannification des releases, dans la préparation des activités scrum et dans la production des indicateurs de l'équipe (même si il y a des outils qui permettent de gagner du temps pour certaines choses). Il est aussi censé servir de tampon entre le monde extérieur et l'équipe. Il garanti que l'équipe n'est pas interrompue pendant le sprint. Si il est membre de l'équipe, c'est lui qui sera interrompu, son travail avancera donc nettement moins vite que celui des autres, il y a le risque de devoir bâcler ou abandonner une tâche commencée.

    Dans une équipe qui se connait bien, qui travaille avec son PO depuis un bon moment. si tout le monde connait bien les principes de scrum, que le gros des tâches est automatisé => c'est peut être possible. Si le PO est un MOA ancienne école nouvellement formé, que l'équipe vient d'être formée plus ou moins de bric et de broc pour le projet avec des gens plus ou moins rôdé à SCRUM: ça me parait risqué.

    Dernier point : Si le scrum master est dans l'équipe, que scrum est nouvellement mis en place, voir en pilote dans l'entreprise. Le PO sera probablement une personne de la MOA ou du métier qui se retrouvera confronté à ce qui restera dans sa tête une équipe MOE. Les anciens clivages resteront présents et ils sont parfois violents :(

    Encore une fois je n'ai jamais pratiqué les méthodes agiles professionellement. Mais j'ai observé ces phénomènes dans tellement de groupes que j'ai du mal à imaginer que ça ne risque pas d'arriver. Les conflits de jugement sur des éléments aussi abstraits qu'un programme informatique sont nombreux (il n'y a qu'a voir la "guerre" scala/ceylon, il manque un modérateur neutre qui n'aurait pas d'intéret direct dans l'affaire)

    Pour moi le SM exterieur à l'équipe sert donc de modérateur neutre, ayant l'autorité de pousser l'équipe et/ou le PO à se remettre en cause lors des séances. Il sert aussi de paratonnerre/bouc émissaire permettant à un camp ou à l'autre de changer sa vision sous pretexte que le SM aurait du détecter l'écart mais que puisque ça n'a pas été le cas on va essayer de faire au mieux. Ca offre une porte de sortie "honorable" aux égos dont le jugement est remis en cause. Enfin il n'appartient pas aux rôles habituels et ne peut pas y être assimilés, les anciens clivages n'ont pas cours pour lui.

    Le SM sait que c'est son rôle et n'a pas d'intérêt particulier dans le projet, il peut donc servir d'excuse à la rationalisation du comportement. Du coup le PO et l'équipe sont à même de communiquer plus sereinement.

    Voilà, j'essaye encore de me trouver une place sur un mission qui pratique vraiment l'agile (et pas juste un paperboard avec des post-it et un tampon agile donné par le commité méthodologie) avec un vrai PO. Pas encore trouvé et la société qui m'accueille actuellement n'est pas très ouverte à ça.

    RépondreSupprimer
  10. @rvignes : le corps de l'annonce de recherche d'un "Chef de projet ScrumMaster" montrait clairement un manque de connaissance sur le rôle du ScrumMaster. A part le titre de l'annonce, et une phrase de conclusion commençant par "Vous aimez l'agilité, ...", le reste était totalement une annonce "pur chef de projet". Ca sentait malheureusement "l'agilité d'apparence" ...

    @Jean : merci pour ces longs retours !

    Les formations sont intéressantes et indispensables. Mais l'agilité s'apprend surtout par la pratique. Il m'a fallut quelques années de pratique pour avoir la vision que j'ai aujourd'hui (je ne dis pas qu'elle soit bonne ou aboutie ...), et tous les 6 mois, j'ai l'impression de me (re)dire : "Ah ça y est, j'ai compris !" ... ;-) ... Je te souhaite vraiment de trouver matière à pratiquer, mais l'effet de mode ne facilite pas la vie de l'aglité.

    Pour en revenir au rôle de ScrumMaster, il doit être un accompagnateur, un facilitateur, un coach : ce dernier point signifie qu'il ne "fait" pas, qu'il ne "montre" pas, mais qu'il "amène" les gens vers les bonnes pratiques, par leurs propres expériences, leurs propres observations, leurs propres auto-amélioration. C'est ce que j'essaie de faire en coaching.

    Pour moi, idéalement, l'objectif du ScrumMaster est de devenir inutile. Si, si ! ;-) Cela voudrait dire que l'équipe est autonome, dans de bonnes pratiques de Scrum, et plus largement, que toute l'organisation (entreprise), autour de cette équipe, est dans la bonne dynamique (ex : plus de remise en cause des choix techniques de l'équipe, de ses estimations, plus de perturbations extérieures, etc ...). Mais bon, ça reste un objectif pour illustrer le cadre d'intervention du SM.

    Pratiquement, le SM va avoir du boulot, surtout au début du projet. Bien sûr, au niveau relations humaines, aspect trop souvent négligé. Mais également de façon pratique, il peut donc prendre en charge certaines tâches pour "aider" l'équipe dans sa mutation, mais ça doit rester transitoire !

    Pour revenir à nos échanges, le SM n'a donc normalement pas de "vision" (= point de vue) sur le projet, les histoires, les choix techniques, etc ... Là où le SM fera forcément bien son cadre, c'est lorsqu'il accompagne une équipe sur un projet qu'il ne connais pas. J'ai expérimenté cette situation, contrairement aux préjugés, c'est finalement plus "facile" pour bien rester proche du rôle de SM. Dans ce contexte, si le rôle du SM est difficile, c'est qu'il y a erreur sur son intervention (trop d'attentes par rapport au projet lui-même, donc hors champ d'intervention prévu).

    Tu comprendras alors que, à l'extrême (en matière de connaissance du projet), si le SM est également équipier, voir pire, est un leader ou un expert technique du produit, il y a alors fort risque de mélange des rôles avec de grosses difficultés pour être un "bon" ScrumMaster ....

    Dernière remarque sur les histoires techniques : normalement, il n'y a pas d'histoires techniques. Le "Sprint 0" est là pour mettre en place le contexte et les outils de développement (IDE, serveur VCS, intégration continue, ...). Ensuite, il ne devrait y avoir que des histoires fonctionnelles. Chaque histoire doit pouvoir être justifiée et surtout montrée au PO, donc avoir une raison fonctionnelle. Ca surprend, je suis d'accord. Je suis moi aussi passé par une phase d'incompréhension sur ce point, mais finalement, c'est bien ça. Et surtout, l'équipe n'est pas là pour saliver ou développer des trucs cool, elle est là pour répondre aux attentes fonctionnelles du PO, et tant qu'à faire, se faire plaisir (à ne pas négliger mais ne pas confondre). ... ;-)

    [Privé]@Jean : contacte moi en direct pour me dire où tu es basé, j'ai connaissance de postes de SM ...[/privé]

    RépondreSupprimer
  11. Je pense que nous sommes tout à fait d'accord sur le rôle du scrum master :)

    Par contre pour les story technique je ne suis pas convaincu.

    [Le "sprint 0" est là pour mettre en place le contexte et les outils de dev]. Il n'y a aucune raison pour que ce contexte soit définitif, pour que de nouveaux outils ne soient pas nécéssaires en cours de projet, etc. Exemples indépendants de la volonté de l'équipe : Fin de vie du serveur d'application ou de la version de la JVM. Il faut alors faire une migration, cette migration n'a aucun intéret fonctionnel du point de vue de l'utilisateur, elle n'apporte aucune nouvelle fonctionnalité. On pourrait argumenter qu'elle empêche d'en enlever mais je trouve ça tiré par les cheveux.
    Exemples liés à l'équipe:
    - Même une équipe très compétente va accumuler de la dette technique, comment gérer cette dette et les éventuels refactorings nécessaires ? tu les cache dans des story utilisateur ? mais dans ce cas le coût des story risque de devenir instable et de provoquer de l'incompréhension.

    - Un nouveau membre rejoint l'équipe (il ne faut pas réver même dans une équipe agile il y aura du mouvement, moins que dans une équipe classique peut être mais quand même). Il apporte avec lui son bagage technique, il connait peut être une meilleure technique de tests par exemple. Si l'équipe utilise cette technique de test, elle gagnera 20% de productivité. Là encore l'utilisateur final ne verra rien du tout, mais la migration de la suite de test existante peut nécessiter du temps. Quelle story porterai ce temps ?

    RépondreSupprimer
  12. Bonjour,

    Afin de clarifier les postes dans Scrum j'ai commencé à rédiger un contrat type des différents engagements :

    https://docs.google.com/document/pub?id=1PZ-6NCNfm-iVsHCi6t64sT2-rMzBO6iEnmKzvQtaZjs

    n'hésitez pas à faire des commentaires et des retours sur ce travail :)

    RépondreSupprimer
  13. @Jean : oui, je crois que nous sommes pas mal en phase sur le rôle de ScrumMaster.

    Ce qui me surprend, c'est que je me retrouve à échanger avec pas mal de personnes surprises des mauvaises mises en oeuvre de Scrum, et malgré tout, ces mauvaises mises en pratique semblent être de plus en plus nombreuses ... Où est le problème ? Effet de mode ? Manque de formations, d'informations ? Manque d'accompagnement ? Pourtant, cet accompagnement est tellement indispensable, rentable, et gage de réussite ... Faites appel ou faites faire appel à des personnes expérimentées, ayant pratiqué, passionnées, et qui ont envie de partager !

    Pour les histoires techniques, je suis en partie d'accord avec toi. Dans la vraie vie, difficile de faire sans, mais elles doivent rester marginales. Le ScrumMaster doit faire attention à ce que les histoires restent le plus fonctionnelles possibles, avec l'approche du "montrable" au PO (qui n'est pas un technique).

    Exemples. Pour un serveur HS, d'accord. Pour une migration de version, en tant que coach agile, je demanderai à l'équipe de me le justifier fonctionnellement ... ;-)

    Quant aux refactorings, c'est une erreur classique de mise en pratique de l'agilité. J'ai connu cette situation où, en tant qu'équipiers, nous devions justifier d'un "gros" refactoring. Avec le recul, je comprends maintenant qu'il était devenu gros car toujours repoussé à plus tard. Il aurait du être fait dès son apparition, lorsqu'il était mineure, plus facile à justifier, et donc lié à une histoire fonctionnelle.

    Une autre erreur amenant à la nécessité d'un gros refactoring, est le manque de "vision" lors des phases importantes du projet (démarrage ou autre). Il est dit qu'on ne doit pas spécifier le produit dans ses détails, et du coup, on ne réfléchit plus à grand chose. Hors, il faut avoir une "vision" de ce qu'on veut obtenir pour pouvoir faire les choix technologiques et d'architecture qui nous permettront de mener à bien le projet, en évitant des remises en question importantes !

    Pour ton dernier exemple, l'amélioration de l'équipe est et doit être continue. Par exemple, elle doit petit à petit migrer vers des pratiques d'ingénierie agile, comme le TDD. Ca ne se fait pas du jour au lendemain, mais ça ne se fait pas non plus sur 1 histoire. Ca se fait vraiment petit à petit et ça doit rentrer de façon globale dans les estimations, sur plusieurs sprints, et bien sûr pas sur une seule histoire.

    @Luc : merci pour ce partage !

    Peux-tu nous en dire plus sur les raisons d'être de ce document ? Dans quel cadre et pour quels objectifs tu le réalises ?

    Je ne m'arrêterai pour l'instant que sur le rôle du ScrumMaster (par rapport à mon billet initial, mais nous pourrons évoquer les autres rôles une autre fois).

    Oui, le ScrumMaster initie l'équipe à Scrum, lui fait respecter le cadre, la fait monter en compétence. Par contre, ce n'est pas à lui de tenir un backlog de problèmes ou mettre à jour le burndown chart. Certes, il peut le faire un certain temps pour montrer l'exemple, montrer l'intérêt des différents artefacts, mais au final, ça doit être de la responsabilité collective de l'équipe pour qui ça doit devenir indispensable (signe de réussite ...) ! En revanche, je suis d'accord sur les points de communication entre les acteurs, et également s'assurer que les indicateurs sont compris de tous.

    Encore une fois, c'est l'équipe qui a la responsabilité de mettre en oeuvre les moyens techniques pour sa meilleure production (tests, TDD, intégration continue, bug tracking, indicateurs) et le ScrumMaster peut être moteur, surtout en début d'agilité.

    Tes derniers points concernant le manager sont intéressants, surtout le dernier.

    RépondreSupprimer
  14. Très très bon! Je suis mort de rire (j'aurais pu pleurer si je n'avais pas été d'humeur)

    RépondreSupprimer
  15. Salut Johan !

    Content de t'avoir fait rire, mais qu'est-ce qui t'a tant plu ?

    Sur le fond, ça me rend triste ... Voir encore hier soir le tweet de @cascrum avec ce lien http://t.co/QxZKNUwF ...

    RépondreSupprimer
  16. Typiquement le type de poste où j'ai débarqué:

    Au début scrum pur et dur mais si possible avec exp cdp, puis maintenant on me dit au bout de 1 mois et demi alors que l'on est dans les clous : que je ne suis pas assez chef de projet.

    Mon premier retour d'expérience est qu'à ce jour aucune boite ( en tout cas aucune boite un peu grande) en France n'est capable de comprendre SCRUM.

    A croire qu'ils veulent soit suivre la mode, soit que cela se plante pour justifier d'un retour en arrière.

    Je n'ai que peu d'éléments de comparaison avec l'étranger mais je pense que l'écart va s'aggrandir encore entre nos sociétés Franco rigide tout sauf agile et les autres.

    en ce qui me concerne j'envisage de terminer la mission et quitter la SSII où je suis ...

    RépondreSupprimer
    Réponses
    1. Salut Damien,

      Merci pour ton retour et ton témoignages, et désolé pour toi et pour cette mauvaise expérience dont tu sauras, j'espère, tirer les enseignements. Mais je vois que tu as commencé puisque tu envisages le changement ... pour toi-même ! Comme dirait l'autre "chosse your boss !". Nous, développeurs, arrêtons de subir un certain système. Tu peux avoir le choix, mais oublie certaines SSII et oublie les offres, va à la rencontre des bonnes boites !

      Et concernant l'agilité et Scrum, c'est possible, et ça marche ! il y a plein d'exemples, mais c'est sûr, faut que ce soit compris et bien appliqué, et ça c'est pas toujours gagné ...

      Supprimer