Anatomie d'une mission agile / Sudweb 2011
Dans quelques dizaines de jours, le 27 mai plus exactement, à Nîmes, j’aurais le plaisir de faire une session autour de l’agilité lors du premier Sudweb, 2011 donc. Il reste 24H chrono pour acheter des places ! Je tiens d’abord à saluer l’effort réalisé par ce groupe d’aventuriers : déclencher ce type d’évènement, avec ce standing (salle, vidéo, traiteur, orateurs étrangers), dans notre région… Bravo, hats off ! Pour ma part je dois représenter le quota gardois. eh eh.
Les enfants et le marshmallow challenge
J’ai été initié il y a peu de temps par Pierre au Marshmallow Challenge. Ce challenge très ludique permet de mettre en évidence l’intérêt du travail par itération (et optimisation), l’intérêt des équipes hétérogènes et complémentaires. Je vous recommande de vous plonger dans la documentation et d’essayer au moins une fois, c’est simple et rapide. Joué plus 70 000 fois, le plus grand rassemblement a réuni 800 personnes, ce n’est pas initialement un atelier agile et pourtant il rempli fort bien ce rôle. Le défi est -à partir de 20 spaghetti, d'1 mètre de scotch, d'1 mètre de corde et d’un marshmallow-de monter la tour la plus haute, le marshmallow devant figurer (intègre) à son sommet. Pour cela 18 minutes.
La dette technique selon Uderzo & Goscinny
Hello, après avoir rapidement jetez un oeil du côté de la loi de Parkinson, voyons aujourd’hui la notion de dette technique. Pour l’historique de cette notion assez simple mais ô combien efficace : wikipedia. Grosso modo l’idée est que, à chaque fois que vous réalisez “à la vite” du développement (généralement parce que quelqu’un exige une date de livraison trop difficile à tenir et donc que la qualité disparaît, ou parce que vos pratiques de développement ne sont pas assez pointues -TDD, Unit Test, Pair programming, refactoring, etc-.) ce même code vous demandera de payer des intérêts à terme. A chaque fois que vous reviendrez sur ce code, une somme de travail supplémentaire due à sa mauvais qualité sera -en plus-nécessaire.
La loi de Parkinson par Astérix & Obélix
La loi de Parkinson… ou les gaz parfaits… veut que “le travail s’étale de façon à occuper le temps disponible pour son achèvement”. Qui dans un projet classique n’a pas vécu cette expérience étrange ? Donnez 3 jours à un “réalisateur”, il consomme les 3 jours pour réaliser ses tâches, donnez lui 10 jours, c’est 10 jours qu’il utilisera… Oui on évite cela avec Scrum au passage ou plus globalement avec l’agile, mais fallait-il le préciser ? Je vous laisse déguster l’explication éminement efficace de Uderzo & Goscinny dans Astérix en Corse.
L'agile pourrait-il redonner à la régie ses lettres de noblesse ?
Cher client, cher acheteur, Si je t’écris cette lettre c’est pour te souhaiter de réussir tes projets. Naturellement il ne t’aura pas échappé que réussir un projet “au forfait” est une entreprise incertaine, malgré le contrat qui te lie à ton prestataire. Je me doute que si tu es mature tu as déjà compris que les projets importants, les projets stratégiques, tu ne vas pas les confier à une société externe. Ce “forfait” qui va partir avec tes demandes et revenir quelques temps plus tard avec un résultat plus qu’incertain ? Un “forfait” dont tu ne connais pas les intervenants, peut-être même que tu ne connais ni leurs visages, ni leurs noms, à ces gens qui vont travailler sur ton projet. Même si il y a de nombreux projets au forfait qui fonctionnent bien, les projets importants, stratégiques, tu les soignes, tu ne les confies pas à des inconnus. Tu souhaites être proche de leur réalisation.
Comment les agilistes s'organisent ?
Récemment Jurgen Appelo a déclenché une initiative prometteuse : réunir, fédérer les agilistes européens. Je trouve cette action très intéressante. Surtout dans sa forme. Jurgen essaye de laisser le réseau faire émerger sa propre organisation tout en l’accompagnant (et pas en le guidant). Je ne sais pas si il réussira. On sent de nombreuses tensions derrière (pas de sa part !), mais comme me l’a glissé Laurent B., l’agile devient “un secteur de l’économie du logiciel” (j’aime sa formule), et donc l’agile aiguise les appétits. Chaque initiative, chaque positionnement est observé avec suspicion. (Ah j’oubliais un postulat important : je suis paranoïaque). Jurgen évoque une grosse liste -beaucoup d’agilistes d’Europe-, une petite liste -les agilistes qui se positionnent pour les actions types conférences, etc.- et une mini-liste : les personnes clefs. Oups pardon, Jurgen précise bien que plus la liste est réduite moins elle est importante (en taille comme en valeur), donc il ne s’agit pas de personnes clefs, du moins pas comme on l’entend habituellement. Il faut faire l’effort de le croire sur parole, car d’instinct on imagine l’inverse: que la mini liste dirige la petite qui dirige la grosse. Jurgen espère -et je l’espère aussi- que la mini liste encadrera la petite qui encadrera la grosse. Encadrer au lieu de diriger. Pas de prévalence.
L'identité agile européenne
Très récemment, Jurgen Appelo (Noop.nl) a lancé une réflexion sur un positionnement européen de l’agilité au travers d’une discussion sur LinkedIn. Ses conclusions et la synthèse des commentaires a pris la forme d’un “post” sur son blog : Agile Europe, entrons en action. Je me propose de le traduire ci-dessous et je vous suggère à tous agilistes de France et de Navarre de prendre contact avec Jurgen. En français ou en anglais, car c’est la première chose que je me suis permis de remonter : le problème de la langue, particulièrement dans notre pays. Je suis sûr que nous avons plein d’agilistes de talents qui ne comprennent rien à la langue de Shakespeare. Cela serait dommage de perdre leur apport. A priori Jurgen Appelo a déjà bien conscience de cette difficulté, inhérente à notre condition européenne.*