http://rad-hass.developpez.com/tutoriels/conception/route-vers-agilite-scrum-et-xp-retour-experience/

Cet article, revient sur ma transformation agile, mais aussi la transformation agile de mon équipe. La pratique de l’agilité m’a permis d’améliorer mon quotidien, mais aussi la qualité de mes développements, refactoring, test, amélioration continue, participation du client… Sont quelques clés de cette transformation.

Cette expérience, m’a donné la possibilité de voir les bénéfices de l’agilité, mais aussi les difficultés lié aux changements.

Au delà des pratiques, l’agilité constitue un ensemble de principes qui sont parfois heurté à des réticences, liées aux mentalités. La transparence, l’absence de hiérarchie forte dans une équipe sont parfois perçu comme des menaces pour les individus. Et l’organisation des équipes avec la présence d’un représentant client, peuvent être un défi compte tenu des hiérarchisations de certaines grandes structures.
Dans le vaste domaine qu’est la conduite du changement, on parle parfois de résistance naturel, le changement doit être progressif, il faut convaincre et accompagné.

Dans les premières étapes de l’introduction de l’agilité dans une équipe, la dynamique que peut apporter une nouvelle pratique apporte un effet levier indispensable au démarrage, mais ceci n’a qu’une durée limitée et tant que l’ensemble de l’entreprise ne pratique pas et adhère pas à ces principes, la courbe de progression risque de stagner, voir régresser. Car tant que la MOA sera MOA et toujours aussi loin de l’équipe MOE, le bénéfice totale de l’agilité ne se fera pas, sans parler des équipes de productions qui sont parfois totalement indépendantes des équipes projets.

Et à ce propos on voit beaucoup de livre et de conférence à ce sujet, prochainement Valtech organise un afterwork (à Paris) sur cette thématique le 13 Octobre, après cela vous pouvez retrouver des sessions sur l’agilité et la transformation agile en particulier dans l’Agile Tour 2010 prévu le 28 Octobre.

Après avoir fait le tour de la question, je suis revenu à la solution d’automatisation la plus simple : Excel.

D’abord l’étape exploration d’outils :

Parmi la multitude d’outils disponibles deux avaient retenu particulièrement mon attention d’abord GreenHopper un plugin pour Jira (l’outil utilisé chez mon client) et IceScrum.
Pour mon expérimentation j’ai choisi IceScrum, qui avait l’avantage d’être totalement gratuit et les graphiques proposées sont plutôt réussi. Ayant déjà un environnement de travail Scrum (mur blanc, backlog de produit …), j’ai voulu utiliser IceScrum comme complément, solution peu évidente puisque l’utilisation partiel des fonctionnalités désirées était impossible. Mais séduit par l’outil et par le panel de fonctionnalités, j’ai convaincu mon équipe de l’expérimenter comme outil principale … Solution vite abandonnée (au bout de 3 sprints) tant l’adoption de l’outil fut un échec, quelques éléments de l’échec ont été sa complexité (peut être il aurait fallu mieux former), des lourdeurs … Au finale une utilisation beaucoup moins instinctive et automatisable que l’est le mur blanc

Ensuite les templates excels :

Souvent payant (chose qui m’a beaucoup étonné), parfois gratuit, les modèles trouvés m’ont souvent frappés par leurs complexités … Ne répondant pas à mon besoin assez simpliste du départ.

Après ces explorations forts enrichissantes des outils Agiles utilisés, je me suis rendu compte que je m’éloignai de mon besoin initial et que les solutions proposées ne répondait pas à mon besoin le plus agilement possible, alors je suis reparti d’une simple feuille excel qui me génère juste ce dont j’ai besoin. Et oui j’ai réinventé la roue, et si c’est le prix à payer pour ne pas devenir esclave d’un outil ?

Une User Storie est en générale présenté sous cette forme :

« En tant qu’utilisateur je peux m’identifier afin d’administrer mon compte »
« En tant que comptable je peux calculer le reste à payer »

Elle permet de décrire en 1 ou 2 phrases une fonctionnalité qui représente l’apport de la tâche du point de vue de l’utilisateur, elle est complété par les critères d’acceptation qui sont sous cette forme :

« Vérifier que l’utilisateur connecté est un comptable »
« Vérifier que le comptable connecté est le gestionnaire du porte feuille du département concerné »
« Vérifier que la somme du reste à payer ne fait pas dépasser le budget initial sinon levé une alerte »

Un autre façon d’écrire des critères d’acceptation serait la suivante :

« Étant donné un utilisateur connecté ayant le rôle de comptable dans le département du projet ouvert Quand le comptable calcule les prévisions des prochaines échéances Alors une alerte est levé si cette prévisions fait dépasser le budget initial ».

Bien sûre au préalable il faut veiller que les users stories ne soient pas de taille trop importante et ne pas hésiter à les découper en users stories de plus petites tailles.

Un des constats c’est que parfois la traduction de la rétrospective* en une réel amélioration n’est pas aisé et certains points votés ne sont toujours pas efficacement mis en place.

Il n’est pas toujours évident d’identifier un cadre à la mise en place d’une amélioration, si une intervention ne nécessite qu’une intervention ponctuel, il est suffisant de la prendre en compte dans un sprint (ex : Notre serveur de sources n’est pas performant, il est suffisant d’avoir un tâche de migration dans un sprint pour améliorer …).

Donc pour éviter que des points d’amélioration qui ont été retenu lors d’une rétrospective ne soit délaisser par l’équipe, on a mis en place un système de responsable de point d’amélioration pour ça on mise sur le volontariat ;-), cette personne doit proposer un cadre et des actions concrètes à mettre en place pour faciliter la vie de l’équipe, bien sûre en collaborant avec le reste de l’équipe.

Le meilleur moment pour le faire ? Entre la rétrospective et la réunion de lancement, il est intéressant de laisser un temps de battement pour faire ce qu’on a pu traiter pendant le sprint.

quel intérêt ? Tout ce que j’ai dis au dessus, mais surtout lancer le débat

*La rétrospective de Sprint est une des réunions majeure dans la pratique de Scrum, elle permet d’inspecter un Sprint pour en déduire les axes d’améliorations (les points d’améliorations sont votés par l’équipe en fin de réunion), elle s’inscrit dans l’axe de l’amélioration continue et permet d’adapter et améliorer le processus.