Voici un petit retour sur le contenu, puis le contenant et le feedback.

Le contenu

J’ai essayé de découper mes slides (ils sont plus bas) en trois parties : la première met en avant le socle “cynefin” et “cynefin dynamics”. Ce framework a pour qualité de bien mettre en évidence les différences entre le domaine ordonné (compliqué ou simple), et le domaine complexe. Je vous encourage à commencer par voir cette vidéo ou à en lire plus ici et là. Mais pour simplifier à l’extrême c’est dans le domaine complexe que l’émergence des pratiques “agiles” va se produire, et c’est en les faisant basculer dans le domaine ordonné que l’on va vraiment pouvoir les répandre au sein de l’organisation. La dynamique de ces pratiques qui passent de “nouvelles” à “émergentes” ou “bonnes” ou “meilleures” est aussi la source de freins. Quand j’essaye de fixer une bonne pratique je suis confronté à des freins. C’est la deuxième partie de cette présentation. L’idée que je souhaite soutenir est que le freins ne sont pas un problème en tant que tel. Ils sont la manifestation que l’on est en train de travailler sur nos pratiques, ils sont nécessaires, ils sont la preuves de nos progrès. Si on souhaite citer la théorie des contraintes de Goldratt, on  peut aussi dire (toujours très simplifié) que les freins sont la plus grande source d’amélioration. Mais si les freins sont trop nombreux, trop récurrents, trop gros nous ne franchirons pas cette étape d’amélioration. Elle sera insurmontable. C’est la troisième partie de ma présentation : si on ne souhaite pas être submergé par les freins (taille, nombre) il faut une bonne conduite du changement. Pour cela je me réfère à un acronyme que je trouve très efficace : ADAPT. Awareness, sensibilisation, si les gens ne savent pas ce qu’est l’agile, difficile de réussir. Desire, envie, maintenant qu’ils savent ce qu’est l’agile, en ont-ils envie ? (avaient-ils envie de quelque chose qui n’était pas l’agile ?). Enfin Ability, capacité, en fonction de la nature de votre organisation, du contexte mais aussi donc de la sensibilisation à l’agile de votre organisation et de son envie, comment adapter votre parcours agile.   (Je ne traite pas “Promotion & Transfer” les deux derniers qui sont là pour “fixer” le changement). Donc, différente capacité, différents parcours, différentes méthodes agiles, différentes possibilités, il y a de nombreuses voies, il faut en choisir une qui soit bien adapté à sa capacité sinon on va générer trop de freins. Il n’y a pas de meilleure capacité.

Pour résumer et en inversant la chronologie de la présentation : si vous vous donnez les moyens d’une bonne conduite du changement, vous éviterez d’avoir trop de freins, ou de trop gros freins. Mais des freins sont nécessaires car ils sont la preuve que le changement est en cours, ils sont aussi la preuve que l’on fait émerger de nouvelles pratiques en adéquation avec ce qu’est votre organisation. Pour bien comprendre ces dynamiques il me parait très intéressant de se plonger dans le framework cynefin.

Les slides chez Slideshare :

 Le contenant et le feedback

J’ai pu donc donner cette présentation dans deux lieux jusqu’à maintenant. Lors d’un petit déjeuner dans les salles de formation de Smartview. J’ai aussi pu donner cette présentation grâce aux efforts de Karine & Eric (@viaxoft) et de l’association Esprit Agile à Marseille. Merci à eux ! (A Marseille nous avons fait 40mn de présentation et 1h30 de discussions…).

La réception a été bonne, mais pas mal chahutée (j’ai appris beaucoup)  :

“c’était trop théorique, pas assez concret”.

Oui mais je crois qu’il faut parfois asseoir une analyse théorique pour mieux appréhender le concret. Cette remarque est recevable naturellement. J’ai cependant la prétention de penser qu’il faut poser une graine sur ces aspects théoriques considérés complexes et laisser murir. Mais oui c’est assez théorique, et surtout *trop* théorique pour les gens venus chercher des clefs concernant l’agile, des novices ou débutant (ceux qui sont venus chercher des réponses “meilleures pratiques” à une checklist de freins : justement nous sommes loin d’être dans ce cas de figure, ce n’est pas ainsi qu’il faut l’appréhender). J’aurais du préciser dans le programme que ce n’était pas pour des novices. Les agilistes (ou les gens endurcis à la conduite du changement) ont su raccrocher mon discours à l’expérience, une partie des autres non.

“cela s’applique à tout, pas seulement à l’agile”.

Oui c’est vrai. Mais si l’on considère (comme moi) que les freins sont le résultats des collisions, des frottements explicités par cynefin dynamics et que l’on estime que l’agile a une forte adhérence avec le domaine complexe et les pratiques émergentes, alors même si ce discours s’applique à beaucoup de chose, il est particulièrement important pour l’agile.

Une présentation à méditer pour moi. Il est clair que je n’ai pas encore assez réussi à clarifier le discours que je souhaite voir passer. Mais d’un autre côté les réactions provoquées me laissent penser qu’il y a vraiment une base de travail très intéressante.

Merci à Jacques Rouxel & Claude Pieplu pour ces inestimables Shadoks ! Merci aux gens présents et aux riches discussions qu’ils ont provoqués.

D’abord

un détail (mais le diable se cache dans les détails) “code retreat” a deux significations : tout le monde a en tête la “retraite” (“retreat”) car les mots dans les deux langues sont très proches. Retraite spirituelle d’un groupe de personnes dans un lieu isolé pour méditer ou se retrouver. Mais c’est aussi et originellement la “re-treat”, traiter à nouveau. On prend un sujet et on le traite, le re-traite, le traite à nouveau. Voilà une ambiguïté levée.

Ensuite

un point que j’ai relevé dès le début de notre journée. Nous nous sommes projetés sur des situations imaginaires, même si on les savait très proches de la réalité. N’est ce pas dommage ? Je m’interroge. Pourquoi choisit-on des situations imaginaires ?

Hypothèse 1 : pour ne pas se focaliser sur la situation de certains ? Ne pas les stigmatiser, ne pas les mettre mal à l’aise, ne pas révéler leur situation (on est  entouré de concurrents même si le niveau de confiance est bon) ? Personnellement cela ne me génerait pas de parler précisément de certaines de mes situations quitte à me mettre en porte à faux : l’enseignement n’en serait que meilleur. Quant à la question de la concurrence, je peux ne pas prononcer le nom de mes clients, si les gens veulent savoir, ils savent.

Hypothèse 2 : pour ne pas s’enfermer dans une situation bien précise qui ne parlera réellement qu’à celui qui l’évoque ? Nous avons fait du dot-voting sur ces situations imaginaires, nous aurions pu le faire sur des situations connues pour être réelles. Quoiqu’il en soit je ne crois pas qu’une situation ne m’intéresse pas même si je ne l’ai jusqu’à présent jamais croisée. Je pense que l’on retrouve toujours un enseignement, un point intéressant que l’on peut mettre en parallèle avec son expérience. Enfin l’évocation d’une situation réelle portée par un “product owner”  me parait bien plus tangible et puissante.

Hypothèse 3 : (qui rejoint l’hypothèse 2) les réponses évoquées, envisagées, dans une situation concrête ne seront valables que pour celle-ci. Le contexte étant fondamental. Oui. Et alors ? Ce qui m’intéresse ce n’est pas tant les réponses envisagées, que la façon d’envisager ces réponses. Quel positionnement, quel raisonnement, quel mécanisme d’analyse mettons nous en oeuvre, quelles actions proposons nous ? Voilà la raison de cette retreat/re-treat. Pour ceux qui me suivent sur Twitter je suis très influencé par Cynefin ces temps-ci. Ce qui m’intéresse c’est donc les bonnes pratiques ou les meilleurs pratiques que mes camarades ont pu faire émerger ou utiliser (et c’est d’ailleurs aussi ce que l’on nous a proposé durant la journée : “clickrewind”, “solution focussed”, “crucial confrontations”, “appreciative inquiry”, etc. sont des bonnes pratiques). Les moments où ils ont bousculés les habitudes de leurs clients pour les placer dans un environnement émergent. Pourquoi, comment, effets observés, succès, échec. Discutons-en. Sur du concret même si je sais qu’il n’est pas reproductible c’est la façon de faire (de coacher) qui m’intéresse.

J’ai profité du “Freeplay: no rules. You do as you wish” pour proposer au groupe d’avoir une approche plus concrête. Pour essayer. Je ne sais pas si cela est réellement profitable. Mais j’ai fait choux blanc.

Enfin,

pour finir, l’éternelle question sur le positionnement coach ou consultant est revenue plusieurs fois sur le tapis. Si je caricature (volontairement), sommes nous des coach qui murmurons à l’oreille de nos clients lesquels intègrent, digèrent comme ils le souhaitent, si ils le souhaitent ? Ou sommes nous des consultants qui indiquons la meilleure marche à suivre, les processus à déployer, les positionnements à prendre ? Nous sommes les deux. Dans l’absolu (=joker) oui il faut murmurer à l’oreille de ses clients : nous ne pouvons décrêter qu’ils sont convaincus, ou motivés. Nous ne sommes pas en mesure non plus de connaitre la meilleure réponse. C’est lui qui la connait et qui doit l’exprimer. (J’ai pu -dans une conférence- oser le rapprochement entre le coach et le psychanalyste). Mais comme les équipes que nous accompagnons nous avons des “deadlines”, des attentes des clients (qui nous sollicitent) et un produit opérationnel à proposer à intervalles réguliers, des processus à déployer. Ne cherchons pas à séparer ces deux facettes de notre métiers. Coach ? Consultant ? Je ne crois pas que l’on puisse avec Agile être soit l’un, soit l’autre sans y perdre quelque chose.

Merci à Oana (que j’adore) pour l’organisation de cette belle journée, merci à Yves pour sa présence.

Quelques évènements qui approchent et où j’espère vous croiser :

D’abord le 17 janvier 2011 si vous êtes du côté de Montpellier Smartview organise un petit déjeuner/séminaire dont le sujet est :

Agilité : Identifiez les freins et adaptez votre parcours

Le pitch : Aujourd’hui l’agilité est reconnue comme un vecteur de progrès, pour autant qu’elle soit bien comprise et bien utilisée. Ce séminaire vous présentera les écueils les plus fréquents et la façon de mieux appréhender ces méthodes dans votre contexte pour en tirer les meilleurs bénéfices. (~45mn)

Ce petit déjeuner aura lieu le mardi 17 janvier de 8h30 à 10h00 dans le centre de formation Smartview : 145 Avenue Clément Ader, 34170 Castelnau Le Lez (Montpellier). si vous êtes intéressé : me joindre !

Cette session sera aussi donné le 26 janvier à Marseille grâce à l’association “Esprit Agile” et ses évènements :

Agile After Work

Cela sera donc : le jeudi 26 janvier 2012 à partir de 18h30 à l’hôtel technologique, 45 rue Frédéric Joliot Curie, 13013 Marseille (le plan d’accès). Attention il faut impérativement s’inscrire en passant par ce formulaire.

Cette session sera aussi probablement donnée à Paris, je l’indiquerai dans le blog si cela intéresse certaines personnes.

Coach Retreat

Sinon question coaching une rencontre qui s’avère passionnante : un coach retreat organisé par Oana J. Il aura lieu le 21 janvier à Paris (un samedi…).  Il reste 4 places. Pour les gens intéressés il faut se presser…

Agile Open Sud

Et surtout le 16 et 17 mars il y aura le premier Agile Open Sud pour regrouper les agilistes du sud. Vous êtes intéressé ?  Vous voulez en savoir en plus ? Plongez vous dans le forum : vous y trouverez les informations, comment s’inscrire, etc.

Conférences et sessions ?

J’ai postulé pour une nouvelle prestation à Sudweb 2012 (cette année à Toulouse le 25/26 mai) avec Bruno, un gars qui hait le printemps. J’espère y présenter la première sortie de “Un projet web dont vous êtes le héros agile”. Un jeu agile que nous souhaitons intéressant et qui prend le format d’un “livre dont vous êtes le héros” mais sous forme de parcours et d’ateliers divers & variés, d’obstacles terribles & inhumains.

Il est aussi possible que j’intervienne à Mix-It pour lequel j’ai aussi postulé pour des sessions plus classiques.

Sur ces deux conférences j’en saurais un peu plus rapidement (fail fast ? ).

Cette question interroge d’abord sur notre faculté à auditer l’agile. Est-ce possible d’auditer une approche qui se veut auto-organisée, en amélioration continue, dans un monde complexe où il n’est pas aisé de reproduire des schémas pré-établis ?

Qu’est ce qui défini aujourd’hui une bonne approche agile, d’une mauvaise ? Peut-on auditer une approche agile ? Même si certaines connaissances autour de moi s’y refusent, je ne partage pas leur avis. D’abord mettons nous d’accord sur le terme “auditer”. Je me base sur la définition de wikipedia (elle me convient) : “une activité de contrôle et de conseil qui consiste en une expertise par un agent compétent et impartial et un jugement sur” … Pas nécessairement une note ou un rang ou une certification, mais un jugement, un avis. Exactement comme dans le cadre d’une rétrospective, ou d’un exercice d’amélioration continue. Si j’ai cet avis je suis capable de dire à la personne qui m’interrogeait (et naturellement si je prends le temps de faire un audit) de lui donner un jugement, un avis.

Comment donc auditer une organisation agile, un groupe agile, un projet agile ?

On peut se baser sur les 3 niveaux fournis par les différentes méthodes et l’agilité de façon plus générale :

Niveau 1, les valeurs du manifeste et des différentes méthodes

Interaction, capacité au changement, collaboration etc. auxquels si nous sommes dans un environnement scrum on ajoute : transparence, inspection, adaption ; ou si  nous sommes dans un environnement XP : respect, courage, feedback, communication, simplicité, ou les deux. On peut aussi intégrer à ce niveau les valeurs du Lean : respect des gens, amélioration continue.

Niveau 2, les principes du manifeste

par exemple : “Simplicity–the art of maximizing the amount of work not done–is essential.”, ou “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation”, ou des principes du Lean: See the whole, eliminate waste, flow, pull, etc.

Chacun des principes découlent des valeurs, c’est une mise en oeuvre de celles-ci. Les valeurs priment donc sur les principes.

Niveau 3, les pratiques des différentes méthodes

Le daily standup de scrum ou XP, le code refactoring de XP, la rétrospective de Scrum, la limitation du travail en cours de Kanban, etc.

Chacune des pratiques découlent des principes et des valeurs. Les valeurs priment donc sur les principes, qui priment eux mêmes sur les pratiques.

Tout devrait vous ramener aux valeurs, le lien avec celles-ci dans chacune de vos activités agiles doit être permanent. Peu importe que vous détourniez, transformiez, inventiez des pratiques si tant est que vous respectiez les valeurs agiles auxquels vous vous réferez. Celles-ci peuvent être réduites à votre seule discipline : Scrum : transparence, inspection, adaptation ; XP : feedback, respect, courage, simplicité, communication. Mais celles-ci sont atomiques. On n’imagine pas faire de l’adaptation sans inspection, on n’imagine pas une inspection sans transparence.

C’est sur ces points que l’audit agile devient complexe. Il m’est facile de dire si un daily scrum se déroule correctement, ou le sustainable pace de XP est respecté. Il est autrement plus compliqué de dire si une organisation, un projet est transparent ou non, si une équipe a été courageuse ou non, si il y a eu assez de respect ou non.

Pour les pratiques je sais, j’ai un savoir ; aussi bien subjectivement qu’objectivement je suis capable de juger si les gens respectent ou non les pratiques du daily scrum ou du sustainable pace.

Pour les valeurs (je laisse les principes : ils se situent entre les deux) j’ai une opinion et non pas un savoir. Je peux difficilement affirmer de façon subjective et objective si la valeur de transparence est respectée, mais j’ai mon opinion. (Sur ces approches, avec le savoir et l’opinion, il faut ajouter la foi et vous aurez les 3 degrés d’assentiment décrits par Kant dans sa critique de la raison pure).

Pour formuler une opinion j’opère comme le fait Comte-Sponville dans son “esprit de l’atheisme” lorsqu’il s’interroge sur l’existence de Dieu (il fallait bien cela en ces jours de fête ou tout le monde se baffre à la mémoire d’un petit gars soit disant né dans une étable) : avec des arguments négatifs. Je ne sais pas si vous êtes agile, mais je crois détecter quand une chose ne l’est pas, j’ai mon opinion là dessus. J’ai une opinion sur les choses qui ne me paraissent pas agiles, en cela je me réfère constamment aux valeurs de l’agilité ou des méthodes que vous déployez (XP, Scrum, Lean, etc.). Mon opinion est basé sur ma connaissance (et donc mon expérience).

J’ai pour opinion que lorsque les tâches des membres d’une équipe sont affectées nominativement avec une durée précise et très contraignante par une personne extérieur au groupe nous ne sommes pas agiles car nous ne respectons pas les personnes, ni leur faculté de s’auto-organiser. J’ai pour opinion que si une équipe se compose uniquement d’un certains types de profils dits techniques et qu’ils travaillent en autarcie l’un des objectifs de l’agile n’est pas atteint en ce qu’il préconise de la collaboration au travers de différents profils qui doivent apprendre à travailler ensemble. Le second exemple me parait moins “grave” que le premier car il enfreint moins de valeurs et de principes. (Si on me demande de mettre des “notes” à ces opinions j’en suis capable, comme je suis capable de donner un tarif avec des chiffres à ces missions, et comme mon banquier me réclame une certaine somme en fin de mois pour ma maison : les chiffres ne sont qu’une convention).

Avoir une opinion sur votre agilité ? observez vos processus, votre principes, vos valeurs relativement à ceux et celles proposés par l’agilité. Essayez de vous projeter par “opinion négative”. Avant toute chose il faut être au courant de ce qu’est l’agilité (c’est probablement pour cela que la question de l’auditeur (tiens un autre sens au même mot) de la session Agile/CMMi m’a d’abord surprise).

Pour finir,

Les valeurs sont peu nombreuses, pour essayer de faire une métaphore :  elles forment des piliers massif d’un immense hall où vous pouvez à loisir vous organiser comme bon vous semble. Ces valeurs sont les seules contraintes mais elles sont indispensables, sans elles le hall s’effondre. Si vous respectez ces piliers, libre à vous de faire comme il vous chante, et c’est cette liberté qui est source de richesse et d’innovation, de progrès. Dans l’agile on parlera de contraintes libératrices (je crois que Thierry @thierrycros qui m’a soufflé l’expression qui vient de Paul Valery) : “contraintes libératrices dira le poête comme le géomètre, “les oeuvres à grandes contraintes exigent et engendrent la plus grande liberté d’esprit” [pioché ici].

Voici donc un complément à ma réponse : pour bien appliquer l’agile ayez des contraintes fortes liées aux valeurs ou aux principes ou aux pratiques de vos méthodes agiles et respectez les impérativement. Les valeurs sont indispensables, faites votre choix dans les principes et les pratiques mais attention l’atomicité est très importante.

Quelques exemples pour me comprendre cette notion de “contrainte” :

• Scrum : Le product owner est responsable du backlog, des priorités et de la validation. Est-il vraiment responsable ?
• XP : Appropriation collective du code : tous les developpeurs peuvent-ils agir sur toutes les parties du code, même celles qu’ils n’ont pas écrites ? Le peuvent-ils véritablement ?
• Amélioration continue : y-a-t-il une véritable réflexion sur l’amélioration continue avec de véritables actions prises ?

D’où aussi l’importance prédominante des moments d’interrogations ,d ‘analyses et d’amélioration. La rétrospective est l’élément phare et révélateur d’une pratique agile.

Naturellement on n’est jamais totalement  accompli , on tend vers l’agile, vers une application idéalisée de toutes les valeurs.

Dans une session old time, une “tune” (un titre) dure entre 10 et 20mn…c’est long. Cette musique est en plus très répétitive (sorte de trance). Mais du coup on apprend le morceau pendant que les autres le jouent. C’est une montée en compétence par la pratique au sein du groupe (on avoisine entre 6 et 20 personnes dans une session, voire plus…). Si on ne connait pas un morceau, les 5 premières minutes on va écouter. Les 5 minutes suivantes on essaye de jouer les bases du morceau. Avec un peu de talent on peut commencer à enrichir notre prestation les minutes suivantes. A la fin du morceau, on le connait, et on est prêt à le transmettre à d’autres un autre jour. On est proche de l’idée de compagnonnage (“ réseau de transmission des savoirs et des identités par le métier “, même si ce nom peut en braquer certains) portée par craftsmanship ou XP. En tous cas ces groupement de personnes qui mèlent apprentissage et plaisir qu’il s’agisse d’une session old time ou d’un code retreat me semblent très proche (et il doit y avoir de nombreux autres exemples…mais bon mon dada moi c’est le old time…).

les sessions old time se pratiquent depuis le XVIIIème siècle.

Voyons donc si nos règles (de “old timey”) pour les sessions pourraient vous inspirer pour vos code retreat (je ne code pas assez pour m’inclure):

(il y a de nombreuses règles de sessions old time mais elles se ressemblent toutes plus ou moins, je me suis donc basé sur celles -10- du site “old time seattle”).

1. Tout le monde, peut importe sa compétence musicale, est invité et encouragé à rejoindre le cercle de la session, mais s’il vous plait essayez de vous entrainer et d’avoir pratiquer avant. (“Every one, regardless of musical ability, is invited and encouraged to join the jam circle, but please try to come practiced & prepared”).
2. Gardez un oeil ouvert (pour voir les nouveaux entrants ou faire de la place pour), laissez de la place que les nouveaux entrants se sentent à l’aise pour entrer dans le cercle à n’importe quel moment. (“Keep your eye out – make room for new players so they can enter the circle at any time and feel welcome to do so”).
3. Un instrument est trop présent ? Laissez votre place durant quelques morceaux et proposez à un quelqu’un autour du cercle de venir prendre votre place (il est aussi possible de faire un deuxième cercle, à valider avec le meneur de la session).(“Too many of the same instruments? Take turns by leaving the circle after playing a few tunes and encourage a sideliner to take your place. Sometimes it’s possible to make a second circle, check with the jam leader”.)
4. Si vous n’êtes pas familié avec un morceau. Ne jouez pas, mais écoutez le quelques minutes puis commencez doucement à le jouer jusqu’à que vous vous sentiez à l’aise. (“If you are unfamiliar with a tune, DON’T PLAY AND JUST LISTEN a few times through, then play along quietly until your sure you’ve got it”).
5. Faites attention à votre volume, soyez sur que la personne qui mène le morceau est entendue par tous. De même si vous menez un morceau soyez sur que chacun vous entende. (“Pay attention to your volume, make certain the person leading the tune can be heard by everyone. Likewise, if you are leading a tune, try to play loudly”).
6. Soyez sûr d’être bien accordé. Utilisez un accordeur électronique si besoin et vérifiez fréquemment. (“Make sure you’re in tune. Use an electronic tuner & check yourself frequently”).
7. Quand vous menez un morceau annoncez la tonalité au préalable. Et annoncez la grille si le morceau est méconnu. Si le joueur à vos côtés ne connait pas le morceau prenez le temps de le renseigner tranquillement (“When leading a tune, announce the key before starting each tune or song. And announce the chords if the tune is more obscure. If a the player next to you does not know the chords and you do: offer to tell them quietly”).
8. Les sessions sont une grande expérience d’apprentissage mais ne sont pas des leçons gratuites. Si vous avez besoin de beaucoup d’informations n’hésitez pas à demander à la ronde si quelqu’un donne des cours privés ou demandez quels disques écouter pour progresser. (“Jams are a great learning experience, but are not meant to be freebie music lessons. If you’re looking for a lot of pointers, feel free to ask around to find others that offer private lessons, or ask for recommended recordings to listen to at home”).
9. Concernant les danseurs : ils sont encouragés à rejoindre la session. Merci cependant d’aider les musiciens en attendant que le morceau joué est assez en place pour lancer la danse. Merci aussi de vous coordonner entre vous afin d’éviter trop de danseurs (ce qui génère une cacophonie terrible). (“Dancer etiquette: Step-dancers are encouraged to come to jams! Please help out the musicians by waiting to dance until the tune is played a few times through the form and is being well-grasped by the majority of the musicians. Also, coordinate taking turns if there are multiple dancers, as too many feet gets awfully cacophonic (you can take turns on the same tune).”)”
10. Si la session se déroule au boulot, faites en un évènement ludique ! Achetez des boissons ou des encas !, invitez vos amis à venir écouter, essayez d’être bon : meilleure sera la session le plus de personnes reviendront et nous aurons de plus en plus de support à ce que nous faisons. (“If the jam is at a business, keep the business happy! Buy a beverage/snack & tip the staff (alcoholic-free drinks are available at bars if you don’t drink alcohol), invite your friends to come listen, & try to play your best as the better the jam sound the more people will listen and gain an interest and support what you’re doing!”)

Je raffole des bouquins (pour le boulot ou autres), et je surpris du désamour pour les livres que je constate sur le terrain. Peu de gens lisent. C’est bien dommage. Les gens qui lisent me posent souvent des questions très pertinentes. Et puis lire un bouquin tranquille dans son lit, relax dans son bain, à l’aise sur la plage, calmement dans le train, ça n’a pas de prix. (un vrai bouquin, un truc que vous tordez, marquez, machônnez, etc.)

L’agile propose pléthore de livres, de nombreux de qualités. Je vous donne mes suggestions et en quelques lignes pourquoi je vous recommande ceux-ci.

Bonnes lectures.

	Claude Aubry, Scrum Je recommande toujours le bouquin de Claude d’abord car il est bien. Il sert autant à découvrir la méthode Scrum, qu’il peut servir de livre de référence quand on a besoin de piocher des informations ou de se remémorer certains détails. Je le recommande aussi beaucoup car il est en français et j’évite donc ainsi plein de quiproquos avec des gens qui ne maitrisent pas assez bien l’anglais.Ce n’est pas grave mais du coup ils n’osent pas me dire qu’ils ne lisent pas les références que je leur donne en raison de l’anglais… avec le bouquin de Claude je fais coup double : il est bon et en français. en français
	Mike Cohn, Agile estimating & planning Mike Cohn est très pédagogue. Ses livres se lisent comme du petit lait. Je ne suis pas à l’aise avec tout (notamment l’utilisation permanente de la “business value” n’est pas simple, de la valeur oui, de la “business value” c’est plus dur). Si vous commencez par le livre de Claude, celui-ci constitue un complément très intéressant pour les product owners notamment. en anglais
	Mary Poppendieck, Lean Software Development Mon favori. Une approche globale sur Lean et son application dans le domaine du logiciel. J’aime tout. en anglais
	Extreme Programming Explained, Kent Beck Un truc comme du cuir dur, difficile à tordre, mais qui résiste au temps et que l’on consulte avec plaisir. Pour se plonger dans les sources de l’Extreme Programming. en anglais
	Hell’s Angels, Hunter Thompson Un retour d’expérience concernant un coach agile plongé au milieu d’un gang de Hell’s Angels. Indispensable. D’autant que je prédis malheureusement la collusion massive et prochaine du coaching agile et du journalisme gonzo (des signaux forts en ce sens en ce moment). en anglais ou français
	Agile Retrospectives, Esther derby La rétrospective est vraiment l’élément clef de l’agilité (tel que je le conçois). Ce livre permet de renouveler le genre, nos formats, et de pousser plus loin nos équipes. en anglais
	Management 3.0, Jurgen Appelo Joker ! Je ne l’ai pas lu. Je suis donc en train de vous suggérer fortement de lire un livre que je n’ai pas encore lu ! (quel culot !) Il est sur ma table de nuit et tous les retours que j’en ai me laissent penser qu’il est lui aussi indispensable à tous les (futurs) managers agiles. Je pense donc qu’il aurait été encore plus dommageable de ne pas le lister. Promis je fais une chronique dès sa lecture (décembre/janvier ?) en anglais

Cette vidéo a été enregistrée par la télévision/web de l’école Polytech qui a hébergé ce premier agile tour Montpellier. Sur le site vous pouvez télécharger la vidéo ou voir les autres interventions tout au long de la journée : http://www.webtv.univ-montp2.fr/?s=agile+tour

La vidéo

Les slides

L’idée derrière ces fortunes est de donner aux équipes des éléments de réflexion pour les aider à la réussite de leurs projets (qu’ils soient agiles, classiques, ou autre).

Vous trouverez donc ici :

http://www.areyouagile.com/wp-content/uploads/2011/11/areyouagile_fortune_0_3.pdf

Les fortunes et une proposition de mode opératoire, mais sur ce dernier point je fais surtout appel à votre imagination, et je serai friand de vos retours.

ps : l’image du “make love, not bugs” vient de là.

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 :

1. 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.
2. 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.