janvier 2010Monthly :

Être ScrumMaster dans une équipe sans ScrumMaster

Si une équipe vous dit qu’elle n’a pas besoin de ScrumMaster, que faites-vous?
Comme ScrumMaster, vous êtes-vous déjà senti comme le(la) secrétaire de service?

Il y a 2 mois, nous étions 4 membres dans cette nouvelle équipe qui venait d’être créée. Le propriétaire du produit (Product Owner, PO), en collaboration avec les membres de l’équipe, avait imaginé ce nouveau modèle d’équipe : plutôt qu’avoir 4 équipes de 3-4 personnes souvent bien débordées par leurs tâches connexes (support aux usagers et coaching dans les autres équipes) et par conséquent disponibles à 80%, 60%, voire même 40% du temps, nous constituons maintenant une équipe « noyau » formée de 4-6 personnes dédiées à 100% à accomplir les objectifs des sprints.

Le PO pensait que je serais naturellement la ScrumMaster de cette équipe. Mais la première journée, alors qu’on révisait ensemble la charte de projet, j’ai eu la surprise d’entendre mes collègues dire qu’ils « n’avaient pas besoin » de ScrumMaster car les « obstacles » envisagés pourraient être gérés par le PO. Classique, me suis-je dit : mauvaise compréhension du rôle de ScrumMaster… Nous verrons bien! Tentons le coup!

Sur ce, après m’être occupée de planifier les cérémonies de ce premier sprint (parce qu’il fallait bien que quelqu’un le fasse), je suis partie en vacances 2 semaines.

Pendant ces 2 semaines, il y a eu un premier Sprint Review (c’était dans leurs habitudes), pas de rétrospective, et 2 ou 3 dailys en retard. C’était à prévoir, évidemment, mais quand même, personne n’a mentionné qu’on avait besoin d’un ScrumMaster.

J’ai joué mon rôle d’équipière de bonne volonté à partir de ce moment. J’ai immédiatement corrigé le tir au niveau des meetings : nous avons tenu une rétrospective, j’ai insisté sur l’importance des dailys, je me suis assurée que l’heure était adéquate pour que tout le monde y soit à tous les matins. J’ai sensibilisé l’équipe à l’importance de refuser les changements demandés par le PO en cours de sprint. J’ai rendu visible nos obstacles et notre avancement.

Après tout cela, vous allez me dire « mais évidemment, Isa, tu ne t’arranges pas pour qu’ils en aient besoin! Tu fais tout ce qu’il faut pour que ça fonctionne! ». En fait, c’est l’objectif… non? Avoir un ScrumMaster ne devrait jamais être une finalité.

Jusque là tout allait relativement rondement, puis aujourd’hui, en meeting, j’ai entendu ceci : « Il me semble que j’aurais besoin d’un ScrumMaster »… Mais vous savez pourquoi? C’était pour recopier des stories d’un White Board à notre outil de gestion de projet. À cela, j’ai évidemment répondu qu’on n’avait pas de ScrumMaster dans l’équipe, et qu’il fallait donc que quelqu’un s’en occupe. Ce qu’ils ont fait avec plaisir.

Puis j’ai réfléchi : et si le fait de ne pas avoir de ScrumMaster nous permettait, justement, de nous aider à s’auto-organiser plus rapidement? Je me questionne, peut-être le PO (qui est bien sensible aux valeurs de l’Agilité et en comprend les principes) prend moins de libertés sur le périmètre du sprint, sachant qu’il n’y a personne pour l’empêcher de le faire? L’équipe apprendra-t-elle plus rapidement à régler ses conflits sans arbitre? À interrompre les conversations improductives?

C’est à suivre…

Je ne vous ai toujours pas dit ce qu’on y fait, dans cette équipe. C’est une équipe qui produit de la documentation. Nous sommes responsables de bâtir la documentation de référence pour les projets Agiles qui seront entamés à partir du mois de mars prochain, et nous nous basons sur les leçons apprises des projets Agiles du passé. Intéressant, non?

Truc podcast 1 – Les bébelles, ça fait du bruit!

Lors du premier podcast de VoxAgile, j’ai réalisé quelque chose : le tripotage de bébelles, ça fait du bruit.

En effet, nous avions laissé un verre et des crayons sur la table où nous faisions l’enregistrement.

Le premier réflexe des personnes autour de la table a été de prendre les crayons ou le verre.
Ils ont joué avec ces bébelles, ce qui faisait des bruits de tapotage et de frottement.

Donc, le premier ‘truc podcast’ c’est :

Enlever les bébelles pour empêcher le tripotage et, par le fait même, les bruits parasites.

La CTA de Pyxis en vedette dans la revue annuelle COOPOINT 2010

L’édition 2010 de la revue COOPOINT, publiée annuellement par les Coopératives de développement régional québécoises, contient une pleine page sur la CTA de Pyxis Technologies. L’article, intitulé “Une étape logique dans l’évolution”, est le résultat d’une entrevue avec le président fondateur de Pyxis, François Beauregard, et André Brissette, le premier à avoir évoqué l’idée chez nous.

[L'idée] d’implanter une coopérative de travailleurs actionnaire l’a remporté grâce à son caractère inclusif et à ses valeurs de démocratie, d’équité et de solidarité.

Après un court résumé de l’histoire de Pyxis, l’article raconte la genèse de l’implantation de la CTA et son impact positif sur le développement de l’entreprise.

[...] la CTA ne doit pas être une action isolée, mais faire partie d’un ensemble cohérent d’actions et de mesures. La responsabilisation de tous les employés et leur adhésion à la mission de l’entreprise sont quelques-unes des conséquences positives.

Pour plus d’information sur les CTA, communiquez avec nous, avec la CDR Montréal-Laval, ou encore consultez les liens suivants :

Les employés membres de la CTA sont maintenant propriétaires à 30%

Depuis le 15 décembre dernier, nous sommes maintenant collectivement actionnaires à 30% de Pyxis. Nous avons en effet exercé l’option que nous avions négocié il y a deux ans pour acheter un 5% supplémentaire d’actions votantes.

Nous sommes en pleine réflexion en ce moment sur les impacts d’être actionnaires de notre compagnie. Nous avons déjà plusieurs réponses, et d’ailleurs Tremeur s’est déjà exprimé publiquement sur le sujet. Qu’est-ce que les employés passionnés d’une entreprise apportent de plus qu’un investisseur externe ou qu’un propriétaire unique? Quels sont les risques de diluer la responsabilité de la propriété à plusieurs?

Je vous lance la question… ;)

Top 10 Agile events of the decade

topten

Top 10 Agile events of the decade

1- Creation of the Manifesto for Agile Software Development in 2001

2- Kent Beck re-exposes Test Driven Development in 2003

3- First Agile Conference in 2003, held in Salt Lake City

4- Ken Schwaber releases Agile Project Management with Scrum in 2004

5- Mike Cohn releases Agile Estimating and Planning in 2005

6- Esther Derby and Diana Larsen release Agile Retrospectives in 2006

7- In 2007, some of the highly regulated avionics companies start adopting Scrum

8- The Software Engineering Institute, creators of CMMI, recognizes Agile and Scrum in 2008 (http://www.sei.cmu.edu/reports/08tn003.pdf)

9- The Project Management Institute (PMI) actively participates at Agile 2009 in Chicago and formally launches the PMI Agile community

10- In 2009, some ISO 13485 compliant medical device companies start adopting Scrum

But I must cheat just a bit and add: Kent Beck’s Extreme Programming Explained published in 1999.

Share/Bookmark