Les pièges de la transition de chargé de projets à « Scrum Master ».

Avons-nous raison de croire que dans un mode Scrum, les chargés de projet deviendront des Scrum Master?

Dans les dernières années, beaucoup d’entreprises ont entrepris un virage Agile. De celles-ci, un très large pourcentage a fait le choix de faire une transition de leurs chargés de projet (CP) vers un rôle de Scrum Master.

Bien qu’il puisse y avoir différentes raisons pouvant motiver ce choix, il faut se poser la question suivante; est-ce par le fruit d’un avis concerté que la grande majorité emboite le pas de cette façon, ou si c’est plutôt par l’incompréhension du mode de réalisation?

Du point de vue des attentes que l’on peut avoir à l’égard d’un CP ou d’un Scrum Master, il y a des différences idéologiques importantes.

Voici quelques-uns des pièges engendrés de la distance entre les deux approches :

  • Organisation du travail

Les réflexes de chargé de projet ne se perdent pas du jour au lendemain. Un bon leader avec une approche agile doit en être un au service de l’équipe, et aider cette dernière à grandir et devenir autonome, contrairement à un leader plus directif en mode traditionnel. Un Scrum Master contrôlant peut nuire à l’évolution de l’équipe.

  • Gestion des livrables

Un aspect pouvant être difficile à accepter pour un CP est que dans le mode Scrum, c’est le Product Owner et l’équipe de réalisation qui ont la responsabilité d’ordonnancer les besoins dans le carnet de produit. L’équipe de réalisation, de par ses compétences, participe activement et conseille le propriétaire de produit. Mais c’est celui-ci qui connait le mieux les besoins et qui tranche lorsque nécessaire.

Comme le profil de la personne déterminera la longueur du chemin à parcourir avant d’assumer pleinement ses nouvelles responsabilités, il faut s’intéresser aux compétences individuelles. Plus précisément le savoir-faire, et surtout, le savoir-être. La bonne compréhension des trois rôles de l’équipe Scrum est essentielle avant de faire de tout CP un Scrum Master.

Cela dit, pour ce qui est de la formation d’équipes Scrums, gardons en tête que le rôle de Scrum Master n’est pas l’unique option qui s’offre à nous. Ainsi, on peut envisager qu’un CP puisse devenir un bon Product Owner. Après tout, ceux-ci ne sont-ils pas, à leur manière, responsables de la portée d’un projet?

Au-delà du purisme, il n’y a pas de raison pour que toutes équipes opèrent en mode Scrum ou tout autre mode de l’approche Agile. Les chargés de projet ont encore une place dans nos entreprises en effectuant des redditions de comptes plus traditionnelles et certains feront le choix de demeurer dans leurs fonctions.

Ceci est le texte intégral qui a été publié sur le blogue d’Agile Québec.

Toute reproduction, en tout ou en partie, sous quelque forme que ce soit, est interdite sans l’autorisation préalable de l’auteur.

Tendances agiles 2020

Au moment où cet article est écrit, la douzième édition de l’Agile Tour de la communauté Agile Québec vient à peine de se terminer. Le contexte l’obligeant, l’édition de cette année fut toute virtuelle. L’Agile Tour Montréal ne fera pas exception à la règle en nous offrant 5 jours de formations, de conférences et d’ateliers du 17 au 21 novembre.

En s’attardant à la programmation des 2 événements, on remarque que deux sujets semblent marquer la tendance :

Agilité à l’échelle

Déjà très populaire en 2019, l’agilité à l’échelle demeure une tendance forte cette année. Les retours d’expériences concernant l’implantation de frameworks d’agilité à l’échelle se multiplient.

Comme l’agilité à l’échelle a été popularisée dans les dernières années, plusieurs méthodes ont vu le jour. Ces nouveaux cadres de travail d’agilité organisationnel n’ont toutefois pas une portée identique.

Si l’on prend, par exemple, le cas de Nexus, développé par Scrum.org, on constate que l’essence du cadre méthodologique Scrum est conservée, mais que l’on amène une dimension Scaled Agile dans la gestion des arrimages et des dépendances.

Du côté de SAFe, nous avons une méthode agile beaucoup plus complète et prescriptive. Celle-ci ne vise pas seulement à améliorer la coordination de différentes équipes vers un objectif commun, mais inclut les gestionnaires de tout niveau hiérarchique dans l’alignement de la livraison de valeur d’affaires.

Peu importe que ce soit une agilité à petite, moyenne ou grande échelle, la communauté agile semble unanime sur le fait qu’une transformation organisationnelle ne peut complètement s’effectuer sans que l’agilité eût été implantée à tous les niveaux de l’organisation.

DevOps

Le DevOps est un mindset basant ses pratiques sur plusieurs approches agiles. L’origine du mot DevOps vient de la concaténation du mot développement et opération.

Dans cette perspective, le développement se réfère à une équipe qui développe, fait évoluer un produit, génère la documentation technique, etc. Dans un cadre plus classique, nous pouvons attribuer ce rôle à une équipe projet.

De son côté, l’équipe d’exploitation (operation) a pour rôle de gérer le quotidien de la solution en supportant les utilisateurs, en réglant les incidents, etc. Selon un modèle ITIL de gestion de services TI, les opérations se positionneront en support niveau 2.

Cela dit, lorsqu’un produit est maintenu par différentes équipes, une scission est parfois apparente. De celle-ci, des frustrations, enjeux de productivité et autres problèmes peuvent survenir. Le DevOps, comme son nom l’indique favorise le rapprochement du « Dev » et « Ops » pour adresser les problèmes ci-dessus mentionnés.

L’équipe avec une approche DevOps, pourra se donner divers moyens techniques pour augmenter l’intégration et la livraison en continu. L’automatisation de pipelines de déploiement est une façon souvent privilégiée. Peu importe l’approche favorisée, si des indicateurs tels que le leadtime, la fréquence de déploiement, etc. tendent vers une hausse, l’équipe doit rapidement intervenir et ajuster le tir.

Ce que nous réserve le futur…

Au sujet de l’agilité à l’échelle, nous faisons définitivement des pas dans le bon sens. Cependant, à la vitesse où les équipes deviennent agiles, je ne crois pas que ce soit demain la veille ou la majorité des organisations auront une gestion agile. En ce sens, nous entendrons encore certes parler d’agilité à l’échelle pour les années à venir.

De façon similaire, la vague DevOps est loin d’être terminée. Non seulement pour le développement, mais le monde de la techno aussi, avec des processus tels que l’Infrastructure as Code (IAC), pourra se voir faciliter une transition vers le DevOps.

L’avenir nous dira quel sera le prochain buzzword agile. Cela dit, chercherons-nous à mettre plus d’emphase sur les humains qui compose nos organisations ? Ou au contraire, désirerons-nous d’explorer une dimension encore plus vaste comme le développement durable ou autre mouvement sociétal ?

Agile et Scrum, est-ce la même chose ?

Pour un Scrum Master, entendre une chose telle que : « nous faisons de l’agilité » est signe qu’il y a du travail à faire! Le premier pas vers une meilleure compréhension est d’avoir une discussion autour du vocabulaire à employer.

Pour ceux qui se demanderait si Agile et Scrum sont les 2 facettes d’une même pièce, j’exposerai ici la différence de terminologie ainsi que le contexte de l’apparition de celle-ci.

Ceci étant dit, c’est en réponse à un besoin de développer de meilleurs logiciels, que la méthode Agile voit le jour. Plutôt qu’une solution technique, un mode de fonctionnement ou une liste d’exigences, l’agilité propose de mettre en valeur l’autoorganisation, le pluridisciplinarisme et la collaboration. Ce courant de pensée est par la suite popularisé, au début de l’année 2000, au moment où parait le manifeste Agile qui reconnaitra 4 valeurs et 12 principes.

Si le manifeste a su donner un élan au mouvement Agile, déjà à l’époque certaines pratiques basées sur l’agilité commençaient à apparaître. De nos jours, Il existe de nombreuses approches agiles telles que le Scrum, le XD, le FDD, le RAD, le Crystal Clear, etc. Toutefois, il est à noter que certaines ne sont applicables qu’à la programmation ou l’ingénierie logicielle.

Le cadre de travail Scrum, qui compte déjà 25 ans d’existence, est probablement de loin le mieux connu et le plus implanté en entreprise. Bien que cela ne soit pas une partie intrinsèque du cadre Scrum, les équipes l’employant pourront incorporer diverses pratiques agiles. À titre d’exemple, nous trouvons souvent des emprunts à l’eXtreme Programming (XD) des pratiques telles que l’intégration continue ou le Poker Planning.

Un autre type de jumelage méthodologique que nous rencontrons fréquemment est l’utilisation de principes Lean TPS (Toyota Production System). Qui plus est, le Kanban (Lean) et le Scrum, ayant des valeurs similaires, unissent leurs façons de faire dans une approche appelée «Scrumban».

En conclusion, Scrum est une approche qui se base sur l’agilité. Son cadre de travail définit des rôles et des façons de faire. Néanmoins, nous pourrions très bien être agiles en employant une autre approche que le Scrum. Ce qui demeurera le plus important, c’est que nonobstant de l’utilisation de méthodes ou de pratiques utilisées, l’on peut se dire agile uniquement si nos actions incarnent les valeurs agiles.

Le rôle de Scrum Master

Les métiers méconnus de l’agilité. Comment devient-on un Scrum Master?

Historique

Il y a maintenant plus d’une 20e d’années, c’est issu du développement logiciel qu’est né le cadre de travail «Scrum» (framework). Scrum est une approche agile fondée sur un processus de contrôle empirique. Ce cadre de travail permet une plus grande transparence, inspection et adaptation à des environnements changeants et complexes.

L’équipe Scrum reconnait 3 rôles :

  • Scrum Master
  • Product owner
  • L’équipe de développement

Il est à noter que le terme développement ne se limite pas au domaine des technologies de l’information.

Une journée dans la vie de Scrum Master

Un Scrum Master est un facilitateur (Servant-Leader) de l’équipe Scrum. Bien qu’il ne soit pas le responsable hiérarchique de l’équipe, il en est à la fois le leader, le coach et l’enseignant. Étant l’expert du contenant plutôt que du contenu, il aide l’équipe à lever ses bloquants, tout en prônant l’auto-organisation de celle-ci. Il est du devoir du Scrum Master de s’assurer que l’équipe ainsi que la gestion comprennent bien le cadre de travail Scrum.

Bien que cela ne fasse pas partie du rôle, certaines organisations choisiront d’assigner des tâches connexes au Scrum Master. Le double rôle pourra être d’ordre administratif, de charge de projets, etc.

Les qualités du Scrum Master

Afin d’être un bon facilitateur, le Scrum Master doit avoir beaucoup de savoir-être (Soft Skills). Pour nommer quelques-unes des qualités nécessaires, il doit faire preuve de pédagogie, d’empathie et d’humilité. Il doit aussi avoir de bonnes capacités relationnelles et communicationnelles.

Le Scrum Master doit garder en tête qu’il sert l’équipe et qu’il ne la dirige pas.

Formations

Il n’y a pas de cursus de formation collégiale ou universitaire permettant d’accéder à un poste de Scrum Master. Ils existent cependant des certifications qui donneront les clés de la compréhension du rôle de Scrum Master. Ce n’est que par la pratique et l’expérience que la maîtrise pourra être acquise.

Certifications

Plusieurs organisations reconnues offrent des certifications agiles. Pour la plupart de celles-ci, il est possible de prendre des ateliers préparatoires à la certification. En général, ces formations sont d’une durée de quelques jours et elles sont dispensées par des formateurs autorisés.

Voici quelques organismes offrant des certifications de Scrum Master :

Évolution du rôle

En travaillant avec les équipes, le Scrum Master développe des outils qui auront pour effet de changer son approche et sa pratique. Un Scrum Master d’expérience pourrait être amené à prendre différents rôles dans l’organisation.

Scrum Master à l’échelle

L’agilité à l’échelle est une approche où plusieurs équipes en mode agile collaborent dans un même produit ou projet. Le Scrum Master à l’échelle sera ainsi responsable de faciliter l’arrimage et la gestion des dépendances entre les équipes tout en s’assurant de la bonne compréhension du cadre de travail.

Coach agile

La philosophie du coach est un peu différente de celle du Scrum Master. On pourrait dire que le Scrum Master travaille à initier des changements de l’intérieur de l’équipe. Le coach, lui, le fera de l’extérieur. Puisqu’il connait plusieurs approches et techniques, il aide l’équipe à s’engager dans un processus d’autotransformation.

Possibilités de carrière

Depuis plusieurs années, l’agilité et le cadre de travail Scrum, gagne en popularité. Puisque les compagnies investissent à devenir plus agile, la demande pour des postes de Scrum Master est en croissance. Pour ceux qui aiment se mettre au service de l’humain, une carrière de Scrum Master s’avère une option de choix.

The modern business’ mindset problem

The last decade has seen the emergence of different schools of thoughts. In recent time, these new approaches continue to cause changes in the way we build service offers. The introduction of many frameworks and methodologies forces us not only to modify our work processes but also to revisit the place that people take in our companies.

If we pay attention to the trends in the different sectors of our economy, we can notice that the Agile movement shows no sign of slowing down. On the contrary, considering that being Agile helps the industry being more productive, the companies continue to massively invest in order to « agilify » their services. Agile is now widespread and the days are long gone since being Agile was only a thing of software development.

That said, Agile doesn’t solely rest on the daily scrum. To produce a maximum of benefits, the teams providing services cannot be the only ones shouldering this important change in orientation.

Information technology continues to generate growth and opportunities. This industry places itself in an environment of constant innovation favourable to the implantation of agility. Notwithstanding companies’ diligent efforts to deploy the Agile way, on the field, there seems to always have a gap to fill. Since there is no cookbook that one team can follow, developing the Agile mindset is not an easy task.

Unfortunately, which is true for Agile is also true for other new ways of tackling old problems. How many development teams only focus on automation when it comes to DevOps? How many companies promote Lean but only to reduce their waste?

Beyond the set of practices adopted, it all comes down to a mindset problem. Let’s take as an example a company that releases new products early to test market fit. Following to the feedback it receives from its consumers, adapts the service offers to stay ever more competitive. From that perspective, does it really matter that this company ever heard of Agile?

At the time where challenges are piling up, it’s all too natural to see a myriad of agile coaches being deployed to help the business with the problems they face. Nevertheless, there is no absolute guarantee that this strategy will make a return on investment without an actual cultural change from within.

As a society, we tend to put most of the emphasis on a set of technical skills. On the other hand, we should be asking ourselves if we do enough to promote and to train on the very values that are changing the way we do business.

The reproduction of this document, in whole or in part, in any form, is prohibited without prior authorization from the author.

Fatigué de l’amélioration continue?

Les organismes tendent naturellement vers une augmentation de la complexité biologique de la matière. Bien qu’il y ait des exceptions à ce phénomène, le mouvement est souvent propulsé par les interactions de ceux-ci avec leurs écosystèmes. Ainsi, du fait de pressions de leurs environnements, les organismes se complexifient pour demeurer adaptés à leur mode de vie.

De façon similaire, les entreprises se ruent à différentes influences extérieures qui les placent dans une situation de lutte pour leur survie. Le marché, la législation, les ressources, etc., sont autant de facteurs qui poussent les compagnies à se dépasser et à se démarquer de la concurrence.

Afin d’être toujours plus performantes, les entreprises pourront employer plusieurs stratégies. Qu’il soit question d’une diversification des services ou d’une acquisition d’un système informatisé, le moyen choisi conduira inévitablement à un changement qui n’est pas toujours simple à gérer.

Expliquant en partie sa popularité, l’agilité est un outil d’adaptation hors pair pour les environnements changeants et complexes. L’équipe, au fil des itérations, se place dans une culture d’amélioration continue. Cela provoquera l’instauration en permanence de changements qui modifieront tant les façons de faire que la nature des biens ou des services produits.

Les adeptes d’agilités seront donc naturellement plus compétitifs et innovateurs. Cela dit, cette course à l’amélioration, jumelée à un désir toujours croissant de performance des entreprises, pourrait avoir un effet pervers auprès des travailleuses et travailleurs.

L’essoufflement aux changements organisationnels (change fatigue) se caractérise par la démobilisation des équipes face à la mise en place de changements. Cela se manifeste lorsqu’un grand nombre de changements sont introduits dans un système et que ceux-ci ne sont pas cohérents, organisés ou orientés vers un objectif clair à atteindre.

Puisque la capacité humaine d’adaptation est limitée, nous pouvons considérer qu’un processus d’amélioration continue mal encadré puisse représenter une baisse de performance ou de productivité pour une organisation.

En somme, une institution évolue au rythme de ceux qui la composent. Par conséquent, pour qu’une initiative d’amélioration produise les bénéfices escomptés, il est primordial que celle-ci fasse l’objet d’une saine de gestion du changement.

Ceci est le texte intégral qui a été publié sur le blogue d’Agile Québec.

Toute reproduction, en tout ou en partie, sous quelque forme que ce soit, est interdite sans l’autorisation préalable de l’auteur.

L’entreprise moderne, une affaire de « MINDSET ».

Les dernières décennies ont vu l’émergence de plusieurs courants de pensée. Ceux-ci bouleversent, encore aujourd’hui, la façon dont les entreprises pourvoient leurs produits et services. Bien que ces nouvelles méthodologies nous forcent, dans bien des cas, à revoir complètement nos processus internes, l’impact sur l’humain est indéniable.

Si l’on s’attarde aux tendances dans les différents secteurs d’activités, on peut remarquer que l’agilité n’est pas en perte de vitesse. Au contraire, y voyant plusieurs bénéfices, les entreprises continuent d’investir massivement pour « être plus agile ». Ainsi, l’agilité est maintenant connue dans la plupart des grands pans de notre économie.

Cependant, l’agilité n’est pas simplement l’affaire de la traditionnelle mêlée quotidienne. Nous constatons également que les équipes en réalisation, à elles seules, ne peuvent être acteurs de ce changement d’orientation.

Les technologies de l’information connaissent une fulgurante évolution. En réponse à un besoin de constante adaptation, ce domaine se positionne en terreau fertile d’expérimentation. Cela dit, au-delà des efforts des dirigeants afin de positionner l’agilité au sein de leur entreprise, il existe toujours un retard à combler. Les méthodologies ne sont pas faciles à implanter et il ne semble pas y avoir de recette miracle.

Malheureusement, les constats sont partout les mêmes. Combien d’équipes ont la compréhension que le DevOps se limite seulement à l’automatisation ? Combien de compagnies font la promotion du Lean, mais ne parlent que de gaspillage ?

Prenons en exemple une entreprise qui teste rapidement ses hypothèses en lançant sur le marché de nouveaux produits et qui, des suites des rétroactions de sa clientèle, améliore son offre de services.  Le fait que cette compagnie n’a peut-être jamais entendu parler d’agilité ne veut pas dire qu’elle ne soit pas agile pour autant. Pour cette raison, il est impératif de s’attarder davantage au mindset plutôt qu’aux mécaniques sous-tendues.

Compte tenu des défis auxquelles l’entreprise moderne fait face, il est naturel de voir des hordes de coachs être déployées pour assister les équipes. Cette stratégie n’est toutefois pas garant de succès sans que ne s’opère un vrai virage culturel.

En conclusion, notre société a tendance à mettre beaucoup d’emphase sur le volet technique. Il semble cependant légitime de se poser la question si nous en faisons assez pour former les gens sur les notions plus idéologiques qui opèrent maintenant tant de changements en entreprise.

Ceci est le texte intégral qui a été publié sur le blogue d’Agile Québec.

Toute reproduction, en tout ou en partie, sous quelque forme que ce soit, est interdite sans l’autorisation préalable de l’auteur.

Doing it the Scrumban way

For a long time, I was working with Software Development teams. Being a certified Scrum Master helped a lot to keep interferences at bay and have the team focused on the delivering value.

At the beginning of 2019 came a new challenge. I was working with an operation team and something was missing. That is how Kanban came into action. Along with Scrum, Kanban is a powerful tool for value-delivering. After the Scrum team manages to create a pull system, the different Kanban practises and metrics will help you get some predictability. Scrum and Kanban are thoroughly compatible and using both will help you increase your teams’ Transparency, Inspection and Adaptation.

In order to increase my knowledge of the Kanban strategy, I started preparing for the new Scrum.org Assessment (Professional Scrum with Kanban). I passed the exam a few weeks later and since I’m a certified PSK 1.

Surprisingly, there is more material to this exam than there is for the PSM 1 or PSPO 1. For you Scrum Masters working with a Development, Operation or DevOps teams, I strongly recommend trying the Scrum and Kanban approach.