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.

Merci pour le feedback

Publié par Marc Allard le mardi 17 février 2015 à 19:19

Thanks For The Feedback

C’est la fin d’une dure journée. Au bureau, des clients vous ont tenu au téléphone pendant une heure à râler pour des pacotilles et votre boss vous a reproché de ne pas être assez patient avec eux. De retour à la maison, vos enfants ont boudé le repas équilibré que vous avez trouvé l’énergie de leur préparer. Et après la routine du dodo, quand vous avez eu enfin la liberté de vous affaler sur le divan pour regarder votre série préférée, votre douce moitié a voulu faire le bilan des factures et de tâches ménagères qui s’accumulent depuis trop longtemps. 

Dans ce temps-là, je ne sais pas pour vous, mais moi j’ai envie de faire comme certains commerces qui ferment un certain temps pour rénover. L’affiche dirait quelque chose comme : « Fermé pour travaux majeurs. Cause : surdose de feedback. »

« On nage dans un océan de feedback », écrivent Douglas Stone et Sheila Heen, dans leur livre Thanks for the Feedback, paru au printemps dernier. Stone et Heen ne parlent pas à travers leur chapeau. Ils font partie du Harvard Negociation Project, un programme fondé en 1979  dans l’université du même nom qui a révolutionné la science de la négociation et dont les membres ont été appelés à l’aide de graves conflits comme la crise des otages iranienne, les négociations de paix israélo-palestinienne et l’apartheid sud-africain.

Stone et Heen, eux, ont travaillé avec tout un assortiment de travailleurs : des PDG, des entrepreneurs, des opérateurs de puits de pétrole, des leaders religieux, des policiers, des cinéastes, des journalistes, des travailleurs de la santé, des astronautes, etc. Lorsqu’ils demandaient à leurs clients de décrire le genre de conversation qu’ils trouvaient le plus difficile, le feedback revenait tout le temps. Après tout, difficile d’en donner, même quand c’est impératif: la personne qui le reçoit se met sur la défensive ou en colère et elle se retrouve moins motivée, pas plus. Alors, pourquoi se casser la tête à en donner?

De toute façon, tout le monde l’a expérimenté avec un patron déconnecté : le feedback est injuste ou infondé, et d’ailleurs le moment était mal choisi et le ton manquait cruellement d’empathie. Le donneur de leçons ne comprenait pas notre job et n’avait aucune idée de nos contraintes. Il aurait dû s’attarder à ce qui va vraiment mal dans la boîte — s’il veut une liste, ça nous ferait plaisir de lui fournir!

Durant longtemps, la solution a semblé du côté des émetteurs de feedback. Il fallait montrer aux cadres comment trouver les bons mots, le bon ton et s’assurer que leurs remarques soient pertinentes. On a toutefois oublié les récepteurs dans l’équation — et la clé se trouve de leur côté, soutiennent Stone et Heen. 

« Entraîner les cadres à donner du feedback (…) peut être utile, écrivent-ils. Mais si le récepteur ne veut pas ou s’il n’est pas apte à absorber le feedback, même la persévérance et une livraison habile du message ne pourront pas se rendre très loin. L’autorité ou le pouvoir des émetteurs importent peu; les récepteurs ont le contrôle sur ce qu’ils font, sur ce qu’ils laissent les atteindre, sur le sens qu’ils donnent à ce qu’ils entendent, et s’ils décident de changer. »

C’est vrai au bureau comme à la maison. Dans son livre sur l’agilité familiale, The Secrets of Happy Families, le chroniquer du New York Times Bruce Feiler rencontre Bill Ury, un des cofondateurs du Harvard Negociation project. Feiler s’interroge à savoir si les techniques de négociation qui ont fait leurs preuves en entreprises peuvent fonctionner dans un couple et avec les enfants. Ury lui répond que son questionnement est tout à fait normal, puisque le modèle hiérarchique qui prévalait depuis des lustres dans la société ne tient plus.

« Maintenant, nous sommes dans une période de transition, explique Ury. La démocratie se répand à travers le monde, les organisations deviennent de plus en plus horizontales. La même chose se produit avec les familles, au sein desquelles les membres veulent prendre part aux décisions qui les affectent. Ce qui veut dire que tout est négociable. Qui fait la vaisselle? Ce n’était pas une question il y a une génération. La nôtre est la première où la négociation est la norme. »

Or, toute négociation repose sur le feedback. Le problème, c'est que la rétroaction est difficile à recevoir, parce qu’elle entre en conflit avec quelque chose de fondamental : notre besoin d’être aimé, accepté et respecté tel qu’on est, expliquent les auteurs de Thanks for the Feedback. Ça ne nous vient pas naturellement de voir le bon côté du feedback; notre réflexe est plutôt de froncer les sourcils.

En se braquant, on perd cependant une source incroyable d’apprentissage. Je me souviens d’avoir lu par exemple que, très jeune, Eugenie Bouchard se distinguait des autres joueuses sur le court de tennis car elle était très attentive aux commentaires de ses entraîneurs et se faisait un devoir de corriger ses erreurs au plus vite pour élever son niveau de jeu. On sait où elle est rendue aujourd’hui! 

Pour le reste d’entre nous qui ne possédons pas cette attitude par défaut, Douglas Stone et Sheila Heen nous rassurent : c’est une habileté qui s’apprend. Même après une dure journée. 

D'autres billets qui pourraient vous intéresser

Entretien avec David Starr

Publié par Marc Allard le jeudi 5 février 2015 à 13:14

DavidstarrDavid Starr est un pionnier de l’agilité familiale. Il y a une dizaine d’années, cet ingénieur en logiciel de l’état de Washington, aux États-Unis, et père de quatre enfants (dont un atteint d’un TDAH et un du syndrome d’asperger), a eu l’idée de transposer à la maison les méthodes agiles. M. Starr et sa famille font partie des figures marquantes du best-seller de Bruce Feiler, The Secrets of Happy Families. Je l’ai interviewé il y a un peu plus d’un an, mais l’entrevue reste toujours aussi pertinente. La voici.  

Q. J’ai lu que vous teniez des réunions familiales à la manière agile, comment se déroulent-elles ? 

R. Chaque jour, on se réunit autour de notre plan hebdomadaire et on regarde notre progression par rapport à ce plan. À la fin de la semaine, on fait une rétrospective : on inspecte et on adapte pour voir comment se comporte notre famille. Et après, on recommence! 

Q. Et vous faites ça vraiment chaque matin ?

R. On appelle ça notre mêlée quotidienne (daily huddle). On se réunit chaque matin cinq minutes alors qu’ils (les enfants) se préparent pour aller à l’école et on se dit : «OK, à quoi va ressembler la journée ?» Ça incite vraiment les enfants à se demander à quoi va ressembler leur journée. Bien sûr, ça va probablement changer, mais au moins ça les start avec un sentiment de contrôle sur eux et sur leur journée. Logistiquement, il faut souvent faire ça un enfant à la fois, mais c’est OK aussi. 

Q. Et à quoi ressemble la rencontre familiale hebdomadaire ? 

R. C’est plus élaboré. On réfléchit à ce qui s’est passé dans la dernière semaine — c’est là que se trouve la vraie valeur de l’exercice. On a des conversations super constructives, utiles et bénéfiques durant cette rétrospective. On évalue ce qu’on a fait pour atteindre les objectifs de la semaine et  à quel point on a réussi, mais aussi comment on s’est amélioré. Parfois, on va discuter d’enjeux personnels, mais on focalise vraiment sur la famille en tant que groupe. De là, on essaie de déterminer de nouveaux objectifs pour la semaine suivante. 

Q. Cette semaine, par exemple, sur quel objectif travaillez-vous ? 

R. Il y en a deux. Le premier est anodin — c’est d’être en mesure de répondre à son téléphone. Nous sommes six dans cette maison et ça arrive qu’on ne soit pas capable de joindre personne. On a découvert que c’est parce qu’ils (les enfants) ne rechargent pas leurs téléphones ! (…) C’est ce qui m’a amené à bricoler une petite station de recharge et à inciter les enfants à déposer leur téléphone à un même endroit. Ça, c’est de la logistique, mais ça adoucit les choses dans la maison. 

Le deuxième, c’est de diminuer les frictions et d’augmenter l’harmonie avant le souper. (…) Pour y arriver, on demande à chaque membre de la famille ce qu’il est prêt à faire pour atteindre l’objectif. Par exemple, ma fille a accepté cette semaine d’aider mon plus jeune garçon [qui a un TDAH] à se calmer quand il se fâche — ce qui lui arrive souvent. Et ça, c’est l’exemple parfait de ce qu’on tente de faire, c’est-à-dire de voir comment on peut s’entraider. 

Q. Transposer des méthodes du travail à la maison reste tabou. Pour beaucoup de gens, on ne doit pas mêler les deux….

R. J’ai réalisé à un certain moment que les choses qui fonctionnent au travail fonctionnent parce qu’elles fonctionnement, et non simplement parce que c’est dans un contexte de travail. (…) Nous sommes tous des humains. Qu’on soit ensemble pour atteindre un objectif dans une business ou qu’on soit ensemble pour atteindre un objectif en famille, les dynamiques sont très similaires. 

Q. Et d’après vous, d’où vient cette réticence à s’inspirer du travail pour s’épanouir en famille ?

R. Pour plusieurs, ça peut être apeurant d’appliquer des stratégies venues du monde du travail à la famille. Certains ont connu des entreprises avec une hiérarchie qui s’apparente à un système totalitaire. Or, le développement agile a mis ce système à l’envers en forçant les leaders de l’organisation à être au service des gens qui travaillent pour eux. C’est beaucoup plus humain et beaucoup plus approprié pour ma famille, parce que je suis au service de mes enfants pour qu’ils deviennent des adultes qui fonctionnement bien.

D'autres billets qui pourraient vous intéresser

Faire le double en moitié moins de temps avec Scrum

Publié par David Beaumier le mardi 3 février 2015 à 18:31

Scrum TwicetheworkhalftimeJ'ai récemment terminé la lecture du plus récent livre de Jeff Sutherland, le co-créateur de Scrum, s'intitulant Scrum: The Art of Doing Twice the Work in Half the Time. L'objectif avoué de Jeff Sutherland avec la publication de ce livre est de faire rayonner Scrum à l'extérieur du secteur des TI et du développement logiciel en particulier. Celui-ci s'adresse donc à des gestionnaires et leaders de tous les horizons. Personnellement, j'ai trouvé qu'il avait atteint son objectif. Il ne peut faire abstraction des succès de Scrum dans le monde du développement logiciel, mais il présente beaucoup d'exemples d'organisations oeuvrant dans d'autres secteurs d'activités qui appliquent Scrum. On voit clairement que Scrum a sa place dans les organisations modernes, particulièrement celles qui font face à des défis créatifs et qui doivent affronter l'incertitude (que ce soit face au marché ou au développement du produit/service lui-même).

D'entrée de jeu, sachez que ce n'est pas un livre pour apprendre comment mettre Scrum en application, il en existe déjà plusieurs qui sont excellents. C'est plutôt un livre qui présente les bénéfices qu'une organisation peut retirer en mettant Scrum en action. Et ça, je trouve que ce livre le fait merveilleusement bien. Jeff Sutherland a écrit ce livre en collaboration avec son fils, un ancien du réseau radiophonique NPR, ce qui n'est sans doute pas étranger au style d'écriture simple, direct et très imagé qu'on y retrouve.

Bien que je ne fasse pas, à priori, parti du public cible du livre, j'ai eu beaucoup de plaisir à le lire. Après plus d'une décennie à mettre en oeuvre les pratiques Agiles et Scrum en particulier, j'ai trouvé cette lecture rafraîchissante et motivante. On s'éloigne parfois de l'essence de Scrum en le pratiquant au quotidien et les aspects mécaniques (telles que les cérémonies ou les artéfacts) peuvent finir par prendre le dessus sur les principes. Parce qu'il doit prouver son affirmation (le double de travail en la moitié moins de temps), Sutherland revient sur les fondements de Scrum et il met l'emphase sur les aspects qui font de Scrum un cadre de travail capable de rendre les individus et les équipes performants: la dynamique des équipes, l'importance accordée au temps, la réduction des gaspillages (sous toutes leurs formes), la visibilité sur la réalité et la gestion des priorités.

Cette lecture m'a aussi permis de prendre conscience de l'arrimage qui existe entre Scrum et le mouvement Lean. À maintes reprises, Sutherland démontre comment tel ou tel aspect de Scrum vient mettre en oeuvre un des principe du Lean. Il consacre même un chapitre entier à l'élimination des gaspillages, un fer de lance du mouvement Lean. Est-ce une stratégie pour favoriser un rapprochement de Scrum avec la communauté Lean et Kanban alors qu'il y a souvent eu des tensions entre ces deux groupes, souvent vu en opposition l'un à l'autre? Je ne sais trop, mais j'ai personnellement bien apprécié qu'on me présente la complémentarité des deux approches.

C'est donc une lecture que je vous recommande même si vous oeuvrez en développement logiciel et ce, quel que soit votre rôle. Je la recommande aussi fortement à tout gestionnaire, peu importe son secteur d'activité. N'hésitez donc pas l'offrir en cadeau à votre patron ou à le laisser traîner dans un endroit stratégique de vos bureaux. Je peux vous affirmer que la couverture attirera l'attention de beaucoup de gens (autant par sa couleur que son titre)!

En terminant, je vous propose cette vidéo d'une quinzaine de minutes où Jeff Sutherland présente plusieurs des éléments qu'il aborde en détail dans son livre.

D'autres billets qui pourraient vous intéresser

La valeur des actifs logiciels

Publié par David Beaumier le mercredi 26 novembre 2014 à 09:39

J’ai beaucoup apprécié l’allocution d’ouverture du dernier Agile Tour de Québec par Michael Feathers. J’ai trouvé qu’il abordait des aspects souvent négligés en développement logiciel. Une des choses qui m’a particulièrement accrochée c’est lorsqu’il a mentionné que les organisations devraient devenir plus consciente de la valeur et de l'état de leurs actifs logiciels.

Aujourd’hui combien d’organisation seraient en mesure de fonctionner normalement sans utiliser une solution logicielle? J’en connais bien peu. La plupart des organisations ont des besoins assez élaborés : outils de collaboration, suivi des opérations, relation clientèle, gestion financière, partage de fichiers, systèmes de téléphonie, etc. Qu’elles aient acquis et piloté un progiciel ou investi dans le développement d’une application sur mesure, des ressources importantes ont été engagées dans ces  solutions logicielles.

Malheureusement, la nature même d’un logiciel (ne dit-on pas justement software en anglais) vient fausser la perception que peuvent en avoir les différentes fonctions de l’organisation. En comptabilité on inclut les logiciels dans la catégorie des « actifs incorporels », aussi appelée « capital immatériel ». Bien qu’il existe des façons de déterminer la valeur financière courante de ces actifs, ça se corse lorsqu’il vient le temps de planifier les investissements futurs requis pour maintenir ceux-ci dans un état permettant d’apporter de la valeur à l’organisation.

Avouez que c’est plus simple de déterminer que l’entrepôt vaut 250 000$ et de prévoir un montant annuel pour couvrir les taxes foncières, les assurances, etc. Un gestionnaire attentif remarquera probablement aussi que la toiture commence à être endommagée et qu’il faudra envisager son remplacement d’ici 2-3 ans.

L'hypothèque logcielle

Est-ce que le même gestionnaire sera en mesure de se rendre compte que le moteur de base de données de son système d’expédition s’apprête à être dépassé en fonction du volume projeté des ventes des prochains mois? Est-ce que les parties prenantes ont pris la peine d’inclure la capacité du système dans leurs analyses?  Pas certain. En contrepartie, est-ce que l’équipe de développement a communiqué le vieillissement de la technologie? A-t-elle mis en place ce qu’il faut pour mesurer les performances du système en production?

HypothequeLogicielleLe jour ou le système deviendra si lent qu’il ne sera quasiment plus utilisable (sans doute pendant la période la plus active de l’année) est-ce que l’organisation aura le luxe de procéder à une mise à jour tout en douceur? L’équipe de développement pourrait devoir prendre certains raccourcis pour livrer rapidement une solution corrigée. C’est une approche tout à fait acceptable si elle permet à l’organiser de retrouver sa vitesse de croissance. Par contre, toutes les parties impliquées doivent être conscientes de l’hypothèque logicielle qui grève maintenant le système.

Prenons l’exemple du camion de livraison d’un marchand de meubles pour illustrer cette situation. Si ce marchand néglige l'entretien de son camion en évitant de procéder à un changement d’huile pour pouvoir effectuer plus de livraisons, il risque d’en payer le prix s’il ne planifie pas un autre moment pour faire cet entretien. Une panne lors d'une grosse journée de livraisons risque lui coûter cher et lui causer bien plus de souci qu’une période d’entretien planifiée.

Feathers a mentionné dans son allocution que certaines organisations rendent ces hypothèques visibles et incluent dans le plan de produit les activités requises pour s’en libérer. En procédant au remboursement, l’organisation réduit la possibilité de se retrouver dans une situation où sa dette logicielle l’empêche de saisir une opportunité d’affaires.

C'est, à mon avis, un devoir qu’ont les professionnels du développement logiciel de garder l'organisation dans son ensemble informée de l'état de leurs systèmes. L’information doit pouvoir remonter de l’équipe de développement jusqu’aux parties prenantes. Il faut travailler pour éviter les situations où un gestionnaire se fait dire un bon matin « Votre logiciel est désuet. Il faut le réécrire et on en a pour x mois et ça vous coûtera x centaines de milliers de $ ».  En même temps, les organisations doivent devenir plus sensibles à l’égard de leurs actifs logiciels, poser des questions aux équipes et prévoir un plan pour limiter le gonflement de l’hypothèque logiciel. 

Pour en savoir plus

D'autres billets sur le même thème

Agile Tour 2014 - Les tests et la qualité: moteur de productivité

Publié par Félix-Antoine Bourbonnais, Pascal Roy le mardi 11 novembre 2014 à 00:00

Description

Comment transformer la qualité, les tests et le déploiement en moteur de productivité plutôt qu’en simple poste de dépenses? Portés par Lean et Agile, de grands acteurs (ex.: Google) ont transformé leur département d’assurance qualité pour le placer au coeur du processus de production! Limitez les tests réalisés après l’itération et diminuez la pression sur votre équipe qualité.

  • Présentateurs:  Félix-Antoine Bourbonnais et Pascal Roy
  • Niveau : Débutant
  • Public cible : Tous, spécifiquement Assurance qualité, gestionnaires et équipes de développement.

Présentation

Archive