Je reviens sur la session Agile & CMMi : potion magique ou grand fossé que nous avons donné récemment Yassine (@yassinezakaria) et moi même lors de l’Agile Tour Toulouse 2011. Les slides sont disponibles ici (ou intégrés plus bas) et je souhaitais les commenter un peu, même si des commentaires écrits remplacent rarement une session.
D’abord sachez que cette session nous a amené -Yassine & moi- a pas mal de discussions assez musclées.
Pourquoi avoir fait une session sur Agile & CMMi ? D’abord car nous trouvons un peu absurde les levées de boucliers et les préjugées dont font preuve une grande partie des gens de ces deux mondes vis à vis l’un de l’autre. Nous nous sommes amusés à mettre cela en forme au travers de différents slides. Mais la malheureuse réalité est que quand l’esprit des gens ces caricatures ne sont pas loin d’être vraies. Et d’ailleurs de nombreuses mauvaises applications de l’agile ou de CMMi les rendent souvent vraies ou les renforcent…
Ces préjugés sont d’autant plus dommageables que :
- qu’il s’agisse d’agile ou de CMMi on fait souvent référence au “chaos report” du Standish Group pour expliquer que l’on souhaite mettre fin aux projets qui échouent, en témoinage nos différents slides de formation…identiques.
- que la réponse initiale prend une forme comparable : un ensemble de pratiques sur lequel on opère un focus : ensemble intégré pour CMMi, pratiques poussées à l’extrême pour par exemple XP. Je précise bien : une réponse ” initiale “, ce que je n’ai pas fait dans la présentation ni les slides et c’est encore aujourd’hui un sujet de discussion (autour des petits fours) avec Thierry (@thierrycros).
Ces préjugés sont d’autant plus dommage que nos “grands sachants” (quelques “grands noms”) cherchent à opérer une convergence entre ces deux approches (CMMi & Agile). Nous donnons en témoignage quelques retours de Jeff Sutherland, David Anderson, Richard Basque ou Scott Ambler. A ce sujet Tullius Detritus se fait un plaisir de vous rappeler qu’il ne faut pas nécessairement croire les yeux fermés les “grands sachants” et qu’un peu de recul ne fait jamais de mal. (Dans ce cadre Jeff Sutherland parle de “potion magique”, c’est ce qui a donné son nom à cette session, ou “grand fossé” pouvons nous nous interroger).
Nous présentons ensuite les différentes façons dont chacun de notre côté nous pouvons faire bénéficier notre approche de certaines qualités de l’autre. De façon assez en adéquation avec les approches de Sutherland ou Basque, Yassine essaye de faire profiter ses projets CMMi de certaines bonnes pratiques agiles : notamment le feedback (souvent trop tardif en CMMi), les aspects itératifs, etc. Il faut rappeler que CMMi propose naturellement : l’implication des “stakeholders”, de réaliser les ajustements nécessaires à chaque projet (on n’embarque pas un CMMi unique et monolithique).
[ajouté le 29 oct] L’approche classique consiste à dire que CMMi est le “quoi”, et agile le “comment”. En tant qu’agiliste je souhaite changer ce paradigme. L’agile est fondamentalement au centre de la rélfexion car il est une culture, il apporte des valeurs. Donc schématiquement il est le “pourquoi”, en amont du “quoi” et du “comment”.
Je suis pour ma part assez d’accord avec David Anderson sur le fait que Agile pourrait profiter des pratiques de niveau 4 & 5 de CMMi, soit pour s’appuyer sur un cadre pour gérer l’innovation au niveau de l’organisation, soit pour s’appuyer sur des tendances pour mieux gérer ses projets. Attention toutefois la métrique pour la métrique est naturellement est danger. QPM niveau 4 de CMMi ne propose justement pas de s’appuyer sur des chiffres pour gérer les projets, mais de tendances. Cette pratique dont on s’inpirerait nous dit juste : voilà les statistiques que nous avons pu collectées, soyez attentifs si votre projet semble ne pas s’y conformer alors qu’il devrait. Soyez juste attentif, avertis (un projet averti en vaut deux) et pas nécessairement plus. Pour que ces statistiques fonctionnent (ça aussi c’est un mot que je n’aime pas trop, et qu’il faut manipuler avec soin), elles doivent provenir d’informations qui puissent être comparable entre projets. Et donc naturellement vous pouvez d’ores et déjà écarter la vélocité. Quels métriques ? je peux vous renvoyer vers par exemple l’article de Jérémie (@jgrodziski), on pourrait aussi se baser sur le taux de turnover (récupéré chez les RH),etc. Attention donc vraiment de ne pas s’aliéner avec des chiffres et de bien réfléchir aux indicateurs (difficile d’utiliser la business value, impensable d’utiliser la vélocité, etc.)
J’évoquerai rapidement dans un futur post les “fortunes CMMi” que je propose. Il s’agit de s’appuyer sur l’énorme rétrospective sur laquelle CMMi se base pour faire -de façon ludique, simple et régulière- monter en compétence les équipes agiles qui manqueraient “de poil aux pattes”.
Enfin, notre conclusion souhaite faire passer deux messages :
- Quelque soit votre choix (Agile ou CMMi) vous devez vous donner les moyens de votre démarche, inutile de faire semblant, uniquement de façon marketing, pour la certification, etc. Il faut vraiment essayer de ce donner les moyens de bien embrasser la démarche.
- Nous ne préconisons surtout PAS un pôt pourri de ces deux méthodes. Vous devez avoir une épine dorsale claire et non ambigüe : agile OU cmmi. Ensuite pourquoi ne pas s’enrichir des apports d’autres méthodes, c’est notre point de vue.
Quelqu’un m’a posé une question : comment sait-on que l’on ne fait pas d’agile “marketing”. La réponse m’a semblée tellement évidente que … je n’ai pas eu de réponse. Cela sera aussi le sujet d’un futur post. Comment être sûr que l’on ne fait pas d’agile “marketing”. Merci à la personne qui a posé cette question restée sans réelle réponse.
En illustration en haut à gauche et afin de relancer une nouvelle la discussion, le mode “Waterfall” interprété par les Goths dans Astérix & Obélix.Je ne sais pas si cela a un lien mais ce post a été écrit avec “Overkill” de Mötorhead dans les oreilles. Je n’en sors pas grandi.
Cet article a été écrit par , posté le October 28, 2011 at 3:37 pm, fichier classé sous cmmi, kanban, méthodes agiles, scrum, XP and tagged agile, asterix, cmmi, obelix, toulouse. Laisser un commentaire ou voir le détail de l'article et des commentaires sur ce lien.
Blog maintenu par
Je n’ai pas assisté à la session mais je vais réagir au billet en évoquant mon expérience qui à mon avis est loin d’être isolée.
La seule implémentation d’une méthode agile (en l’occurrence, Scrum) et de CMMI que j’ai vécue sur un même projet était une vaste farce.
Je pensais naïvement que CMMI dans sa facette appraisal était une approche non coercitive où on se contentait de mesurer la conformité du process existant avec les pratiques CMMI, et tant mieux si tel quel il répondait aux critères, on n’y touchait pas, sinon il y avait des actions à mener.
Dans la réalité, j’ai eu une sensation plus proche de celle de l’éleveur qui voit les mecs de la charte Label Rouge lui tomber dessus pour mettre des bagues électroniques compte-pas à ses poules, établir un registre de chaque fiente produite et poser des anneaux gastriques garantissant le bon calibrage des oeufs.
Concrètement, nous avons vu débarquer un cortège de nouveaux documents à remplir, procédures à suivre, indicateurs à alimenter qui multipliait grosso modo le temps passé en administratif par deux. Autant de solutions CMMI “clés en main” faisant fi de notre réalité et qui au final ne solutionnaient rien puisque la qualité du process n’a pas augmenté. Rien sauf une chose : après m’être renseigné auprès des managers à l’initiative de l’adoption de CMMI dans la boîte (une SSII), il est apparu que l’objectif n° 1 assumé et revendiqué était de plaire aux clients pour qui CMMI était un “plus” chez un prestataire.
Les méthodes agiles sont empiriques et pragmatiques, “no-nonsense” pourrait-on dire, et c’est ce qui fait leur force. CMMI l’a peut être aussi été dans son cadre originel, à savoir un contexte de relation entre offices gouvernementaux et fournisseurs, mais à la suite de cette mauvaise expérience je ne peux m’empêcher de considérer son utilisation typique actuelle comme trop théoricienne, rigide et “plaquée” sur des réalités qui souvent n’ont même pas les problèmes que prétend résoudre CMMI.
Et ce que j’entends autour de moi dans diverses sociétés vient rarement contredire cela. Donc fossé entre Agile et CMMI tel qu’il devrait être théoriquement, peut-être pas. Fossé avec CMMI tel qu’il semble être majoritairement pratiqué aujourd’hui en France, oui, et il est large !
bonjour Pablo
et merci pour ce message. Je partage complètement ta conclusion (votre conclusion). Choisir une épine dorsale. Le chaud bouillant de l’agile et le froid glacial du CMMI.. c’est du tiède, pas terrible.
Je ne crois pas (pour avoir concrètement pratiqué CMMI aussi !) que ce soit la même réponse. Si le constat est identique (type enquête d’insatisfaction…) la réponse est sensiblement différente. XP c’est au départ 13 pratiques, CMMI niveau 2 c’est grosso modo 120 (les spécifiques et les génériques pour chaque PA).
Je me souviens du support CMMI, une grosse loupe sur “Processus”…
D’ailleurs les organisation très centrées “Process” font aujourd’hui du process agile…
J’ai bien aimé le “fortune CMMI”, je compte bien l’utiliser un de ces jours !
Amitiés occitanes
Guillaume,
J’ai beaucoup fait de CMMi, et aujourd’hui mon épine dorsale est uniquement l’agile. Tu vois donc ainsi ou ma culture balance. Car l’agile est avant tout une culture. Chose que j’ai oublié de signaler dans mon poste (mais bien présent dans les slides).
C’est dommage que tu n’aies pas croisé une expérience CMMi réussie, il y a en a. Je comprends tout à fait ton feedback. Mais je suppose que d’autres malheureusement pourrait dire l’inverse. Une expérience agile désastreuse au sein d’une structure plutôt ok en CMMi.
Si mon choix est clairement pour l’agile, Yassine et moi voulons dire que les deux méthodes peuvent être bien appliquées et porter leurs fruits. Chacun de nous deux à sa préférence.
Ce qui est véritablement désastreux et c’est cela contre lequel nous luttons : une mauvaise utilisation de chacune des approches, sans moyen, pour un effet marketing ou autre.
Tu le dis toi même les gens que tu évoques ne voulaient pas CMMi pour ses qualités mais pour vendre plus cher. Pas la peine de préciser que malheureusement je rencontre les mêmes cas avec l’agile avec les mêmes effets.
Bye
Guillaume as-tu vu les slides pour employer le terme de “poulet en batterie” on dirait que tu fais allusion au slide concernant les a priori des agilistes sur CMMi… :p
Merci Thierry !
(en fait elles viennent d’un fichier de Richard Basque que j’adapterai dans un langage plus humain
rendons à César…)
Je vais proposer rapidement un fichier PDF des “fortunes CMMi”. Ou “fortunes de bonnes questions à se poser sur un projet” pour ceux qui ne veulent pas savoir d’où elles viennent
[...] Agile & CMMi, potion magique ou grand fossé ? Je reviens sur la session Agile & CMMi : potion magique ou grand fossé que nous avons donné récemment Yassine (@yassinezakaria) et moi même lors de l'Agile Tour Toulouse 2011. Les slides sont… [...]
[...] Are you agile ? » Blog Archive » Agile & CMMi, potion magique ou … Agile & CMMi, potion magique ou grand fossé ? Je reviens sur la session Agile & CMMi : potion magique ou grand fossé que nous avons donné récemment Yassine (@yassinezakaria) et moi même lors de l'Agile Tour Toulouse 2011 … Source: http://www.areyouagile.com [...]
[...] de la session Agile & CMMi à Toulouse (avec @yassinezakaria) quelqu’un m’a interpellé. Je venais de présenter [...]