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.

La vidéo

Les slides

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.

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“.

La nature et l’engouement autour de cet évènement me pousse à vous encourager à vous y inscrire et à y participer (même si naturellement il faudra comprendre l’anglais, notre esperanto bon gré mal gré).

Pour cela vous pouvez vous pré-inscrire ici : http://ale2011.eu/pre-registration/et avoir une réduction de 50 euros (et pour info je me suis pris un vol Paris/Berlin A/R pour 115 euros …).

Vous pouvez aussi proposer votre propre présentation (en anglais aussi) : http://ale2011.eu/call-for-papers/

Enfin les sponsors sont naturellement les bienvenus : http://ale2011.eu/sponsors/ (déjà Nokia, Agile42, JBBrains, Pair Coaching et Agile Alliance se sont portés candidats).

Je vais essayer de traduire en français les textes les plus importants (et les documents pour la presse) n’hésitez pas à me communiquer les informations qui pourraient vous intéresser à ce sujet.

Je vais commencer ici par vider mon carnet de notes et vous décrire à peu près mon itinéraire. Voici un état des lieux du premier jour.

J’avais décidé de participer aux deux jours orientés conférences (et je n’ai donc pas assisté aux ateliers du mardi ou du vendredi). Quand j’arrive mardi soir vers 22h30, il fait bon (c’est Madrid), et la plupart des participants sont au bar en face de l’hôtel à déguster des “cerveza” et des tapas. J’y fais rapidement la connaissance de Jurgen Appelo (@jurgenappelo) et je découvre que le Olaf Lewitz de twitter (@OlafLewitz) est un sacré gaillard.

La première journée de conférence débute par une keynote “Still no silver bullet” de Esther Derby (@estherderby) sur laquelle je reviendrai mais qui met en évidence une boucle (qui peut s’avérer sans fin) entre ce que va préconiser l’agile et les contraintes des compagnies actuelles, entre centralisation et décentralisation. Elle insiste aussi sur le rôle des métaphores et notre grande réceptivité à leur sujet. Elle rappelle que l’état actuel des choses: mener les compagnies en fonction de budgets établis tous les trimestres est juste absurde. Et surtout elle nous demande  de soigner ce diamant qui représente la communication entre la connaissance contextuelle, et la connaissance du moment, au jour le jour (voir l’image ci-dessous).

Esther Derby semble être une femme assez rigolote et amicale, toujours sympathique lors des discussions off. (Mais c’est le cas de tout le monde lors de cet évènement). Elle glisse au passage que notre “awareness” (sensibilisation) aux bonnes pratiques démarre avec une réflexion sur nous même (et je cite “presque avec votre psychanalyste” // analyst coach).

Cette première keynote est très intéressante et je décide donc d’enchaîner avec une session de discussion avec Esther Derby dans la foulée. Cela se révèle un chouïa moins passionnant car plus attendu, sans surprise. On revient sur certains concepts évoqués lors de la keynote.

Solidement attaché à mon siège je reste dans la salle (au passage l’hôtel est sympa sans être extraordinaire). Débarque une dame aux cheveux multicolores -réellement-. C’est Kati Vilkki (de chez Nokia). S’ensuit une discussion ouverte, très intéressante. Elle met en exergue ce qui pour elle constitue une série d’illusions :

• illusion de la hiérarchie (la hiérarchie n’est absolument pas respectée, l’idée que la hiérarchie est bien établie et fonctionne est fausse)
• illusion du “command & control” (on croit pouvoir vraiment commander et contrôler, c’est souvent faux).
• illusion de la notion de “power is elsewhere” (on croit que le pouvoir est ailleurs, que l’on a pas les moyens de certaines actions, c’est faux)

Mais qui donc forme les managers à devenir manager s’interroge-t-elle ? (et je ne peux que penser : et qui donc forme les coachs agile à devenir coach…).

C’était une discussion passionnante, franche, directe. Kati Vilkki parait saine, simple, efficace. J’ai beaucoup apprécié…et impossible de l’oublier avec sa chevelure multicolore !

J’en profite pour mettre en évidence un fait : cette conférence est celle des femmes : Esther Derby, Kati Vikki, Elizabeth Keogh (et Mary Poppendieck qui traînait aussi par là). Et tant mieux !

L’après midi démarre pour moi avec un speech de Jurgen Appelo (@jurgenappelo) sur “purpose of leadership & governance” (les slides sont ici !) durant lequel Jurgen se réfère assez à l’aventure actuelle du ALE network. Les conférences de Jurgen sont précises et efficaces. Son approche a été en 4 points :

• On manage par des contraintes et pas en imposant des règles
• Il est essentiel de protéger les équipes et les ressources partagées (il fait appel à la tragédie des biens communs)
• Bien comprendre les buts et objectifs de chacun (et notamment le but intrinsèque, le but extrinsèque, et le but émergent, j’y reviendrai)
• Objectifs : ne pas fixer d’objectifs numériques

Et c’est par une grande rencontre ALE Network (quelles actions souhaitons nous mener ?) que je poursuis l’après-midi (voir la photo de Olaf Lewitz @OlafLewitz ci-contre). Vous retrouverez les résultats de ces groupes de réflexion sur le site ALE Network (mais j’aurais l’occasion d’en parler à nouveau). Nous avons fonctionné par groupe de réflexion de 5/7 (avec le moins possible de nationalité en doublon : facile pour moi j’étais le seul français à cette réunion, et globalement les français ont représenté 1% des participants…) et nous avons essayé de faire émerger des idées pour mettre en action ce ALE Network. Pour les résultats je vous renvoie à la galerie de Olaf Lewitz (merci à lui)

La soirée se termine par une sortie de tous les participants ( ~ 250 selon les organisateurs) dans un restaurant archi-bruyant (et pas terrible terrible). J’ai cependant eu le plaisir de faire la connaissance de toute une équipe bordelaise de chez f-secure.

Ester Derby voulait lancer un “Werewolf” (soit un loups-garous de tiercelieux) en soirée mais tout le monde a été bien assommé par cette terrible salle du restaurant. Donc dodo avant d’attaquer la journée suivante.

Feedback sur le jour suivant

Je tiens d’abord à saluer l’effort réalisé par ce groupe d’aventuriers : déclencher ce type d’évènement, avec ce standing (salle, vidéo, traiteur, orateurs étrangers), dans notre région… Bravo, hats off !

Pour ma part je dois représenter le quota gardois. eh eh.

Au début je me suis interrogé, je suis la seule session typée méthodologie, qui plus est : agile. Naturellement il y a plein de très bonnes raisons pour que le web embrasse cette méthodologie, donc pas trop d’inquiétude malgré tout. De plus je perçois un dessein dans la programmation (si, si) : achat (de prestations web), méthodologie (agile), outillage (cloud), politique/valeur (web & humanitaire)… Par la suite des aspects plus techniques. Mais malgré tout il me semble que l’on prend du recul, que l’on cherche à aborder les sujets d’une façon plus globale, plus riche.

Tant mieux, ma session aura pour but de présenter un retour d’expérience au sein d’un grand éditeur (que je ne nommerai pas, trop de contraintes bureaucratiques et juridiques). 9 mois au compteur dans le déploiement de l’agilité chez ces gens, gens ? si j’osais je dirais copains désormais (tout un plateau me dit “bisous” en forme de boutade parfois quand je rentre dans le sud, con). Au delà de ce retour d’expérience -fil rouge-, il s’agira avant toute chose de décider les décideurs à se décider (j’ai un copyright sur cette phrase lourdingue). Je ne rentrerai presque pas (ou pas du tout si c’est possible) dans les questions : qu’est ce scrum, xp, kanban ? C’est à mon avis un acquis. Et d’ailleurs si cela ne l’est pas, cette connaissance n’est pas obligatoire pour comprendre mon propos, et elle se retrouve facilement sur … le web.

Voilà en espérant vous croiser à Sudweb.

Le premier slide de la session durant laquelle (en terme de présentation) je vais essayer de réconcilier mes études littéraires/cinématographiques avec mon métier d’aujourd’hui… (je pense qu’il est trop tard pour qu’ils annulent ma session ah ah ! ): (pensez à réviser les Monty Python dès ce soir sur Arte !)

Ps: C’est une conférence NO WIFI ! avec des humains dedans ! N’amenez pas ou éteignez vos téléphones, ça serait trop con de louper l’occasion de discuter avec de vraies personnes.

Très récemment, Jurgen Appelo (Noop.nl) a lancé une réflexion sur un positionnement européen de l’agilité au travers d’une discussion sur LinkedIn. Ses conclusions et la synthèse des commentaires a pris la forme d’un “post” sur son blog : Agile Europe, entrons en action. Je me propose de le traduire ci-dessous et je vous suggère à tous agilistes de France et de Navarre de prendre contact avec Jurgen. En français ou en anglais, car c’est la première chose que je me suis permis de remonter : le problème de la langue, particulièrement dans notre pays. Je suis sûr que nous avons plein d’agilistes de talents qui ne comprennent rien à la langue de Shakespeare. Cela serait dommage de perdre leur apport. A priori Jurgen Appelo a déjà bien conscience de cette difficulté, inhérente à notre condition européenne.

Une dernière réflexion avant de traduire son appel. Le débat sur l’identité agile européenne me parait très fécond. En effet, pour ma part le côté “Can Do” assez anglosaxon se heurte régulièrement au “Je pense donc je suis” de notre sensibilité français (je pense avant de faire). Il me paraîtrait très intéressant de philosopher un peu là dessus car l’agile est une culture avant toute chose. (ps : l’improbable drapeau à gauche provient de mon esprit retors).

Jurgen Appelo, Agile Lean Europe, Entrons en action.

Dans mon précédent message, j’ai analysé la discussion au sujet d’un réseau de penseurs agile & lean en europe (et d’acteurs). Ma conclusion a été que beaucoup d’entre nous souhaitent une meilleure interaction et collaboration au travers de l’Europe. Mais nous chérissons aussi les idées de diversité et d’émergence.

Nous avons besoin de gens pour pousser les choses plus loin. Mais sans créer une hiérarchie ni une volonté de contrôle.

J’ai discuté longuement avec  Olaf Lewitz et Ken Power, et voici mon plan d’action…

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, …