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 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 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 :
Groupe 1
Groupe 2
Les commentaires sont sur le blog de David Barnholdt mais on aura compris…
Mon propos est d’extrapoler ce jeu de causes et effets au niveau de la contractualisation des projets. On pourrait dire que l’on reste dans le même domaine: expression des besoins (spécifications) que j’étends à la phase précédente cahiers des charges, etc. et donc de la contractualisation.
En France la culture du forfait avec un périmètre très défini est forte, encore plus dans le cadre des appels d’offres publics. C’est à mon avis l’une des causes majeures des échecs ou des difficultés ressentis dans les projets informatiques.
D’une part tout le monde sait bien qu’il est impossible de connaitre 100% de son périmètre à l’avance (si vous lisez Schwaber Popendieck* il dissémine quelques anecdotes “rigolotes” dont celle des “marines” (prononcez “marines” avec un cigare dans la bouche) : lorsqu’ils déclenchent une attaque ils connaissent 70% de leur plan, ils savent que 30% de ce qui va arriver n’est pas “prédictible”). Donc s’engager, payer, contractualiser sur quelque chose d’inconnu ou pire, de faux, est une lourde erreur, lourde de conséquences.
D’autre part, non content de ne pouvoir définir 100% du périmètre par avance, le client, le demandeur, a toujours la crainte de se voir bafouer, flouer : il va donc sur-spécifier (c’est là que je rebondis sur l’exercice évoqué précédemment). Il va en demander des tonnes pour être sûr d’en avoir “pour son argent”. Et cela va se révéler contre-productif : la “sur-spécification”, la spécialisation, va probablement entrainer des développements à façon qui, si ils vont répondre très précisément à un point, vont interdire et limiter fortement tous les autres aspects fonctionnels ou techniques.
On ne peut pas les blâmer, les SSII ont pour vocations de faire des bénéfices et quand il y a contentieux, c’est le cahiers des charges ou les spécifications qui font foi, donc très rapidement. Bref, c’est une lutte, une guerre de tranchées, plutôt qu’une collaboration. Et c’est le serpent qui se mord la queue, car plus les SSII vont jouer bêtement leur rôle, plus les clients vont sur-spécifier.
Difficile aussi de trouver une voie de sortie : si un client fait l’effort de ne pas “en rajouter” la SSII va prendre cela pour un effet d’aubaine et se jeter sur une marge probable à dégager. Je reviens à l’agilité qui est -là encore- la meilleure solution, itération, collaboration, enfin du bon sens. On doit rompre avec une contractualisation basée sur un périmètre complet pré-défini. Aujourd’hui dans le cadre des marchés publics c’est malheureusement quasiment impossible.
Deux maximes à méditer : (faîtes OooommmM) “le mieux est l’ennemi du bien”, “All failure comes from misunderstanding” (“tout échec vient d’une incompréhension”, the wheel of life, truc tibétain, 500 ans av JC)
* oui je me trompe, il me semble que c’est plutôt (les) Popendieck dans “Lean Software Management”, je vais vérifier
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 ?
Juste un retour sur une petite analyse concernant les portails Java sur le marché actuellement. Je ne les connais pas tous naturellement, j’ai pu travaillé avec certains, sur d’autres je n’ai que des retours d’expériences récupérés par ci par là. Je ne me permettrai donc pas d’avoir un jugement définitif, mais en quelques mots je vous indique mon ressenti, si cela peut aider certaines personnes ?
Toute ressemblance avec des personnes existantes ou ayant existé est purement fortuite.
J’entame donc ces petites mises en perspectives entre Scrum et CMMi par les questions de management de projet. Je ne vais pas mettre -encore une fois- en avant la dichotomie entre le chef de projet et le scrummaster, elle ne m’intéresse pas forcément telle qu’elle est présentée et elle n’est pas forcément aussi vraie que cela. Non pour juste dire ce qui sépare dans ma pratique de Scrum et de CMMi la notion de chef de projet/scrummaster je vais plutôt m’appuyer sur un passage de l’excellentissime “Lean Software Management” de Marie et Tom Poppendieck (que j’encourage tout le monde à lire) qui lui même cite le livre “What leaders really do” de John Kotter. Synthétiquement on va séparer deux profils : les managers et les leaders.
Je souhaite réaliser une petites séries de billets dont le but est une mise en perspective entre Scrum et CMMi. Ces billets n’ont pas pour but de préconiser l’un plutôt que l’autre mais de faire partager mon humble expérience à ce sujet : je viens de passer plus de 3 années au sein d’une structure dont CMMi a été l’épine dorsale. A ce titre et ayant œuvré en tant que consultant ou chef de projet j’ai mis en œuvre des pratiques CMMi jusqu’au niveau 4. J’ai abordé Scrum il y a 3 ans mais cela n’a pas été retenu alors dans cette structure, et seulement depuis fin 2008 les projets Scrum sont déroulés. La question revenant régulièrement sur le tapis, écrire des billets à ce sujet me permet aussi d’organiser ma pensée.