Richesse des modes de communication
J’ai pu récemment mettre en oeuvre un atelier très intéressant “Offing the Offsite” de James Shore . Son but est de mettre en évidence la richesse de la conversation (sous entendu générée par une user story dans le mode agile) face à la complexité d’écrire ou de lire une spécification. Je résume l’exercice mais je vous encourage à aller voir la page de James Shore. Il fournit tous les éléments en PDF, ainsi qu’un scénario. On délivre à la moitié des participants une feuille A4 avec un dessin tarabiscoté, on leur demande d’écrire la spécification qui permettra de réaliser ce dessin. 10mn passe, on appelle l’autre moitié des participants et on leur demande de réaliser les spécifications, ils ont 10mn. Dans l’exercice 2 on prend soin de changer les dessins tarabiscotés. Puis on demande aux personnes de décrire à leur partenaire, par le biais d’une conversation, les spécifications du dessin. Les “développeurs” ne peuvent naturellement pas voir le dessin (10mn à nouveau). Sans surprise on percevra l’évidente richesse d’une communication orale sous forme de conversation, à celle froide d’un document écrit (je renvoie aussi ici au diagramme proposé par Scott Ambler placé ci-dessus).
Fiche de lecture : Karmic Management, Roach/McNally/Gordon
Autre lecture cet été, Karmic Management, de Roach, McNally et Gordon. 150 pages qui se lisent en 1 ou 2 heures chez le coiffeur ou sur la plage, le soir dans le lit. Bon allons-y avec des pincettes. Il s’agit d’appliquer des préceptes bouddhistes au management. Gasp. re-gasp. Si j’ai lu ce bouquin c’est que l’un de mes associés me l’a conseillé. Il retrouve en partie dans ces préceptes notre façon de faire. Je ne peux pas le contre-dire. Si lui-même a lu ce livre c’est que l’un de nos clients lui a conseillé : “vous faites du Karmic Management !”. Avant de se sentir honoré il fallait jeter un œil à cette chose.
Fiche de lecture : Scrum, guide pratique, Claude Aubry
En ce début d’été j’ai pu le lire le livre de Claude Aubry. Je consulte régulièrement son blog (j’y retrouve deux sources d’intérêts : l’agilité ET le rock’n roll), lis ses tweets, et j’ai pu croiser celui-ci (assez brièvement) lors d’une présentation Scrum autour de Montpellier. Ses posts (blog) sont généralement simples (dans le bon sens du terme) et efficaces. Je m’attendais donc à quelque chose du même acabit. Mais en me disant : encore un bouquin sur Scrum, sur l’agilité… Il y en déjà pas mal, et des bons, enfin, la littérature disponible sur le web est pléthore. Bref l’exercice n’est pas facile.
Le piège de la contractualisation à la française
L’année dernière j’ai été fasciné par les résultats de l’exercice proposé par David Barnholdt concernant la réalisation de spécifications versus le détail de la demande fournie. David encadre deux groupes de travail, à chacun il donne 1 mn pour réaliser les spécifications suivantes, au premier groupe il demande : “dessiner une prairie durant une belle journée d’été, avec des fleurs bleues et rouges dans l’herbe verte, quelques vaches et quelques oiseaux sous un éclatant soleil”. Au second il demande : “dessiner une prairie durant une belle journée d’été avec : 10 fleurs bleues avec 5 pétales chacune, 5 fleurs bleues avec 6 pétales chacune, 13 fleurs rouges avec 6 pétales chacune, 2 vaches avec 3 tâches noires, 1 vache avec 5 tâches noires, 2 vaches avec 4 tâches noires, 2 oiseaux dans le coin gauche en haut, 3 oiseaux au milieu, le soleil à droite avec 5 rayons”. Le résultat est stupéfiant mais on aurait du s’en douter :
Conseils aux chefs de projet
Ouah. Quelle impudence ! donner des conseils à des chefs de projets. bon allez oui, osons. Juste quelques réflexions sur la façon de traiter certains aspects de votre projet. Ces réflexions viennent autant de mon expérience en la matière, et aussi de ce que je suis (ma personnalité), elles ne vont donc pas s’adapter à tous. Première chose à savoir faire c’est gérer les priorités. Dans la liste des actions à réaliser pour le projet vous devez savoir avec une certaine précision, ou une certaine intuition, dans quelle ordre les actions doivent s’agencer. Je ne vais pas donner d’exemple vous avez tous en tête les problématiques d’agencement et de dépendances soient techniques, soient organisationnelles, pour comprendre cela. En tant que chef de projet votre capacité à bien ordonner, a bien"prioriser" les tâches sera cruciale. Les tâches étant liées entre elles, les équipes affectées aux tâches, la somme des erreurs (qui sont inéluctables) peut s’avérer fatale à votre productivité. Il faut une certaine vision (globale) sur le projet, une certaine expérience, une compréhension des différents enjeux : un schéma mental du projet qui regroupe un peu tous ses axes (techniques, fonctionnels, planning, relation client, dispo des équipes, etc etc etc).Surtout ne pas avoir la “grille MS Project” complètement incrustée en mémoire, un projet est une chose qui évolue constamment -contrairement à votre planning/découpage initial- et donc cela ne marche pas ainsi. D’autant que les bonnes priorités sont aussi liées au rythme de votre client, à sa façon d’aborder le projet. En tous cas :
Les non-dits
Dans le meilleur des mondes il n’y aurait aucun non-dit. Qu’il s’agisse de la vie en générale, ou des projets informatiques (c’est le sujet ici !). Aucun non-dit est un idéal, mais cela n’arrive jamais (comme tous les idéaux). Il y a toujours quelque chose que l’on évite sciemment de dire à son client, son partenaire, son prestataire, etc. Généralement on cache une incapacité, une ignorance, une simple incertitude, etc. J’essaye, et je pense que cela est fructueux, d’éviter au maximum les non-dits. C’est toujours, toujours, toujours, un risque que vous faites courir inutilement à votre projet. Cela ne fait que complexifier la réalisation de celui-ci. Cela introduit un flou dans l’expression ou la résolution des besoins. Cela empêche de bien organiser le projet, etc. A partir du moment ou vous jetez une zone d’ombre sur le projet ne soyez pas surpris d’en subir les conséquences.
Scrum agit, CMMi observe. scrum et cmmi billet 4
Donc cette fameuse question : Scrum et CMMi sont-ils antinomiques ? ou sont-ils complémentaires ? Si l’on en croit le fameux article de Jeff Sutherland Scrum and CMMI Level 5: The Magic Potion for Code Warriors, que vous retrouverez traduit ici grâce à Fabrice Aimetti (merci à lui), la réponse est oui, mille fois oui. Mais bon, il s’agit d’une entreprise CMMi niveau 5 (ça ne court pas les rues dans le coin, je ne parle pas de telle ou telle SSII qui s’est fait tamponner niveau 5 sur son groupuscule indien de 10 développeurs et qui étend magiquement le macaron à l’ensemble de son groupe…). Si tant est que ayez la chance de travailler dans une structure CMMi niveau 5, je suppose qu’elles sont rares celles qui implémentent Scrum ou Lean comme dans l’exemple de Jeff Sutherland.