COMMENT LES GRANDES ENTREPRISES TECHNOLOGIQUES GÈRENT LES PROJETS TECHNOLOGIQUES ET L’ABSENCE CURIEUSE DE SCRUM

La gestion de projets techniques est le processus de gestion de tous les projets informatiques et liés à l’informatique. Les gestionnaires de projets techniques jouent un rôle essentiel dans la conduite d’un projet, qu’il s’agisse de son lancement, de sa planification, de son exécution, de son suivi, de son contrôle ou de son achèvement. La gestion de projets techniques implique la communication avec les parties prenantes techniques et non techniques. Les gestionnaires de projet ont transformé la manière dont les entreprises planifient et exécutent les projets. Ce sont des innovateurs, de solides communicateurs, des facilitateurs axés sur les données et des résolveurs de problèmes qui dirigent et inspirent les autres.

Les grandes entreprises technologiques n’ont pas la même approche de la gestion des projets technologiques que les autres. J’ai recueilli des données en effectuant des recherches sur des entreprises technologiques bien connues et cotées en bourse. Voici comment elles s’y prennent généralement pour mener à bien leurs projets :

Voici quelques-unes des caractéristiques que les ingénieurs des grandes entreprises technologiques partagent dans leur façon d’exécuter les projets

• Les ingénieurs dirigent la plupart des projets : Les startups et les grandes entreprises technologiques font généralement appel à leurs ingénieurs à tous les niveaux pour diriger les projets d’ingénierie. En tant qu’ingénieur, il est essentiel d’acquérir les compétences nécessaires pour mener à bien cette tâche si vous souhaitez évoluer vers des postes de direction et de personnel. Et en tant que manager, aider les gens à développer ces compétences vous aidera à évoluer en tant que leader.
• Les équipes ont la possibilité de choisir la méthodologie de gestion de projet: De nombreuses équipes optent pour un processus de planification de type RFC, répètent la construction et livrent le tout en quelques semaines. D’autres équipes utilisent des méthodes plus proches de Kanban, travaillant sur les éléments les plus prioritaires.
• Il n’y a pas de chef de projet attitré pour les projets menés au niveau de l’équipe : La plupart des entreprises ont des gestionnaires de programmes techniques (TPM) qui s’occupent des grands projets impliquant plusieurs équipes ou s’étendant sur plusieurs organisations. Ces responsables dirigent également des programmes d’ingénierie qui ne sont pas considérés comme des produits. Lorsqu’il s’agit de travailler, il ne s’agit pas d’un produit ou d’une plateforme, mais d’un élément essentiel, comme la migration d’un centre de données sur site vers un fournisseur de services en nuage. C’est dans ces domaines que les TPM prennent la relève.

C’est très courant pour les personnes employées dans les grandes entreprises technologiques. Cependant, si vous deviez copier la même approche dans une entreprise plus traditionnelle, elle serait probablement vouée à l’échec. En effet, la structure organisationnelle des grandes entreprises technologiques affecte considérablement la manière dont les équipes peuvent accomplir et exécuter leurs tâches.

POURQUOI LES GRANDES ENTREPRISES TECHNOLOGIQUES N’UTILISENT PAS SCRUM

• Scrum n’est pas agile : Scrum a été si fortement associé aux projets agiles au début que la communauté n’a pas réussi à les distinguer. L’approche scientifique de Scrum et sa promotion enthousiaste ont donné à beaucoup un faux sentiment de sécurité. L’accent mis par Scrum sur la gestion empirique est logique. Lorsque les circonstances et les priorités changent rapidement, la planification et l’exécution conventionnelles échouent, vous devez donc observer et vous adapter en permanence.
• C’est précisément ce qu’accomplissent les approches agiles de développement de logiciels, bien qu’elles soient arrivées à des pratiques similaires à partir d’une perspective différente.
• L’orgueil et l’enthousiasme : Beaucoup s’attendaient à ce que Scrum soit une « enveloppe » autour de n’importe quelle méthode de développement de nouveaux produits, ce qui partait d’une bonne intention mais ignorait une faille logique fatale : si vous enveloppez un processus non agile, l’ensemble n’est plus agile. C’est à cause de cette arrogance que tant de projets Scrum sèment les graines de leur échec. Le défaut fatal de Scrum est qu’il se considère comme creux ; il n’a pas d’opinion sur la façon dont les logiciels « devraient » être développés. C’est comme si l’association de Scrum avec Agile était considérée comme circonstancielle plutôt qu’intrinsèque. La méthode Agile est décrite par des principes et des valeurs, et non par des cérémonies et des processus. L’Agile est régi par un manifeste, pas par un manuel de processus. Il s’agit de deux choses très différentes, et pourtant, aujourd’hui encore, de nombreuses personnes sont déconcertées par cet amalgame.
• Scrum conduit souvent à un glissement du champ d’application, en raison de l’absence d’une date de fin définie.
• Les risques d’échec d’un projet sont élevés si les individus ne sont pas très engagés ou coopératifs.
• L’adoption du cadre Scrum dans les grandes équipes est un défi
• Le cadre ne peut réussir qu’avec des membres expérimentés de l’équipe.
• Les réunions quotidiennes frustrent parfois les membres de l’équipe
• Si un membre de l’équipe démissionne au cours de la mise en œuvre d’un projet, cela peut avoir un impact négatif considérable sur le projet.
• La qualité est difficile à mettre en œuvre si les membres de l’équipe ne sont pas soumis à un processus de test exigeant.

COMMENT LES STRUCTURES ORGANISATIONNELLES DES GRANDES ENTREPRISES TECHNOLOGIQUES INFLUENCENT LES PROJETS

Pour comprendre comment les grandes entreprises technologiques gèrent leurs projets, prenons un peu de recul et analysons l’environnement dans lequel la plupart d’entre elles opèrent :

Autonomie pour les ingénieurs logiciels. Les développeurs des entreprises établies sont censés accomplir les tâches qui leur sont confiées. Dans le cas des entreprises en phase de démarrage, on attend d’eux qu’ils résolvent les problèmes auxquels l’entreprise est confrontée aujourd’hui. Il s’agit d’une différence considérable qui, à son tour, a un impact sur les activités quotidiennes de tout ingénieur.

Il s’agit de résoudre des problèmes, et non de fournir des ressources sans réfléchir. Un ingénieur motivé qui résout les problèmes rapidement a plus d’impact qu’un ouvrier industriel qui se contente d’exécuter les tâches qui lui ont été confiées. Pour les entreprises ayant une structure de travailleurs industriels, cette méthode ne favorise pas les approches de gestion de projet plus lourdes qui laissent volontairement moins de place à l’interprétation.

Connaissance de l’entreprise et de ses paramètres. Les ingénieurs doivent interagir avec le reste de l’industrie et créer des relations avec le personnel non ingénieur. D’autre part, les entreprises traditionnelles font généralement en sorte qu’il soit difficile pour les développeurs d’interagir avec le reste de l’entreprise.

Communications entre ingénieurs par le biais de communications triangulaires. Ce qui se passe généralement dans les entreprises traditionnelles, c’est qu’elles favorisent une communication hiérarchique qui ralentit le flux d’informations et se traduit par des décisions plus lentes, ce qui retarde la mise sur le marché des produits.

Créer une expérience moins décevante pour les développeurs. Les entreprises qui s’attachent à ce que les ingénieurs soient en mesure de résoudre les problèmes le plus rapidement possible créent plusieurs équipes de plate-forme, ce qui réduit le taux d’attrition des développeurs.

Une rémunération plus élevée est justifiée par un effet de levier plus important. Les entreprises qui font appel à des ingénieurs n’auront aucun mal à les rémunérer à un niveau proche ou supérieur à celui du marché.

La qualité des talents recrutés. Ces entreprises recrutent des personnes très compétentes et très motivées, grâce à la combinaison de tous ces éléments. Elles disposent d’un large éventail de candidats, car elles sont réputées pour la générosité de leurs rémunérations et leurs importantes possibilités d’évolution de carrière.

Qu’est-ce que Scrum ?

Scrum est une méthodologie de développement agile utilisée pour développer des logiciels basés sur des processus répétitifs et incrémentaux. Scrum est facilement adaptable, flexible, rapide et constitue un cadre agile pratique qui aide les équipes à travailler ensemble. Elle encourage les membres de l’équipe à apprendre par l’expérience, à s’auto-organiser lors de la résolution d’un problème et à réfléchir sur leurs victoires et leurs défaites afin d’assurer une amélioration continue. Il est conçu pour apporter de la valeur au client tout au long du développement d’un projet.

Importance de la méthodologie Scrum

• La méthodologie Scrum est simple et efficace. Il s’agit de quelque chose de différent d’une collection essentielle de composants connectés. La méthodologie Scrum est souvent considérée à tort comme une philosophie. Elle actualise la méthode logique de l’expérimentation. La méthodologie Scrum peut également être utilisée à la place d’une approche algorithmique sur mesure. Les individus ont tendance à considérer la méthodologie Scrum et la méthode agile comme quelque chose de similaire parce que la méthodologie Scrum est basée sur l’amélioration constante, qui est une ligne directrice centrale de la méthodologie agile Scrum.
• La méthodologie Scrum est un cadre de travail, tandis que l’agilité est une attitude. Le cadre de la méthodologie Scrum est expérimental ; il s’appuie sur l’apprentissage continu et les changements en fonction des composantes fluctuantes. Elle reconnaît que les individus ne savent pas tout au début d’un projet et qu’ils se développent progressivement.
• La méthodologie Scrum aide les organisations à s’adapter fréquemment à des environnements fluctuants et aux besoins des clients. La principale priorité du cadre Scrum est d’améliorer les cycles de livraison courts et d’aider les organisations à apprendre tout en travaillant. Bien que la méthodologie Scrum soit organisée, elle n’est pas très rigide. Son exécution peut être adaptée aux besoins de n’importe quelle association. Il existe de nombreuses hypothèses sur la manière dont les groupes de méthodologie Scrum doivent fonctionner pour être efficaces. Néanmoins, après plus d’un an passé à aider des groupes agiles à accomplir leur travail chez Atlassian, nous avons découvert que la bonne correspondance, la franchise et l’engagement en faveur de l’amélioration continue devraient toujours rester au centre de n’importe quel cadre Scrum et agile que vous choisirez.

Les différents rôles dans Scrum

Les trois rôles Scrum décrivent les principales responsabilités des membres de l’équipe Scrum. Il ne s’agit pas de titres de postes, ce qui signifie que n’importe quel titre peut remplir l’un de ces rôles, y compris le vôtre. Dans Scrum, l’équipe se concentre généralement sur l’auto-organisation, l’amélioration continue et la création de logiciels de qualité. Le responsable d’un projet Scrum s’attache à définir les caractéristiques du produit (ce qu’il faut construire, ce qu’il ne faut pas construire et dans quel ordre) et à surmonter les difficultés susceptibles d’entraver le travail de l’équipe de développement.

L’équipe Scrum comprend les rôles suivants :

Scrum master : la personne qui se trouve derrière l’équipe, qui lui montre la voie et la guide pour qu’elle agisse conformément aux règles et aux processus de la méthodologie. Il contrôle également la réduction des obstacles au projet et collabore avec le propriétaire du produit pour améliorer le retour sur investissement. Le scrum master aide également le product owner à définir la valeur, l’équipe de développement crée la valeur et l’équipe scrum l’améliore. Le scrum master ne décrit pas seulement un type de leadership de soutien, mais aussi les opérations quotidiennes de l’équipe.

Propriétaire de produit : il s’agit du représentant des parties prenantes et des clients qui utilisent le logiciel. Il concentre son attention sur la partie commerciale et est responsable du retour sur investissement du projet. Le propriétaire du produit comprend non seulement les besoins des clients, mais il visualise également la valeur que l’équipe scrum leur apportera. Il veille également à ce qu’il y ait un équilibre entre les besoins des parties prenantes. Le responsable du produit doit donc être en charge de ces apports et faire du travail la priorité numéro un. Il s’agit d’une responsabilité essentielle, car des priorités contradictoires réduisent l’efficacité de l’équipe et rompent la confiance entre l’équipe de développement et l’entreprise.

L’équipe : il s’agit généralement d’un groupe d’experts possédant les connaissances techniques requises pour développer le projet, qui exécutent en collaboration les tâches qui débutent chaque sprint. La plupart des gens pensent que l’équipe de développement doit être composée uniquement d’ingénieurs, mais ce n’est pas le cas. L’équipe de développement peut être composée de toutes sortes de personnes, y compris des concepteurs, des programmeurs ou des rédacteurs. Cette équipe doit être auto-organisée afin de pouvoir prendre les décisions qui permettront d’accomplir le travail. L’équipe de développement, tout comme l’équipe de soutien à la production, peut mettre en œuvre des décisions qui résolvent les problèmes et apportent une valeur ajoutée. Cette équipe assure également la transparence lors de la réunion quotidienne. Le standup scrum quotidien offre une transparence au travail et fournit une plateforme par laquelle les membres de l’équipe peuvent demander de l’aide.

Conclusion

Nous avons vu comment les entreprises, à différents stades, gèrent leurs projets avec différentes méthodologies et comment les grandes entreprises technologiques n’utilisent généralement pas une approche unique. Néanmoins, les grandes entreprises disposent d’un soutien organisationnel important pour faire fonctionner ce processus.

La manière dont vous gérez les équipes dépend généralement de votre contexte. Les facteurs pertinents comprennent votre structure organisationnelle, les personnes avec lesquelles vous travaillez, l’autonomie et les compétences de ces personnes, votre concurrence et le fait que vous opériez en « temps de guerre » ou en « temps de paix ». La liste est longue.