DESSIN ORIGINAL

Spécifications écrites

Conversation

Sur le second c’est encore plus flagrant (en cliquant sur les images, vous pouvez avoir les versions grandes tailles). J’ai du charger la luminosité ou les contrastes afin de faire ressortir les traits (d’où l’effet baveux…)

DESSIN ORIGINAL

Spécifications écrites

Conversation

Durant cette session j’ai pu faire ressortir deux écueils présents lors de la phase de spécifications écrites qui disparaissaient avec la conversation :  des problèmes de terminologie (“mais qu’a-t-il voulu dire par là ???”), des problèmes de déséquilibre entre la sur-qualité de certains éléments : on s’applique à faire quelque chose que l’on pense avoir compris, et l’absence d’éléments que l’on a omis. La conversation permet la reformulation si il y a un problème de terminologie. Elle permet aussi de dire : “c’est bon, c’est assez, inutile d’aller si loin”, et “tu as oublié ceci ou cela”. C’est évident mais toujours très instructif.

Elémentaire mon cher Watson.

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.

Mais disons le tout de suite, ce livre est une réussite et l’épreuve est passée avec brio.

Premier bénéfice évident :  un livre qui aborde et regroupe beaucoup d’informations concernant Scrum en français. Cela manquait et c’est très bien. Beaucoup de gens ne sont pas forcément à l’aise avec l’anglais et cela pouvait être une source de blocage ou de quiproquo (et donc de rejet de Scrum).

Deuxième évidence : Claude a sacrément creusé son sujet. Il ne mégote pas sur la qualité, mais aussi sur la quantité. Il a beaucoup de contenu. Beaucoup de sujets sont triturés, fouillés (théorie, pratique). Il a une approche très cadencée : thème A, point 1, point 2, point 3, etc. On va donc pouvoir se servir de ce livre comme référence, ce n’est pas un simple ouvrage pédagogique, d’initiation, d’introduction, c’est aussi un manuel (…hum… un guide ? ah oui. c’est ça).

Enfin Claude est un bon vulgarisateur (dans le bon sens du terme). Tout est expliqué clairement et semble couler de source. En cela j’imagine que Scrum l’a aidé.

Pour finir, la réussite du livre tient dans ces 3 facteurs. On a un ouvrage qui va permettre au débutant de se plonger facilement et entièrement dans Scrum, tout en demeurant avec le temps un manuel de références et de rappel des bonnes pratiques pour quelqu’un de plus avancé sur le sujet.

J’en recommande la lecture à tous (avec en fond sonore le dernier album 2009 des Black Crowes qui se transcendent avec l’âge : “Before the frost”).

Amazon ?

ps : En tant que lecteur j’apprécierai pour son prochain livre soit un recueil de retours d’expériences ; soit un approfondissement de la problématique de la conduite du changement à mener dans une organisation avec l’introduction de l’agilité et de Scrum.

ps 2 : Il trouve le moyen de caser Led Zeppelin dans son livre, j’admire.

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

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.

Savoir gérer les priorités

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 :

1. N’hésitez pas mais basez vos choix sur une réflexion logique : je déclenche cela parce ça ça et ça (=> votre “schéma mental du projet”).
2. Tout le monde peut se tromper, sachez revenir en arrière si besoin, ou stopper une tâche en cours dès que les premiers “feedback” montrent que ce n’était pas le bon choix (ou parce qu’un autre critère est venu changer la donne).
3. Soyez prêt à dire oui,non à tout instant. Surtout “non” en fait, car il faut éviter de démarrer des tâches qui seront mieux appréhendées plus tard dans le projet. Gardez sous le coude des tâches “buffer/tampon”, pas complexes, incompressibles (qui devront être réalisées quoi qu’il arrive), qui n’ont pas besoin d’être réalisées par un profil particulier, et qui n’ont pas de dépendances, ceci afin de vous donner un peu le temps de la réflexion si besoin.

Savoir déléguer

Ahh ça c’est dur. hein. Combien de fois vous êtes vous dit : “bon ok, si je le fais cela va prendre 30mn, si je lui donne, hum… 4h”. Donc vous le faites… J’y décèle deux grosses erreurs : d’abord fini la gestion des priorités évoquée plus haut puisque vous vous lancez dans une tâche inattendue qui devient priorité 1 (pour de très mauvaises raisons) et vous empêche de garder assez de recul et assez de temps pour continuer à bien mener le projet.

Deuxièmement, vous faites un très mauvais pari pour l’avenir.  Ce choix indique que vous n’avez pas confiance en vos équipiers.  Peut-être à juste titre, mais le minimum est de leur donner leur chance une ou plusieurs fois. Si effectivement vous ne pouvez pas avoir confiance en certains de vos équipiers il faut le dire et prendre une décision à ce sujet (j’y reviendrai). Mais il faut se baser sur des faits concrets et responsabiliser les gens. Affecter les tâches. Dans de nombreux cas cela va se révéler payant : des gens vont progresser, vous aurez confiance en eux, vous pourrez déléguer de plus en plus souvent, ils en seront contents (voire fiers).

Même cas de figure : je commence le tâche pour qu’elle parte sur “de bonnes bases” puis je la délègue. Même problème. Sachez juger a posteriori : ce jugement sera basé sur des faits ! (c’est quand même indispensable non ? )

Savoir dire à vos collaborateurs que les choses vont mal au moment ou elles se produisent

Je rebondis sur le paragraphe précédent. On juge les gens sur des faits.  Donc A) pas de jugement a priori. Le boulot se déroule mal : trop de retard, pas de qualité, etc. On le dit. On ne porte pas de jugement, on dit les choses. Nous avons du retard. Pourquoi ? discutons. sachons pourquoi. Cela n’est pas forcément lié à la personne naturellement : elle n’a pas été formée, les specs ou exigences sont pourries, un problème inattendue a surgit. etc etc. C’est vraiment lié à la personne (elle n’est pas motivée, ne fait aucun effort, a des problèmes personnels qui la rendent acariâtre, etc. ) : on lui dit. Je ne suis pas satisfait pour telle et telle raison. J’attends de toi ça ça et ça. Peux-tu faire un effort sur ces points. merci. Si les problèmes se reproduisent régulièrement et sont vouées a ne pas évoluer je vous recommande de sortir la personne du projet. Cela arrive rarement si à intervalles réguliers on dit les choses. Dire les choses est la première façon d’instaurer une certaine confiance ou a minima un certain contrat. Quoi de plus injuste que de se faire sortir d’un projet sans avoir vu venir le boulet ? Quoi de plus normal d’être prévenu lors que l’on est pas satisfait de votre travail ? Quoi de plus grisant que de s’observer progresser ? (je vous renvoie sur le même sujet à ce post)

Et son corollaire : faire comprendre qu’un jugement sur une personne n’est ni définitif ni personnel

Je vois trop de chef de projet qui ne disent pas les choses car ils ont le sentiment que leur jugement est définitif et global. Si je dis à X qu’il a mal fait cette tâche c’est comme si je lui disais qu’il est mauvais. Rien de plus faux ! Répétez le autant qu’il le faudra à vos collaborateurs, mais soyez convaincu vous même : oui il y a des bons, oui il y a des mauvais, mais chacun peut changer de catégorie selon les projets, avec le temps (dans les deux sens), selon les interlocuteurs, selon le contexte etc. Ce n’est pas à vous d’avoir un jugement : c’est à vous de leur laissez l’occasion de faire leur preuve. Je reviens au point précédent : ne pas dire les choses quand elles se produisent mais plus tard, trop tard, ne fait qu’accentuer ce sentiment et ce trouble que le jugement est global. Si vous dites les choses ponctuellement en liaison directe avec un évènement présent cela évite beaucoup de quiproquo.

photo de : http://www.flickr.com/photos/atomicshed/161716498/sizes/s/

Sachant qu’au final souvent personne n’est dupe et que le non-dit a un prix : Amplification du stress ? Sur une partie que vous ne dominez pas vraiment mais sur laquelle vous vous êtes vendu ? Amplification du dommage, si vous laissez trainer un aspect technique ou fonctionnel que vous savez pertinemment défaillant ? Amplification de la charge ? l’un des membres de l’équipe n’est pas à la hauteur ? Il faut lui dire. Il devra faire l’effort de se mettre au niveau ou devra quitter le projet, mais dans ce deuxième cas, il aura été informé, et la blessure sera moins forte et plus compréhensible, etc, etc.

N’est-il pas évident qu’un jeune sans expérience répond oui à tout (oh ces CVs que je vois passer ! Messieurs les professeurs d’IUT, d’école informatique, ayez la décence d’expliquer à vos étudiants de ne pas mettre le glossaire de technipedia dans leur CV, ni -au passage- de se proposer Chef de projet des leur première année professionnelle), alors q’un vieux singe expérimenté dira plutôt non,  gage de confiance… (trouvez moi une maxime de Samuraï qui exprime cela en 4 mots).

Ne laissez pas trainer des anomalies, ne laissez pas trainer du code sale, ne laissez pas trainer des incompréhensions, des quiproquos, ils vous reviendront à la figure. Je sais que ce n’est pas simple, je suis le premier à me défausser parfois devant la tâche, mais vous aurez la surprise de voir se renforcer la relation que vous entretenez avec votre interlocuteur, de voir s’éclaircir la gestion du projet, de rendre les choses plus SIMPLES.

On peut rapprocher cela du courage des méthodes agiles. Rappelez vous que Lean demande de ne pas laissez trainer une anomalie. etc.

Le non-dit n’est pas nécessairement de votre fait. Essayez de persuader vos clients de ne pas en abuser, de comprendre où ils se cachent. Devinez les vrais enjeux qui se cachent derrière certaines demandes, derrière certains blocages, etc.

Joker pour les parties commerciales d’avant-ventes : pour ma pomme ces choses sont beaucoup plus simples depuis que je suis consultant (avec mes 2 associés chez SmartView), nous faisons du conseil : la vérité, la franchise sont donc essentielles et naturelles, et surtout je m’engage en mon nom, sur mon travail. Je ne m’engage pas sur une hypothétique équipe qui va réaliser le projet. Mais je ne peux pas jeter la pierre aux commerciaux des sociétés types SSII. Si la partie contractuelle n’est pas toujours juste, ni fair-play  : on va choisir le moins cher sans tenir compte de la qualité, il peut être compréhensible que la réponse ne soient pas toujours vraie. On comprend bien que de trop nombreux projets sont viciés dès la phase de vente. D’où à mon avis le succès des méthodes agiles aujourd’hui.

Je ne vous demande pas non plus de clamer partout et à haute voix tout ce qui se déroule sur le projet. Ce n’est pas le propos*. Je fais appel à votre intelligence pour bien comprendre où se situe la frontière.

Les non-dits dans les projets informatiques, c’est comme les secrets de familles, à la fin ça brise les gens, les dynamiques, les équipes, les projets.

* petite pub pour un ami.

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.

Mais il n’empêche je suis assez d’accord pour dire, selon mon expérience personnelle que les deux se complètent bien, car je vois bien dans ma pratique personnelle que selon les besoins je me tourne soit vers l’agilité (Scrum/XP) soit vers CMMi. Alors dans quels cas ? Puisque c’est cela la question.

Pour résumer : je me tourne vers l’agilité dès qu’il s’agit de produire, de créer, donc de réaliser des projets. Je me tourne vers CMMi dès que je dois auditer. Normal, rien de surprenant. C’est une joyeuse lapalissade. CMMi est un modèle, Scrum est une méthode. Les mots sont importants, une méthode, c’est un ensemble de procédés raisonnés pour faire une chose ;  un modèle c’est une représentation, en informatique (pour CMMi) des structures, des traitements, de pratiques… Une représentation c’est aussi une image, un tableau, une photo prise à l’instant T. La temporalité (oh là là on va m’accuser de branlette intellectuelle, mais que voulez vous j’ai fait fac de lettres ) est différente : action (mouvement, durée) du côté de Scrum, représentation (état, analyse, définition, instant présent) du côté de CMMi.

Naturellement dans l’entreprise les deux sont requis : l’action (création de valeur : les projets etc.), la représentation (indicateurs, analyse, consolidation, etc.). La difficulté est que les deux se situent sur des plans différents et ne sont pas forcément réalisés par les mêmes personnes, ni comme on l’a vu dans le même rythme. Le scrummaster (allez disons le chef de projet), les développeurs, etc. sont dans l’action ; le management (pour utiliser un mot chapeau facile) consolide, analyse à un niveau macro (le Scrummaster consolide et analyse au niveau de son projet !). Rien n’est demandé par exemple spécifiquement au membre de l’équipe scrum concernant l’utilisation de son temps. Il fait parti de l’équipe et il participe (constamment) au projet. Pourtant on comprend bien qu’il devra saisir à un moment ou à un autre son temps passé sur tel ou tel projet dans un outil de consolidation groupe. Je me rappelle aussi d’un projet Scrum qui avait très bien marché et sur lequel on me demande une consolidation tâche/planning dans un cadre CMMi. En forme de pied de nez j’ai remis les photos des radiateurs au fil des jours (c’est une bonne pratique de prendre ses radiateurs en photo tous les jours) mais cela n’est pas vraiment une bonne réponse à la question qui m’était posée j’en conviens car c’est assez inexploitable en l’état… Il faut donc que l’agilité ait l’intelligence de fournir à des modèles comme CMMi les informations nécessaires (je pense que tout l’outillage XP est un premier pont important. Il va donner des métriques importants). En contrepartie il ne faut pas que l’inertie, le côté statique du modèle, vienne rompre le rythme et le dynamisme du projet Agile.

Il faut essayer de réaliser des convergences c’est tout l’enjeu. CMMi sera demandeur, et Scrum fournisseur. A mes yeux on a un pris le chemin en sens inverse : aujourd’hui c’est Scrum qui vient dynamiter l’inertie de CMMi dans les sociétés. C’est plutôt CMMi qui devrait venir consolider les processus Scrum déjà en place. Consolider en donnant des indicateurs forts qui permettront de mieux mener les projets agiles sans les déranger par ailleurs. Une convergence riche d’enseignement mais qui tient sur un équilibre probablement fragile.

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.

Je vais essayer de ne pas être négatif du tout pour faire ressortir que les bons côtés de chaque approche. Je vous fais confiance pour imaginer tout ce qui pourrait ne pas se passer ainsi dans la réalité.

Imaginons qu’elle opte pour la première. Le très évident avantage qu’elle va tirer d’une société CMMi est l’encadrement méthodologique sur lequel elle va pouvoir s’appuyer, les gardes-fous qu’on va lui proposer. On va vérifier qu’elle a pris connaissance de tous les éléments du projet sur lequel elle va travailler. Elle verra clairement les tâches qu’on lui affectera (avec des specs très précises), ainsi que la charge que l’on estimera (avec elle si c’est possible). Elle va clairement tracer dans son code sur quelle partie du projet elle travaille, et à quelle demande, quelle exigence du projet elle répond ainsi. Son code sera soumis de temps en temps à des revues de la part d’experts, on va s’assurer qu’elle a bien connaissance de la configuration du projet (serveur de dev, de staging, de prod, arborescence du code, etc etc.) et son planning. Mieux, on lui signale que le taux d’anomalies qu’elle a relevé ne correspond pas aux moyennes de ce genre de projet dans ce contexte et qu’elle devrait refaire une passe dessus pour valider que vraiment tout est ok. Bingo, elle découvre une belle série d’anomalies qui lui avaient échappées.
Pour elle c’est parfait, le côté bordélique et fofolle qu’elle a bien pris soin de cacher en entretien d’embauche, est gommé par le cadre méthodologique qu’on lui propose. Dieu est chef de projet ou le chef de projet est Dieu. En tous cas le chef de projet est l’interface avec le reste du monde : le client, le management, le responsable qualité, etc. Elle est tranquille dans son coin, avec son casque sur les oreilles dans lequel elle écoute à fond Neil Young chanter “Heart Of Gold” et elle jubile, car, ça y est, elle “pisse” du code.

Imaginons qu’elle opte pour la seconde. La voici qui débarque. On lui présente François, Martial & Yves. Ils ne payent pas de mine mais ils ont l’air sympas. C’est l’équipe lui dit-on. Son équipe. Et voici Pierrot le ScrumMaster, il s’arrange pour qu’elle se sente à l’aise et s’assure que tout roule. Demain le projet démarre elle fera une journée avec l’équipe, son équipe, et le client, ils vont parler du projet, de ce que le client veut, de ce qu’il est possible de faire. Ca y est le projet a démarré. Tous les jours on parle : qu’est ce qui marche, qu’est ce qui ne marche pas, du coup elle entend et comprend tout, et n’hésite pas à poser des questions si quelque chose lui échappe. Elle apprend vite et si elle a un souci, Martial vient développer avec elle. De toute façon on lui demande de faire des tests automatiques tout le temps, du coup ça la rassure : elle sait qu’elle ne casse rien, elle sait que son code marche. ouf. Son côté bordélique et fofolle qu’elle a caché lors de l’entretien d’embauche n’est pas très problématique car le périmètre est finalement très précis, et limité dans le temps avec des itérations relativement courtes. Elle n’a pas l’occasion de s’oublier dans des dérives stériles. Tout est là, à l’esprit, clair. D’ailleurs on présente régulièrement au client le résultat du boulot et celui oriente l’équipe ou précise ce qui ne va pas. Incroyable le client a apprécié une de ces propositions et son idée sera déployée dans le produit final. Le projet avance bien et on fête ça ce midi en partageant tous une megapizza et en gueulant comme des fous “T N T, I’m dynamite !!!“.

Au prochain post, je parle de Caroline, chef de projet fraichement arrivée d’une entreprise sans aucune méthode et qui se fait embaucher dans les deux même sociétés et j’essaye de résumer ma pensée (un peu bordélique et fofolle).

Du côté du manager : on planifie, on budgetise, on organise, on “staff”, on trace et on contrôle. Du côté du leader on indique la direction, la vision, on fédère les gens, on motive les équipes.Voilà tout est dit. Oui je sais j’enfonce allègrement des portes ouvertes.

1ère porte ouverte enfoncée : Rien n’empêche à un chef de projet CMMi d’indiquer la direction la vision, de fédérer les gens, etc.. au contraire c’est la panacée. L’inverse pour le scrummaster est aussi vrai. Seulement il faut bien garder en tête que l’on va d’abord demander à un chef de projet CMMi d’organiser de tracer et de contrôler, et que l’on va d’abord demander à un scrummaster de fédérer et d’accompagner l’équipe.

2ème porte ouverte enfoncée : Certaines personnes ne seront jamais compatibles avec l’une de ces deux missions, ce n’est pas dans leurs natures, cela ne les intéressent pas. J’insiste surtout les notions de fédération de motivation, de leadership, et là je sors un joker un peu tarte à la crême : tout cela est aussi beaucoup affaire d’empathie et de psychologie.

Quelques paradoxes aussi :

Le management désire des leaders, cela donne de la cohésion à ses équipes, cela génère des dynamiques, et ils sont généralement des différentiateurs forts dans les appels d’offres. Car le leader possède une compétence (souvent technique) forte. C’est souvent là dessus qu’il assied son leadership. Oui à mes yeux un ScrumMaster doit avoir une compétence technique conséquente, ce qui n’est absolument pas un pré-requis pour le Chef de projet (CMMi). Au contraire souvent je vois pas mal de gens désirer le poste de Chef de projet pour s’extraire des contingences techniques : ils ne souhaitent plus développer. Ils veulent prendre “de la hauteur” (faire les spécifications, tracer, contrôler, etc.). C’est la verticalité des rôles CMMi. Verticalité exprimée aussi par la hiérarchisation : le Chef de projet est chapeauté par de le Directeur de projet. A l’inverse je perçois le modèle Scrum comme horizontal. Le Scrummaster, le Product Owner, l’Equipe, tout le monde est sur le même plan. Je reviens à mon propos : le management désire des leaders pour tout les raisons évoquées plus haut. Mais cela l’embête bien. Pour lui c’est plus simple de ne pas valoriser certaines personnes, c’est plus simple d’interchanger les personnes, de consolider et de prévoir si il n’y a pas de disparité dans les profils. C’est un reproche assez fort que je fais à l’implémentation de CMMi tel que je l’ai vécue : une hypocrisie forte à continuer à présenter les gens comme égaux, ou tout au moins “assez armé” (grâce aux processus mises en oeuvre pour répondre au modèle CMMi), pour pouvoir être placés, déplacés, interchangeables. J’exagère un peu, mais c’était l’idée dominante dans mon vécu. Dans les faits, tout le monde savait exactement que c’est le contraire qui était vrai. Le management veut des leaders mais préfère gérer des “managers”. En fait là j’étend la notion de leader à celle de personne clef. C’est différent, mais dans les relations que j’ai perçu entre management et équipe, avec scrum ou cmmi, la réponse était la même. Cela dérange CMMi d’avoir des personnes clefs car justement le modèle refuse une trop forte personnalisation et se base sur de fortes pratiques. Or tout le monde sait qu’un projet se bâtit sur des personnes clefs. Dernière remarque à ce sujet, une personne clef un jour ne l’est pas nécessairement le lendemain. Je veux dire par là que ce n’est pas une façon de distinguer des bons et des mauvais, pas du tout.

La verticalité que j’évoque dans le modèle classique CMMI et du chef de projet, a le mérite de proposer une hiérarchie claire : chef de projet, directeur de projets, voire top management, et puis les -plus bas- les développeurs, transverse, les responsables qualité, etc. Il est clair que pour les développeurs ce n’est pas valorisant. Mais c’est assez reposant (moins de responsabilité et d’implication). C’est la hiérarchie qui va encaisser les chocs (quand elle joue correctement le jeu, et que le Chef de projet n’est pas un fusible). Elle a les moyens de substituer le chef de projet (ou une autre personne) si quelque chose coince (pour x raison, ne serait-ce au bout d’un certains que l’usure…). Chez Scrum c’est plus compliqué, le système est normalement comme je le dis, horizontal. Ce n’est pas simple. Si un membre de l’équipe ne fait pas l’affaire ? (“on le sort au plus tôt !” nous dit Extrême Programming, “tu lui en as parlé et qu’en pense-t-il” nous dit scrum, dans les deux cas de jolies phrases mais peu réalistes).Pas d’échappatoire, beaucoup moins de leviers sur lesquels jouer. La mayonnaise prend, …ou pas, il n’y a pas de prédictibilité. Un projet Scrum ou la mayonnaise ne prend pas, c’est complexe, que faire sinon faire le constat de l’échec et : changer les équipes (!!!), passer dans un autre mode ? Mais au moins on aura rapidement de la visibilité sur ce problème.

Ce rôle de ScrumMaster que j’associe au leader est d’autant plus complexe que ce leader doit s’effacer pour que l’équipe et le product owner prennent leur responsabilité.

Donc,

Le chef de projet de CMMi est d’abord pour présent pour consolider toutes les infos, traces, planning, etc. du projet. Si quelque chose va de travers il est sensé anticiper et alerter ou déclencher des actions pour palier aux risques présents ou aux problèmes qui apparaissent. Il surveille : le périmètre, les livrables, les compteurs, les équipes, etc. Il rend compte à sa hiérarchie. Il lutte souvent -presque au corps à corps :p – avec le client pour protéger le cadre très strict de son contrat. Il s’assure d’ailleurs de la fiabilité de son contrat et que son plan d’action et de moyen est clairement défini et applicable. “Le projet sera délivré en temps et en heure avec toutes les fonctionnalités définies dans les spécifications”, c’est son mojo. A la limite si les développeurs et le client le haïssent cela simplifie les relations.

Le ScrumMaster est d’abord présent pour consolider l’équipe autour de la valeur à générer : les users stories, les fonctionnalités à développer, le vrai besoin du client. Si quelque chose va de travers il doit s’en occuper ou trouver au sein de l’équipe ou du côté du product owner une solution. Il s’assure que c’est d’abord de la valeur que l’on produit. Il collabore avec le product owner et l’équipe et les accompagne quand ils rendent compte au client (au travers des retrospectives). Il doit aussi planifier les release et les sprint à venir. Quand son manager lui demande comment il consolide les données du projet : il lui répond qu’il n’a qu’à observer les photos des radiateurs (post-it sur le murs) et se prend une soufflante. “Oui nous n’avons pas couvert tout le périmètre mais ce que nous avons délivré est exploitable, de très bonne qualité, et vous amène beaucoup de valeur ; pour vous le rapport qualité/prix est excellent”, c’est son mojo. Si les développeurs forment une équipe soudée qu’il a su motiver autour des besoins du client il sait que le projet va réussir.

Naturellement la première chose que je vais entendre (ou lire) c’est : CMMi est un modèle et Scrum une méthode. On ne peut donc pas les comparer. Je rejette cet argument dans le sens où chaque société implémente CMMi “à sa guise”, et donc je compare l’implémentation de CMMi (telle que je l’ai connu) à l’implémentation de Scrum. Il est d’ailleurs assez amusant de constater que cette défense de CMMi vis à vis de Scrum prolifère récemment alors que l’implémentation de CMMi est -très- sérieusement bousculée par l’implémentation de Scrum.

Oui il y a une opposition philosophique entre ces deux méthodes, c’est pourquoi l’une bouscule l’autre à mon sens. Par contre il est évident que les deux peuvent dans bien cas se conforter.

Je dois dire qu’au sein de l’organisation dans laquelle j’ai déroulé les pratiques CMMi l’arrivée de Scrum est réellement vécue comme une bouffée d’air frais. Surtout en raison d’un monopole trop totalitaire de cette doctrine (CMMi). Je suppose que dans quelques années un monopole de Scrum pourra tout aussi bien être bousculé par une nouvelle approche.

Les points que j’espère aborder :

• Le couple : manager/CMMI leader/Scrum (je tire cette terminologie (manager/leader) de l’excellentissime: Lean Software Developpement, an agile toolkit (il se lit comme un roman je vous le recommande chaudement)).

• Pour le nouvel arrivant, le débutant, quels sont les bénéfices et inconvénients de CMMi et Scrum.
• Les bénéfices et les risques CMMi & Scrum, je vais essayer de dire quand est-ce que je m’appuierai plutôt sur Scrum ou plutôt sur CMMi, et dans quels cas les deux peuvent cohabiter voire se renforcer.
• d’autres peut-être !

J’espère ne pas me perdre, ni être trop ambitieux et surtout vous donner mes arguments de terrain (donc forcément il seront “teintés”).

Ma problématique :

1. Scrum et les méthodes agiles connaissent un succès exponentiel en ce moment : il suffit de jeter un oeil au Google Trends…
2. Les SSII veulent manger leur part du gâteau, les entreprises se ruent dessus
3. Il n’est pas aisé pour les SSII ou les entreprises de mettre en place Scrum pour -à mes yeux- deux principales raisons : contractualisation, stabilité/pérénité de l’équipe (la troisième serait “responsabilisation” du product owner, et donc du client quel qu’il soit)

A la lecture de l’article cité ci-dessus je me dis que la solution réside peut être dans KanBan. Il ne règle pas la question de contractualisation mais il peut régler celle de la stabilité de l’équipe. Pourquoi ? Scrum apporte beaucoup de souplesse en réponse aux besoins d’un projet, mais il n’introduit pas nécessairement beaucoup de souplesse au sein de l’organisation. Il nécessite un rituel fort et contraignant : les sprints,  les daily scrum, les retrospectives, le tout organisé autour d’une équipe très stable et très impliquée. Pour une SSII (ou une entreprise) ce n’est pas si simple à mettre en oeuvre. Rare sont les moments où une équipe peut effectivement entièrement se consacrer à son sprint. Rare sont les projets ou une personne/évènement externe ne vient pas bousculer le planning, les priorités. KanBan propose un cadre moins rigide (oups scrum méthode agile serait rigide, non ne me faites pas dire cela), en tous cas il propose moins de recommandations d’une part (pour reprendre les termes de Henrik Kniberg (cf les liens ci-dessous)), et ne l’assujetti pas à des timeboxes et un rituel régulier (stand up, etc..). Mais le cycle de Kanban se différencie de la vélocité de Scrum. Le rythme/”flow” de Kanban me parait beaucoup moins contraignant. la vélocité de Scrum est rythmée par le rituel, mise en exergue par les burndown chart, on se doit de respecter l’itération : si une user storie n’est pas achevée à la fin du sprint elle n’apparaitra pas dans la démo, elle a été hors du rythme et donc exclue. Là où Kanban -il me semble- va être plus docile : on déduit le rythme des faits, on ne s’y soumet pas.

Bref, l’exercice de suivre la rythmique de Scrum n’est pas aisé, je me répète, d’où aussi l’importance de la sensibilisation du management au respect des règles d’un projet Scrum. Mon propos est aussi de dire que des fois ce n’est pas possible et qu’il s’agit peut-être là finalement de plutôt se tourner vers Kanban (sans opposer les deux, ce en quoi je ne fais que redire ce que l’article cité ci-dessus explique bien mieux).

Autre point qui m’amène à évoquer KanBan, il se peut (double conditionnel alto arrière..) que je sois amené à coacher des équipes composées de 1 à 2 personnes dans un prochain temps. Avec 1 personne Scrum perd de sa substance…  On se retrouve simplement dans le mode héro (oyez CMMi niveau 1…), en espérant que cet acteur solo a une bonne culture de la gestion d’un projet informatique, des outils qu’il peut mettre en place, etc, mais nulle question à mes yeux de réaliser un daily stand up seul, surtout si une seconde personne vient de façon épisodique compléter l’équipe.

Là encore KanBan avec son approche -apparemment- plus simple, et beaucoup moins ritualisée, va peut-être pouvoir répondre à ce besoin. En introduisant un simple “radiateur” KanBan je peux amorcer une gestion rythmée du projet, je n’ai pas de sprint à respecter, je peux introduire une seconde personne de façon épisodique. Bref je me répète :  je peux rythmer plus simplement le projet  et qui dit rythme, dit charge et planification et donc indicateurs et prévisions, etc.

Pour finir et afin de le rappeler une nouvelle fois, je n’ai pas encore mis en oeuvre Kanban à l’inverse de Scrum, excusez moi par avance si j’avance ici des grossièretés à vos yeux de Kanbanmaster (?). Je veux simplement souligner pourquoi KanBan serait une piste intéressante. J’en décèle deux : impossibilité d’appliquer le rituel de Scrum et de garantir la stabilité de l’équipe, l’un étant souvent le corollaire de l’autre.

Un autre article très intéressant : Kanban and Scrum a practical guide et surtout le PDF associé qui compare Scrum à KanBan, celui avec la citation de Myamoto Musashi, …