Agile Gardener

Une équipe peut-elle vivre sans ScrumMaster 'officiel'?

L’été dernier j’ai rejoint un projet qui avait démarré 15 mois auparavant. L’équipe chargée du développement était répartie entre 3 sites (1 à Montréal, 2 à Bordeaux). Peu après mon arrivée, il y a eu réorganisation des équipes, et dans notre équipe, nous avons proposé de ne pas avoir de ScrumMaster ‘officiel’. La question suivante se posait donc pour nous :

Une équipe Scrum peut-elle vivre sans ScrumMaster ‘officiel’?

Je dois dire tout de suite que nous n’avons pas eu le loisir de pousser très loin l’expérimentation car le projet a été interrompu environ 6 semaines après la réorganisation. Nous avons tout de même travaillé avec ce modèle pendant 2 itérations¹.

Cette équipe était composée de 3 personnes. Deux étaient présentes depuis longtemps : depuis le début pour l’un et depuis 10 mois pour l’autre. Puis il y avait moi, nouveau sur le projet. Le coéquipier leader naturel travaillait depuis plusieurs mois sur le module dont nous avions la charge. Il y avait une bonne cohésion, nous étions à l’aise avec Scrum et nous nous sentions en contrôle!

Nous tenions notre mêlée quotidienne² sans difficultés. Nous allions à tour de rôle à la mêlée des mêlées³ — cette pratique était déjà en place  bien avant la réorganisation. Nous faisions la maintenance du carnet de produit⁴ régulièrement avec le propriétaire de produit⁵. Nous aidions tous à l’organisation de l’équipe, même si une très grosse partie du travail était réalisée par le leader de l’équipe.

Voici les avantages obtenus lors de ce projet

• Nous nous sentions vraiment autonomes. Nous organisions nous même nos rencontres importantes (mêlée quotidienne, maintenance du carnet de produit, réunion avec les intervenants extérieurs).
• Nous étions beaucoup plus responsables. Lorsque quelque chose allait de travers, nous ne pouvions pas dire :  «Le ScrumMaster ne fait pas son boulot ».
• Nous avions une bonne flexibilité, mais ce point relève petut-être du fait que nous n’étions que trois.
• Contrairement à ce que j’ai vu à maintes reprises, personne dans l’équipe n’était perçu comme ‘supérieur hiérarchique’.

Nous n’avons pas subi d’inconvénients, mais peut-être y en aurait-il eu à long terme.

Cependant je suis convaincu d’une chose : il y a un préalable. Cela peut fonctionner à la condition que l’équipe soit mature, tant sur le plan des personnes qui la compose que  sur le plan de la maîtrise des outils, du processus Scrum et de la communication. Je vous invite à lire, sur un thème similaire, le retour d’expérience d’Isabelle Therrien, où elle fait mention des dérives qui peuvent se produire. Dans les commentaires notamment, il est question de prendre du recul, ce qui n’est pas toujours simple quand on a la tête dans le code pour livrer de la valeur à longueur de journée.

Résumé en quelques lignes, le choix de ne pas avoir de ScrumMaster ‘officiel’ peut paraître rapide ou évident, mais tout ceci ne s’est pas décidé en un jour. De fait, même une fois en place, les questionnements suivants revenaient de façon récurrente dans nos conversations :

• S’il fait fonction de ScrumMaster, le leader doit-il prendre le titre et s’exposer?
• Ce rôle peut il être partagé, et dans ce cas, est-ce efficace?

Pour conclure, je dois dire que j’ai aimé cette expérience. Même si cela n’a pas duré bien longtemps, j’ai vu les prémices de quelque chose que je voulais vérifier depuis longtemps : « le rôle de ScrumMaster est un rôle temporaire, il a pour objectif de rendre son équipe capable de se passer de sa présence, et cela peut fonctionner ».

Avez-vous des retours d’expérience similaires à partager ?

Dans le cadre de la démarche “Caddy” ¹ nous avons récemment eu une discussion sur la transparence et le secret professionnel.

Cette discussion est issue de la propostion suivante : (je ne cite pas l’auteur car je ne lui ai pas encore demandé sa permession)

Est-ce qu’il serait possible d’avoir une zone accessible seulement par les “Caddys” dans Confluence afin de pouvoir partager certains cas vécus (bien sur les vrais noms ne seraient pas donné) ?

La discussion a vite porté sur le fait que cet espace pourrait être ouvert à tous (employés de Pyxis)

Voici alors ma première réponse :

Pour l’accès à tous, je suis partagé entre “tranparence” et “secret professionnel”.

La relation de confiance est basée sur le fait que cela reste entre “Caddy” et “Golfeur” et quand je vais demander un conseil à d’autre, j’en avise le “Golfeur”.
Même anonyme, si un “Caddy” pose un question sur un “Golfeur” (anonymisé) il ne faudra pas longtemps pour faire des rapprochements.

D’un autre côté la transparence apportera sans doute de l’aide précieuse de personnes extérieures à la communauté “Caddy” (soutient, idées, …)

mon point de vue partagé

Suite à cette réponse, d’autres échanges ont suivi évoquant le fait que le secret apporte crainte, doute et suspicion, et que les “Caddys” pourraient être vus comme une “élite” qui se partagent des informations auxquelles les autres n’ont pas accès.

Voici le point de vue que j’ai proposé par courriel :

Je reviens sur le point transparence.
Après rapide discussion avec un “Golfeur” (dont je ne suis pas le “Caddy”), je proposerais que l’on en parle aux “Golfeurs” avant de commencer à être full transparents.

Il y a des problématiques que j’ai eu à traiter dans les dernières semaines qu’en tant que “Golfeur” je n’apprécierais pas de voir évoquées (même de façon anonymes) en dehors d’un cercle de personnes dont c’est la responsabilité (tout pyxissien peut faire le choix d’être “Caddy”, il n’y a pas de “sélection” ou de “promotion”).
D’ailleurs lorsque j’ai parlé à d’autres “Caddys” pour de l’aide sur une problématique, j’en avais avisé le “Golfeur” avant et cela était avec son accord.
Le cadre des “Caddys” est pour moi une zone de confiance entre pairs. Je n’y mets aucun “élitisme” simplement lorsque je me place avec ma casquette de “Golfeur”, j’attends que mon “Caddy” agisse comme un coach, c’est à dire avec discrétion et qu’il aille prendre conseil auprès de pairs au besoin, mais pas de toute l’organisation. D’ailleurs, j’espère (comme “Golfeur”) qu’il échange des problématiques, et des techniques pour les traiter, avec ses pairs pour être plus efficace pour m’aider.

C’est un avis très personnel, mais ne confondons pas les processus et les humains. Les infos liées au processus doivent être visibles (pour moi il en reste encore à mettre en lumière mais c’est un autre sujet). Les infos humaines obtenues dans le cadre d’une relation “Caddy-Golfeur” sont pour moi hors de ce cadre. (il me semble que personne ne fait de rencontre “Caddy” au milieu de la cuisine)

Maintenant, si des “Caddys” sont d’avis contraire au mien, je l’accepte complètement, à titre personnel je ne souhaite pas adopter cette démarche (transparence anonymisée) et j’inviterai à demander l’avis des personnes intéressées (moi avec casquette de “Golfeur” par exemple ) avant d’aller plus loin.

D’ailleurs j’ai un gros travail personnel à faire avec ma casquette de “Caddy” pour être bien plus “discret” (pas au sens du secret suspicieux mais au sens de limiter le nombre/cercle de personnes mise au courant) lorsque je traite des situations difficiles mais aussi pour aller chercher du “brief/débrief” auprès de vous autres et limiter mon “expansion” au groupe de 20 personnes ou moins.

Une fois la période des fêtes passée et quelques jours de repos, je compte bien reprendre ma recherche de formation de coach pour approfondir mes connaissances à la fois “techniques” mais aussi approfondir les notions “d’éthiques”… Je pense que celai m’aidera aussi à mieux comprendre notre rôle, ses limites, les applications dans notre contexte, comme par exemple le sujet dont nous parlons.

Nous n’avons pas reparlé de ces échanges depuis, mais en relisant rapidement un livre sur le coaching je suis convaincu que nous devrons aborder prochainement les notions d’éthique lorsque l’on adopte la posture de coach, notamment dans le cadre d’une relation de coaching entre collègues de travail.

Avez-vous des retours d’expérience, des réflexions à partager sur le sujet de l’éthique dans la relation de coaching ? Quelles sont pour vous les limites du secret professionnel ?

Tableau Kanban de l'équipe "production" (première version)

Depuis quelques semaines j’ai le plaisir d’accompagner une équipe dans son adoption d’une gestion de projet en mode Agile. C’est un mandat passionnant sur plusieurs aspects :

• La motivation et l’envie de l’équipe, qui se traduit par un engagement de tous.
• L’utilisation en parallèle de Scrum et de Kanban qui rend mon intervention en tant que coach intense et très riche.

L’équipe est divisée en deux “sous-équipes” qui ont des rôles et des activités bien différentes : L’une s’occupe du volet production (newsletters, mini-sites, mises à jour de l’existant etc.) et l’autre du volet développement des nouvelles fonctionnalités pour le site Internet.

Suite à nos préconisations, chacune des équipes a choisi d’adopter l’outil qui lui semblait le mieux adapté à ses contraintes : Kanban pour l’équipe production et Scrum pour l’équipe de développement. (Ce n’est d’ailleurs pas le modèle que nous avions proposé en premier lieu)

Au cours de la première itération (l’équipe a choisi des itérations de 2 semaines), en regardant le tableau Scrum de ses collègues, un des membres de l’équipe de production (fonctionnant en Kanban) m’a dit : “Notre tableau ne se vide jamais, ça c’est correct, mais notre colonne “Done” n’est jamais pleine, ça me manque, ça donne l’impression qu’on travaille moins.”

En effet, le tableau Kanban reflétant un flux continu ne se vide jamais comparé au tableau Scrum qui a un cycle de vie de 2 semaines. De plus, l’équipe production vide la colonne “Done” lors  de la mêlée quotidienne après avoir passé en revue les items terminés.

Pour changer cette perception, l’équipe à décider de laisser toutes les tâches à “Done” sur le tableau entre chaque rétropective qui se déroule toutes les 2 semaine . En plus de se donner de la visibilité sur le travail accompli, l’équipe compte utiliser cette pratique pour mesurer plusieurs éléments :

• Les cartes sont-elles remplies correctements : date de début, date de fin, client, identifiant de la tâche, etc.
• Le nombre de cartes “urgence”  par 2 semaines.
• Le temps de sortie moyen par taille d’items.

Votre équipe Kanban a-t-elle déjà eu ce besoin de voir son accomplissement dans le temps ? Qu’avez-vous mis en oeuvre pour cela ?

Meilleurs voeux pour l'année 2010

Une année 2009 très belle et bien remplie s’est refermée.

2010 est maintenant entamée alors je vous souhaite à toutes et à tous une très bonne année 2010.

Je souhaite qu’elle vous apporte beaucoup de beaux projets Agiles, de grands moments de plaisir, des équipes joyeuses, perfomantes et motivées.

Et surtout profitez de vos proches, adoptez un rythme soutenable et faites du sport

• Happy new year ! Think big … and … make it real !!! Family, love, health, life, projects. #

Powered by Twitter Tools