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.

Évaluer une équipe Agile

Publié par David Beaumier le jeudi 23 janvier 2014 à 16:11

Pour faire suite à mon billet précédent qui parle de l’évaluation des performances individuelles, j’ai pensé qu’il pourrait être pertinent de se questionner sur nécessité d’évaluer l’équipe dans son ensemble.  Alors qu’en développement Agile on mentionne souvent que la réussite de l’équipe prime sur les performances individuelles, les organisations s’attardent rarement aux équipes dans leurs processus d'évaluations de la performance. Peut-être aurait-on avantage à prendre un moment d’arrêt et à mettre sur pieds un système orienté sur les performances du groupe.

Par exemple, pourquoi ne pas mettre en place des mesures précises de certains aspects que l’on souhaite renforcer? Souvent, il peut être assez simple de le faire, quitte à ce que la collecte soit semi-automatisée (un chiffrier, par exemple).  Voici quelques facettes que l’on pourrait évaluer assez facilement :

  • Variation de la vélocité de l’équipe;
  • Nombre de stories non terminées dans le sprint;
  • Métriques sur la qualité du code;
  • Nombres d’éléments bloquants ouverts/fermés dans les sprints;
  • Niveau de précision des estimés de l’équipe;
  • Nombre de bogues en production et sévérité de ceux-ci;
  • Respect des standards de développement;
  • Valeur d’affaires de chacune des livraisons.

Jurgen Appelo, dans son livre Management 3.0, suggère de mesurer l’évolution des performances dans le temps et d’établir des comparaisons. Une augmentation de 15% de la vélocité par rapport à l’an dernier peut être un indicateur plus pertinent d'améliorations dans l’équipe que de simplement établir une moyenne annuelle de N points/Sprint. 

En plus des mesures quantitatives, on ne peut se passer des mesures qualitatives. Elles apportent un éclairage différent sur les performances et l'état de l'équipe en général. Voici quelques axes possibles d'évaluation:

  • Niveau d'auto-organisation
  • Confiance mutuelle
  • Niveau d'entraide et de partage des connaissances
  • Évolution du moral des membres de l'équipe
  • Recherche du consensus
  • Désir de s'améliorer individuellement et collectivement
  • Taux d'absentéisme

Là-aussi, on peut les collecter relativement facilement ces mesures, pour peu qu'on s'en donne la peine. Par exemple, plusieurs outils permettent de bâtir facilement des sondages anonymes et d'en compiler les résultats.

Quand et comment évaluer?

En agilité on parle souvent de réduire la boucle de rétroaction afin de pouvoir fréquemment ajuster le tire et améliorer nos façons de faire. En se basant sur ce principe, je crois qu'il est aussi pertinent de procéder à l'évaluation d'une équipe plusieurs fois par an qu'il l'est de passer d'une livraison annuelle à des livraisons mensuelles. L'évaluation peut prendre plusieurs formes, mais devrait débuter par l'établissement d'objectifs avec l'équipe. En tant que gestionnaire, à quoi vous attendez-vous de l'équipe? Quelle genre de résultats escomptez-vous pour la prochaine année? De l'autre côté, quelles sont les attentes de l'équipe? Quel niveau de performance souhaitent atteindre les équipiers? Quels aspects souhaitent-ils revoir et améliorer? Attention à cette étape de ne pas confondre les objectifs de performance avec le carnet de produit. Les objectifs doivent être en lien avec l'équipe plutôt qu'avec le produit.

Il existe plusieurs façons possibles de mettre le tout sur pieds. Je suggère d'y aller assez simplement pour débuter. Pourquoi ne pas tenir une rencontre regroupant équipiers et gestionnaire(s) afin de comparer les deux points de vue et produire une liste d'indicateurs qualitatifs et quantitatifs à mesurer. Par la même occasion on peut s'entendre sur la source de chacune des mesures sélectionnées et choisir la fréquence de la collecte de celles-ci. Si votre équipe fonctionne par cycles de livraisons de quelques mois, (3 cycles et plus par an) il peut être intéressant de faire coincider la fin d'une livraison avec la période d'évaluation.

À partir du moment où les objectifs à atteindre sont connus d'avance par toutes les parties, l'équipe devient apte à s'évaluer elle-même. Les équipiers pourraient fort bien intégrer cet aspect à la cérémonie de rétrospective d'itération. En revenant sur ses objectifs en cours de rétrospective, l'équipe est alors portée à réfléchir sur les différents éléments qui affectent, positivement ou négativement, l'atteinte de ceux-ci.

Interpréter les résultats

Un gestionnaire, moins impliqué émotionnellement que les membres de l'équipe, pourra avoir une vision différente et intéressante sur les performances globales de l'équipe. Avec le recul, il est probablement en mesure de déceler des enjeux dans la dynamique d'équipe ou au niveau de son organisation. L'interprétation que fera le gestionnaire des données colligées risque aussi d'être teintée par sa vision des enjeux organisationnels. Dans tous les cas, il importe de s'en tenir à la liste d'indicateurs identifiés au départ et d'être le plus objectif possible.

Qu'il s'agisse de mesures qualitatives ou quantitatives, il est important en cours d'analyse de bien distinguer les tendances systémiques des événements ponctuels. Un taux d'absentéisme qui augmente durant la saison de la grippe est probablement ponctuel (Pierre a transmis le virus à Josée, qui l'a ensuite transmis à Serge et ainsi de suite). Toutefois, si vous remarquez une augmentation de l'absentéisme la semaine qui suit chacune des livraisons, il y a peut être lieu d'en chercher la cause.

Aussi, petite mise en garde : il est toujours préférable de ne pas se baser sur une seule mesure pour tirer des conclusions. Mettez-là toujours en contexte. Par exemple, si on ne mesure que le nombre absolu de builds brisés par une équipe on oublie peut-être que celle-ci a une plus grosse base de code ou un nombre plus grand de développeurs et qu’elle a ainsi démarré plus de builds d’intégration continue qu’une autre. Il pourrait être plus judicieux de mesurer le ratio de réussite de builds en pourcentage. En anglais on dit « Be careful what you measure because that is what you are going to get », tel qu’illustré ci-dessous.

Source: http://www.axosoft.com/blog/2012/08/23/measure-agile-metrics-that-work/

Impliquer (encore) l'équipe

Une rencontre avec l'équipe devrait avoir lieu afin d'échanger sur l'interprétation des résultats. Comment l'équipe et le gestionnaire perçoivent-il chacun ces données? Y-a-t-il un écart entre les deux points de vue et pourquoi? Si l'équipe tient une rétrospective de livraison, parfois appelé rétrospective jalon, il est possible de réserver à l'avance une période de temps pour cet échange à l'intérieur de cette activité.

Peu importe la formule que vous retenez, il est important de prendre le temps d'identifier ce qui peut être mis en place pour traiter les écarts entre les objectifs et ce qui a été mesuré. Une équipe qui a tenu compte de ses objectifs au cours des rétrospectives d'itérations aura sans doute des pistes à suggérer et pourra peut-être même fournir un état de situation sur les moyens qu'elle a tenté pour adresser la situation. Est-ce que le gestionnaire peut venir en appui en faisant une intervention auprès d'intervenants externes à l'équipe? Est-ce que d'autres équipes au sein de l'organisation vivent la même situation? Auraient-elles avantage à échanger à ce niveau? Autant d'aspect sur lesquels le gestionnaire peut intervenir pour aider l'équipe à mieux performer.

Références

En terminant voici quelques références additionnelles pour vous permettre d'approfondir le sujet.

Mots-Clés :

Faire le point sur l'état de Scrum dans votre équipe

Publié par David Beaumier le mardi 19 novembre 2013 à 16:18

Dernièrement, je parlais avec un collègue qui m'expliquait, en ses termes, que l'Agilité dans son équipe allait plutôt bien. Ça fait quand même près de deux ans qu'ils utilisent Scrum. En même temps, il était aussi conscient que l'équipe avait certaines lacunes et qu'il y avait encore place à l'amélioration. Malgré tout ce temps, l'équipe n'en était pas rendue à sa phase de performance, tel que décrit dans le modèle de Tuckman.

C'est bien d'admettre qu'on peut faire mieux, mais comment identifier clairement les éléments sur lesquels l'équipe pourrait travailler? J'ai alors pensé lui proposer le Test Nokia, aussi connu sous le nom de test Scrum But. Originalement développé en 2005 par un consultant qui oeuvrait chez Nokia, ce test a été amélioré au fil du temps. En 2008, Jeff Sutherland (le co-créateur de Scrum) a ajouté un système de pondération en remplaçant les réponses oui/non par des choix multiples.

C'est un test assez rapide à compléter (environ 5 minutes) et il en existe des versions électroniques qui comptabilisent les résultats automatiquement et vous donnent un score global (sur 10 points). Selon Sutherland, une équipe qui prend le test au sérieux et se sert des résultats initiaux pour s'améliorer va grandement augemer sa vélocité: "We are finding that for teams that can establish a baseline velocity, raising the score two points will typically double velocity and quality. Raising to over 9 out of 10 will triple velocity.".

Voici quelques versions disponibles sur le Web:

Il est vrai que le test a été maintes fois critiqué pour sa simplicité et le fait qu'il ne couvrait pas tous les aspects d'une équipe Agile. En même temps, il couvre les aspects fondamentaux et essentiels de Scrum. Si votre équipe obtient un score plus élevé que 9, peut-être auriez-vous effectivment avantage à identifier d'autres aspects à mesurer afin de continuer à vous améliorer.

Je vous invite à faire le test vous aussi et ainsi faire le point sur l'état de Scrum dans votre équipe. Je suis certain que cela pourra alimenter certaines discussions lors de votre prochaine rétrospective!

Le développement de produits Lean chez Toyota

Publié par David Beaumier le vendredi 8 juin 2012 à 17:07

Comme je n'ai pu assister à la conférence Lean Software and System Conference du mois dernier, je me donne comme objectif de regarder certaines des présentations suggérées par mon collègue Louis-Philippe Carignan. Celle de Michael Kennedy intitulée Set-Based Decision Making est particulièrement intéressante. Non seulement c'est une personne qui possède une longue expérience au niveau de Lean, mais il vulgarise très bien le sujet et parvient à faire le parallèle avec le développement logiciel même si à la base les concepts sont liés au monde du "hardware".

Parmi les éléments abordés par Kennedy on retrouve l'histoire de Samuel Langley. Il compare son approche à celle des frères Wright. À la fin du 19ième siècle Langlay a obtenu d'importantes sommes d'argent du gouvernement américain pour mettre en place un programme de développement d'un avion. Il fallut 5 ans à Langley pour arriver avec un appareil prêt à tester et il a eu besoin de fonds additionnels en cours de route. Comble de malheur, ce prototype s'est écrasé lors de l'essai initial.

De leur côté les Wright ont pris une approche différente, principalement en divisant le problème (bâtir un avion) en plusieurs éléments clés et en s'attaquant à chacun d'eux un à la fois. Pour chacun, ils ont mis en place des bancs d'essais dès le départ (parallèle avec ATDD) et ont défini des critères précis de succès avant de conclure qu'ils tenaient LA solution. En fait, quand on y pense avec un peu de recul, ils se sont simplement donné les moyens de réussir. Tout ça avec un investissement minimal de temps et d'argent.

On connaît la suite, du moins celle des Wright: leur premier prototype, le Flyer, a pris son envol le 17 décembre 1903. Pourtant Langley avait l'avantage, lui qui avait réussi des vols précurseurs dès 1896 (sans pilote toutefois).

Kennedy fait un parallèle intéressant entre l'aventure des frères Wright et le manifeste Agile. Évidemment, on ne retrouvait pas de logiciel à cette époque, mais, si on fait fi de cela, les valeurs sont très similaires. Le succès des Wright est attribuable, selon Kennedy, à leur approche qui faisait en sorte de mettre en pratique leur savoir et à apporter les ajustements nécessaires rapidement en fonction de leurs apprentissages. En terme d'agilité, on pourrait dire qu'ils ont su garder une boucle de rétroaction courte entre le moment de la conception et la livraison d'une fonctionnalité (contrairement à livrer un prototype en entier).

Kennedy propose une adaptation au manifeste Agile pour illustrer le cas des Wright

Kennedy vient du monde du développement matériel, mais il n'en demeure pas moins que la majorité des éléments qu'il met de l'avant s'appliquent tout autant en développement logiciel. Malheureusement encore trop de gens dans notre secteur sont à la recherche de la recette magique. Ne devrions-nous pas focaliser un peu plus sur l'apprentissage et le savoir-faire plutôt que sur le processus? En tout cas, c'est une des choses que propose Micheal Kennedy et que je trouve porteuse en développement logiciel.

Parmi ses autres propositions qui ont retenu mon attention, on en retrouve une qui provient des pratiques de Toyota: ne pas bâtir un calendrier tant que l'on n'a pas une cible de succès. Avant cela l'équipe chez Toyota investit principalement ses efforts en apprentissage. L'équipe se donne la chance d'apprendre et identifie ses lacunes et les incertitudes auxquelles elle fait face au lieu de foncer tête première dans le développement et corriger par la suite. Cela ne ressemble-t-il pas encore une fois au TDD ou ATDD?

Quelles exigences vous imposez-vous?

Publié par David Beaumier le mardi 5 juin 2012 à 14:18

En regardant une entrevue avec le réputé musicien Michel Legrand j'ai été très intéressé de l'entendre parler de la pratique de son art. On a souvent le réflexe de décrire le travail d'un professionnel de son calibre comme frôlant la perfection. C'est toutefois intéressant de voir de quelle façon Michel Legrand perçoit cet élément de perfection.

"[la perfection] ce n'est pas le bon mot. C'est l'exigence qu'on a. Personne n'atteint la perfection, nous non plus. Une exigence telle que tout devient difficile. [...] Parce qu'il faut les jouer de façon sublime." - Michel Legrand

Je vois là un parallèle intéressant avec le travail d'un professionnel du développement logiciel. On le sait, la conception logicielle est un domaine qui demande beaucoup de créativité et de doigté (sans mauvais jeu de mots). Tel un musicien, on doit nous aussi pratiquer notre art et développer notre talent. Que dirait-on d'un musicien qui ne jouerait qu'en concert et qui ne s'accorderait aucune période de pratique avec son orchestre? Pourtant, est-ce que notre industrie encourage les gens à se perfectionner sur une base régulière? Les activités comme les Kata, Dojo et Code Retreat sont-elles fréquentes dans votre organisation?

Qu'il s'agisse du Personal Software Process (PSP) ou des pratiques d'eXtreme Programming, il existe pourtant déjà des cadres de travail qui favorisent cet aspect de qualité, d'apprentissage et de savoir-faire. Qu'est-ce qui fait en sorte qu'après toutes ces années ceux-ci demeurent l'exception?

D'un autre côté, quelles sont les attentes de nos clients? Ne sont-elles pas similaires à celles des spectateurs assistant à un concert et qui s'attendent à être émerveillés par la prestation du musicien? Ces spectateurs ne s'attendent probablement pas à la perfection; quelques fausses notes ou l'oubli de quelques mots dans une chanson rend probablement l'artiste plus humain et plus sympathique à la limite. Par contre, il faut bien quelques uns de ces moments où la prestation nous ébahit.

Et si l'on voyait la revue de Sprint comme un concert et nos client comme les spectateurs. Quelles exigences devrions-nous alors nous imposer durant le Sprint? Qu'est-ce que je peux faire comme individu et comme membre de l'équipe pour en arriver à émerveiller le client et lui permettre de dire "Wow, mais quelle prestation de l'équipe"?

Comme Michel Legrand, êtes-vous prêts à sortir de la facilité de votre zone de confort? Est-ce que c'est un parallèle qui tient réellement la route dans notre secteur? N'hésitez pas à commenter ce billet et à partager votre point de vue à ce sujet.

Comment bâtir une équipe exceptionnelle

Publié par David Beaumier le mardi 14 février 2012 à 07:17

Dans cette entrevue, Robert C. Martin présente son approche sur les bonnes façon de composer une équipe exceptionnelle de développement logiciel. Il propose plusieurs pistes intéressantes et offre même quelques références pour approfondir le sujet

Est-ce que vous avez déjà utilisé l'approche du "chef programmeur" tel que mentionné par uncle Bob et popularisé par Fred Brooks dans son ouvrage The Mythical Man-Month?

Archive