Category Archives for "Gestion du Changement"

Rendez votre équipe ou organisation auto-apprenante

Si vous êtes un abonné à la newsletter de L’Agiliste, vous savez déjà que j’ai ajouté une nouvelle fiche pratique au « catalogue ». Vous savez même sur quel article je travaille en ce moment puisque vous avez probablement participé au vote ayant abouti à sa sélection 😉

Si par contre, vous n’êtes pas abonné à la newsletter, sachez que la nouvelle fiche en question a pour titre « L’art de la Rétrospective ». Elle vous donne quelques conseils et astuces pour ne pas basculer dans la routine des rétrospectives d’itération et pour améliorer leur efficacité si nécessaire. Vous aide à saisir la posture de coach permettant de rendre votre équipe auto-apprenante et auto-organisée. Mais elle ne s’arrête pas là puisqu’elle évoque aussi d’autres usages de la rétrospective.

Bonne lecture et bonne pratique
Florent

6

L’art de la Rétrospective

Dans le cadre de Scrum, la rétrospective est une réunion positionnée à la fin de chaque sprint (sprint = itération) pendant laquelle l’équipe Scrum met à profit son vécu sur le sprint écoulé pour améliorer son organisation afin d’être plus efficace. La rétrospective est donc un élément clef du principe d’amélioration continue rendant une équipe auto-apprenante.

Comment exploiter au maximum ce levier d’amélioration ? Comment faire en sorte que chacun exprime son point de vue, que la rétrospective porte ses fruits avec des améliorations notables, qu’elle reste vivante malgré sa répétition. C’est à ces questions que je propose de répondre dans cette fiche pratique. J’y aborde également d’autres usages de la rétrospective.

Je tiens à rendre à César ce qui est à César en précisant que le contenu de cet article est bien évidemment issu de ma propre expérience mais aussi des enseignements donnés par le livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Récolter les points de vue de chacun

Il y a autant de vérités que de points de vue. Autant de points de vue que de personnes. Chaque vision permet de voir un problème ou une idée sous un angle différents pour mieux le résoudre ou la faire grandir. C’est ce qu’on peut appeler l’intelligence collective et différents facteurs permettent de favoriser cette dernière.

La posture de coach

Qu’est ce qu’un coach ? Voici ma définition personnelle : un coach est quelqu’un qui va aider une personne à trouver elle même les réponses à ses questions pour lui permettre d’atteindre un résultat qu’elle s’est fixé. Cette activité repose sur une croyance fondamentale : « la personne coachée dispose des ressources nécessaires pour atteindre le résultat visé« . On utilise souvent la métaphore de la graine qui contient toutes les informations nécessaires pour grandir et devenir un arbre. Pour l’anecdote, étymologiquement parlant, « coach » vient de « cocher » (l’ancêtre du chauffeur de taxi) qui amène une personne d’un point A à un point B.

L’animatrice ou animateur de la rétrospective doit adopter une posture de coach vis à vis de l’équipe et renoncer ainsi à la tentation de dire à cette dernière quoi faire en apportant des solutions toutes faites. C’est un exercice qui peut se révéler particulièrement difficile pour un ex-chef de projet habitué à dire aux membres de son équipe quoi faire, comment le faire et quand le faire. Surtout si cet ex-chef de projet a une formation d’ingénieur avec un cerveau « câblé » pour apporter des solutions à des problèmes.

Sans cette posture de coach, on n’aide pas l’équipe à trouver elle même des solutions, à prendre des initiatives et à innover. On fragilise son engagement à mettre en oeuvre les actions d’amélioration (puisque les actions ne viennent pas d’elle). On peut passer à côté d’idées et de solutions pertinentes. On multiplie nos chances de mettre en place des actions inefficaces voire contre-productives.

Si l’animatrice ou animateur dispose d’une expérience ou expertise particulière qui mérite d’être mise à profit en cours de la rétrospective (le Scrum Master porte par exemple l’expertise Scrum). Elle ou il peut s’impliquer dans la recherche de solution à condition de quitter temporairement le rôle d’animatrice ou animateur et de ne pas décider d’une action d’amélioration, mais plutôt de la proposer à l’équipe. En lui laissant clairement le droit de la juger inopportune. Elle ou il peut influencer mais pas décider.

Pas de jugement ni de recherche de coupable

Il est toujours recommandé d’introduire la rétrospective en mentionnant le fait que l’objectif de la rétrospective n’est en aucun cas de porter des jugements sur ce qui sera dit, en particulier à propos des idées proposées. Ni de rechercher des coupables lorsqu’on mettra sur la table les problèmes rencontrés.

Ce rappel est d’autant plus important si un responsable hiérarchique est présent pendant la rétrospective. Si c’est le cas, l’animatrice ou animateur devra briefer cette personne pour s’assurer qu’elle joue le jeu de la posture de coaching. Cette personne peut même participer à l’introduction est préciser : « Je ne suis là qu’en observateur et en position d’écoute, sentez vous libre de parler de tout, y compris de choses qui, selon vous, pourraient me déplaire ».

Un seul mot suffit parfois

Tout le monde n’est pas à l’aise pour parler devant les autres, proposer des idées, etc. C’est normal et il ne s’agit pas de forcer qui que ce soit à s’exprimer. Par contre, il faut lui en donner l’occasion. De simples tours de table peuvent aider. Et parfois le simple fait qu’une personne réservée ai prononcé un « je passe » peut la débloquer dans la suite des échanges.

L’animatrice ou animateur doit également être attentif aux dynamiques de groupe, notamment lorsqu’une personne monopolise trop souvent la parole. Au quel cas, on peut déclencher une pause et faire observer à cette personne que les autres ont rarement eu l’occasion de s’exprimer, alors que leur point de vue est sans doute intéressant.

La force du silence

Il faut parfois compter jusqu’à 10 dans sa tête après avoir posé une question à l’équipe. Le silence ainsi créé génère un espace libre qui aide l’équipe à réfléchir plus en profondeur pour y chercher une idée ou réflexion difficile à trouver.

Obtenir de véritables améliorations

Obtenir des idées, puis un plan d’actions d’amélioration est une chose. Transformer l’essai en implémentant ces actions en est une autre. Là encore la posture de coach a son importance car l’animatrice ou animateur doit résister à la tentation d’affecter arbitrairement les actions aux membres de l’équipe. Ou inversement, elle ou il doit résister à la tentation de prendre à sa charge les actions (en tant que Scrum Master par exemple). En participant activement aux actions d’amélioration, l’équipe s’habitue à s’auto-organiser et devenir « maître de son destin » au sein du cadre donné par Scrum et l’entreprise ou organisation.

Voici quelques moyens de transformer l’essai :

  • Privilégier la qualité des actions à la quantité. 2 ou 3 bonnes actions à mettre en oeuvre d’ici la rétrospective suivante peuvent suffire.
  • Rendre les actions SMART (Spécifique, Mesurable, Acceptable, Réalisable, Temporellement définie). Les questions du genre « Comment saurons nous que notre action a porté ses fruits ? » peuvent aider à alimenter la réflexion collective.
  • Favoriser l’appropriation des actions par l’équipe en demandant qui serait prêt à prendre en charge telle ou telle action. Prendre la responsabilité d’une action devant le reste de l’équipe favorise l’engagement.
  • Transformer les actions en tâches qui se rajoutent au tableau des tâches, kanban ou sprint backlog et sont ainsi estimées et suivies au même titre que les autres.

Garder la rétrospective vivante

Varier les objectifs

L’objectif « générique » de la rétrospective est du genre « Améliorer notre processus de développement pour le rendre plus efficace et plus agréable à vivre ». Il s’agit aussi d’améliorer la qualité du produit et d’adapter en conséquence la définition de « terminé ».

Mais selon l’actualité du projet, rien n’empêche de varier l’objectif d’une rétrospective à l’autre. Voici quelques exemples d’objectifs un peu plus ciblés :

  • Améliorer notre réactivité vis à vis des utilisateurs.
  • Améliorer notre relation et nos interactions avec le métier et le service marketing.
  • Comprendre les raisons pour lesquels l’objectif du sprint n’a pas été atteint.

Attention cependant à ne pas basculer dans le « trop ciblé » et occulter ainsi des sujets qui méritent d’être instruits en rétrospective.

Varier les activités

Les activités d’animation de rétrospective sont nombreuses et variées. Testez en des nouvelles. Vous apporterez ainsi du renouveau à vos rétrospectives et peut être que vous découvrirez une activité qui fonctionne mieux qu’une autre.

A ce sujet, je vous invite à lire la fiche de livre « Agile Retrospectives – Making Good Teams Great » de Esther Derby et Diana Larsen.

Changer d’animatrice ou d’animateur

Après plusieurs rétrospectives, certains membres de votre équipe se sentiront peut être à l’aise – voire se porteront volontaire – pour animer une rétrospective. Profitez en, car c’est également une bonne source de renouveau et vous serez peut être positivement étonné par les résultats. Si personne ne se propose, faite un appel à volontaire. Si la ou le volontaire a besoin de conseils avant de se lancer, rendez vous disponible pour les lui transmettre.

Faire émerger « code » de conduite de l’équipe

Avez vous pensé à utiliser des activités de brainstorming en petits groupes pour définir ensemble le code de conduite de l’équipe lui permettant de rester efficace (un peu à la Dexter pour ceux qui connaissent la série) ? Le « code » qui s’applique à la rétrospective par exemple (exemples d’accords collectifs formant le fameux « code » : « Ne pas prendre de PC portable pendant la rétro et mettre les téléphones en mode silencieux », « chacun parle à tour de rôle », etc). Mais aussi dans le quotidien des itérations (exemple subjectif : « Pas de modification du code source commun à partir de X heures avant la revue de sprint ou livraison. A l’exception de correctifs ciblés et maîtrisés par du pair programming »). Attention, ne dépassez pas 7 ou 8 accords collectifs, sinon c’est impossible à retenir.

La rétrospective de rétrospective

La rétrospective AgileOn ne pense pas toujours à améliorer un outil d’amélioration. Pourtant, c’est peut être la meilleure façon d’optimiser le retour sur investissement de la rétrospective. Vous pouvez ainsi façonner des activités spécifiques à votre contexte pour aboutir à VOTRE rétrospective, à une rétrospective sur mesure.

Pour y parvenir il existe différentes activités. L’une d’entre elles est appelée le « +/Delta » et prends seulement 10 à 20 minutes selon la taille du groupe. Elle peut servir pour une rétrospective d’itération, de release ou de projet.

Voici comment procéder :

  1. Présentez l’activité en disant: « Avant de terminer, nous allons identifier ce que nous voulons garder et ce que nous voulons changer pour notre prochaine rétrospective. ».
  2. Divisez votre feuille de paper board ou tableau blanc en deux colonnes (une ayant pour titre « + » pour les choses à garder et l’autre « Δ » pour les changements à apporter). Ajouter un titre au dessus (ex : Processus d’amélioration de la rétrospective). Annoncer le temps maximum disponible (cinq à quinze minutes).
  3. Demandez au groupe de prononcer les forces (choses à garder) et les changements. Capturez-les mot pour mot en remplissant les colonnes. Arrêtez-vous lorsque les idées se tarissent, ou à la fin du temps imparti. Attendez quelques secondes. Souvenez vous de la force du silence.
  4. Remercier le groupe pour leur participation franche. Comparez les éléments recueillis avec ceux des précédentes rétrospectives pour voir si des « schémas » (patterns) apparaissent.

Lorsqu’il n’y a plus de place pour écrire dans chacune des colonnes, c’est également le signe que vous pouvez vous arrêter. Au pire, les idées qui ne rentrent pas pourront être évoquées lors de la prochaine rétrospective de rétrospective.

Autres usages de la rétrospective

Définir ses valeurs, façonner sa culture et son organisation

La rétrospective peut également être un formidable outil pour définir les valeurs fondamentales de votre équipe. Des valeurs qui peuvent ensuite évoluer dans le temps, d’où l’intérêt de faire de telles rétrospectives régulièrement, tous les trimestres par exemple. Vous l’aurez compris, dans ce genre de rétrospective on détourne les activités de recherches collective d’idées ou d’actions en recherches de valeurs et principes. Evidemment, le nombre de personnes peut être bien plus grand, ce qui peut influencer la durée et la technique d’animation. Tout comme les rétrospectives de release ou de projet qui sont également possibles.

Pour ces dernières, on peut ainsi identifier des améliorations susceptibles de toucher l’organisation toute entière plutôt que le processus de développement seul.

Premier pas vers l’agilité

La rétrospective est également une bonne façon d’introduire l’agilité dans une organisation. On permet ainsi à l’équipe de s’exprimer librement sur ce qui fonctionne bien aujourd’hui, ce qui mérite d’être amélioré et des actions qu’on peut mettre en oeuvre à court terme. L’équipe est ainsi impliquée dès le début et partie prenante sur les décisions de changements. Au coach agile ou Scrum Master de savoir proposer ce que l’agilité a à offrir.

Message de soutien

Si vous lisez ces mots, c’est qu’il y a de grandes chances pour que vous ayez lu cette fiche jusqu’au bout et je tiens à vous féliciter pour ça car nous prenons de moins en moins le temps de faire des lectures approfondies. Si vous débutez dans l’agilité, cet article pourrait vous décourager d’animer une rétrospective. C’est pourquoi je tiens à vous rassurer en vous disant ou vous rappelant que : « Vous n’avez pas besoin d’être parfait » et je dirai même plus « vous avez droit à l’erreur ». C’est un des grands atouts d’une approche agile.

Vous trouvez que votre première rétrospective manquait de quelque chose ? de fluidité ? d’idées ? d’améliorations concrètes ?… Ce n’est pas grave. Vous venez d’apprendre des choses que vous pourrez mettre à profit lors de la prochaine rétrospective. La seule chose que vous devez vous « obliger » à faire, c’est de renouveler cette rétrospective à la fin de chaque sprint ou itération et d’y consacrer le temps nécessaire. Même lorsque toute l’équipe se dit « je pense qu’on est rôdé, il n’y a plus grand chose à améliorer ». Les choses changent ou évoluent en permanence, il y a toujours des choses à améliorer. Et quand bien même ce ne serait pas le cas, ça ne fait jamais de mal de se poser tous ensemble quelques heures après une période d’effort soutenu.

 

Sortie de Rupture Douce Saison 2

Livre Rupture Douce Saison 2Bonjour,

J’ai le plaisir de vous annoncer la sortie du livre « Rupture Douce Saison 02 » dont j’ai eu la chance de participer à l’écriture. Il ne s’agit pas d’un livre ordinaire. D’abord parce qu’il a été écrit en mode « tribal », au total c’est plus de 25 auteurs qui ont participé à l’écriture. Sans compter les relecteurs et le dessinateur. Le tout animé par Laurent Sarrazin en bon Leader Tribal. D’autre part, la vocation de ce livre est de parler d’agilité en racontant des histoires, des anecdotes. Sa lecture est donc un voyage d’histoires en histoires à parcourir dans la direction de son choix. Mais sa vocation ne s’arrête pas là, l’objectif est aussi d’aller au delà du monde de l’informatique pour mettre l’agilité au service de notre société toute entière. Ce livre n’invite pas au changement pour le changement, il invite à l’expérience, à l’expérimentation. Il est préfacé par Alistair COCKBURN, l’auteur notamment de « Rédiger des cas d’utilisation efficaces » mais aussi et surtout le co-auteur de l’incontournable Manifeste Agile.

En tant qu’auteurs, nous renonçons à tirer le moindre profit financier de ce livre. Le bénéfice est avant tout humain. Ce fut un grand plaisir de participer à ce projet et je remercie encore Laurent pour m’avoir invité à le faire. Les revenus générés par la saison 01 ont été reversés à une oeuvre caritative. Concernant la saison 02, il se peut que les bénéfices financent la traduction du livre en anglais pour toucher davantage de monde.

Je ne peux donc que vous inviter à lire ce livre et surtout à vivre les expériences qu’il propose. Il est disponible en versions papier, PDF et epub sur Lulu.com ainsi qu’en version Kindle sur Amazon.

Bien amicalement
Florent

Sortie d’un guide de transformation Agile

Un guide de Survie à l’Adoption ou Transformation Agile

Bonjour,

Nous venons de terminer la traduction du livre « Un guide de Survie à l’Adoption ou Transformation Agile : Travailler avec la Culture d’une Organisation » de Michael Sahota. Il est disponible gratuitement en téléchargement sur Lulu.

A l’heure où l’agilité vit un moment de fragilité avec pour barrière n°1 « La capacité à changer la culture de l’organisation » (selon l’enquête sur l’Etat du Développement Agile); ce livre a sans doute un rôle important à jouer.

Je remercie également au passage Michael Sahota pour ce don et sa collaboration à la traduction.

Amicalement
Florent Lothon

1 Le leadership serviteur n’est plus une option

[alert type= »info » show_close= »false »]Résumé en moins de 100 mots

Face à la complexité grandissante de nos projets, au besoin d’innovation par recours à l’intelligence collective, à celui de faire naître un véritable esprit d’équipe pour surmonter plus vite les obstacles rencontrés, le rôle de chef omniscient et omniprésent qui commande, contrôle et décide seul, atteint ses limites. Par ailleurs, les nouvelles générations semblent éprouver plus que jamais le besoin de savoir pourquoi elles travaillent, de sentir que leur avis compte. Autant de facteurs qui rendent le leaderhip serviteur (« servant leadership ») quasi incontournable.[/alert]

Mahatma Gandhi, grand leader indien.

Introduction

L’un des ingrédients clef de l’approche Agile est son mode de leadership. Le leader de l’équipe n’est pas la personne qui ordonne, contrôle et décide à la place de l’équipe. Au contraire, le leader Agile donne davantage de pouvoir à son équipe, met tout en oeuvre pour lever les obstacles qu’elle rencontre et la protège des perturbations extérieures. On parle donc de leadership serviteur. Dans cet article nous allons voir pourquoi ce mode de leadership n’est plus une option aujourd’hui.

Face à la complexité

Nos projets deviennent de plus en plus complexes tant du point de vue technique que du point de vue des besoins fonctionnels à couvrir. De nombreuses décisions difficiles et pourtant structurantes doivent être prises avant et pendant le projet. Le leader n’est plus en mesure d’être omniscient et omniprésent. Il doit donc déléguer une partie de son pouvoir à son équipe afin de rester concentré sur l’essentiel, comme lever les obstacles rencontrés par l’équipe et protéger cette dernière des perturbations extérieures afin de garantir qu’elle soit pleinement productive. Il doit également s’assurer que la méthodologie adoptée est correctement appliquée aussi bien côté technique que côté métier. Au besoin, il doit coacher les personnes qui nécessitent un accompagnement en enseignant par l’exemple.

Cette impuissance du leader seul face à la complexité est également le cas de nos figures politiques. Incapables de prendre les bonnes décisions seuls. Les défis environnementaux, économiques et sociaux nécessitent aujourd’hui des compétences qui dépassent largement celles de notre organe politique. Tout comme le leader Agile, il est nécessaire de donner davantage de pouvoir et d’autonomie à ceux qui sont au front, connaissent très précisément la situation et savent le plus souvent quoi faire. Cela nécessite donc de faire confiance.

« Si vous dites aux gens où aller, mais pas comment ils doivent y aller, vous serez impressionné par les résultats » – Général Georges Patton.

Intelligence collective et diversité

Donner à chaque membre de l’équipe le pouvoir d’exprimer son point de vue et influencer ainsi les décisions à prendre fait l’objet d’un excellent levier pour parvenir à la meilleure solution possible. La diversité de culture, d’expérience, de génération apporte une différence de point de vue permettant de voir les problèmes ou enjeux sous différents angles. La diversité est donc une richesse, un atout, elle est source d’innovation.

Esprit d’équipe

L’esprit d’équipe est fondamental pour surmonter plus vite et plus efficacement les difficultés. Là encore la complexité met de nombreux obstacles sur le chemin à parcourir. Cet esprit d’équipe est également nécessaire pour intégrer les nouvelles recrues et les accompagner dans leur montée en compétence et appropriation des principes et pratiques suivis par l’équipe. Dans le cadre d’un projet Agile, cet état d’esprit se cultive notamment à travers les mêlées quotidiennes, les rétrospectives et les travaux en binôme.

C’est pour cette raison que le recours au primes individuelles ou aux évaluations agrémentées d’une note (comme à l’école) sont à éviter. Ces pratiques ne font que fragiliser l’esprit d’équipe et par conséquent la réussite du projet. S’ouvrent alors d’autres possibilités d’évaluation telles que les évaluations par les pairs par exemple. Nous sommes invités à revoir les critères d’augmentation de grade et salaire souvent basés sur la note associée à la « performance » de l’individu. Pourquoi ne pas se concentrer sur l’avis des pairs et le degré d’expertise atteint (pour les profils « techniques ») ou de responsabilités acquises (pour les profils de « management »). Peut être devrions nous également revoir le terme « ressources humaines ». C’est frappant de constater à quel point un terme comportant le mot « humaines » peut véhiculer si peu d’humanité.

Enfin, l’esprit d’équipe annihile l’esprit de compétition, la rivalité entre les membres de l’équipe et augmente donc le plaisir au travail. Au contraire, la compétition limite l’innovation (« je garde pour moi ce qui me permet d’être meilleur que les autres ») et la productivité de l’équipe (« je n’aide pas mon voisin qui rencontre pourtant le même problème que j’ai surmonté hier »).

Plaisir au travail

La notion de plaisir au travail devient fondamentale. 8 heures ou plus par jour, 5 jours par semaine, sur plus de quarante ans de notre vie consacrés au travail (et aux transports en commun pour certains). Laissant si peu de place pour la vie personnelle. La nouvelle génération l’a compris et n’a pas l’intention de se sacrifier autant que les générations précédentes (même si la menace du chômage nous pousse à nous plier aux conditions de l’entreprise). Le plaisir au travail est donc capital pour soi, mais aussi pour l’entreprise qui peut perdre beaucoup en multipliant les transferts de compétences, les efforts de recrutement, les pertes de savoir faire, les arrêts maladie, le support technique sur des applications de mauvaise qualité car développées par des équipes démotivées ou sous pression, etc. Ce plaisir s’obtient généralement par l’épanouissement, qui lui même découle de l’expression de sa créativité, du développement personnel et de la participation aux décisions. Pour d’autres, une simple « bonne ambiance » suffit. Ce plaisir généré se retrouve dans le produit que l’organisation réalise ou dans le service qu’elle offre.

A l’occasion d’un recrutement, un élève terminant ses études m’a confié ceci : « Je ne cherche pas spécialement un emploi avec un super salaire et plein de responsabilités, ni même une promesse de carrière dans ce sens. Ce qui compte le plus pour moi, c’est de me sentir bien dans mon travail, avec du contact humain ».

Leader serviteur Vs Leader carpette

Il ne s’agit pas de basculer dans le chaos au sein duquel chacun y va de son point de vue et rien n’avance. Pour favoriser la convergence, l’équipe peut définir des valeurs fondamentales communes et sa mission. Si ces valeurs demeurent communes, la divergence de point de vue est alors une richesse permettant de faire de meilleurs choix au lieu faire tourner l’équipe en rond.

Le leader serviteur offre un cadre, des règles du jeu au sein duquel les membres de l’équipe (ou de la tribu à plus grande échelle) peuvent exprimer leur point de vue et participer aux décisions. La rétrospective est bien sûr un lieu d’expression et de décision tout comme la mêlée. Les décisions se prennent par consensus (tout le monde dit oui, ce qui est parfois difficile) ou par consentement (personne ne dit non). Lorsque le leader souhaite orienter l’équipe vers une autre direction, c’est à lui de convaincre comme les autres membres de l’équipe. Mais un leader qui applique les principes évoqués bénéficie d’un respect durable, la confiance est réciproque et l’équipe (ou tribu) se montre réceptive aux orientations proposées. C’est cette même confiance qui permet à un membre de l’équipe de révéler une difficulté qu’il rencontre plutôt que de la masquer (par peur des représailles), ce qui fait du leader serviteur un leader averti.

Leviers de motivation

En complément des principes évoqués plus haut, rappelons quelques leviers de motivation :

  • Donner du sens : Que nous l’exprimions ou pas, nous avons tous (ou presque) la même question en tête lorsque nous exécutons une tâche. D’autant plus si la demande associée vient de l’extérieur. Cette question est bien sûr « Pourquoi ? ». « Pourquoi dois je réaliser cette tâche ? ». Plus la réponse à cette question sera claire et en phase avec le porteur de la tâche, plus l’investissement de ce dernier et le résultat atteint seront grands.
  • Objectifs concrets, mesurables et atteignables à courts et longs termes : Une équipe a besoin d’un challenge positif auquel se mesurer. Celui ci s’obtient en fixant un ou des objectifs à long terme (donnant une vision, une perspective) mais également à court ou moyen terme permettant de se nourrir de petites victoires concrètes. Ces objectifs doivent être mesurables afin de rendre leur atteinte objective et non pas dépendante de l’opinion du leader ou du commanditaire.
  • Célébrer les petites victoires autant que les grandes : Les petites victoires sont aussi importantes que les grandes car elles nourrissent les efforts de l’équipe à long terme et contribuent à cultiver l’esprit d’équipe.
  • Rythme de travail soutenable : Participer à un projet est davantage comparable à une course de fond (type marathon) qu’à une épreuve du 100 m (même si le terme « Sprint » issu de Scrum est trompeur). La fatigue, ou pire encore, les sacrifices réalisés sur la qualité, peuvent sérieusement entamer la motivation d’une équipe. Nous devons donc promouvoir un rythme de travail soutenable en encourageant les membres de l’équipe à partir à l’heure le soir, à manger équilibré, à entretenir un sommeil de qualité. A cultiver une vie personnelle suffisamment riche pour ne plus penser au boulot (meilleure façon de porter un regard neuf sur son travail une fois de retour au boulot), à exercer une activité sportive. A rester concentré sur son travail de retour au boulot en désactivant les alertes email, tchat et sonneries de téléphone (en planifiant des pauses pour consulter ses messages et y répondre).
  • Choisir ses mots : En tant que leader ou manager, le choix des mots peut se révéler important. Chez les grandes entreprises, la tendance consiste à parler d’Industrialisation, d’Usines de développement, de Centres de services, etc. Les images véhiculées par ces termes ou d’autres peuvent se révéler néfastes auprès des équipes inquiètes de se retrouver cloisonnées, spécialisées et robotisées, que la menace soit réelle ou non. Encore une fois, le terme « Ressources Humaines » est également concerné, bien qu’universellement répandu.

Article connexe : « Introduction au leadership tribal ».

2 La tendance Agile

Bonjour,

Voici 2 tendances de recherches Google intéressantes.

Tout d’abord la comparaison des recherches sur les mots clefs « agile process » et « waterfall process » au niveau monde. On peut observer une inversion de tendance en 2005.

Puis la comparaison des recherches sur les mots clefs « scrum » et « cycle en v » sur la France. On peut observer une inversion de tendance en 2007.

Amicalement
Florent

Lettre ouverte aux décideurs

Madame/Monsieur,

Vous avez sûrement entendu parlé de l’agilité. Peut être, vous a t’on rapporté qu’il ne s’agit que d’une méthode à la mode venue de l’IT. Que l’agilité ne peut s’appliquer à votre contexte car elle s’adresse à ceux qui travaillent sans documentation, ni plan ou vision et uniquement sur des projets à taille humaine; ou encore que l’agilité n’a rien inventé car on en faisait déjà il y a 20 ans avec RAD, etc. Aussi, je vous propose d’aller au delà de ces idées reçues et d’évoquer les bénéfices concrets qu’une telle approche peut vous apporter.

La complexité des technologies et des processus métier à informatiser rendent difficile la réalisation d’une application que les utilisateurs adoptent véritablement. Le “droit à l’erreur” est devenu indispensable pour atteindre cet objectif. Le délai de mise à disposition de votre application aux utilisateurs peut également faire l’objet d’un enjeu fort.

Face à ces enjeux, l’approche Agile est un allié de choix. Elle vous offre une visibilité précieuse très tôt, toutes les 2 semaines sur les nouvelles fonctionnalités développées et utilisables. Cette visibilité permet d’aider vos utilisateurs (ou leurs représentants le cas échéant) à se projeter dans l’usage de l’application. A être de plus en plus précis dans l’expression de leur besoin. Par ailleurs, elle comporte un mécanisme d’amélioration continue de la méthodologie employée. Enfin cette démarche peut vous offrir l’opportunité de mettre en service en avance une version partielle mais utilisable de l’application. Dans le meilleur des cas, votre projet pourra s’autofinancer grâce au revenu tiré des premières versions.

Cela suppose la mise en place de rôles et de règles du jeu strictes permettant de maîtriser les enjeux de délai et de budget. Ainsi qu’une collaboration métier et IT étroite quasi quotidienne. Cette approche en rupture avec une démarche classique longuement pratiquée nécessite un accompagnement dans cette transformation. Le temps de renoncer aux anciens repères et de s’approprier les nouveaux. Cette rupture peut également vous pousser à privilégier un contrat Agile propice à une relation gagnant-gagnant entre vous et un éventuel prestataire.

Pour reprendre les propos de Jean-Pierre Chardon, l’entreprise doit avoir l’agilité du banc de poisson qui agit et réagit avec vitesse, simultanéité et précision. La maîtrise de l’approche Agile permet ce tour de force. En outre le management participatif qui lui est associé est aussi l’occasion de placer l’humain au cœur des projets pour une meilleure qualité de vie au travail.

Cordialement
Florent Lothon

Le contrat Agile

Cette semaine Xebia vient de mettre à disposition de tous un contrat Agile type sous licence Open Source. Même si c’est l’occasion de faire de la publicité, je ne peux que saluer ce geste. La contractualisation constitue l’un des freins au déploiement des méthodes Agile. En particulier en France dont la culture du forfait classique « perdant/perdant » et du clivage MOA/MOE est lourdement ancrée.

Démarche Xebia : Nous nous sommes attachés à produire un contrat équilibré, intégrant les problématiques des Directions Achats tout en ne pervertissant pas les principes agiles. Ce contrat est le fruit d’un travail réalisé par deux cabinets de conseil spécialisés sur les méthodes agiles ainsi qu’ un cabinet d’avocats assermenté par la justice française.

Résumé du contrat

Outre les clauses habituelles de confidentialité, propriété intellectuelle, etc, le contrat Agile proposé par Xébia se distingue d’un contrat classique sur différents aspects évoqués ci dessous.

Avantages client

Le changement de périmètre fonctionnel est permis. Le principe de troc (Trade in / Trade out) consistant à remplacer un besoin de plus faible valeur ajoutée par un nouveau besoin à plus forte valeur ajoutée et de coût équivalent est proposé afin de respecter les enjeux de budget et de délais. Le client pourra ainsi mettre à profit les idées qui apparaîtront en cours de route (surtout lors des démonstrations des premières fonctionnalités).

Par ailleurs, le client a la possibilité de mettre fin aux développements plus tôt que prévu en cas d’atteinte anticipée des objectifs (ce que l’approche Agile rend possible grâce au développement incrémental centrée sur la production de valeur). Dans ce cas de figure, il est également possible de prévoir une indemnité de préavis pour le prestataire.

Couleur Agile

La couleur Agile est donnée à travers la définition de l’agilité, de ses valeurs et principes. Ces valeurs telles que la transparence ainsi que la recherche de solutions amiables avant la négociation du contrat sont soulignées. Par ailleurs, le chapitre dédié aux définitions ne manque pas de décrire l’ensemble des termes méthodologiques Agile (Scrum en particulier) nécessaires à la bonne lecture du présent contrat. Le Product Backlog ainsi que le document portant la Vision du Produit sont rendus incontournables à travers leur annexion au contrat.

Phases

Le contrat définit les trois phases suivantes :

  • La phase de lancement comptant le sprint 0 de “cadrage” du projet ainsi que les 3 premiers sprints délivrant les premiers incréments du produit et permettant d’étalonner les indicateurs et métriques de pilotage du projet.
  • La phase opérationnelle durant laquelle les sprints s’enchaînent jusqu’à la livraison du logiciel attendu.
  • La phase de finalisation en cas d’atteinte anticipée des objectifs du client.

La recette réalisée par le client se décompose quand à elle en :

  • Recettes incrémentales permettant de vérifier fréquemment (à chaque sprint) la bonne couverture du besoin.
  • Une recette définitive réalisée avant la mise en production.

Engagements

Le prestataire prend ses engagements en relation avec les niveaux de service définis dans le Plan de Qualité de Service (et pénalités associées si nécessaire). Le client dont l’implication contribue également à la réussite du projet prends lui aussi des engagements (par exemple, il devra lever les obstacles remontés par l’équipe de développement dans un délai limité convenu entre les parties).

Le Plan de Qualité de Service propose des exemples d’indicateurs auxquels sont associés des objectifs et seuils d’alerte. Voici un aperçu de ces indicateurs :

  • Prédictibilité : Nombre de fonctionnalités démontrées en fin d’itération par rapport aux fonctionnalités prévues.
  • Productivité : Nombre de “story point” qui ont été implémentés dans un sprint rapporté à la taille de l’équipe.
  • Qualité fonctionnelle : Nombres d’anomalies découvertes après la livraison de l’incrément produit.
  • Qualité technique : Couverture de code par les tests unitaires et complexité cyclomatique.
  • Implication de l’équipe : Lors de chaque rétrospective, chaque membre de l’équipe du prestataire se prononce sur sa propension (sur une échelle de 1 à 5) à recommander cette équipe et ce projet à un de ses collègues.
  • Satisfaction du client : A chaque démonstration de sprint, chaque membre de l’équipe client se prononce sur sa propension (sur une échelle de 1 à 5) à recommander cette équipe et ce projet à un de ses collègues.

Modalité de paiement

Concernant les modalités de paiement, le sprint 0 est facturé au réel puis chaque sprint au forfait (avec une facturation à la fin de chaque sprint). Tous les X sprints, le montant du forfait associé à chaque sprint peut être régularisé d’un commun accord.

Pourquoi proposer Scrum ?

Ces dernières années, le mouvement Agile a pris énormément d’ampleur. En 2008, le SEI propose officiellement d’associer CMMI aux méthodes Agile. En 2009, on compte plus de 60 000 ScrumMaster certifiés contre 30 000 en 2006. Et aujourd’hui, PMI lance sa propre certification Agile. Dans cet article, je propose de décrire le raisonnement qui me pousse à proposer Scrum dans le cadre de mes missions plutôt qu’une méthode maison et d’évoquer le nouveau cursus de formation Scrum proposé par Ken Schwaber (co-créateur de Scrum).

Scrum plutôt qu’une méthode Agile maison

Aujourd’hui la majorité des SSII ont saisit l’ampleur du mouvement Agile et se sont positionnées sur le marché. Ce positionnement passe souvent par la proposition d’une méthode Agile maison. Cette méthode est souvent une adaptation de la méthode traditionnelle maison pour la rendre plus Agile et/ou un mixe de plusieurs méthodes purement Agile.

Plusieurs raisons peuvent motiver la proposition d’une méthode Agile maison :

  • Se différencier de la concurrence et espérer des retombées commerciales
  • Résister un temps soit peu au changement impliqué par le passage aux méthodes Agile en se contentant d’adapter la méthode traditionnelle maison
  • Refus de lâcher prise sur la méthode traditionnelle maison capitalisée depuis des années voir des décennies
  • Prendre le meilleur de chaque méthode et mixer le tout comme une sorte de recette secrète

Personnellement, je fais le choix de résister à cette tentation et propose principalement la méthode Scrum dans le cadre de mes missions (généralement des projets d’intégration en position MOE dans le cadre d’un forfait classique). Ci dessous, je décris les éléments qui me poussent à prendre cette orientation.

Admirez ma méthode Agile X

Imaginons le cas de figure suivant : la SSII X remporte l’appel d’offre d’un important projet pour un gros client. Le projet démarre et X met en place sa méthode Agile maison « AgileX ». Le projet se déroule pas trop mal et se solde par un succès. C’est la première fois pour ce client qu’un projet est accompli sans dérapage de délais ni de budget tout en aboutissant à un produit qui séduit les utilisateurs. Il souhaite donc généraliser cette méthode en interne, voir même l’imposer aux SSII avec lesquelles il travaille.

Je vous laisse imaginer les difficultés auxquelles ce client devra faire face :

  • Qui forme ?
  • Quelles certifications garantissent les compétences ?
  • Cette méthode est elle régulièrement améliorée et si oui, ces améliorations sont elles partagées ?
  • Faut il payer une redevance à la société X ?
  • Existe t’il un support, des ouvrages ou une communautés sur laquelle le client pourra se reposer ?
  • Les SSII accepteront-elle facilement de l’appliquer ?

Être vraiment Agile

Seule une méthode en accord parfait avec les 4 valeurs et 12 principes du manifeste Agile peut se considérer comme véritablement Agile. Ce qui élimine d’office bon nombre de méthodes maison. Seule une méthode véritablement Agile peut apporter à un client ou une entreprise tout le bénéfice qu’on attend d’elle (à condition bien évidemment de bien la mettre en oeuvre).

Choisir un « standard »

Scrum est la méthode Agile la plus utilisée parmi les autres méthodes Agile. Et de fait, la plus éprouvée. En 2009, 84% des entreprises utilisant des approches Agile utilisaient Scrum. La communauté, les nombreux retours d’expérience, les formations, les ouvrages associés sont autant d’éléments sur lesquels on peut se reposer pour mettre en place et optimiser la méthode.
D’autre part, Scrum est simple à expliquer/comprendre et en perpétuelle amélioration (on peut parler d’un authentique cercle vertueux).

L’une des particularités de Scrum est également sa revendication à n’être qu’un « framework de gestion de projet ». Cet aspect rend Scrum adaptable à de nombreux contextes (parfois même des contextes très éloignés du développement logiciel complexe voir même de l’informatique).

Voilà autant d’éléments qui mettent Scrum en position de standard (au même titre que PMI ou CMMI dans un autre registre) et qui rendent à mon sens les méthodes maison inappropriées. Du moins pour la gestion du projet proprement dite. Piocher quelques bonnes pratiques ou outils dans sa méthode traditionnelle maison peut rester pertinent du moment que les éléments utilisés s’insèrent correctement dans la méthode maître.

Du nouveau dans les cursus de formation Scrum

Après avoir argumenté sur le choix de Scrum et toujours pour rester dans l’objectif de l’article, je propose d’aborder le sujet des formations Scrum.

Là encore un évènement relativement récent à changé la donne. En effet, Ken Schwaber (co-créateur de Scrum) a quitté la Scrum Alliance. Il avait fondé cette organisation dans le but d’honorer une noble mission : celle de contribuer à « améliorer la profession du développement logiciel » sans but lucratif. La principale activité de la ScrumAlliance étant le domaine de la formation Scrum.

Malheureusement, les choses lui ont quelques peu échappé et la Scrum Alliance est devenue une entreprise visant à gagner de l’argent, se détournant ainsi de la mission première portée par Ken.

Ken a donc montée Scrum.org et propose maintenant son propre cursus de formation dans l’esprit qu’il a toujours souhaité. Grâce à lui, il est désormais possible de passer un réel examen de certification ScrumMaster sans être obligé de suivre la formation associée. On peut donc s’autoformer et passer l’examen de son choix (niveau 1 pour 100 $, niveau 2 pour 500 $). Il propose également une formation de développeur Scrum qui doit sans doute être d’une grande richesse. Le niveau d’exigence qu’il a établi en terme de méthode de formation est bien plus haut que celui de la ScrumAlliance.

Via la Scrum Alliance, la certification était « offerte » sans examen à la fin de la formation. Les choses ont changé récemment. Cependant – sauf erreur de ma part – il est toujours impossible d’obtenir une certification de la part de la Scrum Alliance sans suivre la formation associée qui est plutôt onéreuse.

Si le sujet vous intéresse, je vous invite à lire l’article suivant de Ken himself : Genesis of Scrum.org and Professional Scrum Developer.