Je n’ai rien contre les SSII sur le fond et je sais que c’est un travail difficile, mais lorsque les SSII se mettent à parler d’agilité, à part quelques unes qui savent de quoi elles parlent, pour les autres c’est du grand guignol … ou plus bassement un vil intérêt financier !

Mes clients et prospects me font écho des 2 points suivants, que je considère comme une réelle dérive et j’en détaille les raisons dans la suite de cet article :

1. Demande d’augmentation des coûts journaliers
2. Promesse de réduction des coûts globaux

Une dérive similaire a été constaté à la fin des années 90 aux USA et a conduit beaucoup de société a abandonner l’agilité suite à des échecs, souvent du fait d’un mauvais conseil. La bonne nouvelle est que ce n’était que temporaire et que ces mêmes sociétés ont retenté l’expérience à la fin des années 2000, en s’appuyant sur des coachs confirmés, avec de belles réussites.

Clients, faites donc bien attention aux miroirs aux alouettes et choisissez bien votre coach !

Coûts Journaliers

Ce sujet est revenu 4 fois depuis mi-avril lors de mes discussions avec les clients et toujours sous la même forme : « Notre fournisseur XXX nous affirme que le tarif d’un équipier agile est plus cher, qu’en pensez-vous ? ».

Je réponds généralement qu’un équipier agile est souvent expérimenté et de ce fait plus cher qu’un débutant, mais qu’être un équipier agile n’est rien de moins ni rien de plus que d’être un simple équipier (dans le sens membre d’une équipe).

L’équipier agile va devoir travailler en équipe, être pro-actif, honnête et courageux … franchement, pourquoi un client prendrait un équipier dans un contexte traditionnel qui ne dispose pas de ces compétences ? Sous prétexte que le Chef de Projet s’en débrouillera ?

Si l’équipier agile est très bon techniquement, alors il sera également vendu plus cher en mode traditionnel (par exemple comme expert, vous pouvez faire confiance aux commerciaux, ils sont généralement bons !) donc pas de raison que l’agilité augmente les prix.

Mais en conclusion je dis également à mes clients qu’il y a eu un positionnement excessif des coûts journaliers des sous-traitants vers le bas depuis plusieurs années (voir plus de 10 ans) et qu’il est de bonne guerre pour les SSII d’essayer de justifier une augmentation des coûts du fait de l’agilité … même si rien ne le justifie !

Réduction des coûts

Lorsque Jeff Sutherland affirme que l’agilité réduit fortement les coûts des projets et donne des éléments financiers concrets sur des projets qu’il a lui même piloté, je serais tenté de le croire … quoique, cela me semble un peu trop beau ?

Lorsqu’un fournisseur affirme à ses clients que l’agilité va réduire leurs coûts de 30% ou plus, il dit simplement ce que le client veut entendre et rien de plus ! Il faut beaucoup de courage pour dire le contraire et risquer de perdre le contrat.Certains fournisseurs se couvrent en ajoutant « cette réduction ne sera obtenue que si l’agilité est mise en place correctement » ce qui dénote une forte malhonnêteté de leur part, puisque l’on trouvera toujours un petit quelque chose de travers … et on retombe dans la justification contractuelle qui a fait les belles heures des approches traditionnelles et des Chefs de Projets.

Je crois beaucoup plus au fait que l’agilité augmente la productivité, ce que confirme l’enquête faite par VersionOne en novembre 2009, de même que la possibilité de gérer le changement, une meilleure visibilité, l’alignement des objectifs IT et business, le moral de l’équipe et la réduction du time-to-market et donc une augmentation de la satisfaction des clients.

En conclusion de ce point, je dirais que ce que j’ai constaté sur les projets que je coach est que la réduction des coûts est une conséquence et non un objectif ! Elle n’est pas automatique, bien que fréquente, mais par contre les autres bénéfices mentionnés sont eux systématiquement obtenu, ce qui justifie déjà pleinement l’utilisation de l’agilité

Avoir été le rédacteur en chef de cette revue a été une bonne expérience pour moi, avec quelques challenges comme la définition d’une ligne éditoriale cohérente, la recherche de sujets en phase avec cette ligne, l’appel aux rédacteurs d’articles et le suivi de la fabrication.

Aujourd’hui je suis vraiment fier du résultat obtenu et je remercie tous les contributeurs pour la qualité de leurs articles.

Au sommaire :

• Qu’est-ce qui fait courir les agilistes ? Laurent Bossavit
• Le défi de l’agilité par Messaoud Oubechou
• SCRUM – retour d’expérience chez Orange par Jean-Michel Ortholand
• Agilité et logiciel avionique critique chez Thales par Pascal Fortin et Nicolas Blanpain
• Retour d’expérience : Agilité distribuée par Stéphane Mercier et Emilio Gutter
• Spécifications exécutables par Radhouane Gourchene
• Découverte de l’Agilité par Valentin Brossard

Dites-moi ce que vous en pensez en laissant un petit commentaire sur ce blog

Message personnel pour les anciens ENSIMAG :

Merci de payer votre cotisation 2010

pour que nous puissions continuer à éditer des revues de cette qualité.

Pourquoi ? Simplement par curiosité intellectuelle et envie d’ouverture, et surtout parceque je voulais faire une évaluation agile de CMMi (Lire plus bas) pour essayer une approche inverse à ce que l’on peut lire un peu partout, c’est à dire la traditionnelle évaluation CMMi de l’Agilité qui démontre que l’Agilité est pas mal … mais doit mieux faire pour être au niveau de CMMI … grrrr …..

CONTEXTE

Il s’agissait plutôt d’une journée de discussion ouverte à 4 sur le thème CMMi et Agilité et le groupe était constitué d’un assesseur CMMi certifié, de 2 préconisateurs de l’approche CMMi et moi-même.
Je connais ces personnes depuis plusieurs années et j’apprécie leur ouverture d’esprit, leur capacité de dialogue et leur intérêt pour l’agilité … même si c’est par le bout de la lorgnette CMMi

ORIGINES

Coté approches, pas de révélation, elles sont différentes.

CMMi part du principe que les projets sont répétables et qu’il est donc possible de définir un process formel qui, s’il est suivi à la lettre, contribue fortement au succès du projet. D’où l’émergence de CMMi dans les grandes structures institutionnelles avec beaucoup de projets similaires.

AGILE considère que chaque projet est unique ou presque et que l’approche empirique est la meilleure façon d’atteindre l’objectif qui n’est généralement pas connu avec précision au début du projet. Si un cadre structurant existe bien, l’équipe doit se l’approprier et l’améliorer en permanence sans avoir besoin de justifier les décisions proses auprès de directions méthode ou qualité.

SURPRISE

A ma grande surprise, j’ai appris que selon Humphrey Watts, grand ponte du CMMI, cette approche est déjà AGILE puisque, en complément de l’approche organisationnelle (Les Process Area du CMMI), elle dispose du TSP (Team Software Process) pour le fonctionnement en équipe et du PSP (Personal Software Process) pour l’amélioration de l’efficacité personnelle.

En y regardant de plus près, le TSP comporte de nombreuses caractéristiques communes avec l’agilité (But commun pour l’équipe, Implication de toute l’équipe sur les décisions, Négociation des activités, Coopération, Feedbacks …) mais doit s’appliquer, selon l’approche de Watts, dans un process traditionnel par étapes qui n’est donc pas du tout agile.

Pour ce qui est du PSP, j’avoue ne pas avoir vraiment tout compris mais ce que je garde en mémoire c’est qu’il faut une discipline de fer pour le mettre en œuvre (pour soi même) et qu’il s’inscrit également dans une démarche traditionnelle par étape.

EVALUATION

L’évaluation Agile de CMMI a été conduite en utilisant les 4 valeurs et les 12 principes décrit dans le manifeste agile et n’engage que les 4 personnes qui ont fait l’exercice.

BILAN

Donc au bilan, sur 16 points AGILES évalués :

• 4 points en opposition totale
• 6 points non traités par CMMi
• 2 points partiellement traités par CMMi
• 4 points couverts correctement par CMMi

Et vous, qu’en pensez-vous ?

Sans remettre en cause le bien fondé ou pas des informations présentent sur le site, j’essaye d’étudier dans cet article, comment l’agilité permet, ou pas, d’éviter ces 20 problèmes.

Au bilan : 17 RESOLUS et 3 OUVERTS .. et VIVA AGILISTA !!!

Pour plus de détails …

Axe 1 Organisation du projet

• Piège 1 Le problème est mal défini et mal délimité –> RESOLU. Incrément de produit et feedback régulier garantissent la fourniture du produit attendu par le client
• Piège 2 Les exécutifs refusent de voir la réalité –> OUVERT. Même problème en agile si les décideurs n’adhèrent pas
• Piège 3 Les plannings sont réalisés à la petite semaine, sans impliquer les acteurs de terrain –> RESOLU. Toute l’équipe participe et les utilisateurs finals sont impliqués
• Piège 4 Les plannings sont trop rigides et imposent des coupes franches improvisées –> RESOLU. Le périmètre est variable avec un timeboxing strict des itérations.
• Piège 5 Les estimations à la bonne franquette deviennent les objectifs à tenir –> RESOLU. Les estimations en « Story Points » évitent la pression sur les charges
• Piège 6 Les budgets sont trop verrouillés –> RESOLU. La notion de « business value » permet de faire les bons choix en terme de budget et de coût de réalisation.donne une réelle solut… mais s’il n’y a même pas le budget pour la release 1 … rien à faire !
• Piège 7 Le projet n’est pas en phase avec les budgets alloués –> RESOLU. L’approche itérative et incrémentale permet de livrer une version du produit dans le budget et de plus je suis convaincu que que l’agilité permet de réduire les coûts

Axe 2 Coopération étendue, team building

• Piège 8 Les responsabilités sont trop mal définies ou changent constamment –> RESOLU. La réduction du nombre de rôles simplifie grandement le problème. Pour ce qui est du changement constant … les agilistes adorent cela
• Piège 9 Les équipes ne sont qu’un ensemble d’individualités –> RESOLU. La communication et l’interaction des personnes est une valeur de l’agilité mise en oeuvre avec toutes les méthodes.
• Piège 10 Les acteurs du projet sont déplacés et réaffectés à tort et à travers –> OUVERT. C’est un problème de management et non de gestion de projet.
• Piège 11 Un manque de participation des autres parties prenantes –> RESOLU. Les démos impliquent fortement toutes les parties prenantes de façon très régulière (toute les 2 à 4 semaines)
• Piège 12 L’absence de véritable communication entre les exécutants et les managers du projet –> RESOLU. Il n’y a plus de « Managers du projet » et le « Product Owner » est totalement intégré dans l’équipe de réalisation.

Axe 3 Assisance à l’anticipation

• Piège 13 Les enjeux mal précisés évoluent et bouleversent les priorités –> RESOLU. La gestion des priorités est un des points forts des méthodes agiles
• Piège 14 Les ressources sont inappropriées ou mal utilisées –> RESOLU. L’approche agile consiste à délivrer de la « business value » et non d’occuper les ressources comme dans les méthodes traditionnelles.
• Piège 15 Les exécutants ont perdu de vue les objectifs initiaux –> RESOLU. Les objectifs sont redéfinis régulièrement et partagés avec toute l’équipe
• Piège 16 L’instrument de mesure est inadéquat…–> RESOLU. Le suivi par la mesure des délais et des coûts n’est pas pratiqué en agile, d’autres indicateurs sont utilisés
• Piège 17 Le balisage du projet ne permet pas une appréciation concrète de l’avancement… –> RESOLU. L’avancement agile est basé sur une réalité (nombre de points produits) et non des estimations en % d’avancement

Axe 4 Intégration

• Piège 18 Les aspects techniques du projet sont privilégiés aux dépens des besoins fonctionnels –> RESOLU. Tous les besoins sont listés dans un seul et unique document, et sont priorisés par une seule personne.
• Piège 19 Le chef de projet cherche à reproduire ce qu’il fait habituellement aux dépens des besoins propres de l’entreprise –> RESOLU. Le chef de projet traditionnel n’existe plus, l’équipe est autonome et en amélioration constante grâce aux rétrospectives régulières.
• Piège 20 Le budget initial ne tient pas suffisamment compte des besoins propres de l’intégration –>OUVERT. La partie déploiement et formation de tous les utilisateurs n’est pas réellement adressé par les méthodes agiles (manque parfois de vision système comme dans le Lean)

Regardez la vidéo, trouvée par hasard sur DailyMotion, des équipes valentinoises de Thales qui mettent en application avec succès les approches Lean et Agile.

En plus ILS SONT BEAUX … bon d’accord, je ne suis plus crédible

Environ 42 000 ingénieurs de toutes disciplines ont répondu à cette enquête dont les résultats sont consignés dans un document de 100 pages (eh oui, prenez votre temps pour le lire).

Énormément d’informations utiles dans ce document comme la répartition des flux de sortie des ingénieurs par région qui donne la région Rhône Alpes en 2ème position derrière Paris (tiens donc, cela me rappelle le résultat du sondage du French SUG).

Beaucoup de données également sur l’intérêt que portent les ingénieurs à leur entreprise, et en particulier les critères qui les font rester … ou qui les feront partir.

Des pourcentages de satisfaction qui, à ma grande surprise, ne dépendent absolument pas de l’age des ingénieurs … j’aurais en effet parié que les centres d’intérêt évoluaient avec l’âge.

Une section intéressante sur la relation entre l’ingénieur et l’innovation, et le constat chiffré que les écoles forment de mieux en mieux à la création d’entreprise … ce qui est une très bonne chose.

Et une dernière section très détaillée sur « ce que gagne les ingénieurs » dans laquelle vous trouverez absolument toutes les informations dont vous rêvez … enfin seulement si vous souhaitez être convaincu que vous gagnez plus que les autres ou que vous êtes frustré de gagner moins

Bonne lecture

• Questionnaire Méthodes Agiles

Pour le nom du parrain, je vous laisse libre

Pour tout vous dire, il y a un concours entre les parrains pour nous « motiver » à communiquer sur ce concours et avoir le plus de réponses possible afin que le questionnaire soit le plus représentatif possible … honnêtement je n’ai pas besoin de cela pour relayer l’information

Cette prestation réalisée dans le cadre des Dojos organisés par le CARA a attiré une vingtaine de personnes … qui pour une fois n’ont pas pratiqué leur sport préféré (le codage en binôme) mais ont écouté attentivement et activement (beaucoup de questions posées et d’échanges fructueux sur le domaine) les orateurs nous jouer la session qu’ils ont prévu de faire lors des prochains XPDays à Paris les 25 et 26 mai.

Même si je n’utilise pas la notion d’ATDD, je préconise toujours lors de mes formations SCRUM de travailler sur les critères d’acceptation d’une User Story plutôt que sur le libellé de cette User Story. Beaucoup de gens ont pris la mauvaise habitude de discuter chaque mot et la signification de chaque phrase. Cette pratique est généralement utilisée pour valider la compréhension d’exigences fonctionnelles en mode traditionnel afin de se rassurer sur la compréhension réelle du besoin.

Pour moi, cette approche polémique correspond à du gaspillage de temps et d’énergie car la compréhension s’établit bien plus rapidement lorsque l’équipe travaille sur ce qui leur permettra de dire que la User Story est terminée. Cette approche que propose l’agilité permet  d’établir une liste de tests d’acceptation partagée par l’équipe et le Product Owner, outre que cette approche est moins polémique, elle est également bien plus efficace en temps et en énergie dépensée.

Par contre , je n’ai pas encore totalement saisi les différences entre BDD et ATDD … mais je me soigne et je lis les blogs

Le futur n’est pas totalement prédictible, même au prix d’un effort important, et l’approche agile itérative permet de réagir au plus vite aux changements inévitables qui vont survenir. Mais si en plus la chance ou la malchance s’en mêle …

Lire l’histoire

Il y avait, dans un village, un homme très pauvre qui avait un très beau cheval. Le cheval était si beau que les seigneurs du château voulaient le lui acheter, mais il refusait toujours. « Pour moi ce cheval n’est pas un animal, c’est un ami. Comment voulez-vous vendre un ami ? » demandait-il.

Un matin, il se rend à l’étable et le cheval n’est plus là. Tous les villageois lui disent : « Nous te l’avions bien dit ! Tu aurais mieux fait de le vendre. Maintenant, on te l’a volé … Quelle malchance !« . Le vieil homme répond « Chance, malchance, qui peut le dire ?« .

Tout le monde se moque de lui. Mais 15 jours plus tard, le cheval revient, avec toute une horde de chevaux sauvages. Il s’était échappé, avait séduit une belle jument et rentrait avec le reste de la horde. « Quelle chance ! » disent les villageois.

Le vieil homme et son fils se mettent au dressage des chevaux sauvages. Mais une semaine plus tard, son fils se casse une jambe à l’entraînement. « Quelle malchance ! » disent ses amis. « Comment vas-tu faire, toi qui est déjà si pauvre, si ton fils, ton seul support, ne peut plus t’aider ! ». Le vieil homme répond « Chance, malchance, qui peut le dire ?« .

Quelques temps plus tard, l’armée du seigneur du pays arrive dans le village, et enrôle de force tous les jeunes gens disponibles. Tous, sauf le fils du vieil homme, qui a sa jambe cassée. « Quelle chance tu as, tous nos enfants sont partis à la guerre, et toi tu es le seul à garder avec toi ton fils. Les nôtres vont peut-être se faire tuer. ».

Le vieil homme répond « Chance, malchance, qui peut le dire ?« 

Pour ceux qui n’aurait pas acheté le journal, voici l’article
Dans le monde du développement logiciel, il est de bon usage de considérer qu’une personne est au maximum de sa productivité lorsqu’elle produit en permanence, et afin d’obtenir ce résultat, de nombreux managers choisissent de charger chaque personne à 100% ou plus. Ils sont honnêtement persuadés que cette pratique leur garantira l’absence de « temps mort » synonyme pour eux de perte de productivité.

Bien que cette approche semble frappée du bon sens, elle est totalement remise en cause par certains principes prouvés du (*)Lean et d’autres principes mathématiques incontestables. Sur la base de ces éléments, il convient donc de mettre fin à cette pratique et de comprendre que pour atteindre l’optimum de productivité il est judicieux de charger moins les personnes ou les équipes de réalisation.

La métaphore que je préfère pour illustrer ce propos est celle de l’autoroute. En effet, demandez à une personne ce qu’il se passe lorsque le nombre de voitures atteint la capacité maximale de l’autoroute, elle vous répondra naturellement : il y a création d’un bouchon !

Ce bouchon n’est rien d’autre que la matérialisation physique d’une productivité faible. Chaque voiture à la capacité de rouler à 130km/h mais dans les faits, elle ne roule qu’à 30km/h.

De même que pour l’autoroute, il est nécessaire de garder des « temps libres » à l’équipe pour garantir une productivité maximale.

Lorsqu’un développeur continue à coder alors que le système de build de son code est en erreur, il ne fait que rajouter de la complexité et des erreurs dans son système. Il sera ensuite beaucoup moins performant car il consommera une grande partie de son temps à corriger ces problèmes complexes. Ce développeur devrait s’arrêter de coder, trouver ce qui pose problème et remettre en état de marche sa plateforme de build.

Pour pouvoir être plus performant, il faut pouvoir prendre le temps d’analyser son environnement et d’identifier des actions d’amélioration. Si l’équipe technique peut régulièrement « lever le nez du guidon », elle trouvera et mettra en œuvre des solutions (outils, processus …) qui amélioreront sa performance sur le moyen et long terme.

Toutes les équipes techniques sont confrontées à des urgences qu’il faut traiter immédiatement. Si aucun « temps libre » n’a été planifié, ces urgences viendront perturber le fonctionnement prévu de l’équipe, qui, pour tenir le délai, ne trouvera pas d’autres solutions que de dégrader les autres activités prévues (réduction de la qualité du code, architecture non robuste, tests non réalisés …). Ces décisions forcées réduiront d’autant la performance ultérieure

Plusieurs études ont également prouvées qu’une équipe technique est très performante lorsqu’elle travaille sur 1 seule activité à la fois. En procédant ainsi, elle évite les changements de contexte qui consomment environ 45 mn à chaque fois. Avec un planning rempli à 100%, voir plus, l’équipe va essayer de tout faire en même temps, et changer de contexte en permanence, pour au final une perte sèche de plusieurs heures de productivité par jour.

Mais que faire pour être plus productif ?

Prendre la décision de migrer vers des approches Lean pour le logiciel (Kanban …) et/ou de méthodes agiles (Scrum, XP …) car elles intègrent structurellement ces pratiques qui sont donc mises en oeuvre sans effort particulier. Et pour les managers qui appliquent des méthodes plus traditionnelles comme le cycle en V, l’alternative de mise en oeuvre consiste à planifier une occupation des équipes à seulement 80% … pour produire plus sur le moyen et long terme !

Quel individu a jamais eu en fin de semaine, et sans savoir vraiment l’expliquer, la sensation de n’avoir pas produit beaucoup alors qu’il avait travaillé beaucoup ?

La réponse est toute simple, il se trouvait dans un bouchon.

(*)Le Lean pour le logiciel est une adaptation du système de production de Toyota, appelé Thinking ou Lean Production System, qui propose une approche différente et souvent contre-intuitive pour la production industrielle.