La vidéo

Les slides

Mais

Car il y a -à mon avis- un “mais”.

Il est beaucoup plus aisé de ne pas être agile en faisant du KanBan, qu’en faisant du Scrum.

Il sera donc plus beaucoup plus aisé à certaines entreprises de s’emparer faussement du concept agile au travers de KanBan qu’au travers de Scrum.

Dans de nombreux cas une révolution est bien plus préférable qu’une évolution.

En ce moment où le succès des méthodes agiles parait à son comble, et donc où le risque de perversion (pour citer Alistair Cockburn) est très fort, KanBan pourrait finalement plutôt se transformer en cheval de Troie des méthodes agiles à leur insu…

On pourrait me répondre : “l’important est que cela marche ou que cela soit agile ?”, naturellement que cela marche. Après que veut dire “marcher”, “réussir”, “résultat” (ouh les restes d’une discussion dans une voiture hier). Si on s’accorde dessus, je suppose que je compléterai en disant que cela marchera cependant mieux si c’est agile.

Je n’ai naturellement pas à ce jour l’expérience de par exemple Laurent Morisseau  sur KanBan (et je vous recommande donc sa lecture). Mais, -à titre personnel- j’y vois de grosses qualités : centraliser/modéliser et prioriser en un seul point toute l’activité. Comme le backlog de Scrum, si ce n’est que le backlog de Scrum ne contient pas tout, ou très rarement. Avec KanBan tous les arbitrages se font dans un même lieu, sans échappatoire. D’autre part comme on travaille au niveau, disons de la “story”, on a une souplesse (dans le changement) plus grand que dans l’itération.

Mais je retiens aussi des lacunes : dans mon expérience (et je prends donc là aussi une précaution), les aspects collaboratifs d’équipes y sont trop effacés (je sais on peut y remédier : mais comme évoquer plus haut, ce n’est pas une obligation…), la présence d’une deadline (des itérations) s’estompe, les interactions sont moins nécessaires. Globalement si je me sens plus à l’aise avec Scrum c’est qu’il propose une forte connotation humaine, de rapport humain, de dynamique, alors que KanBan est clairement plutôt un plaisir intellectuel de modélisation (d’où aussi sa séduction).

J’ai évoqué un peu ce sujet hier à ce panier repas agile auquel j’ai eu le plaisir de participer, et finalement je crois que c’est Thierry (Cros @thierrycros) qui a eu le mot de la fin et j’espère ne pas trahir sa pensée : “oui KanBan mais ne pas démarrer avec, l’appréhender quand l’équipe est déjà mature“.

Voici certains des retours que j’ai eu :

“Pourquoi Scrum ?”

“Parce que cela va augmenter de 400% votre productivité ! ”

“ah… et pourquoi ?”

“Parce que c’est Scrum !”

ok on est bien avancé…

“Je travaille avec une équipe QA (assurance qualité) de 10 personnes en Roumanie, comment dois-je l’intégrer avec mon framework Scrum à Paris ?”

“Faites la venir en France”

C’est probablement une bonne réponse *dans l’absolu*, mais il est inconvenant de la limiter à cela. Je sais bien qu’il faille un électrochoc, et que devenir “agile” est un changement culturel fort. Je comprends et je pratique souvent la “réponse par une question” en formation, mais cela doit être un cheminement, une réflexion qui doit s’ancrer dans les pratiques en cours :  avec une mise en situation nécessaire, une mise en évidence des contraintes, des risques, des objectifs, etc.

Une connaissance me rétorque : “oui mais 2 ou 3 jours pour entamer une révolution psychologique personnelle c’est court”. Oui, naturellement, mais cette formation est souvent un premier pas essentiel. Si on a l’impression en sortant que le formateur a bouffé trop de champignons, c’est déjà un très mauvais départ, et cela ne va pas nous aider au quotidien !

Sur ce, meilleurs voeux 2011

* en haut à gauche : psilocybin, indispensable pour certaines formations agiles manifestement

On assiste donc à une guerre de positionnement dont la certification est probablement la face la plus visible. Constat : la certification agile n’a pas de sens réel : soit on passe 2 jours (plus de 1000 euros) avec un coach agile et on obtient automatiquement la certification (ScrumAlliance), soit on paye 100 euros et on a le droit de passer un QCM pour avoir une certification (scrum.org).
Alors oui c’est mal car on se retrouve avec pas mal de gens qui n’ont aucune expérience réelle du terrain et qui sont certifiés. Mais est-ce que cela diffère des autres certifications ? ben non, pas vraiment à mes yeux. Est-ce que cela a de la valeur : très peu mais pas rien (j’ai passé du temps -2 jours- avec un coach agile, ou je me suis plongé dans le manuel (20 pages) de scrum.org avec un QCM au  bout) ; c’est déjà une différence n’en déplaise à certains. Le problème est plutôt que certains s’octroient le droit d’attribuer la certification, et que d’autres n’ont pas ce privilège.

Faut-il blamer quelqu’un ? Celui qui abuse du système en certifiant à tour de bras ou celui qui n’emploie que des gens “certifiés” sachant que cette certification n’a que peu de valeur ? J’opte pour l’acheteur. Sans demande, pas d’offre… Pour autant il est compréhensible que l’on souhaite s’assurer des compétences des personnes que l’on embauche ou avec lesquelles on va travailler. Il me parait cependant évident que les acheteurs doivent faire un effort concernant leur recrutement.

Est-ce possible de certifier en agile ? Pas moins que dans d’autre domaine. Cela a-t-il un sens ? Je suis moins convaincu. Le côté humain, conceptuel, contextuel jouent un rôle fort, comment dès lors proposer une check list permettant de valider les connaissances agiles de certains et industrialiser (argh) cela…

Alors faut-il certifier malgré tout l’agile et comment ? Je me baserai sur le modèle CMMi (que bien j’ai connu). Je certifierai une organisation, une entité, et non pas une personne, et à intervalles réguliers. En continuant ce parallèle avec CMMi, au lieu de pratiques j’évoquerai les principes et valeurs et je laisserai libre cours à l’entitée de les embrasser comme elle le souhaite. Mais je ne fais que repousser le problème (bien visible côté CMMi) : qui ??? a le privilège de certifier…

Et on retombe ainsi sur les errements actuels de la “communauté agile” : faut il un pragmatisme outrancier (quitte à faire tourner la machine à billets), ou faut-il se lancer dans de longues diatribes sur le changement culturel, le côté humain, etc… qui fleurent bon parfois le charlatanisme ou la croyance.  Au passage les deux ne sont pas si mauvais, négatifs. Oui c’est beau et bien de défendre un idéal, une philosophie (même si les clients ne cherchent pas forcément cela…enfin un salarié heureux est un bon salarié). Deuxio je ne vois aucun mal à gagner de l’argent avec l’agile. Il faut bien gagner de l’argent, si en plus on peut le faire en faisant ce que l’on aime…

Ca tiraille fort. Mais c’est bon signe aussi ces discussions endiablées, ces oppositions.
Et, pour adoucir mon billet, de mon humble point de vue, il y a une voie au milieu et la majorité des gens que j’observe semblent la choisir.

Ah je note que agile-certification est disponible en .fr (messieurs tirez les premiers).

Un très bon article sur les problèmes soulevés par la certification agile :

http://xprogramming.com/articles/csm-certification-thoughts/

Les faits m’accablent :

a) je me mêle à la meute concernant la certif agile
b) je suis certifié
c) je gagne de l’argent avec l’agile

image : http://www.flickr.com/photos/denverjeffrey/458846356/

En voici une (il s’agit d’un mix d’extraits entre plusieurs clients, que j’ai anonymisés), histoire de rendre les choses concrètes. Vous pouvez la juger, la dénigrer, l’utiliser, etc.

Comment : on regroupe toute l’équipe (équipe, scrummaster, product owner). On fixe 4 grands axes : “les plus”, “les moins”, “les optimisations à envisager”, “le plan d’action”. Le plan d’action étant constitué par les optimisations que l’on souhaite mettre en oeuvre dès à présent, ou qui concerne un évènement pour le prochain sprint. Presque une antichambre : si nous envisageons régulièrement la même optimisation il faudra se décider à la basculer dans “plan d’action”. De même on peut rapidement glisser dans “les moins” les éléments du plan d’action que l’on aura finalement pas ou mal mis en oeuvre. Chacun évoque les points qu’il souhaite mettre en évidence. Je n’interviens (en tant que ScrumMaster) qu’à la fin, mais j’ai mon mot à dire et si je peux influencer dans tel ou tel sens je n’hésite pas mais je ne tranche pas.

Mes commentaires en italiques.

Les plus

- Backlog et stories plus complets (Stories plus complètes : au niveau des tests d’acceptation et/ou des scénarios de validation)

- Réorganisation de l’espace, salle, post-it, etc. (chez ce client un espace dédié a été aménagé pour l’agilité durant le sprint).

- Motivation de l’équipe (se passe de commentaire, mais j’explique qu’il est normal avec Scrum d’avoir des équipes plus motivées. Par contre il est essentiel de faire signe quand la motivation n’est plus au rendez-vous, et surtout pourquoi. Tout le monde ne peut pas être motivé 100% du temps.)

- Intégration des tests unitaires dans la notion de fini (se passe de commentaire)

Les moins

- Mauvais découpage des stories et des tâches (trop de dépendances !)

- Ponctualité (se passe de commentaire)

- Un expert externe peut interférer sur le périmètre du sprint sans faire partie de l’équipe. (il faudra résoudre ce point si celui-ci se répète, c’est un point de vigilance)

- Cadence pas assez régulière (coup de collier sur la fin). La validation des stories doit être régulière. (se passe de commentaire, un point du plan d’action est dédié à ce problème)

- Difficulté à concilier le focus du sprint et les demandes externes (il faut protéger cette équipe)

A envisager/optimiser ?

- Intégrer la revue de pair dans la notion de fini (c’est à dire que dans ce cas elle s’applique sur toutes les stories).

- Meilleurs jeux de données.

- Plus/Mieux utiliser des normes de codage/développement/nommage. (XP…le pair programming va suivre…)

Plan d’action

- Validation régulière des stories (pas de coup de collier final) (sur le prochain sprint -3 semaines- on se fixe les premières validations sur la seconde semaine)

- Chaque membre de l’équipe annonce aux autres au début du sprint le nb de jours qu’il estime pouvoir accomplir sur le projet (des soucis d’estimation liés notamment au temps “réel” passé sur le sprint)

- Chart température équipe (un des participants sort d’une formation Scrum, on lui a parlé d’un chart décrivant la courbe du moral des membres de l’équipe, il souhaite le mettre en oeuvre. je vais lui passer le relais en tant que ScrumMaster pour prendre du recul. C’est sa première “mission” de ScrumMaster : établir ce chart et surveiller le moral des troupes)

- préparation en amont de l’arrivée d’un nouveau membre de l’équipe (annoncée le mois prochain il faut préparer cette arrivée, la dernière fois on a perdu un temps fou !)

Voilà. La rétrospective dure une heure max. J’affiche au mur (radiateur) uniquement le plan d’action. Naturellement plus celui-ci sera concis plus il sera suivi.

The prick.

Images : Grotto in an iceberg, photographed during the British Antarctic Expedition of 1911-1913, 5 Jan 1911, http://www.flickr.com/photos/nationallibrarynz_commons/4078337967/

Exemple, vous déployez Scrum au sein d’une organisation ayant pignon sur rue (disons un grand compte), avec des habitudes, des méthodes, des gens qui ne vous ont pas attendu pour délivrer un produit. Mais vous voilà qui débarque avec votre “agilité”.

Support, documentation, QA viennent aux nouvelles.

Qu’en sera-t-il des spécifications (sur lesquelles la documentation se fonde), qu’en sera-t-il des tests ? qu’en sera-t-il de la documentation ? etc. etc. Ma position est simple (ce qui ne veut pas dire qu’elle est facile à tenir) : voici l’état des lieux, voici nos objectifs dictés par la création de valeur, voici notre planning, voici le périmètre actuel, voici la méthode, etc. Vous estimez que nous devons intégrer ce niveau de documentation pour pouvoir vendre le produit ? Très bien, j’en fais part à l’équipe et au product owner (ou mieux : aller leur en parler !). Ce dernier décidera (probablement pas seul d’ailleurs, il est le représentant investi des pouvoirs d’un groupe de travail plus vaste) de la priorité à donner à cette création de valeur. L’équipe proposera peut-être d’intégrer ce point dans leur notion de “fini”. Il faudra probablement se demander si la documentation que vous réclamez est réellement porteuse de valeur. Pourquoi et comment.

Je n’ai pas la réponse, vous avez réponse, ils ont la réponse. (Le consultant dans sa pose la plus obscène s’écrient certains).

Nous affichons clairement nos objectifs, nos priorités, le contexte, le calendrier, la notion de “fini”, etc. On peut essayer des choses si on n’est pas sur de la bonne solution. On analysera vite si cela a fonctionné ou non.

Transparence, Inspection, Adaptation.

Je réponds finalement souvent : “je ne sais pas, qu’en penses-tu ?”. Mon rôle est d’accompagner, protéger, garantir, expliquer, faciliter, lever les ambiguïtés, mettre en évidence, etc (sur ma mission actuelle et qui sert de décor à ce post j’ai un rôle ambivalent entre le coach agile et le scrummaster, certains vont crier à l’hérésie, perseverare diabolicum). Que les arbitrages et les priorités soient clairs, basés sur les bons indicateurs, communiqués. Que le droit à l’erreur et à l’essai soient permis.

Je n’ai pas de parti pris, pas de sentiment, je suis neutre.

Il m’arrive aussi de dire : à telle date nous aurons un feedback assez conséquent pour estimer si cela marche ou si c’est un échec (sous entendu le déploiement de Scrum fonctionne-t-il ou est-il un échec ?). Nous prendrons une décision en fonction d’indicateurs clairs et transparents.

Transparence, Inspection, Adaptation.

Cela peut irriter. Et là tout dépend de la psychologie (ouh là là comme c’est galvaudé) du Scrummaster ou du coach agile. Est-ce pour cela que Ken Schwaber dans une célèbre vidéo renomme le scrummaster, the prick… (la piqûre, mais en argot : la bite, la queue…) ? Oui très certainement, nous pouvons irriter.

Attention, un dernier point, rester neutre ne veut pas dire ne pas encourager ou féliciter l’équipe, ou au contraire lui dire que l’on est surpris ou déçu dans certains cas.

The prick.

* photo by m4r00n3d

http://www.flickr.com/photos/mar00ned/193863350

Bref il s’agit d’avoir une cadence. Au sein de celle-ci deux éléments importants : une certaine anticipation, une livraison effective. Je traduis là deux concepts mis en évidence par Mary & Tom Poppendieck** et propre à l’agilité : “délivrer aussi vite que possible”, et “décider aussi tard que possible”. Il faut savoir jongler pour éviter le trop tôt ou le trop tard (dans vos livrables, dans votre expression du besoin, etc.). Si vous n’êtes pas dans le rythme vous dégradez la qualité ou vous fournissez trop d’effort pour peu de résultat (ce que j’appellerai sur-qualité). Toute la gamme d’artéfacts proposée par l’agilité est là pour éviter cela : sprint, timeboxes, dailyscrum, user stories, etc.

Dans le schéma ci-dessous (cliquez 2 fois dessus pour le voir en grand…) j’essaye de mettre en évidence de façon macro les effets négatifs dans le cycle du projet. En rouge ce qui génère le plus de problèmes, en vert ce qui propose le plus de valeur, d’efficacité. Toute la difficulté résidant à viser les zones vertes sans tomber dans les zones rouges adjacentes. C’est souvent mal perçu mais je tiens à le préciser : l’expérience y joue un facteur clef, un novice pouvant jouer sur toute la longueur de la barre…

* en fait je vois tellement d’analogies entre musique et scrum (ou plus généralement l’agilité) que je vais y dédier un post…

** je vous recommande encore, toujours, l’excellent “Lean Software Developpement, an agile toolkit“

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.

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.