Mon projet est-il Agile ?

Que la réponse soit « Bien-sûr ! »  ou « Honnêtement, je n’en sais rien. », se la poser est un excellent exercice !

Une équipe qui a choisi l’Agile a toujours la possibilité d’apprendre et de s’améliorer quel que soit son niveau de maturité. Comprendre comment un bug a pu perdurer jusqu’à la démonstration client, réussir ses rétrospectives d’itération et en mesurer le bénéfice,… Les sujets peuvent être nombreux et leur résolution d’autant plus satisfaisante !

En cherchant à améliorer certains rituels agiles sur des projets de delivery mobile, nous sommes parvenus à compiler toutes les pratiques et outils indispensables à nos projets Scrum. Nous en avons fait un document de mesure et de suivi sur nos missions que nous allons partager ici : notre checklist d’un projet agile.

 

Pourquoi mesurer l’agilité dans ma mission ?

Une démarche d’amélioration continue

Au delà de savoir si nos projets étaient agiles, notre volonté était d’améliorer nos pratiques. Et pour améliorer, il faut mesurer. D’où l’idée de lister les points de méthodes appliquables concrètement dans nos missions.

La réalisation de ce travail nous a permis de partager nos expériences, nos outils et de les condenser sous une forme accessible et utilisable par tous. Le résultat est un ensemble de points qu’il est possible d’utiliser pour former des nouveaux intervenants sur un projet agile, partager la connaissance, et enfin s’améliorer en continu !

Si beaucoup de rituels agiles issus de Scrum nous semblaient indispensables, d’autres outils venus notamment du Lean nous sont apparus tout aussi pertinents. Nous les avons donc incorporés et pensons qu’ils peuvent être complétés par d’autres.

 

Une checklist pour mon projet !

 

Rituels agiles

 

>  Stand up
Point quotidien de l’équipe de dév : « qu’ai-je terminé, que vais-je commencer, quels sont les points de blocage ? »
  • Un standup quotidien est réalisé à heure fixe
  • Les interventions aux standup sont limitées à 1 minute par personne (la réunion reste courte)
  • Chaque participant s’adresse aux autres membres de l’équipe (et pas à un leader unique)

 

>  Démonstration de fin d’itération
Démonstration du produit au client
  • En fin d’itération, une démonstration du produit est réalisée par l’équipe de dév au Product Owner (PO)
  • Les démonstrations sont préparées à l’avance (vérification préalable de chacune des stories)

 

>  Bilan de fin d’itération
Retour du client sur chaque story développée
  • Lors du bilan, le PO valide/invalide chacune des stories développées
  • Lors du bilan, les métriques du projet (vélocité, avancement, etc.) sont présentées

 

>  Planning game (planification de l’itération)
Planning game : choix, priorisation et estimation en complexité des stories
  • Le PO sélectionne les stories à estimer pour l’itération et les présente à l’équipe de dév
  • Le PO associe des tests de validation à chacune des stories
  • Un planning poker est réalisé avec toute l’équipe de dév pour estimer chacune des stories
  • Le nombre de stories à développer par itération est choisi en fonction de la vélocité de l’équipe (somme des points de complexité validés dans l’itération précédente)
  • A la fin du planning game, les stories sont priorisées

 

>  Rétrospective d’itération
Retour sur l’itération, sur le process, les relations avec pour but leur amlioration
  • Avant le démarrage d’une itération, une rétrospective est réalisée sur l’itération précédente
  • En début de rétrospective, les actions décidées à la dernière rétro sont revues
  • Toute l’équipe de dév, le delivery manager et le PO sont présents à la rétrospective
  • Chacun arrive à exprimer des points difficiles du projet
  • Des solutions concrêtes sont trouvées pour résoudre les points difficiles et des acteurs sont identifiés pour les mettre en oeuvre
  • La rétrospective a un facilitateur désigné qui l’anime. Le facilitateur ne contribue pas au contenu

 

Méthodologie

 

>  Tenue de backlog
Planification des itérations
  • L’équipe de dév et le PO partagent le même document listant les fonctionnalités de l’application (Backlog)
  • Les fonctionnalités à développer sont rédigées sous la forme de User stories (ex : « en tant que …, je peux … »)
  • Les fonctionnalités sont rattachées à la StoryMap du projet s’il y en a une
  • A partir du Backlog, on peut retrouver les tests de recette associés à chaque story

 

>  Management visuel partagé
La salle projet reflète l’état du projet
  • L’équipe de dév utilise un support visuel pour organiser les stories (Kanban board)
  • Les différentes colonnes du kanban sont clairement séparées et une « Definition Of Done » (DOD) est définie pour chaque colonne
  • Les DOD sont respectées par chaque membre de l’équipe de dév
  • L’équipe de dév utilise un bac rouge pour référencer et traiter les problèmes liés au projet
  • Le bac rouge est traité régulièrement (application par exemple de la méthode « 5 pourquoi »)
  • Les informations complémentaires importantes du projet (prochaines dates de release, contenu de ces releases, burndown chart, planning d’itération, trophées, etc.) sont affichées
  • Chaque itération a un objectif qui est affiché (au dessus du kanban)

 

Bonnes pratiques

 

>  Développement organisé
L’équipe de dév organise son travail
  • Les stories sont développées dans l’ordre de priorité défini par le PO en planning game

 

>  Industrialisation des dévs
Les processus de développement/livraison sont industrialisés
  • Le projet utilise une Usine De Développement (UDD) pour l’intégration continue (build, lancement des tests, vérification qualité)
  • La livraison au client est réalisée grâce à l’UDD
  • La livraison est réalisée en suivant une checklist

 

>  Méthodes de développement
L’équipe de dév utilise des pratiques permettant de s’améliorer
  • L’équipe de dév réalise les stories les plus difficiles en Pair Programming
  • Tout code est validé par un autre membre de l’équipe (correction, alignement des pratiques)
  • Les fonctionnalités de l’application sont testées unitairement et automatiquement
  • L’équipe développe en Test Driven Development (TDD)
  • Le projet possède un document avec ses normes (page wiki, feuille au mur, fichier readme, autre), de préférence de manière visuelle

 

Communication

 

>  Vie de l’équipe et relation client
Comment se sentent les membres de l’équipe
  • L’équipe s’améliore de façon continue
  • L’équipe a la confiance du client
  • La communication dans l’équipe et avec le client est facile / bonne
  • L’équipe favorise la colocalisation (tous les acteurs du projet sont colocalisés)

 

 

Et du coup, il est agile mon projet ?

Avoir un outil à sa disposition n’est que le premier pas ! Il faut encore l’adapter à son contexte, que son équipe l’accepte et enfin, savoir analyser ses résultats !

 

Adapter ses outils à son besoin

Certains des points présentés ne correspondent peut-être pas à tous les projets et d’autres peuvent manquer. Un conseil que nous pourrions donner avant d’ajouter (ou retirer) un élément de la liste est de s’assurer que cet élément fait l’unanimité dans l’équipe.

N’hésitez pas à y ajouter vos standards (meilleures pratiques observables sur vos missions). Une bonne communication et une formulation pédagogique des questions sont également nécessaires pour maximiser l’adhésion de chaque participant.

La forme de la checklist peut également être adaptée. Dans le but de la communiquer facilement à nos équipes et de centraliser ses résultats, nous en avons fait un formulaire Google. Nous avons également modifié sa forme pour éliminer la frustration du « tout ou rien » en ajoutant un choix de réponse intermédiaire. Cette réponse permet de préciser qu’un effort est réalisé mais que la pratique n’est pas totalement maitrisée/appliquée.

Utiliser un Google Form pour créer votre questionnaire

 

Visualiser et analyser ses résultats

Mesurer régulièrement sa pratique agile permet d’en suivre l’évolution et d’analyser rapidement les bienfaits d’une pratique. Vérifier la checklist par exemple tous les mois permet de mettre en évidence les résultats des actions d’amélioration entrepris par un groupe. Un(e) responsable pourra être choisi(e) pour analyser les réponses des participants du projet.

De plus, il est intéressant que ce questionnaire soit rempli par toute l’équipe. Cela fera éventuellement apparaître des divergences d’opinion qui pourront valoir la peine d’être discutées pour améliorer la vision commune dans le groupe.

Afin de mieux visualiser les résultats et de les comparer dans le temps, nous avons créé un excel qui convertit notre Google Form en tableau récapitulatif et qui simplifie grandement notre analyse.

Utiliser un excel pour conserver et analyser ses résutats

 

Echanger avec son équipe

Enfin, une fois l’analyse effectuée, se réunir régulièrement permet de présenter les résultats. C’est l’occasion d’échanger, de comprendre les difficultés de chacun et de choisir des points que l’on souhaite améliorer ou suivre avec une attention particulière. C’est aussi à ce moment qu’on peut choisir d’ajouter une nouvelle pratique observée ou encore d’arrêter d’utiliser la checklist (« On est trop forts ! »).

 

Et ça marche ?

Après 4 mois d’utilisation de notre questionnaire, nous sommes parvenus à réduire certaines douleurs que nous observions de manière systématique dans nos missions. Notre vision de la façon d’utiliser l’agile a été renforcée et chacun est plus à même d’accompagner une équipe, mais également un client pour que son projet réussisse au mieux ! Nous encourageons donc cette pratique d’amélioration continue.

Et pour qu’elle reste efficace, un dernier conseil : ne pas l’imposer comme outil d’évaluation de performance mais plutôt la proposer comme base de réflexion à des équipes motivées par l’amélioration de leur quotidien.

 

10 commentaires pour “Mon projet est-il Agile ?”

  1. Article intéressant mais il aurait été sympa de partager le formulaire Google…

  2. Bonjour,

    Voici pour partage un autre moyen de mesurer son degré d’agilité par rapport à d’autres projets (l’approche est différente) :
    : http://www.comparativeagility.com/

    Il couvre 7 dimensions : Teamwork, Requirements, Planning, Technical practices, Quality, Culture, Knowledge creation. Et 3 à 6 caractéristiques par dimension. 125 questions au total. Ce n’est pas forcément utile de le faire à chaque itération mais tous les trimestres peut être un bon rythme en phase d’adoption.

    Cordialement
    Florent

  3. Merci pour vos commentaires.

    @Gilles : notre Google form est personnalisé pour nos projets mobilité et a subit quelques assauts pour arriver à sa forme finale. Le partager ainsi ne serait pas idéal pour son analyse (les questions qui ont été reformulées apparaissent toujours dans le spreadsheet). Si néanmoins vous quand même le récupérer, envoyez-moi un e-mail (mwa@octo.com).

    @Florent : merci, j’ai cependant l’impression que cet exercice est trop long / poussé pour être réalisé volontairement par une équipe !

  4. L’intention est louable, mais c’est une checklist « scrum », pas une checklist « agile »

  5. @Maxence : Oui et non. En effet, on s’attend davantage à ce que ce soit le delivery-manager ou coach Agile qui réalise le test complet à intervalles réguliers potentiellement supérieurs à l’itération. Mais on peut aussi cibler uniquement les dimensions de son choix. L’équipe pourra par exemple se contenter de se mesurer sur les axes « Teamwork » et « Technical practices ».

    @oaz : Ce n’est pas un questionnaire « scrum ». Il s’adresse même à ceux qui font du Kanban.

  6. @Florent : le questionnaire ne s’applique pas à une équipe organisée autour des principes Kanban, mais bien à une équipe Scrum.

    La plupart des points de cette check-list ne traduisent pas les recommandations Kanban, ni même les recommandations de l’agilité de manière générale, mais bien les recommandations Scrum : rituels, tenue du backlog, etc. Et la partie « bonnes pratiques » relève plus de l’XP, au passage.

    D’autre part, une check-list Kanban devrait au grand minimum contenir un point « un plafond max de reste-à-faire est appliqué à toutes les étapes du processus et ce plafond est toujours respecté ».

    Ceci étant dit, cette check-list et le retour d’expérience sur l’analyse sont intéressants, et inspireront pas mal d’équipes je l’espère !

  7. Bonjour et merci Emilie pour ton message qui me donne l’occasion de préciser mon propos ;-)

    En effet, ce questionnaire ne comporte aucune question spécifique au Kanban (portant sur la limitation du WIP par exemple ou le suivi du Lead Time).

    Je voulais simplement dire qu’une grande partie des questions (pas toutes en effet) ne sont pas spécifiques à Scrum. Dans cet esprit, le questionnaire mentionne : « Some of the following questions refer to iterations. If you use kanban and do not have iterations, you may choose to use the ‘Not Applicable’ response. ».

    Voici quelques exemples de questions non spécifiques à Scrum prises au hasard : « Everyone required to go from requirements to finished system is on the team. », « Team members are kept together as long as possible. », « Management sets goals but doesn’t tell team members how to achieve them. », « Team members choose which tasks to work on. », « Standup meetings are effective at synchronizing work. », « Team members communicate in a high-bandwidth manner without undue interference. », « Teams are able to start projects with incomplete requirements. », « Estimates are created collaboratively by the people who will do the work. », « Most code is written using unit test-driven development. », « Refactoring is performed whenever needed. », « The team has pre-defined and agreed-upon criteria for considering a feature done. », « The team maintains a steady rate of productivity without being overworked. », « The team acts on retrospective feedback in a timely manner. ».

    Et il y a en effet des questions spécifiques à Scrum comme : « Whole teams, including the ScrumMaster and Product Owner, have no more than 12 people on them. », « The product owner maintains a prioritized product backlog. », « Teams know their velocity. ».

    Par contre, je ne suis pas vraiment d’accord avec toi quand tu dis que la plupart des points de cette check-list ne traduisent pas les recommandations de l’agilité de manière générale.

    Mais bon, c’est sans doute une question de perception.

  8. @Florent : Merci de ta réponse !
    En fait je crois qu’on s’est mal compris, je parlais de la check-list de cet article de blog, et non du lien comparativeagility… :)

  9. Aaaah ok, autant pour moi :)
    Bonne journée à toi

  10. Très intéressant merci !
    Juste une question : où est la « célébration » dans tout ça ?
    Octo est bien connu pour savoir dynamiser ses équipes par la mise en avant des réussites..si petite soit-elle ;)