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.

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.

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 :

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 :

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.

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.

Toute ressemblance avec des personnes existantes ou ayant existé est purement fortuite.

Imaginons Cinthia, fraichement diplômée, qui se lance dans sa vie professionnelle. Elle est développeuse .Net et deux belles entreprises ont répondues positivement à sa candidature. Dans la première, on lui vante les mérites de CMMi, que la société décline jusqu’au niveau 4 (ce qui est excellent); dans la seconde on lui dit qu’elle sera “agile” avec XP & Scrum.