Le mythe de l'auto-organisation?

Les approches agiles (y compris le Lean) renforcent le degré de responsabilisation des équipes dans leur travail quotidien. Le but est donc de laisser les équipes décider. On peut en retirer les avantages suivants:

• c'est la personnes qui effectue une tâche, qui sera la plus à même d'estimer correctement le temps nécessaire à sa réalisation, d'anticiper les problèmes à venir ou de proposer des pistes d'amélioration.
• l'efficacité d'une personne se voit améliorer si elle fait preuvre de plus d'autonomie : il est plus motivant d'être l'acteur de ses propres décisions, plutôt que de "subir" la décision d'une tierce personne.

En combinant ses avantages à l'échelle d'une équipe, si chaque membre se sent réellement impliqué et mobilisé autour de l'objectif commun, la performance de l'équipe sera grandement améliorée!

Mais bien souvent, on associe auto-organisation avec chaos; le sens commun nous incite à croire que si il y a pas de chef il n'y aura pas de décision. On nous dit que le consensus est une utopie (merci Thomas ;-) pour son billet). Heureusement, nous ne sommes pas obligés d'adhérer à ces croyances.

Sur un terrain de sport, les membres de l'équipe savent ce qu'ils doivent faire, ils ont été entrainés par un coach... l'intelligence de leur jeu est plus élevée que la simple somme des intelligences de chacun. Pouvons-nous en dire autant dans nos projets?

Mais quelles sont les conditions nécessaires à cette auto-organisation? 3 axes pour tenter de répondre à cette questions :

L'équipe est-elle réellement identifiée?
Les membres peuvent-ils compter les uns sur les autres à tout moment? Les membres de l'équipe sont-ils des ressources partagées ou des membres investis et impliqués? Scrum insite sur ce point grâce à la fameuse blague des cochons et des poulets. Clairement, une bonne pratique consiste à se focaliser sur le moins de choses possibles à faire à la fois. J'aime la remarque d'un collègue qui me disait un jour "A la maison, le matin, est-ce qu'on est efficace si on se brosse les dents en habillant le petit dernier, tout en préparant son biberon, alors que le téléphone sonne..."

Les membres d'une équipe partagent-ils un objectif commun?
C'est souvent le cas mais on constate trop souvent qu'il existe des enjeux personnels, des incompréhensions, bref, toutes sortes de freins à la cohésion de l'équipe sur l'objectif, la façon de l'atteindre ou simplement une décision le concernant. Il n'y a pas de solution miracle pour adresser ce point. Travailler la communication et le développement interpersonnel des acteurs du projet sont des pistes à considérer. Suivre des formations en communication c'est excellent, personnellement ça m'a ouvert les yeux sur pas mal de choses. Mais n'oublions pas le rôle du coach d'une équipe... j'ai bien dit coach, pas chef ;-) Son but est bien de faire grandir l'équipe, d'aider cette dernière à gagner en auto-organisation. Mais au delà de l'objectif commun de l'équipe, il y a les valeurs, les croyances et les motivations de chaquun des membre : sont-elles alors compatibles avec celles des autres membres? Sont-elle alignées?

L'équipe peut-elle décider?
Quel est la zone de contrôle de l'équipe? Quel est son pouvoir de décision? Quels sont les moyens mis à disposition de l'équipe? Dans Scrum ce n'est pas l'équipe qui décide du "quoi faire?", c'est plutôt le Product Owner. Néanmoins, c'est l'équipe qui est responsable du "comment faire?". Or, toute décision engage des moyens (réallocation de ressource, changement de méthode, etc...). Si une équipe n'a pas de tels moyens, peut-elle réellement décider?


Si l'une de ces conditions n'est pas remplie, peut-on encore espérer l'auto-organisation? J'avoue que ma vision du travail d'équipe est largement inspiré des Core Protocols. C'est que j'y trouve des principes simples, claires, pragmatiques et universels (enfin à quelques cultures près). Ca me parle le simple et le pragmatique! De votre coté, de décidez-vous pour laisser plus d'autonomie à vos équipes? Si vous êtes dans une équipe, êtes-vous aligné avec les objectifs de votre équipe?

Première formation CSM à Grenoble!

J'ai le plaisir de vous annoncer que François Beauregard viendra du Québec pour animer une formation Certifiante ScrumMaster dans notre belle région à Grenoble les 12 et 13 février prochains. Il s'agit de la première formation de ce type ouverte au public dans notre région. Les informations et l'inscription sont disponibles en ligne. La formation est co-organisée par la société Pyxis et l'association Club Agile Rhône-Alpes (CARA).

Groupe des Utilisateurs Français de Scrum

Je souhaite la bienvenue à cette toute nouvelle formation : le SUG-France (Scrum User Group en anglais dans le texte) dont la première rencontre se tiendra à Paris le 19 mars prochain en présence de Jeff Sutherland (l'un des pères fondateurs de Scrum). Le groupe herbergé sur meetup compte déjà plus d'une centaine d'inscrits! Les fondateurs du groupe envisagent de créer une association à but non lucratif, sorte de relais local en France de l'association internationale ScrumAlliance. Pour info, il existe de très nombreuses "antennes" de la ScrumAlliance à travers le monde.

"Etre Agile" ou "Faire de l'Agile" ?

Cette question revient souvent sur le tapis. Elle peut paraître dénuée d'intérêt de prime abord, mais je trouve qu'elle résume à merveille le bouleversement silencieux que peut représenter l'Agilité. Pour illustrer mes propos, j'en veux pour preuve les fondements du manifeste Agile; vous n'y trouverez aucune solution toute faite, pas de processus, pas d'outils non plus... vous y trouverez tout simplement des VALEURS.

Il est vrai toutefois que ces valeurs peuvent se décliner dans les différentes activités de l'entreprise qui développe du soft: pratiques d'ingénierie, gestion des tests, gestion de projets, analyse du besoin, etc.. il en résulte bien évidemment des outils, des méthodes (comme Scrum), des pratiques (comme celles d'eXtreme Programming) et bien d'autres choses, mais n'attendez pas de pouvoir simplement réutiliser clef en main ce qui marche ici pour l'implémenter là-bas. L'histoire des constructeurs automobiles américains copiant en vain les procédés de Toyota (approche Lean) montre que les richesses d'une entreprise sont parfois invisibles, trop subtiles pour être photographiées. Une culture, un état d'esprit, ça prend un certain temps pour se construire. Aussi, n'attendez pas des résultats immédiats, mais préparez vous à investir aujourd'hui pour demain.

L'Agilité est donc à mon sens plus un savoir-être qu'un savoir-faire. Ce savoir-être peut nécessiter une révolution des mœurs dans l'entreprise! Il faut s'attendre à pas mal de résistance dans les situations suivantes:

• les chefs de projets n'affectent plus les tâches quotidiennes des équipes
• les décisions d'architecture sont prises par les équipes
• les managers communiquent sur les comportements attendus et les valeurs au lieu du règlement et des procédures
• les équipes décident par elles-mêmes si une personne devrait être "sortie" du projet
• les évaluations individuelles s'appuient sur une évaluation par ses propres collaborateurs
• l'entreprise développe les motivations et les talents des collaborateurs
• les relations d'autorité sont remplacées par de la collaboration gagnant/gagnant
• toute l'information disponible de l'entreprise est accessible par tous
  

Cela vous parait-il ubuesque, démagogique, inapplicable? Ben, j'aime les débats qui pourraient survenir! Attention, je ne cherche pas à dire que l'Agilité est la panacée à tous les maux; je ne dis pas non plus que l'Agilité est meilleure qu'une autre démarche. Je veux juste mettre en garde sur ses conséquences sur l'entreprise, en terme de management, c'est à dire au niveau de la gestion des hommes. Ce management conscient des valeurs (qu'elles soient ou non celles de l'agile) offre - quand il existe l'avantage de pouvoir aligner les forces de l'entreprise dans un même effort.

Beaucoup de courants de pensée (en dehors du développement logiciel) alliant performance, humanisme et écologie m'incite à croire que la complexité grandissante de notre monde nous condamne à nous remettre en question un peu plus chaque jour ;-)

Agilité chez Orange

Hier, j'ai été invité à intervenir à un Webinaire interne à Orange Labs (ex France Telecom). L'objet du séminaire était d'introduire et d'expliquer l'agilité avec retours d'expérience à la clef. Il y avait 17 présents dans la salle et 60 en conférence web.

Je remercie Hervé Lourdin de m'avoir proposé d'animer avec lui sa présentation "Agile Démystifiée". Le principe de cette présentation est de faire participer le public en leur demandant de prioriser les questions qu'ils veulent poser, sachant que les animateurs auront une période de temps fixe pour y répondre. Le public devient ainsi le "product owner" (ou directeur de produit dans Scrum) et doit faire des choix pour rentabiliser au mieux le temps d'animation qu'il a à sa disposition. Marrant le vote à main levée dans la salle, complété par les votes par "chat" pour ceux qui étaient sur le net. Nous avions abordé les sujets suivants

• L'intégration continue
• Contrat au forfait ou en régie?
• Les outils pour faire de l'agile
• Spécification agile

Ensuite Thomas DONY a présenté son retour d'expérience sur un projet d'Orange Labs géré en Scrum depuis 1 an. Le bilan du projet est positif et il est question d'étendre l'expérience. Enfin, j'ai présenté mon retour d'expérience chez Varian après 3 ans de Scrum/XP, discours relativement proche de celui tenu par mon collègue Bruno Orsier à l'Agile Tour 2008 à Grenoble.

Le timing global de l'après-midi était assez serré, ne laissant pas beaucoup de place aux questions/réponses. Parmi les questions soulevées durant les retours d'expériences, j'ai pu relever :

• Comment puis-je faire de l'agilité sachant que j'ai des points de recontres très précis (contenu et date) avec mes fournisseurs?
• Puis-je introduire de l'agilité sur la partie "amont" seule (travail sur le backlog, avec des échelles de temps de l'ordre d'une release) ?
• Comment être agile dans un environnement où le top-management est plus "directif" que "participatif"?

Dommage que nous n'ayons pas pu faire un ROTI (return on time investment) afin de mesurer le degré de satisfaction du public, bien que j'ai su par la suite directement et indirectement que l'après-midi fut très appréciée!

Merci à Rémy et Pierre qui m'ont invité, ce fut un plaisir de contribuer à leur démarche pour faire connaître l'agilité au sein de leur grande société.

XP et Scrum depuis les Tranchées

Ce matin, j'ai deux raisons d'être content! La première c'est qu'il y a 10 cm de neige dehors (oui, je suis un grand enfant et j'aime la neige! même si j'ai mis 2 heure pour atteindre le bureau ce matin).

La seconde raison c'est le mail d'infoQ qui m'informe que le livre que nous avons traduit est disponible en ligne! Guillaume, Bruno, Christophe et moi-même avons travaillé dur durant les 6 derniers mois sur notre temps libre pour traduire le livre d'Henrik Kniberg intitulé "Scrum et XP depuis les tranchées". Depuis ce matin, il est à vous, gratuitement sur le site d'infoQ:

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

Il s'agit d'un ouvrage qui fait référence dans le domaine, une vrai mine d'or pour la mise en place pratique de l'agilité dans une entreprise!

Je remercie encore mes coéquipiers Bruno, Guillaume et Christophe pour leur disponibilité, leurs efforts, sachant que nous avons complètement opéré à distance sans jamais nous rencontrer. Techniquement, nous avons mis en place les outils suivants

* un backlog partagé sous forme de feuille de calcul (liste des tâches de traduction, relecture, vérifications, etc... qui? quand?)
* un dictionnaire partagé pour assurer une homogénéité de traduction des termes récurrents (comme Product Owner qui est devenu Directeur de produit)
* un wiki collaboratif pour s'échanger les morceaux du livre

Ce fut une expérience très enrichissante (maintenant je comprends mieux la gestion des sections et des entêtes dans MS Word ;-)

PNL (Partie 1) - Niveaux logiques

C'est en lisant le livre Les 3 types de coaching d'Alain Thiry que j'ai fait une première excursion dans la PNL (programmation neuro-linguistique). Il s'agit d'un petit (par la taille) livre qui explique certaines techniques de coaching en se basant sur des cas concrêts.

Quel rapport entre PNL et Agilité? Ben... pour moi, les méthodes agiles reposent sur des valeurs comme l'esprit d'équipe, une communication sincère, l'engagement... La PNL donnent des outils de communication qui peuvent aider les équipes, les coachs, les managers, les chefs d'entreprises à obtenir le meilleur d'eux-même. Alors pourquoi s'en priver?

Parmi les différents outils présentés dans ce livre, les niveaux logiques de Robert Dilts sont très utiles. Les niveaux logiques sont :

• Système : ce niveau correspond à notre système (le corps humain, notre "hardware").
• Identité : c'est le "software" qui nous définis comme une personne unique, un "software" qu'on ne pourra jamais modifier donc.
• Convictions : c'est l'ensemble ne nos croyances, nos valeurs... il est possible que nos convictions changent avec le temps ou selon les événements.
• Compétences : c'est notre "savoir faire", issu de nos apprentissages
• Comportement : c'est notre "savoir être", la façon dont on se comporte dans notre environment, dont on communique aussi.
• Environnement : c'est le milieu externe avec lequel on intéragit
  

Cette approche permet par exemple d'expliquer les 3 différents types de coaching :

• le coaching de compétence où l'objet est de travailler sur les niveaux compétences, comportement et environnement : par exemple, une personne peut apprendre une nouvelle façon de s'organiser, ou alors apprendre à utiliser un nouvel outil.
• le coaching de performance où la personne travaille sur l'alignement de ses convictions avec son identité (un principe primordial est que l'identité ne se modifie pas!). Grâce à ses alignement interne, la personne pourra s'épanouir, et donc "performer".
• le coaching stratégique (ou d'entreprise) s'opère à tous les niveaux : à la fois en travaillant sur la stratégie de l'organisation, sa structure, les rôles, les convictions des individus, etc... Le but est de réussir à aligner un maximum toutes ces entités afin d'optimiser la performance globale de l'organisation.
  

Une seconde utilisation de ces niveaux logiques permet d'analyser un problème... La plupart du temps, un problème est difficile à formuler... les différentes parties prenantes ne partagent pas la même vision du problème. Une première étape à sa résolution devrait être un débat (voire un consensus) sur la nature du problème : quel est son niveau logique? S'agit-il d'un problème d'environnement? De comportement? De compétence? Là encore, ne pas oublier que l'identité ne doit jamais être un problème (on doit accepter l'identité d'une personne ;-). Cette façon d'analyser un problème permet de dédramatiser, ou au moins, permet d'aborder les différents point de vue des parties prenantes.