Pyxis

Dans un article intitulé 2010 Trends in Project Management, deux d’entre elles ont particulièrement attiré mon attention :

Trend 1 – Enterprises continue to look for Efficiencies in Process & Technology
(…)
Companies will continue to look for ways to become more efficient and save money in both the short & long run. They will do this by re-evaluating their processes and technology. Lean Thinking will take precedence in influencing how this happens.
(…)
Trend 2 – Agile and Lean Processes are overtaking Waterfall
With the need to do more with less, the demand by executives for “predictability” in projects and customers needing valuable deliverables produced quicker – Agile and Lean processes will become much more the norm rather than the exception in projects during 2010.
(…)
Companies are already trying to transition to Agile, but when we look under the covers we see they are really just doing waterfall in short iterations. So without proper training on how to do this transition, a concern will continue to grow regarding project managers’ ability to deal with a new Agile world.
(…)
The need for Agile and Lean coaching will be in more demand as well. By companies bringing “experts” in to teach, model and coach teams in the use of Agile and Lean practices that work “for them” – since every environment is different – one size doesn’t always fit all. This will catapult company’s transition to Agile.

Aucun doute, l’Agilité est maintenant un mouvement de masse! Il est temps pour les entreprises d’attraper le train, et de bien se faire accompagner.

De notre côté, nous sommes loin du temps où il fallait prêcher dans le désert sur les vertus des équipes auto-gérées et de l’importance de la gestion par valeur d’affaires! Il est temps plus que jamais de contribuer à ces transitions et d’en faire des succès.

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?

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 :

• Sur le site du gouvernement du Québec
• Sur le site de la CDR Montréal-Laval

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…

Found in Michele Sliger and Stacia Broderick’s book, The Software Project Manager’s Bridge to Agility, some “unspoken reasons” behind the spoken ones heard so many times…

• I’m afraid of change
• I’m afraid I will have nothing to do
• I’m afraid I will lose my job
• I’m afraid people will see how little actually I really do
• I’m afraid I won’t be able to keep up
• I’m afraid I won’t be able to learn the new software
• I’m afraid this will mean hard work
• I’m afraid I’ll be fired if the decisions we make don’t work out
• I’m afraid I won’t get raises or promotions anymore
• I’m afraid of conflict and trying to reach consensus
• Nuts! There go my three-hour lunches
• Nuts! That means I can’t mosey in at 10:30 anymore
• Nuts! That means I’ll have to really think now
• Nuts! That means I’ll actually have to talk to people now
• It’s just so much easier and safer when someone else tells me exactly what to do
• It’s just so much easier and safer when I can tell them exactly what I want them to do

Do you have more of them? What were yours the first time you heard about Agile?
What do you do when you know people have these reasons in mind?

At Pyxis, we at least make sur people feel secure to make errors and learn from them, and we try to reproduce it in our consulting mandates. That is necessary but not sufficient. I think the best thing to do is to make sure the motivation and the fun to work wins the battle against all these unspoken reasons…

At least, we can be sure that the real winners will be everyone else in the team and in the management, the moment these people either change their mind or leave!

Voici un article qui concerne notre “sujet de l’heure” à Pyxis, la maturité : Agility at Scale: Become as Agile as You Can Be. Par Scott W. Ambler lui-même, produit par IBM.

Dans cet article, le focus est sur la complexité des processus nécessaires pour répondre à des besoins divers en terme de taille de projet, distribution, risque, de niveau de gouvernance, et 4 autres critères. Au final, on n’y parle pas beaucoup de maturité de processus, mais plutôt de contextes d’application : “However, whereas the goal of the CMMI is to provide a framework for software process improvement, the goal of the Agile Process Maturity Model (APMM) is much more modest — it merely strives to define a framework that can be used to put the myriad agile processes into context.”

Les 3 niveaux de “maturité” sont définis selon les besoins du projet. Est-ce que le niveau de complexité du projet (calculé par 8 critères) exige qu’on couvre le développement logiciel, ou la durée de vie complète d’un projet, ou même la gestion de l’entreprise dans son ensemble?

1. Niveau 1? Utilisez Scrum, XP et/ou Agile Modeling
2. Niveau 2? Utilisez RUP, OpenUP, DSDM ( warning : “[RUP] can be instantiated anywhere from a very agile form to a very traditional form as your situation warrants”)
3. Niveau 3? Explorez RUP, EUP!!!

Je me pose évidemment plusieurs questions. Clairement, je ne vois pas de modèle de mesure de maturité d’une équipe, ni même d’une implémentation de processus, mais bien un support pour faire un choix de méthode pour une situation X. Avez-vous vu d’autres modèles de maturité des processus Agiles? À quelles questions devrait répondre un tel modèle?

De mon côté, j’aimerais bien savoir comment détecter le niveau de maturité d’une équipe pour savoir le niveau d’auto-organisation auquel je dois m’attendre de leur part, le niveau de gouvernance nécessaire au projet, le nombre d’experts (coachs agiles, coachs techniques, architectes) à qui je dois avoir recours pour leur venir en aide. Dans le cadre d’une transition, j’aimerais savoir à quel point il faut être directif, à quel point il faut les bousculer dans leur confort. Mais c’est évidemment en dehors de la portée de ce modèle. C’est même complètement autre chose.

Le mot “maturité” est-il trop général? De quoi ai-je besoin?

Il y a 2 listes synthèse intéressantes qui méritent également un regard à cet article :

• Pour savoir “si une équipe est agile”, Scott propose ses 5 critères. Peut-être les avez-vous déjà vu quelque part?
• Les 5 stratégies à appliquer pour accroître vos chances d’avoir du succès dans l’amélioration de votre processus.

Aujourd’hui, grosse journée avec des sessions dès 9h. Et je vous rassure, le titre ne fait pas référence à la bière que j’ai bue ce soir à la soirée francophone

La journée a très bien commencé avec une session sur le leadership par Mme Leadership en personne : Pollyanna Pixton. La présentation s’appelait “Stepping Up and Stepping Back: The Leadership Tipping Point” et c’est le 3e module sur 4 d’une formation sur le leadership conçue à la base pour IBM.

Elle a sa façon à elle de présenter le leadership : “Step back and let them do their job!”. Elle insiste énormément sur l’importance de faire confiance à tous nos collègues: “Si vous ne leur faites pas confiance, ils le savent!”, “Suspicion is a permanent condition”. Elle soutient que les vrais leaders ne prennent jamais de décision. Surtout quand ils sont haut dans la hiérarchie…

Elle nous a même fait faire un exercice intéressant. Nous avons discuté pendant quelques minutes avec notre voisin de table. L’un d’entre nous était un “worker bee” et l’autre le “leader”. Le worker exposait un problème, et le leader NE DEVAIT ABSOLUMENT PAS DONNER DE SOLUTION. Ça me rappelle beaucoup ce qu’on a vu en formation de coaching et ce qu’on doit faire comme caddy. J’ai réussi à me taire, mais j’ai de nouveau réalisé à quel point c’est difficile! La conversation est allée dans le bon sens lorsque j’ai demandé à mon interlocuteur de me dire la raison pourquoi il pensait que j’étais mieux placé que lui pour prendre cette décision.

En bonus, j’ai appris l’existence d’un bouquin qu’elle a trouvé très inspirant : The Seven Day Week-end. Le bouquin parle d’une compagnie brésilienne, Semco, qui ressemble étrangement à Pyxis… Les sceptiques seront confondus! Qui disait qu’on ne pourrait pas scaler?

Imagine a company where employees set their own hours; where there are no offices, no job titles, no business plans; where employees get to endorse or veto any new venture; where kids are encouraged to run the halls; and where the CEO lets other people make nearly all the decisions. This company—Semco—actually exists, and despite a seeming recipe for chaos, its revenues have grown from $35 million to $160 million in the last six years. It has virtually no staff turnover, and there are no signs that its growth will stop any time soon.

En sortant de ce meeting, en se retrouvant tous les 3, on a discuté de ce qu’on avait entendu dans nos sessions. Il est intéressant de voir comment des interprétations à première vue opposées se révèlent être des aspects d’une même réalité, vus d’angles différents, et tout à fait complémentaires au final. Je ne vous en dis pas plus, on va sûrement produire quelque chose là-dessus…

Malheureusement, j’ai suivi son conseil d’aller au deuxième module qu’elle présentait en après-midi. Or, ce n’était pas la meilleure idée, car beaucoup de matériel se répétait. Normal, c’étaient 2 sessions différentes, pas une session de 180 minutes!

Bon, je vais me coucher. Je vais vérifier quelques fois mon cadran, car demain matin ne serait pas un bon moment pour ne pas me réveiller :p

Aujourd’hui j’ai assisté à 5 sessions et j’ai marché un peu dans Chicago. L’heure de notre présentation s’en vient (jeudi matin) et je commence à être nerveuse, mais je me dis que c’est une bonne chose que j’assiste à autant de présentations, ça me permet d’enrichir le nôtre!

Alors aujourd’hui, j’ai assisté à :

• Keynote: par Alistair Cockburn. Bon orateur, évidemment… Si j’ai bien compris, il a dit qu’il y avait à peine 5 compagnies au monde qui arrivaient à exprimer les besoins des clients sous la forme de spécifications exécutables? Ai-je mal compris? Aussi, c’est le premier que j’entends soulever des craintes par rapport à la monotonie des processus continus à la Kanban…
• Pragmatically “Crossing the Chasm” from Project-level to Enterprise Adoption : Celle-là a viré, croyez-le ou non, en discussion sur l’efficacité des meetings! Le modèle qu’il propose pour les transitions Agiles est inspirant, ça permet de structurer facilement une roadmap avec un client.
• ScrumMasters Considered Harmful – Where Did It Go Wrong? : déception ici… J’aime bien sa liste de “symptômes” qui révèlent les ScrumMasters nuisibles. Il soutient avec raisons que les ScrumMasters sont souvent mal choisis et ne connaissent pas bien leur rôle.
• Can you hear me now? Good… : sur les outils utilisés dans les projets distribués. Très bon contenu, enfin une présentation concrète! Ça manquait, sur ce stage…

…et un “talk” surprenant d’un des Vendors : “Fixed-Price Contracts in Agile Development” (par des gars de Danube). Pourquoi surprenant? Parce que les commanditaires, en général, profitent de cette demi-heure pour vanter leur produit, pas pour discuter d’un sujet X. Mais aussi, car il est surprenant qu’il ait réussi à nous communiquer une présentation qu’il donne habituellement en une heure en 20 minutes, coincées entre UrbanTurtle et les sessions d’après-midi, dans un bruit épouvantable de chocs d’assiettes et des échos des autres discussions l’entourant.

Mais vous savez quoi? Sa réponse à lui c’est d’utiliser les Function Points de COSMIC pour définir une entente dans le contrat. Je pourrai vous en parler davantage quand j’aurai digéré ses slides, ce midi je n’ai pu que les survoler. Mais c’est intéressant, ça nous permettra de pousser notre réflexion sur ce sujet déjà.

Pour les intéressés à voir le résultat de ma marche dans Chicago, une ville extrêmement propre et sécuritaire (et on comprend pourquoi quand on entend parler des lois qui la régissent!), mes photos sont ici : IsaAtPyxis

Vous saviez qu’il y a une “Agile Lawyers Association“?
La citation de la journée : “Kick people out of the SHU box!” ~A. Cockburn.

C’est un débat qui semble être éternel dans la communauté Scrum, car comme beaucoup de choses, il n’y a pas d’indications claires à ce sujet dans les bouquins. Et c’est tant mieux, c’est ce qui fait de Scrum une méthode flexible et adaptable à chaque réalité. Dans chaque projet, il est possible de déterminer ce sur quoi on met des points, et donc ce sur quoi on calcule la vélocité.

Je vous annonce d’ores et déjà que je n’ai pas de réponse à cette question, j’ai surtout des questions et je viens chercher ici votre avis sur la chose.

Dans mon projet actuel, qui est distribué, nous utilisons Jira et GreenHopper et nous avons plusieurs types d’items au backlog.

• Nous avons des Epic, des User Story et des Anti-Story, qui nous permettent d’exprimer les besoins des clients, les fonctionnalités qui apportent de la valeur d’affaires.
• Nous avons des Task et des Bug qui nous permettent de répertorier les tâches qui n’apportent pas une valeur directe au client mais qui sont nécessaires au projet : le développement d’outils pour les développeurs, l’installation de frameworks et d’outils externes, l’accumulation de la dette technique et les défauts (qui viennent de fonctionnalités non terminées ou de régression causée par des nouvelles fonctionnalités).
• Nous avons des Spike : du boulot de recherche timeboxé qui vise à atteindre un ou plusieurs de ces buts :
  1. débroussailler vaguement un sujet
  2. estimer une (ou des) stories, découper une épique
  3. réduire le risque
  4. faire un choix de technologie

Les User Story Points servent à mesurer la complexité relative des tâches attribuées aux développeurs. C’est un excellent moyen pour eux d’informer le Propriétaire de produit (Product Owner ) de la complexité des items sur lesquels ils vont travailler afin de les aider à prioriser leurs demandes. Ça permet ensuite de connaître la capacité d’une équipe (sa vélocité en points par sprint) et de planifier la quantité de boulot qu’on peut abattre à chaque sprint.

Les User Story Points ne sont PAS une mesure de la valeur d’affaires. Et ce n’est PAS un outil utilisable pour contractualiser une relation d’affaires ni un outil de reporting. Cela dit, passons au débat.

En ce moment, nous n’estimons que les Epics, User Story et Anti-Story en points. Le reste est estimé en heures. Mais on se pose la question : (1)pourquoi ne pas mettre des points sur tout? Après tout, le besoin est le même, quelque soit le type de tâche, on veut en estimer la complexité relative et permettre au Propriétaire de produit de faire un choix éclairé. Par contre, nous pensons que ce n’est pas pertinent d’estimer en points des Bugs. Nous sommes d’accord que ce n’est pas très utile dans ce cas, car les Bugs sont toujours notre première priorité, et que peu importe le temps qu’on y passera, il faudra bien se rendre au bout…

Ensuite, quand vient le temps de se poser la question du calcul de la vélocité, on se dit que ce serait dommage de priver le Propriétaire de produit de sa “vélocité fonctionnelle”. Comme le projet est en cours depuis 1 an et demi déjà, nous ne voulons surtout pas embrouiller ses statistiques. Alors nous avons pensé au concept de “vélocité technique”, qui nous permet de bien séparer ce qui apporte de la valeur d’affaires de qui n’en apporte pas directement. (Comme dit David, un de mes collègues sur le projet, la dette technique n’est pas une valeur ajoutée, mais plutôt du service après vente sur un produit à moitié défectueux). (2) Qu’est-ce que vous en dites?

Nous ne savons trop que faire à propos des Spikes et ici, nous avons (3) besoin d’avis externes et d’arguments.

1. Option 1 : on met des points et ça compte comme vélocité fonctionnelle. Après tout, ça permet de réduire le risque, et c’est la première étape d’une épique. Et ça a de la valeur pour le client.
2. Option 2 : on ne met pas de points sur les Spikes. C’est inutile, on a déjà une timebox pour ça.
3. Option 3 : on met des points et ça compte comme vélocité anticipation. Un nouveau type de vélocité… compromis…

Dernière question : (4) Quel est selon vous l’impact de ces choix sur la motivation des développeurs de l’équipe? celle du PO?

Jeudi le 19 février dernier, nous étions 10 pyxissiens au Gala du Mérite Coopératif 2008. 5 prix ont été décernés. La Coopérative de travailleurs actionnaire (CTA) de Pyxis était finaliste dans la catégorie « Relève coopérative 2008 ». Cette catégorie est ouverte aux coopératives qui ont été crées dans les 5 dernières années. Comme nous vous l’avions dit, il est très rare que des CTA soient finalistes dans cette catégorie.

Nous n’avons pas gagné.

FibrEthik a gagné. Ils le méritent d’ailleurs amplement. Autant que Touski, une coop-bistro qui a gagné dans la catégorie « Coopérative de l’année 2008 ». Les défis qu’ils ont rencontrés et qu’ils ont surmontés, leur contribution sociale unique, tout ça est tout à leur honneur.

Tout de même, ça me rend triste pour une seule raison : je n’ai pas pu parler de Pyxis, de nos valeurs, et je n’ai pu parler de ma fierté d’en faire partie devant les 500 personnes réunies pour l’événement. Alors j’ai envie de vous écrire ce que je n’ai pas pu dire au gala. Alors voici:

Merci à François Beauregard pour ses valeurs, sa vision et son travail acharné à faire de Pyxis ce qu’il est : une place où il fait si bon travailler. Merci à André Brissette pour cette idée brillante d’implanter une CTA au sein de Pyxis. Merci à Marc-André Thibodeau, Marie-Ève Trempe, Marion Gilbert et Christian Lapointe pour le travail bénévole et pour le courage d’avoir fait partie de ça dès le début. Merci à la CDR Montréal-Laval de nous avoir appuyés dans la démarche : en particulier à Armand Lajeunesse, Nada Elkouzi et Chantal Jolicoeur.

À Pyxis, avoir une Coopérative de travailleurs actionnaire était tout simplement une étape logique dans notre évolution : la responsabilisation de chacun, la gestion décentralisée et le partage des richesses correspondent au modèle coopératif.

En ce moment, le message que nous envoyons est extrêmement fort : en groupe, nous faisons avancer Pyxis! Nous sommes un partenaire financier de premier ordre pour Pyxis. D’une part, nous avons la possibilité d’investir dans l’entreprise que nous connaissons le mieux, celle qui nous fait vibrer : la nôtre. Mais aussi (et surtout), nous avons le pouvoir d’en faire ce que nous voulons par nos actions au quotidien.

À l’heure où on se questionne sur les modèles économiques partout dans le monde, parlons de coopération à toutes les entreprises qui pourraient en bénéficier! C’est une façon magnifique d’allier les valeurs sociales économiques pour vivre dans un monde plus humain. Les entreprises se cherchent des façons originales de récompenser leurs employés, de les retenir à long terme, de les fidéliser. Les valeurs coopératives peuvent apporter tout ça, et même plus, à condition d’en faire une vraie philosophie, une vraie vision.

C’est que nous réussissons à Pyxis.

Et je suis très fière d’en faire partie. Bravo à nous tous!