La différence entre Scrum et la gestion de projet traditionnelle

Les personnes qui découvrent le cadre de travail Scrum se posent souvent la même question : Quelle est la différence entre Scrum et la gestion de projet traditionnelle ? La plupart des gens connaissent les bases de la gestion de projet traditionnelle, et cette question est donc un excellent point de départ pour comprendre Scrum et ses avantages.

Approche prédictive axée sur le plan ou approche empirique axée sur la valeur

Gestion de projet traditionnelle

La gestion de projet traditionnelle commence par la planification initiale de tout le travail nécessaire pour obtenir le résultat final souhaité.

Une fois que nous avons rassemblé toutes les exigences probables et analysé les tâches à entreprendre pour mener à bien le projet, un gestionnaire de projet distribue ces tâches à ceux qui possèdent les compétences spécialisées nécessaires. Vient ensuite la phase d’intégration et de test, au cours de laquelle nous rassemblons tous les travaux achevés pour voir si nous avons atteint les résultats souhaités. 

Dans la gestion de projet traditionnelle, les mesures courantes comprennent des éléments tels que le suivi de l’avancement des activités et des étapes franchies (par exemple, l’approbation de la conception, le pourcentage de tâches achevées, les heures effectives par rapport aux heures restantes). Les mesures se concentrent souvent sur le plan lui-même plutôt que sur les résultats tangibles et les indicateurs directs de la valeur.

Scrum

Dans Scrum, nous commençons par recueillir des informations sur les résultats souhaités (la valeur que nous prévoyons de créer dans le produit). Notre équipe identifie ce qui est susceptible d’atteindre le résultat, puis commence à construire le produit de manière itérative et incrémentale sur de courtes périodes appelées « sprints », qui ne dépassent jamais un mois. Cet incrément de produit fournit une valeur utilisable.

Le cadre Scrum nous permet de savoir si ce que nous avons produit est sur la bonne voie (validation). Si ce n’est pas le cas, nous pouvons modifier notre approche en fonction de cette information. Nous avons également la possibilité de livrer de la valeur aux clients plus tôt afin de commencer à obtenir un retour sur investissement.

Ainsi, au cours de chaque sprint, nous avons achevé l’analyse, la conception de la solution, la construction, l’intégration et les activités d’assurance qualité pour une petite partie du champ d’application. Nous ne planifions pas autant en amont parce que nous voulons rester flexibles et apprendre de ce que nous produisons dans chaque sprint. Ce cycle de validation, d’apprentissage et d’adaptation est une approche empirique. Un autre de ses avantages est de se prémunir contre le gaspillage potentiel en planifiant juste ce qu’il faut. Nous utilisons souvent l’expression « prendre des décisions au dernier moment responsable ».

La mesure centrale de Scrum est de savoir si nous avons livré une valeur utilisable à la fin de chaque sprint.

Structure et fonctionnement de l’équipe

Gestion de projet traditionnelle

Les équipes de gestion de projet traditionnelles sont généralement organisées par spécialisation. Nous pouvons avoir des équipes indépendantes d’analyse, de développement, de test et d’assurance qualité. De manière linéaire, une équipe transmet le travail à la suivante au fur et à mesure que les tâches sont achevées.

Les chefs de projet assignent les tâches et contrôlent les progrès. Bien que ces équipes indépendantes puissent collaborer et se rencontrer parfois pour faire le point, il est plus fréquent qu’elles travaillent de manière isolée et qu’elles ne voient la synthèse de leur travail qu’à la fin du projet.

Comme les équipes n’ont pas de visibilité sur l’avancement concret de leur travail ni beaucoup d’autonomie, elles s’appuient sur des spécifications détaillées qui leur disent ce qu’elles doivent faire et comment le faire.

Scrum

Les équipes Scrum sont inter-fonctionnelles, ce qui signifie que toutes les compétences nécessaires à la réalisation du produit sont représentées au sein de l’équipe. Nous avons habilité les membres de l’équipe à s’auto-organiser et à déterminer le travail à effectuer et la meilleure façon de le faire pour atteindre les résultats souhaités.

L’équipe détermine les normes de qualité requises pour qualifier un incrément de travail d’achevé (Définition de « Fini »). Plutôt que les membres de l’équipe soient propriétaires des éléments de travail, c’est l’équipe Scrum dans son ensemble qui est responsable.

Nous pouvons clairement voir les progrès et les problèmes émergents parce que tout le monde collabore à un objectif commun et est impliqué dans l’inspection et l’adaptation de son travail au moins une fois par jour au cours de chaque sprint.

Gestion du changement

Gestion de projet traditionnelle

Dans le cadre d’une gestion de projet traditionnelle, il est plus difficile et plus coûteux d’apporter des modifications. Nous avons fondé notre planification initiale intensive sur de nombreuses hypothèses et décisions précoces.

Comme nous réalisons une grande partie du travail en silos avant de l’intégrer dans une pièce finale, toute nouvelle idée ou tout nouveau besoin est difficile (c’est-à-dire plus coûteux) à prendre en compte parce qu’il nécessite souvent beaucoup de travail supplémentaire. Il se peut que nous ne réalisions pas que notre compréhension initiale des besoins du client était inexacte jusqu’à ce que nous nous engagions à la fin pour la « grande révélation ».

Scrum

Scrum est conçu pour s’adapter au changement et à l’incertitude. De courtes itérations de travail aboutissant à un produit utilisable donnent aux parties prenantes, y compris les clients, de nombreuses occasions de voir comment le travail progresse et s’il répond à leurs besoins. 

Prenons l’analogie de l’utilisation d’un GPS pour un voyage en voiture. Lorsque nous conduisons, nous vérifions fréquemment où nous sommes et où nous devons aller ensuite. Lorsque la technologie nous avertit d’un embouteillage ou d’une fermeture de route, nous pouvons nous repositionner pour trouver un meilleur itinéraire.

Faire face aux risques

Gestion de projet traditionnelle

La gestion de projet traditionnelle comporte beaucoup de risques en raison du long délai qui s’écoule avant de livrer de la valeur au client , ou même d’avoir un produit utilisable. Nous pouvons créer tous les plans de gestion des risques que nous voulons, mais tant que nous n’avons pas livré et prouvé que ce que nous avons livré atteint les résultats escomptés, il s’agit d’un pari très risqué.

Scrum

Dans Scrum, nous reconnaissons que la seule façon de réduire nos risques est de livrer et de valider. De plus, comme l’équipe organise son travail au fur et à mesure qu’il progresse, nous pouvons choisir d’apprendre plus tôt les aspects les plus risqués de notre travail.

Le risque peut se présenter sous différentes formes. Il se peut que nous travaillions avec une technologie nouvelle ou peu familière, et que nous commandions d’abord une petite partie du travail pour nous aider à apprendre comment utiliser au mieux la technologie (ou à changer de technologie). Il s’agit peut-être d’un risque commercial que nous devons gérer.

Il se peut que nous ne soyons pas sûrs que le marché de ce que nous sommes en train de construire soit suffisamment vaste. Le fait de livrer un produit plus tôt nous permet de valider plus rapidement nos hypothèses sur l’opportunité commerciale.

Projets vs. Produits

Gestion de projet traditionnelle

Le Project Management Institute (PMI) définit un projet comme un effort temporaire entrepris pour atteindre un résultat unique. Un projet a donc un début et une fin, et nous ne produisons pas la même chose encore et encore, comme la fabrication de gadgets sur une chaîne de montage. 

En règle générale, un projet unique a un impact sur un ou plusieurs produits, et plusieurs projets peuvent avoir un impact sur un seul produit. Le projet est temporaire, et le produit continue à fournir de la valeur.

Scrum

Scrum est un cadre qui aide les gens à résoudre des problèmes complexes de manière créative et productive, en livrant des produits de la plus grande valeur possible. Le guide Scrum utilise le mot « produit » tout au long du processus pour ne pas perdre de vue l’essentiel, à savoir fournir de la valeur au client.

L’aspect projet du travail est temporaire, alors que le produit qu’il génère vit pour créer de la valeur. Vous pouvez considérer un Sprint comme un projet ou une série de Sprints développant un produit de manière itérative pour atteindre les objectifs du projet.

Les deux concepts sont compatibles et les chefs de projet travaillent efficacement avec les équipes Scrum dans certaines organisations. Ce qui crée des conflits, c’est la façon dont les organisations incitent et mesurent en utilisant un « état d’esprit de projet » plutôt qu’un « état d’esprit de produit ».

Les produits sont des vecteurs de valeur ajoutée. Il peut s’agir d’objets physiques tels qu’un smartphone ou d’un logiciel tel qu’une application. Les services peuvent également être des produits et dépasser les limites d’un projet. Le marketing, la planification financière ou les ressources humaines sont des exemples de produits de service.