Ce que vous devez savoir sur la gestion de projet Scrum

Comment le monde du travail a-t-il changé?

Le travail est un aspect de notre vie quotidienne qui évolue constamment. Il n'y a pas si longtemps, le travail était considéré comme beaucoup plus proche de l'artisanat et du travail manuel, notamment pendant les périodes préindustrielles. C'est dans les années 1950 que la version la plus reconnaissable de la gestion de projet a vu le jour, juste après la Seconde Guerre Mondiale et au milieu du boom économique que connaissait la civilisation occidentale d'après-guerre. C'est à cette époque que nous avons été initiés aux concepts d'organisation de projet grâce aux travaux d'Henri Fayol et d'Henry Gantt (le fameux diagramme de Gantt).

Naturellement, l'évolution des technologies a continué à progresser, et a introduit des méthodologies plus complexes pour suivre et mesurer les progrès de plusieurs projets. Richa Dhall, qui l'a partagé sur LinkedIn, note que "tout cela a changé notre façon de travailler, d'exécuter les tâches, de partager les données et de convertir le ROI (retour sur investissement) en ROTI (retour sur temps investi). Chaque tâche était effectuée plus rapidement, et les projets devaient alors être terminés en beaucoup moins de temps qu'auparavant."

Avec tout cela, les technologies ont continué à se développer, et les sociétés de logiciels ont été les premières à remarquer la nécessité de mettre en place de meilleurs systèmes pour faire face à l'évolution rapide des concurrents sur le marché. Cependant, la programmation restait un processus long et fastidieux, et les chefs d'entreprise étaient désireux de chercher des moyens d'améliorer les délais d'exécution des produits en réponse aux évolutions et aux réactions du marché et des consommateurs.

L'histoire de la méthode Scrum

Dans les années 1990, Jeff Sutherland et Ken Schwaber ont présenté une version publiée de la première itération de ce qui est maintenant connu sous le nom de "gestion de projet Scrum". Il est important de noter ici que ce qu'ils avaient formellement développé n'était en aucun cas entièrement nouveau, mais qu'il est mieux compris comme une coalition de différents principes de méthodologie agile qui étaient utilisés par des entreprises du secteur.

À cette époque, il y avait quelques façons pour une entreprise de choisir d'être plus agile dans ses étapes de développement produit, en utilisant des méthodologies comme la gestion de projet en cascade, aussi appelée Waterfall, dans un effort pour réagir rapidement aux changements nécessaires dans leurs processus de développement. Dans un livre blanc publié sur son site Web, Schwaber a déclaré que si des systèmes comme Waterfall peuvent être efficaces dans le développement de produits, ils reposent également sur un processus attendu, bien compris et standardisé. Les scénarios de la vie réelle, affirme Schwaber, sont beaucoup plus volatils par nature, et nécessitent un retour d'information beaucoup plus cohérent concernant les changements et les itérations nécessaires.

En 1994, un article-clé a été rédigé pour la Harvard Business Review, décrivant une "nouvelle" méthode de développement de produits. Cet article, rédigé par Hirotaka Takeuchi et Ikujiro Nonaka, expose une théorie de la gestion de projet qui peut permettre aux managers et aux équipes d'éviter l'"approche façon relais d'équipe" et de travailler plutôt au sein d'équipes spécialisées pour faire avancer un produit dans une "mêlée" (en anglais, scrum). Scrum est un terme que le duo a emprunté à la façon dont les équipes de rugby mènent un jeu ensemble pour amener le ballon au but.

Avec cet article et le terme, certes approprié, qui l'accompagne, Schwaber et Sutherland ont défini une version plus complète de cette méthodologie et l'ont présentée à la conférence OOPSLA'95 (Object-Oriented Programming, Systems, Languages and Applications).

Comment fonctionne la méthode Scrum

Si l'histoire nous montre pourquoi un tel système était nécessaire pour mieux répondre à l'avancée vers de nouvelles méthodologies agiles, les processus exacts qu'il contient peuvent être difficiles à comprendre pour le lecteur novice. Dans l'essentiel, le Scrum est une méthode permettant d'établir des calendriers de développement incrémentiels rapides, afin de mettre sur le marché des itérations de produits viables dans un court laps de temps (généralement de 1 à 4 semaines).

Ces sessions de Scrum sont de courtes réunions, au cours desquelles les membres de l'équipe, les chefs de produit et les Scrum Masters se connectent pour examiner l'état actuel du produit en cours. Il peut s'agir de discuter des principaux succès, des préoccupations immédiates et même des défis futurs qu'ils prévoient de rencontrer sur le marché. L'objectif ultime de ces réunions est d'accélérer la livraison d'un produit de haute qualité, en étant mieux informés par les canaux internes et externes.

Encore une fois, le Scrum n'est pas la seule façon de mettre en pratique la vision agile dans votre travail, et ne se limite pas à l'espace du développement logiciel. L'objectif principal du Scrum est de fournir aux équipes un cadre général à suivre, fondé sur l'action, la révision et l'adaptation dans un processus court mais efficace. De cette façon, le Scrum est suffisamment flexible pour être intégré dans différents contextes, tout en offrant un minimum d'orientation aux équipes qui naviguent dans des processus de développement peu clairs.

Les principaux processus du Scrum

Le cadre Scrum, tel que Schwaber et le Project Management Institute (PMI) le décrivent, est moins une méthodologie exacte étape par étape qu'une structure dans laquelle les équipes peuvent injecter leurs propres processus d'une manière plus organisée. Les principaux composants d'un Scrum qu'un chef de projet doit connaître sont les backlogs, les sprints et les revues incrémentales de produit (aussi appelés Product increment reviews), qui contiennent eux-mêmes des sous-composants que les chefs de projet doivent prendre en compte pour réussir un projet en mode Scrum.

Le backlog du produit

En tant que précurseur de l'ensemble du produit, un objectif clair pour l'entreprise est défini comme étant l'objectif global pour l'ensemble de l'équipe. Ensuite, on définit les backlogs de produit, qui sont essentiellement un ensemble de fonctionnalités du produit qui sont définies par les besoins du marché, le développement de la concurrence, les retours des clients ou d'autres aspects qui peuvent influencer la mise en œuvre des fonctionnalités. C'est ici que les "Product Owners" désignés sont chargés de gérer la communication de ces fonctionnalités demandées au "Scrum Master" et à l'"équipe Scrum".

Les sprints

Un cadre temporel ou "time box" est ensuite fixé, qui dans le cadre de Scrum est connu comme étant une itération individuelle ou "sprint". Avec ce sprint, une durée est établie entre tous les membres de l'équipe Scrum, pendant laquelle ils doivent livrer les fonctionnalités sélectionnées dans le backlog du produit. Le temps nécessaire à chaque sprint varie, mais est généralement fixé à une norme de 1 à 4 semaines.

Il s'agit d'une base de travail complète, car elle établit essentiellement la cadence à laquelle l'équipe de mêlée travaille pour développer le produit en fonction des fonctionnalités convenues, qui sont dérivées du backlog de produit et sont définies comme le "backlog de sprint" pour le sprint spécifique en question.

Pendant le sprint lui-même, l'équipe de mêlée peut se concentrer pleinement et se voir allouer des ressources pour terminer le sprint dans le temps imparti. Il est important de noter ici que le Scrum nécessitera une gestion pratique de la part du Scrum Master, car des problèmes risquent de survenir pendant ces périodes de développement. En fonction de la sensibilité au temps du produit, le temps imparti peut être ajusté pour mieux répondre aux préoccupations critiques.

Le travail à réaliser au cours du sprint lui-même ne doit pas être modifié pendant cette période, ce qui signifie qu'aucune fonctionnalité supplémentaire ne doit être ajoutée pendant le sprint lui-même. Les demandes de développement de produits supplémentaires peuvent être ajoutées aux backlogs de produits ultérieurs qui, à leur tour, seront développés dans les backlogs de sprint suivants. Au cours de ces périodes de sprint, les équipes Scrum, ainsi que le Scrum Master et le Product Owner, si nécessaire, se reconnectent lors de courtes réunions (d'une durée standard de 15 à 30 minutes) pour s'aligner sur les tâches terminées, sur ce qu'elles prévoient d'achever d'ici la fin de la journée, ainsi que sur les obstacles majeurs qui entravent le travail spécifique à effectuer. Ces courtes réunions sont une ressource fantastique pour le travail inter-équipes, en particulier lorsque l'équipe se rapproche de la fin de ses sprints.

La revue incrémentale du produit

C'est après ces sessions de sprint individuelles que l'aspect court mais néanmoins essentiel du Scrum entre en jeu par le biais des révisions incrémentales du produit. Certaines ressources de la méthode Scrum peuvent se référer à cette partie comme à une refonte du backlog, un nettoyage, ou d'autres termes similaires.

L'aspect essentiel de cette composante du Scrum est de revoir l'état du produit lors de son itération la plus récente après le sprint, de réévaluer si le backlog de produit actuel est toujours pertinent, et si des ajustements aux processus de développement sont nécessaires. Il s'agit notamment de recueillir les commentaires des parties prenantes internes et externes pour voir où et comment elles peuvent s'améliorer.

C'est ici que la méthode Scrum s'appuie sur les principes d'action, de révision et d'adaptation que nous avons mentionnés précédemment. Sans cette dernière étape de révision et d'adaptation, le produit risque de passer à côté de fonctionnalités-clés qui pourraient faire partie intégrante de son succès sur le marché. Le paysage actuel évoluant rapidement en termes de ce qui est susceptible d'être développé dans les mois à venir, il est d'une importance absolue de revoir constamment où en est le produit et de s'adapter en conséquence dans le cadre du fonctionnement en mode Scrum.

Les rôles-clés en fonctionnement Scrum

En dépit du processus relativement robuste dont nous venons de parler concernant le fonctionnement global de la méthode Scrum, le nombre de rôles-clés dans ce cadre est relativement réduit. Le Scrum n'a besoin que de trois rôles principaux qui doivent être correctement définis afin d'être pleinement fonctionnels à des fins de gestion de projet. Selon le formateur certifié Scrum Mike Crohn, pour ScrumAlliance.org, ces rôles sont définis comme étant celui de Product Owner, de Scrum Master et des équipes Scrum.

Le Product Owner

Bien qu'il soit orienté vers le client et vers l'aspect commercial du produit au sein des projets Scrum, le responsable du produit, aussi appelé le Product Owner (ou parfois chef de produit) gère et assure la liaison entre le Scrum Master, l'équipe Scrum et toute autre partie prenante interne ou externe qui aura une influence sur le projet. Le Product Owner peut également être perçu comme une voix-clé pour visualiser la forme en cours de développement et la version finale du produit, conformément à la vision commerciale principale définie en amont du projet.

Avec de nombreux changements susceptibles de se produire entre chaque backlog de produit et le sprint suivant, c'est le Product Owner qui doit être pleinement responsable de la cohérence des éléments-clés qui sont nécessaires pour le succès du produit sur le marché. Il devra également être capable de communiquer cette vision au Scrum Master et à l'équipe Scrum, car ces deux dernières parties seront chargées de la gestion et du développement effectif du produit.

Les Product Owners compétents savent comment exploiter les backlogs de produit, afin de mieux aligner tout le monde sur les éléments prioritaires pour le développement du projet, car ils seront probablement ceux qui comprennent parfaitement ce que les utilisateurs du produit recherchent. La connaissance du secteur et la prévoyance sont essentielles à cet égard, car ils doivent être en mesure de s'adapter à tous les changements visibles (et invisibles) du marché.

Le Scrum Master

Si le Product Owner est responsable de l'aspect commercial et de l'utilisateur final du produit, le Scrum Master est chargé de gérer le processus de développement du projet. Son rôle principal est de s'assurer que chaque membre de l'équipe comprenne la portée des développements Scrum, ainsi que son rôle individuel au sein de celui-ci.

Agissant comme un facilitateur, un guide et un coach tout au long du processus, le Scrum Master doit être capable de comprendre le flux opérationnel de chaque sprint et de répondre aux préoccupations de l'équipe. Compte tenu des délais serrés de chaque sprint (1 à 4 semaines), le Scrum Master doit absolument garder le cap.

En assumant ce rôle de supervision, il est essentiel pour le Scrum Master d'être également conscient des limites des équipes, afin d'éviter tout problème de surcharge dans leurs tâches. Le Scrum Master peut également fournir des conseils en matière de réflexion transversale, afin de mieux aider les membres de l'équipe à surmonter les difficultés lors du développement.

L'équipe Scrum

Enfin, l'équipe Scrum est responsable de l'essentiel du projet Scrum. Alors que le Product Owner, (le chef de produit) et le Scrum Master gèrent et délèguent les tâches, l'équipe Scrum se charge du développement et de la mise en œuvre au cours des sprints proprement dits.

Les équipes Scrum sont généralement pluridisciplinaires, et se composent souvent d'individus ayant des objectifs différents dans le projet, tels que des analystes commerciaux, des testeurs de produits, des développeurs de produits, des responsables marketing, et même des responsables financiers.

C'est cette équipe qui travaille au cours de sprints, dans le but de respecter le backlog, en tirant parti de l'expertise de chacun au cours des réunions quotidiennes, et en apportant son aide chaque fois qu'elle le peut dans le cadre du sprint en cours.

Le résultat final que vous attendez d'une équipe Scrum pleinement opérationnelle est une équipe qui a un fort sentiment d'autonomie et d'appropriation de son travail. L'auto-organisation et la confiance dans leurs capacités pendant les phases de sprint sont nécessaires pour produire les meilleurs résultats pour l'itération du produit.

Une fois ces trois rôles définis, vous pouvez mieux délimiter les responsabilités et réduire l'inefficacité générée par les chevauchements de tâches et les malentendus. La clarté et l'organisation sont essentielles à la gestion de projet Scrum, et restent un principe-clé du fonctionnement des méthodologies agiles dans leur ensemble.