Une amie, à la lecture de mon blog, m'a rétorqué : "j'y comprends rien".
Comme quoi une petite prise de recul fait toujours du bien, je vais tenter, sans parler "chinois", d'expliquer mon métier aux visiteurs se promenant ici par hasard.
Je suis donc Chef de Projet Technologie Web, Scrum Master, voire Product Owner, bon, ça commence mal! Je barre tout ça, et je recommence.
Je suis animateur d'équipes. J'ai mis en place un cycle de travail de deux semaines.
Le premier lundi
Le premier lundi, notre commanditaire nous expose les différentes nouveautés qu'il souhaiterait voir aparaître sur nos sites Internet, selon un ordre de priorité. Il peut s'agir d'un nouveau service proposé à nos internautes, d'une nouvelle rubrique, d'une correction d'un dysfonctionnement ou l'amélioration d'une rubrique existante, mais qui ne fonctionne pas très bien.
Avec l'ensemble de l'équipe, nous évaluons la charge de travail nécessaire à la mise en place de chaque nouveauté, de manière relative. C'est-à-dire que ce qui est important, ce n'est pas de savoir qu'il faille 2 jours pour modifier un menu du site et 4 jours pour reprendre le design de la home page, mais c'est de se dire il faut deux fois plus de temps pour reprendre le design de la home que pour modifier un menu.
Ensuite, je demande à l'équipe de s'engager, collectivement, sur un ensemble de nouveautés à mettre en place pendant la quinzaine. Ce n'est pas moi qui impose "vous me ferez ça et ça et ça, et si c'est pas fait, vous êtes tous virés!". Non, c'est collectivement que l'équipe choisit de faire "ça et ça et ça" et s'engage sur cet ensemble de nouveauté à mettre en place. La seule contrainte, c'est de suivre les priorités du commanditaire.
Une fois que nous avons un ensemble de nouveautés à traiter, nous les décomposons en petite tâche, dont il est aisé d'évaluer les nombre d'heures nécessaire à leur réalisation. Celà nous donne donc le plan de développement sur lequel l'équipe va travailler pendant la quinzaine. Mais pour l'instant, personne n'a dit qui va faire quoi. En effet, dans une méthode traditionnelle, je dirais "toi, tu fais ci. Machine, tu fais ça. Truc, tu t'occupe de ceci et celà." Non, je ne dis pas ça. J'anime l'équipe, mais je ne commande rien. C'est l'équipe elle-même qui s'auto-organise. Comment ça marche? Nous écrivons l'ensemble des tâches sur des post-it colorés, avec le temps estimé pour leur réalisation, et nous les collons au mur!
Tout les matins
Je réunis toute l'équipe autour de moi et nous faisons face au tâches collées sur le mur. Et à chacun, tour à tour, je pose ces trois questions immuables : "Qu'as-tu fait hier? Que feras-tu aujourd'hui? As-tu rencontré un problème?". Et chacun répond, non pas à moi spécialement, mais à toute l'équipe. Ainsi, chacun sait ce que chacun a fait et fera. Et comme les tâches sont accrochées au mur, il m'est facile, pendant que chacun s'exprime, de modifier les temps des tâches. Je barre les tâches qui sont terminées. Je modifie les temps restant selon les indications de chacun. Parfois, quelqu'un s'aperçoit qu'une tâche avait été oubliée. dans ce cas, on l'écrit sur un nouveau post-it, et on la colle sur le mur.
Comme ceci se passe tous les jours, on sait tous l'avancement global des choses à faire, ce que chacun fait et compte faire.
Le dernier vendredi
C'est le jour de la démo. Je convie notre commanditaire, voire d'autres managers ou collègues interessés, et les différents membres de l'équipe exposent le travail effectué lors de cette quinzaine. Des échanges ont lieu, des demandes de modification peuvent avoir lieu...
Puis, je réunis l'équipe une dernière fois, pour faire une rétrospective de la quinzaine. En posant à chacun trois questions : "as ton avis, qu'est-ce qui s'est bien passé? qu'est-ce que nous pourrions améliorer? qu'est-ce qui n'a pas fonctionné et que nous devons changer?". Chacun s'exprime, moi compris, et de cet échange, nous batissons un avenir meilleurs.
Et ainsi de suite...
Bravo tu as réussi le tour de force à expliquer de manière extrémement simple comment peut fonctionner une équipe travaillant sur un projet informatique. Tout cela ne semble être que du bon sens. Je vais me prescrire de relire ta démonstration tous les matins pour m'en imprégner fortemement ;).
Rédigé par : Didier Bretin | jeudi 12 juin 2008 à 08:26
Merci Frédéric pour cette explication de l'agilité en contexte.
Expliquée ainsi il ne devrait plus y avoir de raisons pour ne pas sauter le pas.
Dans la majorité des cas, l'essayer, c'est l'adopter!
Rédigé par : Camille | mardi 10 juin 2008 à 17:41