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.
#post33190 ul.checkboxes { margin: 1em 0 1em 1em; list-style-type: none; padding: 0; } #post33190 ul.checkboxes li { padding-bottom: 5px; } #post33190 ul.checkboxes input { display: inline-block; vertical-align: top; position: relative; top: 5px; } #post33190 ul.checkboxes span { display: inline-block; vertical-align: top; width: 90%; padding: 0 0 0 3%; } #post33190 div.formTitle { display: block; } #post33190 .form { position: relative; padding: 10px 20px 10px 20px; margin: 0 auto 2em; background-color: #FFFFED; -webkit-box-shadow: 0 0 4px rgba(0, 0, 0, 0.2), inset 0 0 50px rgba(0, 0, 0, 0.1); -moz-box-shadow: 0 0 4px rgba(0, 0, 0, 0.2), inset 0 0 50px rgba(0, 0, 0, 0.1); box-shadow: 0 0 5px rgba(0, 0, 0, 0.2), inset 0 0 50px rgba(0, 0, 0, 0.1); }
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.
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.
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.