Transformation agile ? transition à l’agilité ?
Les histoires d’agilité finissent mal, en général. Une raison possible aux nombreux échecs est que ces initiatives tendent à considérer l’agilité comme la finalité.
Un outil pour se poser des questions sur la capacité de l'équipe à vivre ensemble, et à s'accorder avec ses parties prenantes.
Quand une équipe va au fond des choses, rencontre des obstacles ou subit des conflits, cela est souvent dû à des désaccords enfouis, qui remontent à l’occasion.
Ce décalage entre les coéquipiers, ou entre l’équipe et son environnement, porte soit sur des valeurs, soit sur une vision du produit à faire, soit sur la façon de travailler ensemble.
Comment y remédier ? En prenant un peu de temps pour discuter des points de vue et trouver un équilibre permettant de travailler en symbiose. L’outil support à cette recherche d’alignement, qui peut servir de charte projet, c’est un canevas, le CARE.
L'outil convivial est celui qui me laisse la plus grande latitude et le plus grand pouvoir de modifier le monde au gré de mon intention - Illich
Quand on est allé à une conférence agile ou qu’on a participé à un Agile Games France — le Graal — je pense qu’on associe volontiers l’adjectif convivial à l’agilité.
Dans le cadre plus restreint d’une équipe, la pratique courante de la célébration à la fin d’un sprint donne une touche conviviale.
Dans permaculture, il y a permanence. On retrouve cette idée de durée dans le 8e principe du Manifeste agile, celui qui parle de rythme soutenable :
L’agilité encourage un rythme de développement soutenable. Ensemble les développeurs et les utilisateurs devraient être capables de maintenir indéfiniment un rythme constant.
Mais revenons aux principes de la permaculture.
Cette semaine, j’ai eu deux interpellations à propos de mon rapport avec les outils Scrum.
Dans la première, un participant à un story mapping qui me demandait quel outil utiliser pour garder la trace des stories a trouvé “rétrograde” pour notre époque ma réponse “on n’en a pas besoin'.
Depuis son lancement, plus de 10.000 exemplaires de mon livre Scrum ont été vendus. Pour ces lecteurs, que je remercie bien chaleureusement, je fournis régulièrement des suppléments en ligne.
Voici ceux qui portent sur Scrum et les outils, le chapitre 17 de la troisième édition, qui a été publiée en juin 2014.
Le but du chapitre
L’objectif de ce chapitre est de vous parler de tous les outils qui aident à faire ce qui a été présenté dans les chapitres précédents. Applications informatiques, mais aussi des jeux, des tableaux physiques et, bien sûr, des post-it.
J’ai eu un quatrième commentaire publié sur la page Amazon de mon livre. C’est un commentaire positif, son titre est “Agréable à lire et vivant”.
Mais ce qui a particulièrement attiré mon attention…
Une nouvelle version d’iceScrum va bientôt être diffusée, avec une pré-release en août. L’équipe actuelle, portée par iceScrum Technologies, a réécrit toute l’application à l’occasion du changement sur la plateforme de développement agile Grails.
Je profite de ce changement majeur pour revenir sur l’histoire d’iceScrum.
L’histoire d’iceScrum a commencé en octobre 2005 à l’IUP ISI de l’Université Paul Sabatier de Toulouse.
En l’espace de quelques semaines, iceScrum va faire l’objet de présentations dans 4 manifestations à travers la France :
mardi prochain, pour la conférence Agile France à Paris, le 7 juin à Toulouse dans un atelier organisé par la SigmaT, le 7 juillet à Bordeaux pour les RMLL (Rencontres Mondiales du Logiciel Libre, catégorie Développement), le 8 juillet dans le cadre d’une session sur Scrum à la Sophia Conf. Pour préparer tout ça, je me suis demandé quelles étaient les attentes de participants à ces présentations. Après avoir interrogé quelques personnes, j’ai commencé la constitution d’un backlog des sujets susceptibles d’intéresser le public de ces sessions.
Dans les commentaires de mon billet “le post-it défie le temps”, noname vitupère contre le post-it [1].
A l’opposé, on voit régulièrement sur les blogs des billets pour promouvoir le post-it et vouer aux gémonies l’outil informatique.
C’est à chaque équipe de se déterminer et de choisir l’outil qui lui convient le mieux. Évidemment la dispersion géographique est un élément important et influe sur le choix : moins facile avec les post-it quand toute l’équipe n’est pas dans le même espace.
Par Yannick, je découvre un comparatif d’outils Open Source pour la gestion de projet, dans lequel figure IceScrum.
L’étude est fouillée, on voit que du temps a été passé à définir les critères et utiliser les produits. IceScrum s’en sort plutôt bien.
J’apporte quelques compléments à l’analyse qui en est faite. D’abord, la version 2#13 a été utilisée pour les tests, ce n’est pas la dernière, qui est la R2#14.1, avec son lot d’améliorations.
Suite à mon billet sur les Fonctions d’un outil Scrum, Xavier se demande si je ne suis pas contradictoire :
Si une équipe utilise le tableau mural, comment peut elle afficher le burndown chart dans son outil Scrum sans double saisie?
Le groupe de discussion Scrum de Montréal s’interroge sur les outils pour Scrum. Je reprends leur compte-rendu en donnant mon point de vue d’utilisateur, de consultant et aussi de Product Owner d’IceScrum.
J’ai expliqué il y a quelque temps le processus de gestion des bugs pour le projet IceScrum. Les utilisateurs peuvent déposer des bugs et des demandes d’évolution dans un bugtracker,Jira.
Jusqu’à récemment et faute de disposer d’un serveur, l’équipe IceScrum utilisait GoogleDocs pour gérer le projet — à la Scrum — avec les backlogs en ligne. C’était limité.
Maintenant on utilise IceScrum (R2#11) comme outil pour le développement du produit IceScrum.
C’était toujours la question à l’époque où je travaillais chez un éditeur qui vendait des outils de génie logiciel :
est-ce que vous avez utilisé votre outil (par exemple Asa ou Geode ou STP) pour le développer ?
Dans un article trouvé sur InfoQ, Kent Beck rappelle que l’application des méthodes agiles sur des projets passe par l’utilisation d’outils :
it’s ridiculous to speak of agile software development without tools
Plutôt que ruminer sur la défaite cruelle du Stade Toulousain, j’ai fait un petit tutorial qui vous aidera à expérimenter IceScrum. Je vais décrire comment constituer un backlog de produit initial, créer une release et ses sprints, faire une planification de release et aller jusqu’au démarrage du premier sprint. Cette phase de préparation est aussi appelée sprint 0.
Un backlog de produit peut se concrétiser sous différentes formes. Dans les différents projets auxquels j’ai participé, j’ai utilisé :
des fiches bristol épinglées sur un tableau une feuille de calcul d’un tableur OpenOffice ou Excel une feuille de calcul partagée avec GoogleDocs, ce qui est déjà beaucoup mieux qu’un simple tableur un outil dédié, IceScrum bien sûr, ce qui est encore mieux
Le manifeste agile rappelle que les personnes et leurs interactions sont plus importantes que les processus et les outils. Faire un outil qui reste dans cet esprit tout en assistant utilement lors de l’application d’une méthode agile, ce n’est pas facile. Le pari a l’air réussi pour la nouvelle version d’IceScrum.
