Bienvenue sur Développement Agile

Référence sur le développement logiciel Agile. Nous traitons de conception, de programmation, de pratiques de génie logiciel, d'essais et d'autres sujets connexes.

Le changement organisationnel [Partie 2 / 2]

Publié par Olivier Dugas le mardi 13 mai 2014 à 15:09

À la partie 1 de cet article, nous avons avancé qu'un changement organisationnel n'était pas nécessairement durable. La grande question est donc de savoir comment arriver à rendre un changement organisationnel durable.

L'une des pistes de réponses se trouve dans le type de motivation choisi pour mener le changement. En effet, il faut ajouter à la motivation extrinsèque du personnel affecté une motivation intrinsèque, c.-à-d. une motivation liée aux valeurs véhiculées par les personnes. La motivation extrinsèque mise sur les aspects techniques et structurels d'un changement, ce qui est généralement véhiculé par les gestionnaires, les experts de ce changement, les agents de changement et les champions. La motivation intrinsèque, elle, mise plutôt sur les croyances, l'intégration du changement dans les valeurs et dans les comportements, ainsi que sur le niveau d'engagement des personnes affectées par le changement. Bien que les motivations extrinsèques soient importantes, un changement a bien peu de chance d'être durable sans les motivations intrinsèques.

Selon la théorie d'autodétermination, il faut amener à faire en sorte que le choix de l'agilité soit fait par les personnes affectées sans influence ni interférence externe. Curieusement, cette théorie se rapproche formidablement d'une conférence de Dan Pink. Selon ces théories et à notre avis, les différents éléments à viser afin d'augmenter la motivation intrinsèque sont l'autonomie, la maîtrise et le but.

  • Autonomie : Le désir de se diriger soit même.
  • La maîtrise (ou la quête de la compétence) : Le sentiment d'urgence à devenir meilleur à quelque chose.
  • Le but (ou l'appartenance psychologique) : Le pourquoi de l'entreprise, le pourquoi du changement, la vision de l'agilité. Ce qui donne envie à tout employé de participer à quelque chose de grand, un projet commun.
  • La satisfaction personnelle : Le niveau de bien-être dans l'entreprise en lien avec les objectifs de vie d'un employé.

Petite parenthèse, certaines compagnies, comme Amazon, Zappos et Netflix, paient leurs employés s'ils démissionnent afin de conserver ceux qui sont réellement motivés par la mission de l'entreprise.

Il faudrait, en tant que consultant, trouver un ou des champions à travers les équipes. Il faudrait orienter les manières de voir et de discuter de l'agilité en visant les valeurs mentionnées ci-haut.

Il faudrait également trouver une manière de capitaliser sur la victoire afin de la soutenir et de souligner les bons coups de chacun. Les champions devraient aussi être capable de faire ce travail lorsque le consultant n'est plus là. Il faudrait utiliser les victoires (petites ou grandes) pour répandre la motivation à d'autres équipes, puis à d'autres départements de l'entreprise. Batement et David (2002) l'ont d'ailleurs suggéré dans leur modèle des niveaux de durabilité d'améliorations.

Improvementsteps

Le changement organisationnel [Partie 1 / 2]

Publié par Olivier Dugas le jeudi 8 mai 2014 à 16:00

Je commence cet article avec une question : croyez-vous qu'un changement organisationnel soit durable?

Des recherches sur la durabilité des changements en entreprises indiquent que malgré le succès des initiatives de changements, il y a une variation considérable quant au niveau de durabilité atteinte. Alors que quelques-uns parviennent à conserver les gains obtenus suite à un changement organisationnel, la grande majorité des gains se sont inexorablement évaporés après quelques semaines, quelques mois, ou même quelques années (Kotter, 1995).

Ainsi, il est dangereux de croire qu'il suffit d'engager un consultant pour jouer le rôle d'agent de changement pour ensuite espérer que son expertise permettra au changement de s'ancrer dans la culture de l'entreprise. Afin de parvenir au succès d'un changement, il faut de la volonté et un engagement face à celui-ci.

Tout changement organisationnel se fait en trois phases :

  1. La décristallisation : Cette phase consiste en une reconnaissance du problème et en un diagnostic de la situation. Pendant cette phase, l'agent de changement ou les personnes qui collaborent avec lui doivent s'affairer à convaincre les gens plus réticents des avantages et de la nécessité du changement. Cela mène à un éveil, une prise de conscience quant à la cause du changement à apporter. À l'aide d'un agent de changement, les personnes affectées vont acquérir une motivation extrinsèque qui les mène à participer activement au changement.
  2. La transition : Lors de cette phase importante, les personnes désintègrent leurs façons de faire afin de reconstruire de nouvelles habitudes. C'est une étape cruciale, où l'agent de changement occupe une place importante.
  3. La recristallisation : Il s'agit de l'étape où le changement est intégré à la culture de l'entreprise, mais aussi aux valeurs des personnes affectées par le changement. Il faut ancrer le changement dans les habitudes de ces dernières.

Du point de vue du consultant et à titre d'agents de changement, nous sommes confrontés à ce défi dans de multiples entreprises, principalement en ce qui concerne l'agilité. Nous contribuons à la décristallisation d'anciennes façons de faire pour ensuite participer activement à la transition d'équipes vers les méthodes agiles. Enfin, nous devons, du moins en partie, participer activement à la phase de recristallisation afin de nous assurer que l'agilité fasse partie intégrante du quotidien des personnes au long terme.

Malheureusement, deux effets jouent en notre défaveur :

Effet d'Hawthorne : Les chercheurs ont remarqué que les personnes ont tendance à changer leurs comportements lorsqu'ils savent qu'ils sont étudiés. Lors de l'introduction d'une nouvelle pratique, par exemple, tout le monde observe, et tout le monde se sait observé. Cela entraîne un haut niveau d'excitation, de discipline et de motivation. Puis, alors que la nouveauté s'estompe et que les gens cessent d'observer ce qui se passe, le changement glisse et les gens retournent inexorablement vers les anciennes manières de faire.

Effet de la nouveauté : Les gens ont tendance à avoir un gain de motivation lors de l'acquisition de nouvelles techniques ou de nouveaux outils. Cependant, avec le temps, cette motivation tend à disparaître.

Batemen et David (2002) ont étudié le niveau de durabilité du changement en entreprise. Bien que leurs recherches indiquent que les interventions dans des cellules de travail mènent à des améliorations significatives, lorsque l'intervention se termine, il y a des variations considérables quant au niveau de durabilité du changement apporté. Certaines cellules parviennent à transformer le changement en un nouveau standard, alors que d'autres voient leurs gains évaporés très rapidement. D'ailleurs, selon Kotter (1995), 20% des changements tendent à disparaître complètement à l'intérieur de seulement deux années.

Improvementbyclass

Classesdescription

La grande question est donc de savoir comment arriver à rendre un changement organisationnel durable.

La suite à la partie 2!

Une anomalie devrait-elle donner des points à l'équipe?

Publié par David Beaumier le mercredi 27 novembre 2013 à 21:07

Dernièrement, on me posait la question suivante : « J’aimerais une confirmation sur le fait que les bogues ne devraient pas être pointés et comptabilisés dans le calcul de la vélocité de l’équipe ». C’est une excellente question et une qui revient assez souvent, particulièrement lorsqu’une équipe débute avec Scrum.

La réponse que je donne généralement est assez simple : non, on n’attribue pas de points aux anomalies. La raison principale est que Scrum se veut un cadre de travail qui valorise la livraison de valeur ajoutée (appelée value-driven en anglais). Lorsqu’on ajoute un élément au carnet d’un sprint c’est dans l’objectif de livrer une fonctionnalité qui a de la valeur pour le client. À l’opposé, un bogue représente une somme de travail de correction à quelque chose qui a déjà été livré. En corrigeant un bogue, l’équipe n’apporte, malheureusement, pas de valeur au client. En anglais, on parle de failure-driven.

L’objectif d’un cadre de travail empirique comme Scrum c’est d’amener l’équipe à réfléchir sur sa façon de travailler et d’en venir à identifier des façons de livrer plus de valeur au client durant un Sprint. Si l’équipe reçoit des points pour corriger des bogues elle n’aura alors aucun incitatif à être créative et à trouver des façons d’éviter ces bogues à la source. À mon avis, ça reviendrait en quelque sorte à offrir un biscuit à un chien alors qu’il vient de désobéir. En fait, en éducation on suggère d’encourager les bons comportements et d’ignorer les mauvais. C’est exactement l’approche préconisée par Scrum puisque l’équipe n’est pas pénalisée. Elle ne perd pas de points, mais elle n’en gagne pas non plus et sa vélocité n’augmentera pas.

Une équipe qui doit corriger un nombre significatif de bogues au cours d’un sprint va probablement en souffrir puisque sa vélocité risque de « prendre une débarque ». C’est un peu le but en fait... Si l’équipe est sérieuse, on devrait voir émerger des suggestions pour corriger la situation et éviter que la situation se répète. Cela peut parfois prendre plus d’un sprint pour que l’équipe réalise qu’elle est sur une mauvaise pente. Scrum Master, soyez vigilants!

Toutefois il est important pour les équipes de distinguer un bogue (un vrai) d’un changement au comportement d’une application. Je prends un exemple qui m’a été présenté récemment : lorsqu’un utilisateur imprime un rapport en sélectionnant un client qui n’a pas de facture impayée, le rapport "plante" car ce cas n’avait pas été prévu par le PO, ni testé dans ces conditions  (le rapport sert en principe pour les clients qui ont des comptes en souffrance). J’ai alors suggéré à l’équipe de créer un élément dans son carnet de produit afin d’ajouter le support pour ce besoin qui venait d’émerger. Par contre, si le rapport avait affiché la liste des factures dans le mauvais ordre, là j'aurais plutôt penché pour le bogue.

Qu’en pensez-vous? Est-ce que vous suivez cette règle dans votre équipe?

Les conditions de succès et la définition de terminée s'invitent au restaurant

Publié par Louis-Philippe Carignan le vendredi 5 octobre 2012 à 20:00

Pour tenter de bien expliquer les conditions de succès ainsi que la définition de terminée à quelqu'un, un collègue (merci Marc-André) a utilisé l’analogie d’un restaurant pour souligner l'importance de ces deux concepts. Je trouvais l’idée intéressante alors j’en profite pour l’expliquer à nos lecteurs.

Imaginez un restaurant avec deux pièces : la salle à manger et la cuisine. Le Product Owner (PO) est assis dans la salle à manger tandis que son équipe de réalisation est dans la cuisine.

Le PO a le droit de passer les commandes qu’il veut au serveur. Celui-ci les apporte à son équipe qui les cuisinera. Lorsque le PO n’est pas assez clair avec sa commande, il y a de fortes chances que le plat préparé ne corresponde pas exactement à ce que le PO avait commandé.

Par exemple, si le PO commande un hamburger, il se peut que l’équipe lui retourne un hamburger avec une tranche de laitue parce qu’elle croyait que c’était ça que le PO préférait. Le PO, insatisfait, retourne alors le plat en demandant une tranche de tomates, de la moutarde et aimerait bien garder sa tranche de laitue puisque cela lui plait finalement. 

Dans notre exemple, les tranches de tomates et de laitue, ainsi que la mourtade, sont les conditions de succès de la commande du PO. Elles permettront à l’équipe de savoir quel type de hamburger ils doivent cuisiner à leur PO. Sans ces conditions de succès, il y a de fortes chances que le PO retourne son plat à quelques occasions jusqu’à ce que son besoin soit comblé.

On peut observer cela dans des équipes Scrum lorsque la vélocité d’une équipe varie d’une itération à l’autre. Sans de bonnes conditions de succès, il sera difficile de combler les besoins du client parce que ceux-ci ne sont pas bien exprimés au début d’une itération. À la revue d’itération, le PO n’acceptera pas certaines stories puisqu’elles ne respecteront pas ses conditions de succès. Mais puisque ces dîtes conditions n’avaient pas été dictées explicitement au début de l’itération, l’équipe de réalisation avait fait de son mieux pour répondre à son client.

Quant à la définition de terminée, elle demande à l’équipe de nettoyer la cuisine après le souper. Une fois tous les mets cuisinés, il faut laver la vaisselle, nettoyer le plancher et fermer les lumières. Si les chaudrons ne sont pas propres, il faudra plus de temps pour préparer la prochaine commande. Dans la vraie vie, cela implique de faire du réusinage (refactoring), de la documentation ainsi que toute autre tâche nécessaire pour s’assurer qu’on a terminé une story. À la longue, si ces tâches ne sont pas faites, il sera de plus en plus pénible d’ajouter et/ou modifier des fonctionnalités au logiciel. 

Bonne cuisine!

 

 

  • Plus récents
  • 1
  • Plus anciens

Archive