Category Archives for "Scrum"

22

Introduction à Holacracy

La première claque professionnelle que j'ai pu recevoir en terme de remise en question sur la façon de travailler était la découverte des méthodes agiles en 2007. Depuis, c'est devenu une passion, un véritable levier de réussite sur les projets confiés aux équipes que j'accompagne dans l'apprentissage de cette approche. Et j'irai même jusqu'à dire, un art de vivre basé sur les valeurs et principes agiles. Cette année, soit 9 ans plus tard, je reçois une seconde claque. La découverte de Holacracy.

C'est cette découverte que je souhaite partager dans ce nouvel article. Le premier d'une série sur le même thème sans doute. Ca dépendra surtout de vous (cf. message en bas de cet article) 😉

Pour précision, j'utilise le terme Holacracy plutôt que la traduction française Holacratie car Holacracy est désormais une marque. A travers le dépôt de cette marque, les créateurs ont souhaité protéger l'intégrité et la qualité des services associés. Le contenu quant à lui est open source. De la même façon que Linux est une marque.

Allons au delà des idées reçues

Heureusement, ma curiosité et ma soif d'apprendre a été plus forte que les idées reçues ou intox qui gravitent autour de cette nouvelle technologie sociale et managériale qui fait polémique. L'idée reçue la plus répandue étant : "Avec Holacracy, on vire les chefs et c'est l'anarchie". C'est bel et bien une idée reçue.

Holacracy, successeur des méthodes agiles ?

Autre bonne nouvelle, Holacracy ne remplace pas les méthodes agiles pour ceux qui les utilisent. Au contraire, les équipes réellement agiles - dans le respect des valeurs et principes du manifeste agile - bénéficient d'un terreau fertile à l'adoption de Holacracy. En fait Holacracy revient à changer le "système d'exploitation" de l'organisation sur laquelle on peut conserver les "applications" utilisées (dont les méthodes agiles).

Autrement dit, le changement est plus profond. Je dirais que les méthodes agiles font l'objet d'un changement de paradigme en matière de gestion de produit et Holacracy fait l'objet d'un changement de paradigme de l'organisation qui l'adopte. L'agilité se positionne principalement à l'échelle d'une équipe ou projet là où Holacraty peut nativement s'appliquer à toute l'entreprise quelque soit sa taille ou son secteur.

Connaître les origines de Holacracy pour mieux cerner son potentiel

Pour aider à comprendre ce point, il y a une histoire à connaître. Celle de l'origine de Holacracy. Cette technologie sociale et managériale a été mise au point par des agilistes aguerris qui ont décidé de créer leur entreprise. Mais hors de question pour eux de travailler au sein d'une organisation similaire à celles dans lesquelles ou pour lesquelles ils avaient travaillé. Qui représente - il faut bien le dire - quelques inconvénients notoires (cf. illustration ci contre).

Ils devaient trouver un nouveau modèle d'organisation. L'inventer. On peut facilement imaginer l'ampleur et la complexité de la tâche. Ils ont donc eu recours au meilleur outil utilisé par les méthodes agiles pour faire face à la complexité et l'incertitude : un processus empirique. Pendant 7 ans, ils ont testé des idées, gardé ces dernières si elles s'avéraient utiles, les ont rejeté ou adapté dans le cas inverse. Pour aboutir à une première version publiée et partagée en 2009. Inutile de préciser le degré de pragmatisme et d'efficacité de cette technologie conçue selon une telle approche.

Une technologie applicable à n'importe quel secteur, n'importe quelle échelle et tenant compte des réalités du monde d'aujourd'hui devenu si complexe et incertain. Une technologie pouvant donner à une entreprise un degré d'agilité sans précédent tout en libérant les énergies et l'engagement des collaborateurs. Chacun y trouve donc son compte. Direction, actionnaires et collaborateurs.

Mais Holacracy ou l'holacratie, c'est quoi au juste ?

Holacracy, c'est quoi encore ce non barbare ? Il vient du mot "holarchie" qui décrit l'encapsulation d'élément(s) autonome(s) dans d'autres élément(s) autonomes de façon fractale. Ce qui caractérise une organisation holarchique par opposition à une organisation hiérarchique classique.

Quid du manager et du leadership en Holacracy ?

Etant particulièrement sensible au thème du management et étant moi même manager, la question de la place du manager dans une organisation fonctionnant en Holacracy n'a cessé de m'obséder durant les lectures et formations que j'ai pu suivre à propos de cette technologie. Avant d'y répondre, faisons un petit état des lieux des responsabilités généralement associées au manager dans le monde d'aujourd'hui.

Pour commencer, lorsque l'on devient manager, nous ne sommes plus seulement responsable de nous même mais aussi des autres, de son équipe. Nous devons donc fixer des objectifs, contrôler le travail et assurer le reporting de l'activité associée, au niveau hiérarchique supérieur. On prend généralement des engagements de délais voire de budget à respecter. On assure le suivi "RH" de ses collaborateurs : évolution de carrière, formation, augmentations & primes, etc. Nous devons souvent intervenir pour gérer toutes sortes de problèmes organisationnels, techniques, humains, etc. Bien sûr, nous devons définir la meilleure organisation possible pour être efficace. Parfois ou souvent, nous devons mettre à profit notre expertise pour des sujets pointus ou à fort enjeux. On attend souvent de la part du manager qu'il ait réponse à tout. Omniscient et omnipotent. Par ailleurs, dans le monde d'aujourd'hui, chaque service devient de plus en plus dépendant des autres,  la transversalité devient un enjeux fort, nous devons également assurer la coordination avec nos pairs et leurs équipes. Nous devons aussi faire redescendre l'information venant d'en haut et des "côtés" (autres équipes).

C'est déjà pas mal non ? Est ce bien raisonnable d'ailleurs ? Ne sommes nous pas en train de demander à ce manager d'être un véritable super héros (sans les super pouvoirs....) ?

Combien de temps reste t'il à ce manager - qui passe probablement beaucoup de temps à traiter ses mails ou en réunion - pour écouter les difficultés ou idées d'amélioration de son équipe pour les traiter ou les mettre en oeuvre ? Et quid de notre monde qui bouge et pousse les entreprises à se transformer en profondeur ? N'a t'on pas cruellement besoin des managers pour réaliser cette transformation ? Comment faire avec des managers saturés et souvent en souffrance ?

La réponse de Holacracy à ce problème ? Décharger le manager des tâches sur lequel sa valeur ajoutée est faible et remettre à profit son expertise pour des tâches à plus forte valeur ajoutée pour l'entreprise et lui même.

Ok, c'est bien beau tout ça, mais on arrive à la fin de l'article et on n'en sait pas beaucoup plus sur le fonctionnement concret de Holacracy. En effet, c'est ce que nous verrons dans un prochain article maintenant qu'on vient de poser le décor 😉

D'ici là, dites moi - via le formulaire situé en bas de cette page - ce que vous voulez absolument savoir à propos de Holacracy. J'essaierai de vous répondre au mieux dans le prochain article ou directement dans les commentaires.​

La théorie des contraintes : augmenter son rendement, diminuer son lead-time

Une belle théorie enveloppée dans un roman sympathique

Une lecture aussi enrichissante que distrayante

Réduire radicalement ses encours de développement et augmenter sa productivité pour un investissement minimum : telle est la promesse de la théorie des contraintes. Si l’on ajoute que cette méthode est simple et particulièrement compatible avec une approche agile dans une équipe logiciel, cela fait suffisamment de raisons pour la regarder d’un peu plus près.

La théorie des contraintes (ou ToC pour les habitués) ne date pas d’hier. A la manière du Lean, elle est née dans l’industrie il y a plus de 30 ans et n’a été importée dans le monde du développement que récemment, notamment à l’initiative de partisans de l’Agile. La bible des aficionados de la ToC s’appelle « le But », un roman d’entreprise remarquablement construit qui explique avec une clarté peu commune ses principes et sa mise en oeuvre. Son auteur, Eliahu Goldratt, a ensuite perfectionné son modèle et étendu cette approche au monde des services dans une douzaine d’ouvrages.

Continuer à lire

Lancement du SPOC d’initiation à Scrum

Suite au dépouillement des réponses au questionnaire envoyé au printemps de cette année, j'ai décidé de mettre au point un nouveau dispositif de formation et d'accompagnement afin de répondre aux objectifs suivants :

  • Aider chaque acteurs d'un projet (maîtrise d'ouvrage, PMO, chef de projet, développeur, décideurs, etc) à partager une même définition de l'approche agile et Scrum afin de collaborer le plus efficacement possible ensemble
  • Expliquer le fonctionnement concret d'une approche agile et plus particulièrement Scrum pour mener collectivement un projet
  • Préciser quels bénéfices une telle approche peut apporter à votre organisation
  • Guider vos premiers pas vers l'adoption d'un approche agile avec Scrum
  • Vous aider à éviter les principaux pièges liés à cette mise en oeuvre.

J'ai également voulu créer un environnement d'apprentissage vous permettant d'apprendre à votre rythme, d'où vous voulez avec ce sentiment d'appartenance à une communauté de personnes qui, comme vous, s'intéressent à l'agilité. Un environnement dans lequel on apprend et progresse ensemble.

Concrètement, chaque semaine en moyenne, vous accédez à un nouveau module de formation composé de vidéos que vous pourrez consulter directement en ligne sur la plateforme de formation privée. Ou télécharger, pour les visionner dans les transports en commun par exemple. A l'issue de chaque module, un quiz vous permettra d'évaluer vos connaissances.

Je répond personnellement à vos questions sur le forum de la plateforme ou pendant des sessions live. Vous pouvez vous même répondre aux questions des autres si vous le souhaitez. Saviez vous que la meilleure façon d'assimiler ses connaissances consiste à les transmettre à son tour ?

Par ailleurs, vous pouvez opter pour un parcours avancé comportant en plus des éléments déjà cités, un exercice fil rouge vous permettant de mettre en application vos connaissances sur un projet fictif.

Comptez environ 2 à 3 heures de travail par semaine en moyenne pendant 5 semaines.

Parcours du SPOC d'initiation à l'approche agile et Scrum

Parcours du SPOC d'initiation à Scrum et découverte des méthodes agiles

Voici le contenu du programme
Module 1 - L'agilité : plus qu'une méthodologie, un état d'esprit

Objectif : comprendre en quoi l'agilité est un véritable changement de paradigme à travers les valeurs et principes qu'elle véhicule et son principe général de fonctionnement

Module 2 - Scrum : focus sur la "méthode" agile la plus éprouvée

Objectif : Connaître les différentes méthodes du marché ainsi que le contenu et fonctionnement concret du cadre méthodologique Scrum, ses rôles, ses évènements et leur articulation.

Module 3 : Pilotage d'un projet Scrum

Objectif : comprendre comment piloter un projet SCRUM , et notamment les règles du jeu proposées en matière de gestion des changements sur un projet dont le délai et budget sont fixes.

Module 4 : Les bénéfices à tirer et les pièges à éviter

Objectif : Saisir les principaux bénéfices d'une approche agile tout en étant conscient des pièges à éviter et donner des pistes pour approfondir ses connaissances.

Bonus de la formation : "Extrait d'une formation Scrum Avancée"

En bonus, vous apprendrez par l'exemple une technique d'animation de la "Rétrospective". La rétrospective fait parti des pratiques agiles d'amélioration continue. Applicable à tous types de contextes, cette pratique fait aussi parti des premières "briques" généralement mises en place en cas d'adoption d'une approche agile.

Garantie "satisfait ou remboursé"

Vous avez changé d’avis ? La formation ne vous convient pas ? Vous n’avez pas le temps de participer à cette session ? Aucun souci. Vous avez 7 jours, à compter du jour de lancement de la formation, pour appliquer la procédure de remboursement sur simple demande à l’adresse contact@capitainespoc.com en précisant la raison de votre demande. Vous aurez alors deux options : Transférer votre inscription sur une session ultérieure de ce SPOC, ou d’un autre SPOC ou demander un remboursement.

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.

 

22

Enfin une vraie certification Scrum Master ?

certification-scrum
Il n’a jamais été aussi compliqué de réussir son logiciel. Les besoins des utilisateurs et les technologies en évolution permanente génèrent une grande part d’inconnus et d’imprévus. Si on ajoute à cela, le recours à l’entité la plus complexe au monde qui est l'être humain, on atteint alors des sommets en termes de complexité. C’est d’ailleurs l’une des principales raisons d’être de l’agilité, et de Scrum en particulier : "gérer des projets complexes grâce à une approche non plus prédictive (la boule de cristal n’existe pas) mais empirique". Une fois qu’on a le moyen de gérer des projets complexes, encore faut-il former des personnes à son utilisation et pouvoir garantir leur niveau de connaissance ou de maîtrise. D’où l’importance des certifications.

Les premières certifications Scrum

Il semblerait cependant que le plus grand organisme délivrant des certifications Scrum ait été dépassé par les événements et le succès des méthodes agiles. A moins qu'il ait négligé l’importance du niveau d’exigence associé à l’obtention d’une certification. En effet, il y a quelques années, il suffisait de faire acte de présence pendant deux jours pour être certifié Scrum Master par la Scrum Alliance. Je peux en témoigner, puisqu’en 2008, une certification Scrum Master m’a été délivrée à l’issue d’une formation animée par Jeff Sutherland en personne (co-créateur de Scrum) sans aucun examen préalable.

Et maintenant ?

Heureusement, la situation a évolué. Même si le mal est fait, malheureusement. Je ne compte plus le nombre de conversations évoquant tel projet ou telle équipe ayant basculé(e) dans le ScrumBut (exemples : “on utilise scrum MAIS on ne fait des mêlées que deux fois par semaines”, “on utilise Scrum MAIS on ne fait plus de rétrospective car on n’a plus rien à améliorer”, “on utilise Scrum MAIS en tant que Scrum Master, c’est moi qui affecte les tâches aux développeurs”, etc) et passent à côté des réels bénéfices de l’agilité. Et dans le pire des cas, amènent les décideurs à se forger une opinion négative, faussée et parfois définitive à propos des méthodes agiles. Pendant ce temps, la minorité qui a réussi à maîtriser l’agilité, obtient des résultats encore jamais atteints et des conditions de travail si plaisantes que les problèmes de turn-over (départs et remplacements fréquents des membres d'une équipe ou organisation) appartiennent au passé.

La vision de Scrum.org

Je disais donc que la situation a évolué. En effet, la Scrum Alliance n’offre plus la certification sans un examen préalable. On pourra cependant se demander si cet examen est suffisamment exigeant. Pour se faire une idée, il faut s’intéresser à Scrum.org créé par Ken Schwaber (l'autre co-créateur de Scrum). Commençons d’abord par la mission et la vision de Scrum.org :

Mission :

Pour améliorer la profession de développement logiciel.

Vision :

Un monde dans lequel tous les développeurs de logiciels aiment leur travail et leurs clients aiment travailler avec eux.

Ça donne déjà le ton. Précisons que le terme "développeur" utilisé ici rassemble tous les acteurs d’une équipe de développement pluridisciplinaire et non pas uniquement des “codeurs”.

Prenons maintenant, la certification Agile la plus répandue, celle de Scrum Master et comparons les niveaux d’exigence entre la Scrum Alliance et Scrum.org qui offre également des services de formation et de certification.

OrganismeConditions d’obtention de la certification Scrum Master
Scrum Alliance24 réponses juste sur un total de 35 questions soit 68% de réussite*
Scrum.org85% de réussite sur un total de 80 questions à traiter en moins d’une heure
* J’ignore si il y a une contrainte de temps pour répondre.

Notons que la Scrum Alliance rend obligatoire la participation (l'achat donc) à la formation officielle (de la Scrum Alliance) Scrum Master pour obtenir le droit de passer l’examen. Contrairement à Scrum.org qui laisse au participant le choix de se former par lui même ou via un autre organisme compétant.

Certification Professional Scrum Master II - PSM II

Mais Scrum.org ne s’arrête pas là puisqu’une seconde certification d’un niveau plus avancé est proposée. Il s’agit de la Professional Scrum Master II qui est - vous l’aurez compris - beaucoup plus exigeante.

Description officielle :

L’examen Professional Scrum Master niveau 2 (PSM II) est disponible pour toute personne qui a passé avec succès l’examen PSM I et souhaite démontrer sa capacité à appliquer le cadre Scrum pour résoudre des problèmes complexes dans le monde réel. Ceux qui passent l’examen avec succès reçoivent une certification PSM II reconnue par l'industrie comme une indication de leurs capacités.

Quiconque tente l’examen PSM II doit avoir une expérience approfondie de Scrum et / ou ont suivi le cours Professionnal Scrum Master avant de passer cet examen. Toutefois, assister à un cours n'est ni nécessaire ni suffisant pour la certification. L'examen de la PSM II est incroyablement difficile, et se compose de questions à choix multiples, des questions d'études de cas et des essais.

L’examen consiste à répondre à un questionnaire en ligne composé de QCM et d'essais en anglais en moins de 120 minutes. Ce qui ne laisse pas le temps de chercher les réponses dans un livre ou sur internet. Dans mon cas, c’était 34 questions au total avec une majorité d’essais. Là encore, il faut dépasser les 85% de réussite. La description est fidèle à ce que j’ai ressenti en préparant et passant l’examen.

L'Agility Path pour l'entreprise toute entière

Je sors un peu du sujet pour préciser Scrum.org propose également une démarche simple baptisée Agility Path permettant d'étendre l'agilité à l'entreprise toute entière afin de la rendre plus compétitive. L'idée maîtresse est de ne pas tomber dans le piège consistant à établir à l'avance un plan de transformation agile sur X années puis de l'exécuter, mais plutôt de voir une telle transformation comme un projet complexe (or je rappelle que Scrum a été créé pour mener des projets complexes). Vous l'aurez sans doute compris, il s'agit d'utiliser les principes de Scrum pour mener cette transformation. La mise en place d'indicateurs de mesure est donc incontournable pour établir un bon niveau de transparence permettant de rendre l'entreprise auto-apprenante.

2

Les évolutions de Scrum de 2011 et 2013

Guide ScrumScrum est un cadre méthodologique ouvert. Leurs créateurs ont su rester à l’écoute des praticiens experts du monde entier pour faire évoluer Scrum en fonction des retours d’expérience de ces derniers. Aujourd’hui, il existe même un formulaire pour soumettre des propositions de modification du guide Scrum. S’intéresser à ces évolutions de Scrum permet de mieux comprendre certains de ses aspects, certaines de ses subtilités et ce qui fait son identité actuelle.

Les évolutions de 2011

La fin des poulets et des cochons

On a longtemps utilisé la métaphore des poulets et des cochons pour distinguer les niveaux d’engagement des acteurs et les règles du jeu associées. Pour rappel ou précision, cette métaphore partait de l’histoire du poulet qui propose au cochon d’ouvrir un restaurant et de l’appeler « jambon et œufs » et le cochon de répondre « non merci, je serai engagé alors que tu seras seulement impliqué (le poulet à juste des œufs à donner alors que le cochon…) ». Cette métaphore servait à illustrer le fait que l’équipe Scrum ayant un niveau d’engagement plus fort que des parties prenantes, elle doit avoir un pouvoir de décision et d’auto-organisation plus important.

Seulement voilà, le recours à cette métaphore pouvait fonctionner à l’époque où Scrum était peu connu. Mais entre temps, l’utilisation de Scrum s’est étendu aux grandes entreprises « sérieuses ». Difficile donc de parler de poulets et de cochons dans ces conditions. D’autre part, Scrum cherche à favoriser la collaboration de toutes les parties prenantes et catégoriser ainsi les individus ne va forcément dans ce sens.

D’où la disparition des poulets et des cochons du guide officiel Scrum.

Ordonnancer le Product Backlog plutôt que le prioriser

Trier les éléments du Product Backlog par priorité est une technique parmi d’autres. Je me souviens qu’une de mes premières mise en pratique à ce sujet avait consisté à calculer le coefficient « valeur ajoutée/coût-complexité » et à trier les éléments dans un tableur du plus grand au plus petit coefficient. Je me suis vite rendu compte des limites de cette technique. Au mieux, elle permet de dégrossir le travail. Le Product Owner a donc un travail d’analyse (de dépendance par exemple) et de décisions à faire pour ordonner correctement le Product Backlog. D’où le changement de vocabulaire.

Le nouveau Sprint Backlog

L’ancienne version du guide officiel Scrum avait tendance à trop « normer » le Sprint Backlog, laissant peu de souplesse et peu de place à la créativité. La nouvelle définition du Sprint Backlog y remédie en permettant de mieux s’adapter au contexte de chacun.

Disparition de la planification de release (ou version) et du release burndown chart

Cette évolution peu surprendre voire choquer, mais vous allez voir que l’explication tient la route (selon moi en tout cas). Si on se replonge dans le manifeste Agile, le premier principe nous dit « Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée. ». Or l’utilisation de release va plutôt dans le sens d’une livraison tardive du produit (après plusieurs sprints). Alors qu’une bonne utilisation des pratiques de développement peut permettre une livraison à chaque sprint. Je pense même que le succès grandissant des approches Kanban et de livraison continue ne sont pas sans lien avec ce changement. Avec de telles approches, la notion même d’itération/sprint est remise en question.

Quoiqu’il en soit, la planification de release ou version et l’utilisation du release burndow chart ne sont pas de mauvaises pratiques pour autant et prennent tout leur sens dans certains contextes. Notamment, lorsque le rythme de livraison aux utilisateurs doit rester raisonnable.

Disparition de la notion d’engagement

Voilà une évolution qui a fait et fait encore débat.

Voici mon point de vue sur la question. L’équipe de développement ne peut porter seule l’engagement de terminer les éléments du sprint backlog d’ici la fin de ce dernier. En raison notamment de la part d’inconnus fonctionnels, techniques ou autres (ex : indisponibilité du Product Owner, interruptions, absence imprévue d’un membre de l’équipe) qui persiste. Il ne s’agit donc pas de prendre un engagement sans être sûr de pouvoir le tenir. D’autre part, prendre un engagement implique des effets négatifs en cas d’échec, en particulier sur la qualité, la motivation, la fiabilité des estimations et la capacité de l’organisation toute entière à tirer des leçons de cet échec. Si engagement il y a, il doit donc être collectif impliquant non seulement l’équipe de développement mais également le Product Owner, le métier et le management. L’équipe de développement seule, prend toutefois un engagement : se focaliser sur l’objectif du sprint (qui répond au “Pourquoi” on fait cette itération), prévenir au plus tôt le Product Owner si la tenue de cet objectif est en péril, livrer des fonctionnalités utilisables en fin d’itération et s’améliorer sans cesse.

Les évolutions de 2013

Renforcement de la notion de transparence

La notion de transparence a été particulièrement renforcée dans le guide avec un paragraphe dédié. L’objectif étant de favoriser la transparence en soulignant le fait que sans transparence, de mauvaises décisions peuvent être prises.

Les artefacts (Product Backlog, Sprint Backlog et Incrément notamment) doivent donc être visibles et compris de tous de la même façon.

La planification monobloc et l’objectif de sprint

Cette évolution met fin à la séparation en deux phases de la planification de sprint laissant ainsi plus de liberté et de créativité aux praticiens de Scrum. Cette séparation avait peu d’intérêt et qui sait, pouvait même être néfaste dans certains contextes. Par exemple dans le cas d’une collaboration pleine et entière entre le Product Owner et l’équipe de développement. En effet, dans ce cas là, pourquoi séparer les « quoi » du « comment » dans le temps et les acteurs avec ?

L’objectif de sprint quant à lui est clarifié et favorise ainsi la canalisation du travail de l’équipe de développement et le travail (esprit) d’équipe. Cet objectif peu consister à réaliser une fonction donnant une cohérence d’ensemble du sprint ou tout autre cohérence invitant l’équipe de développement à travailler ensemble plutôt que sur la base d’initiatives personnelles. Pour rappel, l’objectif de sprint donne une certaine flexibilité à l’équipe de développement sur la façon d’implémenter la fonctionnalité au cours du sprint (sur le « comment » donc).

« Affinage » du Product Backlog et notion de « prêt »

En anglais le terme « Grooming » (qui ne convenait pas aux anglais et était peut être un peu trop argotique) est remplacé par le terme plus heureux de « Refinement » (affinage). Le tout pour décrire l’activité d’affinage du Product Backlog permettant de rendre se dernier « prêt » pour la planification de sprint. C’est donc également l’occasion d’insister sur cette notion de « prêt » consistant a avoir en entrée de planification de sprint suffisamment d’éléments clairs (avec peu d’inconnus), fins (réalisables dans le sprint) et correctement estimés.

Assouplissement des timebox des événements

Le guide continue à donner une durée maximale pour les événements Scrum. Comme par exemple les 8 heures pour la planification d’un sprint de 4 semaines. Il normalise cependant moins ces durées pour les sprints plus courts. L’ancienne version nous orientait sur des durées maximales inférieurement proportionnelle (ex : 4 heures pour des sprints de 2 semaines).

L’intérêt est de cet assouplissement est de laisser libre court à des initiatives visant par exemple à réduire davantage la durée maximale d’une planification de sprint en s’obligeant à affiner davantage le Product Backlog en amont. Il est clair qu’une planification de sprint est beaucoup moins laborieuse lorsque qu’on se pose peu de questions. Et celle ci se termine lorsque les questions ont trouvé leurs réponses et que l’objectif du sprint est clair. On favorise ainsi une bonne pratique tout en offrant davantage de souplesse afin de s’adapter au contexte de chacun.

Modification des questions de la mêlée quotidienne

Les questions de la mêlée quotidienne sont passé de :

  • Qu’est que j’ai réalisé (ou terminé) depuis la dernière mêlée ?
  • Qu’est ce que je compte réaliser (ou terminer) d’ici la prochaine mêlée ?
  • Quels obstacles je rencontre ?

à :

  • Qu’est ce que j’ai fait hier qui a aidé l’équipe de développement à atteindre l’objectif du sprint ?
  • Qu’est ce que je vais faire aujourd’hui qui va aider l’équipe de développement à atteindre l’objectif du sprint ?
  • Est ce que je vois un obstacle qui risque de m’empêcher ou d’empêcher l’équipe de développement d’atteindre l’objectif du sprint ?

Ce changement permet de renforcer la concentration de l’équipe sur l’objectif (commun) du sprint et de mettre l’accent sur le travail d’équipe. Il vise donc à modifier positivement la dynamique de groupe.

Renforcement de la notion de valeur

La notion d’apport de valeur a été renforcé un peu partout dans le guide.

Principale source

Voici ci dessous la vidéo (en anglais) dans laquelle Jeff Sutherland et Ken Schwaber (les créateurs de Scrum) expliquent les évolutions apportées en 2013. Ils commencent par un bilan de l’évolution de Scrum et rappellent deux événements majeurs en faveur de l’agilité. A savoir, le Gartner qui exhorte les organisations à abandonner le cycle en V au profit de l’agilité et même discours du Standish Group dont les dernières statistiques sont sans appel : seulement 14% des projets réalisés en Cycle en V réussissent (délais respecté, budget respecté et utilisateurs satisfaits) contre 42% (soit 3 fois plus) pour les projets menés en approche Agile.

D’après moi, ce second chiffre est amené à augmenter avec la maîtrise grandissante des principes et pratiques agile et l’évolution culturelle. Scrum est simple mais difficile 😉

17

Introduction aux méthodes agiles et Scrum

Vous avez surement entendu parlé des méthodes agiles ou de la méthode agile. Certains la perçoivent comme une énième méthodologie à la mode, difficilement compatible avec leur contexte. Surtout dans le cadre d'un contrat au forfait. Qu'est ce que l'approche agile au juste ? D'où vient-elle ? Comment s'applique-t-elle concrètement ? Voilà ce dont traite cette introduction aux méthodes agiles et à Scrum en particulier.

Approche Agile plutôt que méthode Agile

Si l'approche agile est nouvelle pour vous, il me semble important de partir sur de bonnes bases. Laissez moi vous dire au passage, que je suis honoré d'être votre guide vers ce nouvel horizon.

Le terme "méthode" est trop réducteur pour parler de cette façon d'aborder la gestion de projet. Il s'agit de bien plus qu'une méthode. On parle plutôt de paradigme agile, d'état d'esprit agile, de philosophie agile, de culture Agile ou encore d'approche agile, de mouvement agile, de courant agile, etc. En poursuivant votre lecture et en concentrant notamment votre attention sur le paragraphe "Le Manifeste Agile, un changement culturel", vous comprendrez mieux cette dimension cruciale.

On parle cependant de "méthodes agiles" pour définir les méthodes qui relèvent de ce courant.

Une autre approche de gestion de projet

Le terme "agile" définit une approche de gestion de projet qui prend le contre-pied des approches traditionnelles prédictives et séquentielles de type cycle en V ou waterfall (en cascade). La notion même de "gestion de projet" est remise en question au profit de "gestion de produit". De façon à raisonner davantage "produit" que "projet". Après tout l'objectif d'un projet consiste bien à donner naissance à un produit.

Une approche dite "traditionnelle" attend généralement du client une expression détaillée et validée du besoin en entrée de réalisation, laissant peu de place au changement. La réalisation dure le temps qu'il faut et le rendez vous est repris avec le client pour la recette. Cet effet tunnel peut être très néfaste et conflictuel, on constate souvent un déphasage entre le besoin initial et l'application réalisée. On se rapporte alors aux spécifications validées et au contrat. Certains projets se terminent dans la douleur (surtout dans le cadre d'un contrat au forfait classique) au risque de compromettre la relation client. De plus il n'est pas rare que certaines fonctionnalités demandées se révèlent finalement inutiles à l'usage alors que d'autres, découvertes en cours de route, auraient pu donner plus de valeur au produit.

Une enquête de 1994 du « Standish Group » (certes controversée, comme toutes les enquêtes qui traitent d'un sujet sensible) fait le constat suivant : « 31 % des projets informatiques sont arrêtés en cours de route, 52 % n'aboutissent qu'au prix d'un important dépassement des délais et du budget tout en offrant moins de fonctionnalités qu'il n'en était demandé ; seuls 16 % des projets peuvent être considérés comme des succès. ».

Cette même enquête renouvelée en 2008 indique un taux de réussite de 35%, ce qui est plutôt positif mais demeure très faible. Le problème reste entier. Parmi les motifs d'échecs, arrivent en tête :

  • Manque d'implication des utilisateurs finaux : 12,8 %.
  • Changements de spécifications en cours de projet : 11,8 %.

L'approche Agile propose au contraire de réduire considérablement voire complètement cet effet tunnel en donnant davantage de visibilité, en impliquant le client du début à la fin du projet et en adoptant un processus itératif et incrémental. Elle considère que le besoin ne peut être figé et propose au contraire de s'adapter aux changements de ce dernier. Mais pas sans un minimum de règles.

Anthony Bleton de Novius; dans la vidéo ci dessous intitulée Oubliez le cahier des charges, soyez agiles !; explique très bien en quoi l'approche agile se distingue de l'approche traditionnelle. Le tout en moins de 4 minutes, belle performance !

Fonctionnement des méthodes agiles

Les méthodes agiles partent du principe que spécifier et planifier dans les détails l'intégralité d'un produit avant de le développer (approche prédictive) est contre productif. Cela revient à planifier dans les détails un trajet "Paris - Narbonne" en voiture par les petites routes. Spécifiant chaque villes et villages traversés, l'heure de passage associée, chaque rue empruntée dans les agglomérations, litres d'essence consommés, kilomètres parcourus, etc. Les imprévus ne manqueront pas d'arriver : embouteillages, déviations, travaux, sens de circulation inversés, voire la panne, etc. Rendant votre planification et vos spécifications très vite obsolètes. Combien de temps aurez vous passé à planifier cet itinéraire, comment réagirez vous face à vos frustrations de ne pas pouvoir appliquer votre plan à la lettre ?

L'idée consiste à se fixer un premier objectif à courts termes (une grande ville par exemple) et se lancer sur la route sans tarder. Une fois ce premier objectif atteint, on marque une courte pause et on adapte son itinéraire en fonction de la situation du moment. Et ainsi de suite jusqu'à atteindre la destination finale. On parle donc d'une approche empirique. Dans le cadre d'un projet de développement logiciel, le client élabore sa vision du produit à réaliser et liste les fonctionnalités ou exigences de ce dernier. Il soumet cette liste à l'équipe de développement, communique directement avec elle (plutôt que par papier) qui estime le coût de chaque élément de la liste. On peut ainsi se faire une idée approximative du budget global.

L'équipe sélectionne ensuite une portion des exigences à réaliser dans une portion de temps courte appelée itération. Chaque itération inclut des travaux de conception, de spécification fonctionnelle et technique quand c'est nécessaire, de développement et de test. A la fin de chacune de ces itérations, le produit partiel mais utilisable est montré au client. Ce dernier peut alors se rendre compte par lui même très tôt du travail réalisé, de l'alignement sur le besoin. L'utilisateur final quant à lui peut se projeter dans l'usage du produit et émettre des feedbacks précieux pour les futures itérations. La visibilité ainsi offerte est clef. Cette transparence peut également apporter davantage de confiance et de collaboration dans la relation client/fournisseur. Les risques quant à eux sont levés très tôt.

Si le client a priorisé avec soin son besoin, il peut saisir l'opportunité d'accélérer le "time to market" si il estime que le produit en l'état (partiel) peut aller en production. Économisant ainsi son budget et récoltant un premier retour sur investissement. Il a aussi la possibilité de changer en cours de route la priorité des fonctionnalités qui n'ont pas encore été développées (prévues pour les itérations futures). Afin de retarder une fonctionnalité dont le besoin n'est pas mûr, ajouter une nouvelle fonctionnalité cruciale en échange du retrait d'une autre (respectant ainsi budget et délais), etc.

Cette souplesse ainsi offerte est donc un véritable atout pour le client.

Témoignage client

Quels ont été les avantages de ces méthodes pour votre projet ?

Déjà, on voit concrètement l’évolution du projet car après chaque itération, les utilisateurs peuvent visualiser un « bout » de projet qui fonctionne, ça brise l’effet tunnel des méthodes classiques. Cette évolution nous permet de prioriser nos réels besoins, l’application s’enrichit selon nos demandes. Le surplus n’existe pas, on ne développe pas des fonctionnalités qui ne nous serviront jamais comme c’est régulièrement le cas en adoptant des méthodes classiques. On atteint un bénéfice utilisateur plus rapidement mais aussi un gain financier non négligeable. Nous n’imaginons même pas un retour avec des méthodes classiques.

Thierry Roche

DSI de l'APEC

Source : Le Monde Informatique | Dossier méthodes agiles : Le renouveau des relations client/fournisseurs.

Historique des méthodes agiles

Sans rentrer dans les détails, la première chose à savoir est que l'approche Agile n'est pas un effet de mode né de la dernière pluie. En effet la première approche de gestion de projet de développement itératif date de 1986. La première mise en œuvre de la méthode Scrum (la méthode Agile la plus utilisée, documentée et éprouvée aujourd'hui) date de 1993.

La seconde concerne un événement majeur rassemblant, en 2001, dix sept figures éminentes du développement logiciel pour débattre du thème unificateur de leurs méthodes respectives. De cet événement est né le Manifeste Agile rassemblant à la lueur des expériences de chacun les critères pour définir une nouvelle façon de développer des logiciels. Le terme "Agile" pour qualifier ce type de méthode est également né à cette occasion.

Aujourd'hui ces méthodes ont fait leurs preuves. Tout le monde (dans le monde de l'informatique) ou presque a au moins entendu parler d'une méthode Agile (Scrum, eXtreme Programming, RAD, Chrystal Clear,...). L'outillage associé est maintenant disponible sur le marché y compris dans le secteur Open Source. Les formations, certifications, conférences, livres, blogs se sont multipliés. Nous pouvons également noter la prise de position en faveur de l'approche Agile de la part des organismes faisant "autorité" en matière de gestion de projet informatique :

Le Manifeste Agile, un changement culturel

Le manifeste Agile contient l'essence et la philosophie de l'approche en question. Il illustre à lui seul le changement culturel profond qui est en jeu.

Nous découvrons comment mieux développer des logiciels par la pratique et en aidant les autres à le faire. Ces expériences nous ont amenés à valoriser :

  • Les individus et leurs interactions plus que les processus et les outils
  • Des logiciels opérationnels plus qu’une documentation exhaustive
  • La collaboration avec les clients plus que la négociation contractuel
  • L’adaptation au changement plus que le suivi d’un plan

Nous reconnaissons la valeur des seconds éléments, mais privilégions les premiers.

ATTENTION AUX IDÉES REÇUES


La dernière phrase a son importance car si on néglige sa lecture, on peut tomber dans les idées reçues très répandues du style : "Sur un projet agile, il n'y a pas de spécifications, de plan, de processus, d'outil et même pas de contrat".

Au passage, passons en revue d'autres idées reçues "Un projet Agile ne fonctionne que sur des projets de développement web, qu'avec une dizaine de personnes maximum, qu'avec des super développeurs" ou encore "sur un projet agile, le client change d'avis tout le temps et on tourne en rond à faire et défaire des choses".

Principes sous-jacents au Manifeste Agile

Nous suivons ces principes :

  1. Notre plus haute priorité est de satisfaire le client en livrant rapidement et régulièrement des fonctionnalités à grande valeur ajoutée.
  2. Accueillir positivement les changements de besoins, même tard dans le projet. Les processus Agiles exploitent le changement pour donner un avantage compétitif au client.
  3. Livrer fréquemment un logiciel opérationnel avec des cycles de quelques semaines à quelques mois et une préférence pour les plus courts.
  4. Les utilisateurs ou leurs représentants et les développeurs doivent travailler ensemble quotidiennement tout au long du projet.
  5. Réaliser les projets avec des personnes motivées. Fournissez-leur l’environnement et le soutien dont ils ont besoin et faites-leur confiance pour atteindre les objectifs fixés.
  6. La méthode la plus simple et la plus efficace pour transmettre de l’information à l'équipe de développement et à l’intérieur de celle-ci est le dialogue en face à face.
  7. Un logiciel opérationnel est la principale mesure d’avancement.
  8. Les processus agiles encouragent un rythme de développement soutenable. Ensemble, les commanditaires, les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
  9. Une attention continue à l'excellence technique et à une bonne conception renforce l’agilité.
  10. La simplicité – c’est-à-dire l’art de minimiser la quantité de travail inutile – est essentielle.
  11. Les meilleures architectures, spécifications et conceptions émergent d'équipes auto-organisées.
  12. À intervalles réguliers, l'équipe réfléchit aux moyens de devenir plus efficace, puis règle et modifie son comportement en conséquence.

Le cadre méthodologique Scrum

Je vous propose maintenant de zoomer sur l'une des méthodes Agile existantes afin de vous montrer plus concrètement le fonctionnement. Pourquoi traiter de Scrum en particulier ? Tout simplement parce que Scrum est de très loin la méthodologie la plus utilisée parmi les méthodes agiles existantes. Elle est donc la plus éprouvée, documentée et supportée. Livres, blogs, formations, vidéos, associations, conférences traitant de Scrum ne manquent pas et bon nombre de ces ressources sont accessibles gratuitement. On pourrait pratiquement parler d'un standard Agile. Un autre atout important : Scrum est simple à comprendre. Sa maîtrise est en revanche difficile.

Le "package" Scrum

Processus de la méthode Scrum

Processus Scrum

Scrum est considéré comme un cadre ou « framework » de gestion de projet. Ce cadre est constitué d'une définition des rôles, de réunions et d'artefacts.

Scrum définit 3 rôles :​

  • Le « Product Owner » qui porte la vision du produit à réaliser (représentant généralement le client).
  • Le « Scrum Master » garant de l'application de la méthodologie Scrum.
  • L'équipe de développement qui réalise le produit.

La vie d'un projet Scrum est rythmée par un ensemble de réunions clairement définies et strictement limitées dans le temps (timeboxing):

  • Planification du Sprint (Sprint = itération) : au cours de cette réunion, l'équipe de développement sélectionne les éléments prioritaires du « Product Backlog » (liste ordonnancée des exigences fonctionnelles et non fonctionnelles du projet) qu'elle pense pouvoir réaliser au cours du sprint (en accord avec le « Product Owner »).
  • Revue de Sprint : au cours de cette réunion qui a lieu à la fin du sprint, l'équipe de développement présente les fonctionnalités terminées au cours du sprint et recueille les feedbacks du Product Owner et des utilisateurs finaux. C'est également le moment d'anticiper le périmètre des prochains sprints et d'ajuster au besoin la planification de release (nombre de sprints restants).
  • Rétrospective de Sprint : la rétrospective qui a généralement lieu après la revue de sprint est l'occasion de s'améliorer (productivité, qualité, efficacité, conditions de travail, etc) à la lueur du "vécu" sur le sprint écoulé (principe d'amélioration continue).
  • Mêlée quotidienne : il s'agit d'une réunion de synchronisation de l'équipe de développement qui se fait debout (elle est aussi appelée "stand up meeting") en 15 minutes maximum au cours de laquelle chacun répond principalement à 3 questions : « Qu'est ce que j'ai terminé depuis la dernière mêlée ? Qu'est ce que j'aurai terminé d'ici la prochaine mêlée ? Quels obstacles me retardent ? »

L'organisation générale

Travaux préparatoires

L'approche Scrum propose de commencer par lister les exigences du client afin de produire le « Product Backlog ». Voir l'exemple ci dessous pour la réalisation d'un site d'e-commerce :

Elément du backlogEstimation
Un internaute peut rechercher un article selon différents critères5
Un gestionnaire du catalogue de produits peut ajouter des articles2
L'internaute peut acheter en ligne un ou plusieurs articles3
......

L'unité de coût (ou complexité) de la colonne "Estimation" est arbitraire, on procède généralement par relativité en définissant un étalon de base. Par exemple, "voir le détail d'un article" étant une exigence simple, elle servira d'étalon et son estimation convenue sera par exemple de "1 point", "modifier les caractéristiques d'un article" étant 2 fois plus compliquée, son estimation sera de "2 points", etc. Le recours à une telle unité (plutôt que des jh ou €) permet de faciliter l'ordonnancement du Product Backlog, la planification des sprints et des releases. D'autre part il souligne le fait qu'il ne s'agit que d'une estimation (par définition fausse) et non pas un chiffrage en tant que tel.

Le Product Owner ordonnance ensuite la liste en fonction de la valeur ajoutée métier, du coût estimé de chaque exigence et des risques identifiés. Les exigences seront réalisées dans l'ordre ainsi défini selon les contraintes de l'équipe de développement et les éventuelles dépendances (exigence D à faire avant l'exigence X). On fixe ensuite la durée des sprints durant laquelle un certain nombre d'éléments du « Product Backlog» seront réalisés. L'objectif de Scrum consiste à produire le plus tôt possible la plus grande valeur possible, afin de créer des opportunités d'accélération du "Time to market".

Enchaînement des sprints

Une fois que le Product Backlog est prêt et que la durée du sprint est fixée en accord avec le client, il n'y a plus qu'à remplir le sprint avec des éléments du Product Backlog (planification de sprint). C'est également à ce moment que le Product Owner exprime plus précisément son besoin (qu'il aura affiné au préalable) pour permettre à l'équipe de développement d'estimer plus précisément la charge de travail du sprint. Inutile pour autant de réaliser la conception détaillée en séance, des ateliers dédiés pourront avoir lieu en cours de sprint. Le Product Owner peut à tout moment revoir la priorité des exigences qui n'ont pas encore été planifiées dans le sprint en cours. En revanche, les exigences engagées dans le sprint en cours sont "sanctuarisées", seule l'équipe de développement à le pouvoir de modifier le périmètre du sprint en cas d'avance ou de retard.

Chaque sprint se termine par la revue de sprint suivie de la rétrospective. Le sprint suivant s’enchaîne à la suite selon le même cycle et ainsi de suite jusqu'au dernier sprint de la release.

Mesure de l'avancement

Exemple de graphique d'avancement de release

Exemple de graphique d'avancement de release.

Grâce aux estimations individuelles des exigences du « Product Backlog » ainsi qu'à la segmentation en sprints, on peut aisément produire un graphique de suivi d'avancement représentant l'évolution du travail accompli en fonction du temps (voir illustration ci contre : total de "points" d'estimation des exigences terminées en bleu et charge totale de "points" de la release en rouge).

La contractualisation agile

La contractualisation d'un projet agile n'est pas la partie la plus facile étant donné que le périmètre est par définition variable. La régie ferait bien l'affaire mais difficile de rassurer le client avec un tel contrat. En France et ailleurs, le contrat au forfait domine; surtout sur les gros projets. Malheureusement pour le fournisseur - dans le cadre d'un forfait classique - tous les risques sont pour lui (aussi bien sur un projet agile que sur un projet traditionnel). On peut limiter ces risques en prenant quelques précautions, mais on limite également la souplesse offerte par une approche Agile.

Cela ne veut pas dire qu'il n'existe pas de solutions. La forfaitisation de chaque itération avec la possibilité pour le client d'arrêter le contrat à la fin de chaque itération est assez intéressante. Ainsi que le principe de troc d'exigence : réalisation d'une exigence imprévue en échange du retrait d'une autre moins importante, de priorité faible et de même coût.

Voici quelques liens qui traitent du sujet :

Vous souhaitez allez plus loin ?

Visitez la rubrique "Par où commencer ?". Vous y trouverez par exemple, le guide de démarrage Scrum ainsi que des vidéos d'introduction.

12

Guide de démarrage Scrum

La méthode Scrum (« Scrum » signifie « Mêlée » en anglais), ou plus exactement le cadre méthodologique Scrum est de loin la méthode Agile la plus utilisée dans le monde. Expérimentée en 1993, elle bénéficie aujourd’hui de nombreux retours d’expérience. Les conférences, communautés, formations, blogs, outils et ouvrages à son sujet ne manquent pas.

L’objectif de cet article est de vous aider à vous lancer dans la mise en oeuvre de Scrum. Il décrit le processus associé, ses étapes, réunions, rôles, etc. Dès que les limites de cet article seront atteintes, la lecture du Guide Scrum (20 pages, gratuit, complet et traduit en français) puis du livre « Scrum et XP depuis les tranchées » (160 pages, également gratuit, complet et traduit en français) est recommandée. Pour une meilleure compréhension de cet article, il est préférable d’avoir assimilé les principes Agile. Au besoin, je vous invite à lire la fiche pratique « Introduction aux méthodes Agile ».

Au sujet de Scrum

Parler d’une « méthode » concernant Scrum n’est pas ce qu’il y a de plus approprié. Scrum ne se considère pas comme une méthode mais comme un cadre méthodologique. Une méthode dit généralement « comment » faire les choses. Scrum ne dit pas comment réussir son logiciel, comment surmonter les obstacles, comment développer, comment spécifier, etc. Il se contente d’offrir un cadre de gestion de projet Agile (et c’est déjà beaucoup) : des rôles, un rythme itératif, des réunions précises et limitées dans le temps, des artefacts (product backlog, sprint backlog, graphique d’avancement) et des règles du jeu.

Au sein de ce cadre méthodologique de gestion de projet, les acteurs ajustent empiriquement, au fil des itérations, leur propre méthode en fonction de leur contexte. On peut qualifier Scrum de simple, pragmatique, transparent et empirique. Scrum ne couvrant que les aspects de gestion de projet, c’est souvent la méthodeeXtreme Programming (XP) qui vient compléter le vide laissé en matière de pratiques de développement. XP apporte ainsi les pratiques de programmation en binôme, de développement piloté par les tests (TDD ou Test Driven Development), intégration continue, etc. Ces dernières jouent un rôle capital pour relever le défi du développement incrémental. Le mouvement Software Craftsmanship est également là pour répondre à ces enjeux techniques.

NB : Sachez que eXtreme Programming couvre également efficacement les aspects de gestion de projet, faisant d’elle l’une des méthodes Agile les plus complète qui existe.

Utilisation de Scrum

Méthode Scrum

Processus Scrum (source des icônes des personnages : Mike Cohn)

Pré requis recommandés

  • Un grand mur libre et dégagé dans l’espace de travail de l’équipe.
  • Blocs de post-it et marqueurs.
  • L’ouvrage « Scrum et XP depuis les tranchées ».
  • Jeu de cartes ou logiciel de Planning Poker.

Les Rôles en bref

Scrum définit seulement 3 rôles :

  • Le Product Owner qui porte la vision du produit à réaliser et travaille en interaction avec l’équipe de développement. Il s’agit généralement d’un expert du domaine métier du projet.
  • L’Equipe de Développement qui est chargée de transformer les besoins exprimés par le Product Owner en fonctionnalités utilisables. Elle est pluridisciplinaire et peut donc encapsuler d’autres rôles tels que développeur, architecte logiciel, DBA, analyste fonctionnel, graphiste/ergonome, ingénieur système.
  • Le Scrum Master qui doit maîtriser Scrum et s’assurer que ce dernier est correctement appliqué. Il a donc un rôle de coach à la fois auprès du Product Owner et auprès de l’équipe de développement. Il doit donc faire preuve de pédagogie. Il est également chargé de s’assurer que l’équipe de développement est pleinement productive. Généralement le candidat tout trouvé au rôle de Scrum Master est le chef de projet. Celui ci devra cependant renoncer au style de management « commander et contrôler » pour adopter un mode de management participatif.

Vision du produit et product backlog

La première étape consiste à formaliser la vision du produit (logiciel) que l’on souhaite réaliser. Cette vision décrit les principaux objectifs, jalons, utilisateurs visés. Elle contribuera à guider et fédérer les acteurs du projet. La suite consiste à établir la liste des exigences fonctionnelles et non fonctionnelles du produit. Chaque exigence est ensuite estimée par l’équipe de développement avec la technique de Planning Poker. A la lueur des estimations, la liste ainsi complétée est ordonnancée. Les exigences seront converties en fonctionnalités utilisables selon cet ordonnancement. Le principe étant de convertir en premier les exigences qui apportent le plus de valeur ajoutée (ou ROI) au commanditaire. Il s’agit donc de faire remonter les exigences fonctionnelles de la plus haute valeur ajoutée (ou dont le ROI est le plus élevé) en haut de la liste. Cette liste est appelée le Product Backlog. Le Product Backlog servira à piloter l’équipe de développement et pourra évoluer tout au long du projet. Le changement est non seulement autorisé mais encouragé afin de pouvoir éliminer les idées de départ qui s’avéreront mauvaises et de prendre en compte les nouvelles idées qui arriveront en cours de route. Cette activité de construction du Product Backlog est collaborative, elle implique le Product Owner et l’équipe de développement.

ET DANS LE CAS D'UN APPEL D'OFFRE ?

Vous répondez à un appel d’offre pour la réalisation du logiciel de votre client ? Vous ne pouvez pas construire le Product Backlog avec lui ? Dans ce cas, vous pouvez partir du cahier des charges, extraire de ce dernier les exigences, les estimer (idéalement avec 3 membres de l’Equipe de Développement pressentie) et initialiser ainsi le Product Backlog. Vous pouvez également aller plus loin en proposant un premier ordonnancement.

Pondérer chaque exigence d’une valeur ajoutée n’est pas toujours évident pour une équipe métier (MOA) novice. Différentes techniques s’offrent à vous. Le fameux Planning Poker (voir paragraphe ci dessous) peut s’avérer utile pour déterminer collectivement les pondérations en « points » de valeur ajoutée. On peut également utiliser des échelles de valeur plus ou moins fine (exemple : « faible », « moyenne », « haute » ou encore les tailles de tee-shirt : XS, S, M, L, XL, XXL).

Estimations des exigences

L’ensemble des fonctionnalités de la liste doivent être estimées par l’équipe de développement afin de permettre les futurs engagements de cette dernière. Impliquant plusieurs développeurs, le Planning Pokerpermet de mettre à profit les expériences de chacun et de parvenir rapidement à une estimation optimale et objective. Avant ou pendant les estimations, le Product Owner pourra être sollicité afin de répondre aux questions de l’équipe de développement. A ce stade, le besoin pourra être approfondi, mais sans aller trop loin (il s’agit simplement d’estimer le coût de chaque exigence). La conception détaillée se fera pendant les itérations (sprints).

Démarrage

Vous pouvez commencer par déterminer ensemble (équipe de développement et product owner) la durée des itérations ou Sprints (4 semaines maximum). Cette durée devra être la même pour l’ensemble des sprints afin de maintenir un rythme régulier propice aux automatismes et pouvoir construire des indicateurs de pilotage fiables. Un projet démarre généralement par ce qu’on appelle souvent le « sprint 0 » dédié aux travaux préparatoires du projet (ex : construction du product backlog et de la vision du produit, préparation des environnements, mise en place de l’intégration continue, définition de l’architecture générale du projet, initiation des acteurs à Scrum, etc.). Exceptionnellement, la durée de ce « sprint 0 » ne respecte pas forcément la durée fixée précédemment. Mais inutile de le faire durer trop longtemps, souvenez vous (cf. fiche pratique « introduction aux méthodes Agile »), l’idée est de se lancer sans élaborer au préalable un plan et une architecture millimétrés qui risqueraient de nous enfermer, de nous frustrer, voire de nous coûter cher à courts et longs termes. L’architecture doit être souple et émerger au fil des sprints.

Réunion de planification de sprint

Durée maximum : 2 heures par semaine de sprint (autrement dit : 4 heures pour des sprints de 2 semaines).

Phase 1 : Le « Quoi »

Une fois que le Product Backlog est suffisamment complet et ordonnancé, on peut planifier un sprint. LeProduct Owner revoit alors avec l’équipe de développement la vision du produit, la roadmap, le plan de livraison (jalons et deadline), l’objectif du sprint et le Product Backlog. L’équipe de développement vérifie les estimations, confirme qu’elles sont exactes et sélectionne en haut du Product Backlog les exigences qu’elle se sent capable de convertir en fonctionnalités utilisables d’ici la fin du sprint (il s’agit d’une prévision et non pas d’un engagement « contractuel »).

Phase 2 : Le « Comment »

Exemple de tableau des tâches

Exemple de tableau des tâches

L’équipe de développement fait ensuite l’inventaire des tâches qui permettront de convertir les exigences sélectionnées en fonctionnalités utilisables d’ici la fin du sprint. Toutes les exigences n’ont pas nécessairement besoin d’être découpées en tâches. En cas de manque de temps, l’équipe de développement peut se contenter de découper celles qui seront réalisées au cours des premiers jours du sprint (elle découpera en cours de sprint les autres exigences). Elle doit cependant aller suffisamment loin dans l’effort de conception pour pouvoir vérifier sa prévision. Si elle constate après analyse des exigences sélectionnées, que sa prévision est erronée, elle peut réajuster avec le Product Owner la liste des exigences sélectionnées.

Les tâches de développement sont centralisées dans le Sprint Backlog et ajoutées au tableau des tâchesphysique (aussi appelé Kanban, même si Kanban veut dire bien plus). L’idéal est de parvenir à un découpage relativement fin (inférieur ou égal à une journée de travail).

Photo d'un tableau des tâches

Photo d'un tableau des tâches

Chacun peut personnaliser les colonnes de son tableau des tâches, ou code couleur des post-it. A titre d’exemple, voici la photo du tableau que nous avons utilisé sur l’un de nos premiers projets (au passage, vous pouvez également jeter un œil à la vidéo tournée sur ce projet et au retour d’expérience associé). Les User Stories (une User Story représente une exigence, voir annexe pour plus de détails) sont les gros post-it larges (rose et orange), les sous tâches des User Stories sont en jaune, on trouve en bleu des tâches imprévues indépendantes. Au dessus du tableau figurent les obstacles courants, un graphique d’avancement appelé burdown chart ainsi qu’un calendrier géant avec les dates clefs et les congés de chacun. Sur la droite on trouve des maquettes d’IHM, des documents métier, etc. Cette réunion de planification est l’occasion de préciser ou rappeler à l’équipe la définition de « terminé » pour une user story ou exigence. Exemple de définition de « terminé » : code commité, testé unitairement, documenté, testé en intégration, revue par un pair, tests d’acceptation de la user story passants.

Sprint (2 à 4 semaines)

Au cours du Sprint, l’équipe se concentre sur l’accomplissement des tâches du Sprint Backlog. En cas de retard (indiqué par le Burndown Chart), des exigences ou tâches seront retirées du Sprint Backlog en cours de route en essayant de préserver l’objectif du sprint (pour cela, il est conseillé d’ordonnancer les exigences au sein du sprint). Et inversement, si l’équipe avance plus vite que prévu, des exigences ou tâches y seront ajoutées. En accord avec le Product Owner dans les deux cas.

Les développements se font verticalement et non pas horizontalement par couche. Le but est de développer les fonctionnalités de bout en bout (de la conception aux tests) au fil de l’eau au cours du sprint. Autrement dit d’éviter un mini cycle en V au sein du sprint, voire de se retrouver avec une surcharge d’effort de test en fin de sprint. Les développeurs doivent donc éviter de trop paralléliser les exigences et encore moins les tâches de développement. Pour cela, le pair programming peut se révéler utile ainsi que la définition d’une limite maximum d’éléments au sein d’une colonne du tableau des tâches (voir notion de Work In Progress du Kanban). Si l’équipe de développement n’est pas convaincue, le « jeu du prénom en mode multitâche » peut s’avérer utile.

Le tableau des tâches physique rempli de post-it est pratiquement indispensable. Il permet d’avoir une vision claire du travail à accomplir, en cours et terminé. Il peut également s’avérer précieux lors des réunions quotidiennes (voir § suivant), surtout si vous calculez à la main le « reste à faire » du Sprint afin de tracer le graphique d’avancement (voir plus loin le « Burndown Chart »). Le tableau facilite également l’affectation des tâches par l’équipe en ayant une vision d’ensemble du sprint en un coup d’œil. Inutile de se torturer à planifier à l’avance dans le détail l’activité de chaque développeur sur toute la durée du sprint. Il faut se détacher d’une approche prédictive et des diagrammes de Gantt et renoncer au style de management « commander et contrôler ». Ce sont les développeurs qui « tirent » les tâches et non pas le Scrum Master qui les affecte.

Pendant le sprint, l’équipe de développement assistera le Product Owner dans ses activités d’affinage du Product Backlog. Cette assistance peut consister en des ateliers de conception anticipés, de priorisation ou d’estimation. Il faut compter environ 10% de la capacité à faire de l’équipe de développement pour ces activités.

Mêlée quotidienne ou « stand-up meeting »

Durée maximum : 15 minutes.

Cette réunion qui se fait debout (ça évite de s’éterniser) est très importante. Elle permet quotidiennement aux membres de l’équipe de se synchroniser, de remonter les obstacles rencontrés, de s’entraider, de vérifier l’avancement du sprint. Elle contribue également à faire naître l’esprit d’équipe. A condition bien entendu de ne pas transformer cette réunion de « synchronisation » en réunion de « reporting » vers le Scrum Master.

Photo d'une mêlée quotidienne

Photo d'une mêlée quotidienne

Chaque personne répond à 3 questions :

  • Qu'ai-je fait hier qui a aidé l'équipe de développement à atteindre l'objectif Sprint ?
  • Que vais-je faire aujourd'hui pour aider l'équipe de développement à atteindre l'objectif Sprint ?
  • Est ce que je vois des obstacles susceptibles de m'empêcher ou d'empêcher l'équipe de développement d'atteindre l'objectif du Sprint ?

Le Scrum Master est ainsi immédiatement au courant des obstacles rencontrés, il doit impérativement les prioriser, les suivre et bien sûr s’efforcer de les lever au plus tôt afin de garder l’équipe pleinement concentrée et productive.

La mêlée quotidienne se déroule à lieu et heure fixes (devant le tableau des tâches physique de préférence) déterminés par l’équipe de développement. Au début le Scrum Master peut avoir à rappeler qu’il est l’heure de la mêlée et animer cette dernière en rappelant les 3 questions et évitant l’instruction des problèmes ou obstacles en séance afin de ne pas dépasser les 15 minutes imparties. L’objectif du Scrum Master consiste cependant à viser l’appropriation de la mêlée par l’équipe de développement.

Graphique d’avancement (Burndown Chart)

Exemple de Sprint Backlog

Exemple de Sprint Backlog

Pour connaître votre avancement, vous allez avoir besoin de tracer le Burndown Chart du sprint en cours. Ce graphique est simple, il s’agit du tracé de la charge de travail restante (généralement en heures) en fonction du temps (en jours). Pour tracer ce graphique, il suffit de mettre à jour (lors de chaque mêlée quotidienne par exemple) le sprint backlog (voir illustration). 

Exemple de Burndown Chart de Sprint

Exemple de Burndown Chart de Sprint

Vous pouvez également construire un indicateur d’avancement de Release à mettre à jour en fin de chaque sprint (voir outillage proposé via le bouton ci dessous).


Revue de Sprint

Photo d'une revue de sprint

Durée maximum : 1 heure par semaine de sprint (autrement dit : 2 heures pour des sprints de 2 semaines).

Fréquence : A la fin de chaque sprint.

L’objectif de la revue de sprint est d’inspecter l’incrément produit au cours du sprint écoulé, faire un point sur l’avancement de la Release et adapter au besoin le plan et le Product Backlog. L’équipe de développement présente à tout acteur projet intéressé (à minima le Product Owner idéalement accompagné d’utilisateurs finaux) les nouvelles fonctionnalités développées au cours du sprint. Le Product Owner donne un feedback à l’équipe de développement, il accepte ou refuse les fonctionnalités présentées.

L’équipe de développement calcule sa vélocité en additionnant les points d’estimation associées aux fonctionnalités acceptées. Une fonctionnalité partiellement terminée ne rapportera aucun point car une telle fonctionnalité n’est pas utilisable. La vélocité ainsi calculée va permettre de mettre à jour le graphique d’avancement de Release et de vérifier l’avancement de cette dernière. C’est l’occasion de vérifier que le nombre de sprints de la Release demeure adapté ou non.

La livraison à la fin de chaque sprint n’est pas obligatoire.

Rétrospective de sprint

Photo d'une retrospective

Photo d'une rétrospective

Durée maximum : 45 minutes par semaine de sprint (autrement dit : 1 heure 30 pour des sprints de 2 semaines).

Fréquence : A la fin de chaque sprint.

Cette réunion est généralement animée par le « ScrumMaster » qui s’adresse à son équipe. Elle a pour but d’améliorer continuellement le processus de développement de l’équipe en mettant les idées de chacun à contribution. Il existe différentes techniques d’animation de rétrospectives. Voir le livre « Agile Retrospective: Making Good Teams Great » pour en savoir plus.

L’une d’elle consiste à identifier et pondérer les éléments positifs (éléments à cultiver ou source de motivation) du sprint écoulé, puis les éléments à améliorer, puis de définir un plan d’action d’amélioration (en commençant par améliorer les éléments dont la pondération est la plus forte). Si les membres de l’équipe sont à l’aise pour s’exprimer, un simple tour de table permet de remplir le paper-board d’éléments. Dans le cas contraire, on peut avoir recours aux post-it (chacun se voit remettre des post-it vierges et un marqueur et inscrit ses idées dessus pour ensuite les transmettre à l’animateur. Une idée par post-it.). Pour pondérer les éléments, il suffit d’allouer un certain nombre de points (5 par exemple) à chaque membre. Chaque membre peut ventiler ses points à sa guise (exemple : 4 points sur un sujet qu’il considère très important, 1 point sur un autre sujet également important à ses yeux mais quatre fois moins que le premier). Pendant la phase d’inventaire des éléments à améliorer, veillez à ne pas essayer de trouver des solutions avant la phase dédiée au plan d’action d’amélioration. Vous risqueriez de ne pas faire remonter à la surface la majorité des « problèmes ». Ce serait dommage car, j’ai pu constater que parfois, le simple fait d’évoquer un problème sans forcément avoir le temps de trouver une solution entraîne une amélioration au sprint suivant.

Commencer par les points positifs peut être vital lorsque le sprint a été éprouvant. L’équipe aura peut être besoin de se nourrir des éléments positifs avant de s’attaquer aux éléments à améliorer.

Tous les domaines peuvent être abordés en rétrospective : humain, organisationnel, pratiques, processus, outillage, qualité de vie au travail, conflits, interactions avec le métier. Le compte rendu de la dernière rétrospective, les graphiques d’avancement de sprint et release, les événements du sprint, les feedbacks de la revue de sprint sont autant d’éléments qui alimentent les conversations.

Projet Scrum et MOA

Il est important de prendre conscience que les méthodes Agile ne considèrent pas à juste titre de séparation MOA MOE contractuelle (typiquement française empruntée au secteur du BTP). Il est donc primordial de s’efforcer de décloisonner au maximum MOA et MOE, ces deux entités doivent collaborer étroitement tout au long du projet. Etant donné que l’on touche ici à des habitudes bien ancrées, ce chapitre explique quel rôle peut jouer la MOA dans un projet Agile.

Le rôle du consultant métier

Dans le cadre d’une approche Agile, les tâches d’un profil fonctionnel peuvent rester les même que dans le cadre d’une approche traditionnelle :

  • Participation au reengineering des processus et à la conduite du changement.
  • Modélisation des processus métier.
  • Participation aux ateliers de conception.
  • Rédaction des tests d’acceptation (en amont des développements).
  • Vérification de la conformité des fonctionnalités (en aval des développements).

Le changement réside dans l’organisation du travail. L’approche séquentielle propice à l’effet tunnel est remplacée par un mode itératif, le travail est donc lissé dans le temps sur toute la durée du projet. De plus, un responsable métier devra jouer le rôle clairement défini de « product owner ».

Rôle du Product Owner

Le Product Owner (ou Directeur/Responsable Produit) est chargé de :

  • Construire le Product Backlog.
  • Ordonnancer ces dernières en fonction de leur importance métier.
  • Répondre aux questions de l’équipe de développement.
  • Valider/Rejeter une fonctionnalité « terminée ».
  • Prendre des décisions importantes en temps voulu.

L’équipe de développement s’engage à faire une démonstration à la fin de chaque sprint le produit enrichi de nouvelles fonctionnalités. A la fin de chaque sprint, le Product Owner peut :

  • Ajouter une exigence manquante.
  • Retirer une exigence finalement inutile.
  • Redéfinir la priorité des exigences.

Renfort du Product Owner

Le Scrum Master enseigne au besoin au Product Owner les règles du jeu de Scrum et la maîtrise des techniques associées. En particulier celles qui tournent autour de la gestion de Product Backlog, la planification de releases et l’utilisation des indicateurs de pilotage. Il facilitera également les interactions entre le Product Owner et l’équipe de développement. L’équipe de développement l’aide quant à elle à ordonnancer le Product Backlog en fonction des dépendances, risques et estimation qu’elle révèle. Enfin, une équipe de consultants métier peut l’aider sur :

  • Les réponses à apporter aux questions de l’équipe de développement tout au long du projet.
  • La prise de décisions.
  • La rédaction des tests d’acceptation.
  • L’ordonnancement du Product Backlog.
  • La fourniture des feedbacks à la fin de chaque sprint.
  • D’autres sujets : logistique, conduite du changement, déploiement, etc.

Par ailleurs, il est recommandé de solliciter quelques utilisateurs finaux représentatifs des utilisateurs visés par le produit afin de vérifier pas à pas (à minima en revue de chaque sprint) la bonne couverture de leur besoin.

Les pièges à éviter

Scrum est simple mais difficile

Nous l’avons vu, Scrum est un cadre de gestion de projet qui laisse à d’autres méthodes agilecomplémentaires, le soin d’apporter les pratiques de développement appropriées. C’est le cas de eXtreme Programming et software craftsmanship. Il est donc primordial de ne pas se contenter d’utiliser Scrum sans s’assurer que les pratiques de développement Agile sont ou seront maîtrisées in fine. Constatant de nombreuses dérives liées à cette erreur courante, les créateurs de Scrum alertent :

« Début 2009, davantage d’organisations utilisaient des processus agiles plutôt que des processus en cascade. Cependant, moins de 50% de celles utilisant Scrum développaient les itérations de façon incrémentale, ce qui est le cœur de Scrum. Un des plus grands défis de l’utilisation de Scrum a toujours été la courbe d’apprentissage des développeurs de l’équipe Scrum. »

Gestion du changement

Selon la culture de votre organisation, Scrum peut être porteur de nombreux changements qui impliquent une véritable gestion du changement Agile.

Plusieurs équipes de développement Scrum

Idéalement, pour être efficace, une équipe de développement Scrum ne devrait pas dépasser 9 membres sans compter le Scrum Master et le Product Owner. Si votre projet nécessite plusieurs équipes de développement, évitez dans la mesure du possible de constituer des équipes par composant ou technologie (exemple : une équipe qui développe les IHM et une autre les services métier et l’accès à la base de données). Constituez deséquipes pluridisciplinaires capables de développer intégralement une fonctionnalité (donc de coder toutes les couches). Comprenons nous bien, le principe n’est pas que chaque membre d’une équipe dispose de toutes le compétences mais plutôt que toutes les compétences requises soient couvertes par au moins un membre de l’équipe. De cette façon, chaque équipe peut avancer de façon autonome sans dépendre étroitement d’une autre, la coordination est plus simple. Chacune étant spécialisé sur un ou des domaines fonctionnels plutôt que technologiques. L’intégration du code de l’ensemble des équipes sera également plus facile.

Il y aurait davantage à dire sur l’utilisation de Scrum à grande échelle mais nous dépassons l’objectif de ce guide de démarrage.

Annexes

Caractéristiques d’une User Story

Une fonctionnalité peut être rédigée selon le principe de la « User Story » défini par la méthode Agile eXtreme Programming (XP). Une « User Story » doit être :

  • Courte : généralement une ou trois phrases environ.
  • Négociable : elle peut être discutée avec l’équipe chargée de la réalisation du produit, notamment lors de l’estimation.
  • Source de valeur : elle doit être porteuse d’une valeur pour le client ou l’utilisateur.
  • Indépendante des autres histoires d’utilisateur (dans la mesure du possible).
  • Estimable : elle peut être estimée par l’équipe de réalisation avec un risque d’erreur faible.
  • D’une taille appropriée : sa taille doit être relativement petite afin de faciliter son estimation. Elle doit pouvoir être conçue, développée et testée au sein d’une itération.
Exemple de User Story

Exemple de User Story (simpliste pour l’exemple)

Quid des spécifications ?

La conception fonctionnelle voire technique d’une fonctionnalité se fait au fil de l’eau dans chaque itération. Ce n’est qu’au moment où on s’apprête à l’implémenter qu’on rentre dans les détails du besoin (pour rappel, le besoin lié à cette fonctionnalité à été abordé dans les grandes lignes lors de la phase amont d’estimation). Cette approche a le mérite de permettre au client d’ajuster ou approfondir son besoin sur les fonctionnalités implémentées plus tard. Elle lui permet aussi (ainsi qu’à l’équipe) de retarder certaines décisions sans risque pour le projet (c’est souvent plus sage quand on manque de visibilité).

La méthode Agile eXtreme Programming considère que les User Stories, les tests associés et le code source constituent les spécifications fonctionnelles du projet. D’autres méthodes vont plutôt préconiser la rédaction de cas d’utilisation avec un niveau de détail variable selon le contexte du projet, les exigences du client et la complexité de la fonctionnalité à spécifier.

Il faut bien comprendre que rédiger des spécifications ultra détaillées n’a de sens que dans une approche traditionnelle. Car dans ce cas de figure, le client ne verra son produit qu’à la fin des développements. Il doit donc avoir une vision précise de ce qu’il aura en fin de projet grâce aux spécifications détaillées. Or l’approche Agile apporte au client une visibilité sur le produit dès le début du projet ainsi qu’une possibilité d’ajustement du besoin. On privilégie donc le développement de l’application à une documentation exhaustive et pléthorique (d’ailleurs souvent indigeste pour le client qui tarde à valider et retarde ainsi son propre projet. Ou pire, valide sans vraiment lire et analyser).

Pour la partie technique on peut souvent se limiter à un dossier d’architecture, un modèle conceptuel de données (voir physique) émergeant, aux commentaires du code (Javadoc) et à une spécification détaillant les modules éventuellement complexes pour faciliter la maintenance du produit par la suite.

En appliquant ce principe, on assiste généralement à un gain de productivité par rapport à une approche traditionnelle, puisqu’on ne perd pas un temps considérable en rédaction, validation puis mises à jour de spécifications détaillées. Il est sans doute bon de préciser également que l’on ne néglige pas la conception du produit pour autant. La conception fait partie des tâches sous-jacentes à la réalisation d’une fonctionnalité.

Vous souhaitez aller plus loin ?

Visitez la rubrique "Fiches pratiques" ou "boite à outils".​

Proposition de cursus pour devenir agile

Grâce aux nouvelles technologies nous pouvons réduire notre effort d’apprentissage ou du moins rendre ce dernier plus vivant et ludique. Si on ajoute à ça, l’accès gratuit à la connaissance (un peu dans un esprit Open Source), on peut rapidement monter en compétence ou à minima changer sa vision des choses de façon autonome. Cet article a pour but de proposer un cheminement d’apprentissage autonome, francophone, vivant, gratuit et de qualité.

Tout d’abord, commençons par Scrum que l’on pourrait presque considérer comme un standard Agile en tant que cadre méthodologique (tout simplement parce que Scrum est de loin le plus utilisé et éprouvé dans le monde). La première étape consiste donc à lire le Guide Scrum proposé par Ken Schwaber et Jeff Sutherland (créateurs de Scrum) via Scrum.org. Moins de 20 pages à lire porteuses de toute l’essence de Scrum et donc de l’Agilité par extension. Une fois, ce guide lu (dans la langue de son choix grâce aux traductions offertes par la communauté Scrum), on peut éprouver le besoin légitime de passer de la théorie à la réalité. Une façon de le faire est de visionner la vidéo suivante de moins de 5 minutes :

Il est temps ensuite de creuser un peu le sujet avec des vidéos plus longues et pointues.

Devenez le coach de votre équipe agile (1 heure)

Cette vidéo de Véronique Messager traite du type de management associé à une démarche Agile, en particulier Scrum et le rôle de Scrum Master.

Le Product Owner Proxy (1 heure)

Celle ci de Bertrand Dour traite d’un autre rôle important qui est celui de Product Owner et plus précisément du Product Owner proxy. Ces rôles s’inscrivent souvent au sein de la Maîtrise d’Ouvrage ou Assistance à Maîtrise d’Ouvrage.

Pratiques avancées de tests (1 heure)

Celle là de Nathaniel Richand adresse un domaine primordial du développement incrémental Agile, à savoir la pratique des tests. L’art de coder des tests unitaires automatisés. Elle s’inscrit dans les logiques de refactoring réguliers, de l’automatisation des tests fonctionnels, de l’intégration continue, de la spécification et conception par les tests ou pilotage par les tests (TDD, ATDD).

Scrum et Kanban (1 heure)

Parce que tous les contextes projets ne se prêtent par forcément à du développement itératif et incrémental rythmé par des sprints, c’est intéressant de comparer Scrum et Kanban pour tirer le meilleur parti des deux. Vidéo de Claude Aubry, Antoine Vernois et Fabrice Aimetti.

D’autres vidéos sont disponibles sur la French SUG TV.

Ensuite, il est encore possible d’aller plus loin dans la même logique autonome, francophone, vivante, gratuite et de qualité avec les 2 livres de Henrik Kniberg qui regorgent d’authentiques retours d’expérience se lisant comme des petites histoires :

Il est bien sûr possible et recommandé de parfaire son apprentissage via les formations proposées par Scrum.org ou autres formateurs et organismes de formation (ce n’est pas ce qui manque) et les différents livres que l’on peut trouver sur le sujet. Mais rien ne vous empêche d’expérimenter tout de suite. C’est même une bonne chose de venir en formation avec une première expérience et des questions concrètes et précises sous le bras.

Si je devais recommander seulement 3 livres (après la lecture du Guide Scrum évoqué plus haut), il s’agirait de « Scrum et XP depuis les tranchées », « Agile Coaching » et « Succeeding With Agile ». Ce dernier est moins digeste mais très complet et riche en retours d’expérience. Au besoin, il peut également faire office de pont vers d’autres livres que l’auteur avisé recommande sur les différents sujets abordés. Les deux premiers ouvrages peuvent se lire en parallèle en prenant connaissance d’une pratique décrite dans « Scrum et XP depuis les tranchées » puis en tirant de « Agile Coaching » les recettes de mise en œuvre de celle ci. « Succeeding With Agile » serait plutôt à lire en dernier, il nécessite d’avoir une bonne compréhension de Scrum voire un peu de pratique derrière soi.

Mais rappelez vous, « Scrum est simple, mais très difficile ».