J'ai eu la semaine dernière la chance de participer au raid agile organisé par Pablo et
Claudio. Je dis bien une chance car, de mon point de vue, cette formation atypique donne vraiment
l'occasion de passer quelques jours loin du quotidienn dans un cadre idyllique et une ambiance
sympathique, à réfléchir aux fondements des méthodes agiles. En plus d'y (re)découvrir un tas
d'outils et de jeux agiles, c'est l'occasion d'échanger avec tous les participants et de remettre en
cause ses pratiques. Bref, une bonne remise à zéro des compteurs. Je ne vous révélerais pas plus
l'emploi du temps minuté-mais-aéré des trois jours (vous en saurez plus sur le site), je ne saurais
que vous recommander de sauter sur l'occasion de partiper à une prochaine édition du raid !
Ceci étant dit, revenons-en à l'objet principal de ce billet : ce que j'ai ramené dans ma petite
tête pour améliorer nos pratiques à Logilab. Ou en tout cas celle que j'essaie de mettre en place
avec mon équipe à Toulouse.
Une de mes principales problématiques est la suivante : comment adapter une méthode comme Scrum ou
un outil comme le kanban dans le cadre d'une petite société de service, où nous avons
majoritairement des petits projets, plusieurs en parallèle, développés par une à deux personnes
maximum ? La littérature sur le sujet applique systématiquement (à ma connaissance) la méthode à des
équipes de développement "produit" avec des phases souvent gérées par des personnes différentes
(développeurs, testeurs, intégrateurs, etc.). Ça fait un moment que je tâtonne sur le sujet, d'une
manière parfois satisfaisante, parfois frustrante, mais certainement améliorable. Sans prétendre
avoir répondu à toutes mes interrogations, une réflexion de Claude m'a donné envie d'améliorer un
point en particulier : travailler en équipe, plutôt qu'être une somme d'individus dans un même
espace. Le principal changement à conduire consistera donc à faire travailler tous
les membres de l'équipe sur tous les projets. Il y aura bien sûr un coût non-négligeable dans la
mise en place de chacun sur chaque projet, mais j'espère que cela sera contrebalancé par :
- la montée en compétence de l'ensemble de l'équipe ("essaimage")
- moins de spécialisation individuelle, plus de souplesse dans la gestion des projets
- un renforcement de l'esprit d'équipe
Pour moi, ça vaut donc le coup de tenter ! Et le compagnon de ce changement sera un autre point qui
me pose souvent question : le découpage des besoins du client en user stories (voir features ou
epics) et tâches, leur relation avec le kanban qu'on essaie de mettre en place (principalement
pour visualiser les tâches de chacun jusqu'ici) et notre extranet de gestion de projet. Jusqu'ici,
nous dupliquions plus ou moins l'information, sans vraiment faire ressortir la notion de tâche
autrement que dans les discussions informelles. Pour maintenir un rapport coût de gestion / besoin
de collaboration et d'indicateurs, on va maintenant essayer de maintenir les histoires dans
l'extranet, avec leur estimation, les discussions avec le client et autres (dépendance, relation aux
features, etc.), tout en ayant sur le kanban les tâches qui en découlent. Ceci devrait notamment
permettre de mieux échanger sur les implémentations des différentes histoires en amont, voire de
permettre à plusieurs personnes de travailler sur la même histoire. Et ainsi de rendre le kanban
plus au centre de notre gestion quotidienne en diminuant sa granularité.
Ces deux points sont les gros morceaux qu'il va falloir digérer dans les prochains mois. Parmi les
autres points abordés ou évoqués pendant la formation et ramenés en stock, il y a :
- faire un delegation board avec l'équipe à Toulouse et peut-être aussi à l'échelle de Logilab
entre les équipes de direction et de développement, voire au sein de l'équipe de direction ;
- ne pas oublier de faire fixer l'heure sur l'horloge de Cohn à nos clients qui jouent le jeu de
l'agilité (ils ne seront jamais assez nombreux) ;
- faire plus de rétrospectives, sans hésiter à en essayer différentes formes ;
- à l'occasion, réessayer un impact mapping, l'exercice le plus délicat que nous ayons abordé ;
- rappeler que si on fait des journées "compactes" à Toulouse, il ne faut pas oublier de maintenir un
rythme soutenable. Voir acheter un canapé ou un siège confortable pour les amateurs de power
nap (merci Pierre-Jean dont la pratique décomplexée est rafraichissante !) ;
- enfin creuser les core protocols et le business value game dès que possible, voire réfléchir
au #noSlides pour nos formations techniques.
Voilà, y a encore d'autres restes parmi les outils et idées discutés, mais je pense avoir cité ici
l'essentiel et ça promet déja des impacts non négligeables. J'accueillerais avec plaisir vos
remarques ou idées sur les points ci-dessus. Et avec un peu de chance j'aurais même le courage de
faire un billet pour raconter ces différentes expériences ! En tout cas, encore un grand merci à
Pablo et Claudio ainsi qu'à tous les participants de ce raid du changement.
