L’idée de cet article est de vous raconter en quelques lignes le parcours atypique que j’ai pu avoir depuis mes débuts en tant qu’ingénieur DevOps/Cloud jusqu’à ma position actuelle de Scrum Master qui peut s’articuler autour de trois principales phases :
- L’ingénieur DevOps/Cloud dans un contexte agile
- Les facteurs déclencheurs du changement de rôle
- L’environnement actuel du Scrum Master
L’ingénieur DevOps dans un contexte agile
Durant deux ans et demi et de multiples missions chez différents clients, j’ai pu observer sur le terrain à quel point la culture DevOps/Cloud a pu se développer à une vitesse effrénée tout en se combinant avec la culture de l’agilité qui elle pareillement, peut se targuer d’avoir connu une évolution non pas des moindres par rapport à celle de son « confrère », les deux ayant permis et continuant d’améliorer en profondeur les organisations des entreprises.
J’ai eu l’opportunité de travailler dans des équipes d’ingénieurs DevOps/Cloud tout en pratiquant au quotidien les différentes méthodes agiles à savoir Kanban, Scrum et Scrumban.
Ce qui est particulier et qui peut paraître surprenant à première vue c’est que dans une de ces missions (chez un client reconnu du secteur des énergies), nous étions une Scrum Team composée d’un Scrum Master, d’un Product Owner et surtout entièrement d’ingénieurs DevOps/Cloud et non pas d’ingénieurs de développement et de quelques ingénieurs DevOps/Cloud comme c’est le cas dans certaines entreprises. Malgré cette spécificité, nous fonctionnions de la même manière qu’une Scrum Team typique avec toutefois des finalités différentes : au lieu de déployer de nouvelles fonctionnalités pour les clients, nous déployons des features portant par exemple sur la stabilisation de l’infrastructure ou des requêtes venant des développeurs qui étaient plus dans notre domaine d’expertise que dans les leurs.
De mon point de vue, ce que je trouvais génial, c’est qu’en alliant ces deux cultures, nous pouvions à la fois nous adapter aux circonstances aléatoires et prioriser les sujets selon leur criticité tout en conservant une part de flexibilité sur le choix des sujets sur lesquels nous souhaitions travailler tout en variant bien entendu à chaque sprint le thème choisi. La possibilité de pouvoir travailler sur ces sujets infrastructures divers et variés nous permettait d’accroître notre bagage technique tout en contribuant parallèlement à la polyvalence des membres de l’équipe pour pallier aux imprévus/absences.
Les facteurs déclencheurs du changement de rôle
Lors du début de ma mission chez ce client, j’avais d’abord comme premier objectif de gérer le Kanban de l’équipe qui rassemblait les demandes des dizaines d’équipes de développeurs ce qui pouvait s’apparenter à une récurrence quotidienne afin de pouvoir monter en compétences sur l’environnement technique et de mieux discerner les besoins et les enjeux du client. Cette tâche m’a permis d’échanger avec des personnes occupant des postes que nous pouvons retrouver dans le monde de l’IT : des business analystes, des testeurs, des développeurs, des Scrum Masters, des Product Owners et des managers d’équipe. A chaque échange avec chaque interlocuteur, je devais adapter mon vocabulaire technique pour pouvoir me faire comprendre et les accompagner pour résoudre les problèmes qu’ils pouvaient croiser. Ces nombreux échanges ont amplement contribué à améliorer mes « soft-skills », à savoir : ma manière de communiquer, ma faculté d’interpréter les sujets et mes qualités de « facilitateur ».
Par la suite, j’ai enchaîné sur une autre mission toujours en tant qu’ingénieur DevOps/Cloud cependant, c’est lors de cette mission qui a fini par devenir trop technique, que j’ai réalisé que c’était le bon moment au niveau de ma carrière de changer de rôle au sein de l’IT. J’avais pu observer depuis longtemps les multitudes de postes qui existaient, tout en connaissant ce que chacun avait comme fonctions particulières. En me rappelant de ma mission précédente où j’avais pu être ingénieur DevOps/Cloud « facilitateur » et parfois Scrum Master (J’avais quelques fois remplacé le Scrum Master de l’équipe pendant son absence), je me suis fait à l’idée que la posture de Scrum Master pouvait très bien me correspondre du fait bien entendu, en plus d’avoir travaillé dans la technique, j’avais des qualités humaines (être sociable, ouvert d’esprit, être perspicace) qui rentraient dans la personnalité d’un Scrum Master que toute entreprise recherche.
L’environnement actuel du Scrum Master
Cette opportunité pour devenir Scrum Master n’a pas été simple à trouver pour vous l’avouer mais grâce au Scrum Master de chez Aubay avec qui j’ai collaboré durant cette dernière mission, ce « rêve » est devenu une réalité. Suite à mes entretiens avec un coach agile senior et le manager de la practice Agile de Aubay qui se sont avérés concluants, j’ai donc intégré Aubay. C’était la première étape de faite, il fallait ensuite convaincre un client qu’il puisse m’offrir la possibilité de pouvoir exercer à plein temps la position de Scrum Master. Par conséquent, j’ai débuté une mission chez un client reconnu du secteur des télécommunications. Le rôle que j’allais occuper et que j’occupe toujours à l’heure actuelle est celui de « Chef de projet agile/Scrum Master » au sein de l’entité responsable de l’hébergement et de l’exploitation des applications dans le Cloud. Mon expérience passée d’ingénieur DevOps/Cloud conjuguée à une pratique quotidienne des méthodes agiles allait de facto considérablement me guider dans ma manière d’appréhender l’écosystème de cette nouvelle mission.
Dans le cadre de mon activité de « chef de projet agile », je dois gérer une multitude de projets en parallèle avec des points de suivi hebdomadaires incluant à chaque fois des développeurs et des ingénieurs DevOps/Cloud. Ces points similaires aux daily meeting de la méthode Scrum ont pour vocation de suivre l’avancement des projets et de remonter les points bloquants. Je dois, de surcroît, surveiller au quotidien la consommation des budgets alloués aux projets. Pour un projet en particulier, je suis rattaché à un train SAFe et dois donc suivre les multiples cérémonies dédiées.
Dans le cadre de mon activité de Scrum Master, je gère une équipe composée de quatre Product Owners (ce sont les techleads) et de dix ingénieurs DevOps/Cloud. La raison pour laquelle ce sont les techleads qui occupent le rôle de Product Owner, est liée au fait que la Scrum Team que j’ai repris en main récemment n’est pas encore arrivée à maturité au niveau de la méthode Scrum. J’ai donc dû repartir de zéro en leur présentant les caractéristiques de Scrum car certains n’avaient jamais travaillé avec auparavant et étaient plus habitués au cycle en V. Nous enchainons actuellement notre troisième sprint (les sprints sont mensuels) et je commence à noter une certaine amélioration sur l’organisation de travail de l’équipe qui assimile au fur et à mesure l’importance des piliers Scrum « Transparence, Inspection et Adaptation » ce qui se ressent notamment lors du daily meeting et de la rétrospective où les membres de l’équipe n’hésitent pas à partager les informations qu’elles soient bonnes ou mauvaises mais qui sont indispensables à l’avancée des tâches et au bon fonctionnement de la Scrum Team. Cette avancée renforce mon optimisme quant à la capacité de l’équipe d’ici à la fin d’année de pouvoir atteindre le degré de maturité attendu.
Conclusion
Cette nouvelle expérience qui m’a permis de passer de celui qui pratique la méthode Scrum à celui qui la met en place, a dû emprunter une transition qui s’est dans l’ensemble bien déroulée notamment grâce aux expériences emmagasinées durant les missions précédentes et également grâce aux précieux conseils des agilistes de Aubay qui sont toujours disponibles et qui sont surtout à jour au niveau des tendances agiles.
