Scrum et Kanban : deux puissantes méthodologies Agiles expliquées

Vous vous apprêtez à gérer un projet complexe ? Il y a tout un tas de travail à faire, mais pas de panique ! En tant que chef de projet, vous serez responsable de la planification, du suivi, de la gestion du budget, de l'exécution, de la vérification de la qualité et de la livraison du projet final à temps. Heureusement, il existe de nombreuses méthodologies de gestion de projet qui peuvent rendre votre travail (et celui de votre équipe aussi) plus facile et beaucoup plus efficace !

Dans cet article, je voudrais me concentrer sur les deux méthodologies Agiles les plus populaires - Scrum et Kanban - qui ont pris d'assaut le monde du développement logiciel ces dernières années. De nos jours, vous trouverez difficilement un éditeur de logiciels qui n'adopte pas ces deux cadres de gestion de projet. De quoi s'agit-il ? Continuez à lire et apprenez tout ce que vous devez savoir sur Scrum et Kanban !

Qu'est-ce que la méthodologie Agile en gestion de projet ?

Aujourd'hui, les entreprises ne travaillent plus sur un seul projet sans le tester à toutes les étapes du processus de développement. Cela ne rapporte tout simplement pas! Pourquoi pas?

Imaginez : toute votre équipe travaille pendant plusieurs mois sur, disons, le développement d'une application mobile, que vous ne testez et n'évaluez qu'à la toute fin, une fois que tout le travail de vos développeurs, designers et rédacteurs backend et frontend est déjà terminé. Et si seulement vous vous rendiez compte que votre produit ne répond plus aux exigences du marché et aux besoins des utilisateurs ? Vous auriez alors besoin d'introduire des itérations ultérieures de l'ensemble du projet, ce qui consomme beaucoup de temps, d'argent et d'énergie.

La méthodologie Agile est donc une excellente solution qui améliore considérablement le flux de travail et facilite la mise en œuvre des changements à chaque étape. Le principe clé derrière Agile est de décomposer un projet "grand" et complexe en plusieurs éléments (ou fonctionnalités) plus petits et de les publier les uns après les autres. Ici, le développement et les tests sont deux activités simultanées, ce qui facilite la validation continue du projet et l'introduction de toutes les améliorations nécessaires.

Ce qui est intéressant, c'est que si l'Agile a prévalu pendant de nombreuses années dans les sociétés informatiques et de développement de logiciels, cette méthodologie s'est avérée si efficace qu'elle est aujourd'hui utilisée dans de nombreux autres domaines tels que le marketing, les ventes, les RH ou les opérations. Selon le rapport sur l'état de l'Agile préparé par Verison One, en 2020, 95 % des entreprises technologiques et des éditeurs de logiciels pratiquaient diverses méthodes Agiles.

Framework Scrum : pourquoi est-ce si génial ?

Beaucoup de gens ont tendance à confondre deux concepts qui, bien qu'ils semblent assez similaires, ne sont pas synonymes : Agile et Scrum. En un mot, Agile est un terme générique qui désigne toutes les méthodes et approches spécifiées dans le Manifeste Agile , tandis que Scrum est en fait l'une de ces méthodes. C'est aussi simple que ça!

Qu'est-ce que Scrum et quand peut-il être utilisé ?

Scrum est un cadre de gestion de projet, appliqué principalement à la construction de produits complexes où le processus de développement prend au moins plusieurs mois. Elle repose avant tout sur la transparence, la communication permanente entre tous les membres de l'équipe et la responsabilité collective. Cette stratégie facilite la livraison de la version finale du projet qui satisfait les besoins du public cible et répond aux demandes actuelles du marché.

Même si Scrum est devenu un framework de premier plan, surtout ces dernières années, ce n'est en fait rien de nouveau. Revenons en 1986 lorsque la Harvard Business Review a publié l'article The New Product Development Game . Là, les auteurs ont décrit une approche de gestion employée par des entreprises comme Honda ou Canon qui a conduit à leur succès. Puis, en 1993, ces concepts ont inspiré Jeff Sutherland et l'équipe d'Easel Corporation à établir un processus d'équipe appelé Scrum.

Rôles et responsabilités dans une équipe Scrum

Dans une équipe Scrum, tous les rôles sont clairement définis dès le début et ne changent généralement pas tout au long du projet. En règle générale, ce framework a 3 rôles fondamentaux : Product Owner, Scrum Master et Development Team.

Maître de mêlée

Un Scrum Master est une sorte de chef d'équipe (mais pas entièrement) qui s'assure que tout est fait correctement et que le processus de développement se déroule sans heurts. Les principales responsabilités d'un Scrum Master sont :

• coacher les membres de l'équipe afin que chacun travaille plus efficacement pour fournir de nouvelles fonctionnalités du produit numérique
• planifier toutes les tâches pour les prochains sprints (ci-dessous, je vous en dirai plus sur les sprints en Scrum) et maintenir le backlog produit
• éduquer les parties prenantes et tous les membres de l'équipe sur l'importance des principes Scrum pour la gestion de projet
• évaluer si toutes les tâches sont exécutées conformément au plan
• essayer d'éliminer tous les obstacles qui entravent la réalisation des tâches dans un sprint donné.

Il est extrêmement important qu'un Scrum Master travaille toujours en étroite collaboration avec un Product Owner . Ensemble, ils planifient les sprints suivants, évaluent la qualité des tâches terminées, définissent une direction pour l'équipe et déterminent si le projet nécessite d'introduire des changements. En termes simples, le Scrum Master fait de son mieux pour aider l'équipe de développement à réussir et à livrer toutes les fonctionnalités à temps.

Propriétaire du produit

Un propriétaire de produit est responsable de la livraison de la version finale du produit qui peut générer des bénéfices commerciaux réels. Ainsi, dans toute l'équipe Scrum, c'est le Product Owner qui fixe les priorités et a le rôle le plus décisif . Ce qui est important ici, c'est que le backlog de produit soit géré par le Product Owner, qui détermine quelles fonctionnalités du produit doivent être développées en priorité, car elles ont la plus grande valeur commerciale.

Voici les principales responsabilités d'un Product Owner :

• gérer le backlog produit
• contacter les parties prenantes
• définir l'objectif principal de chaque sprint
• planifier la sortie de nouvelles fonctionnalités
• évaluer le travail de l'équipe de développement et annuler le sprint si nécessaire

Équipe de développement

Sans une équipe de développement, Scrum ne serait pas possible car ils font le travail réel et accomplissent toutes les tâches planifiées pour des sprints particuliers.

En règle générale, l' équipe de développement est composée de personnes ayant une expertise dans un domaine particulier , tel que iOS, l'apprentissage automatique, le développement backend ou frontend. Ils unissent tous leurs forces pour fournir les fonctionnalités de haute qualité d'un produit numérique. Vous devez garder à l'esprit, cependant, que bien que le terme "équipe de développement" se réfère généralement aux ingénieurs, ce n'est pas toujours exact. Les spécialistes du marketing, les concepteurs, les analystes, les testeurs, les rédacteurs ou les spécialistes des ventes peuvent également apporter une certaine valeur et faire partie d'une équipe Scrum.

L'une des choses à considérer lors de la constitution d'une équipe de développement est le nombre de ses membres. Même ici, Scrum spécifie quelques règles de base ! On dit qu'une telle équipe doit être composée de 3 à 9 personnes et qu'elles doivent avoir les compétences requises pour livrer toutes les fonctionnalités. Bien sûr, tout dépend de la complexité du projet et des besoins du client ; parfois 4 ou 5 développeurs suffisent amplement pour créer un produit numérique.

Mais quel est exactement le rôle de l'équipe de développement dans Scrum ? En gros, il faudrait :

• créer toutes les fonctionnalités du produit conformément aux instructions du propriétaire du produit
• déterminer le nombre d'éléments à construire dans un sprint donné
• gérer efficacement la charge de travail afin que toutes les tâches soient terminées à la fin du sprint
• prendre toutes les décisions pertinentes conjointement
• avoir une attitude « nous » – l'équipe prend toutes les décisions, résout les problèmes ensemble et chacun se sent responsable des autres collègues

Processus de développement Scrum en bref

Vous savez déjà ce qu'est Scrum et qui forme une équipe Scrum, il est donc temps maintenant de comprendre à quoi ressemble le processus de développement dans cette méthodologie et comment le faire correctement.

Dans le processus Scrum, chaque étape compte et apporte une réelle valeur ajoutée à votre équipe. Voici les grandes étapes à ne pas sauter :

1. Product Backlog : Une liste de tous les éléments qui doivent être construits dans les sprints suivants. Il est géré par un Product Owner en collaboration avec un Scrum Master qui sait exactement quand chaque fonctionnalité ou élément doit être publié.
2. Réunion de planification de sprint : L'objectif principal de cette réunion est de définir ce que chaque membre de l'équipe de développement fera lors du prochain sprint. Il est toujours organisé avant le début du sprint afin que chacun puisse évaluer s'il peut terminer toutes les tâches avant la date limite. Assurez-vous que chaque membre de l'équipe saisit pleinement l'objectif principal du sprint.
3. Sprint Backlog : Ce sont les tâches sélectionnées tirées du Product Backlog que l'équipe a choisi d'effectuer dans un Sprint donné.
4. Sprint : C'est là que toute la magie opère. Le sprint est une courte période, qui prend généralement de 1 à 4 semaines lorsque l'équipe de développement travaille à l'achèvement de toutes les tâches assignées lors de la réunion de planification de printemps.
5. Daily Scrums (aussi appelé Standup) : Des réunions extra courtes tenues tous les jours à la même heure, au cours desquelles chacun rend compte de l'avancement de son travail en 1-2 phrases : on parle de ce qui a été fait, et de ce qu'il reste à faire.
6. Sprint Review : Lorsque le sprint est terminé, chacun a la possibilité de présenter ce qu'il a réalisé aux autres coéquipiers et même aux parties prenantes, qui assistent assez souvent aux Sprint Reviews.
7. Rétrospective Sprint : C'est maintenant l'heure de la dernière réunion qui clôture tout le cycle Sprint. Si un membre de l'équipe a des suggestions ou des idées sur ce qui pourrait être amélioré pour le sprint suivant, il peut le faire lors de la réunion de rétrospective du sprint.

Pour le processus Scrum, il est essentiel de s'assurer que chaque cycle Scrum a la même structure : cela commence par une réunion de planification de sprint, puis tout le monde se met au travail et complète les tâches définies pour le sprint, et à la toute fin chaque membre de l'équipe montre ce qu'ils ont accompli.

Il y a encore une chose dont je veux que vous vous souveniez : Scrum a une philosophie de changement très stricte. Qu'est-ce que cela signifie en pratique ? Les membres de l'équipe Scrum ne doivent pas modifier les tâches ou les objectifs principaux pendant le sprint. S'ils ne parviennent pas à fournir les résultats prévus, cela devrait être une leçon pour l'avenir afin de mieux estimer le temps nécessaire pour terminer les éléments.

Quelques mots sur Kanban

Maintenant que vous avez appris ce qu'est Scrum et comment créer un produit numérique avec, il est temps de vous concentrer un peu plus sur la deuxième méthodologie Agile. Je suis sûr que vous le connaissez déjà – même si vous ne vous en rendez pas encore compte !

Qu'est-ce que Kanban et quand peut-il être appliqué ?

Le terme Kanban vient du japonais et peut simplement être traduit par « signal visuel ». C'est essentiellement à cela que sert cette méthodologie. Dans Kanban, chaque élément a sa représentation visuelle - une carte que les membres de l'équipe placent sur des tableaux blancs et modifient son statut (comme « à faire », « en cours » ou « fait »).

Cette approche peut être facilement appliquée par n'importe quelle industrie mais est le plus souvent choisie par les équipes de développement de logiciels impliquées dans des projets complexes et chronophages. Et pour cause, Kanban facilite la communication en temps réel et rend le travail de tous les coéquipiers totalement transparent.

Fait intéressant, Kanban est en fait une méthodologie beaucoup plus ancienne que Scrum. Ses débuts remontent aux années 1940 lorsque Toyota a introduit un système de cartes séparées placées sur des tableaux blancs dans ses usines que les travailleurs pouvaient changer à tout moment. En conséquence, cette stratégie a rendu leur travail beaucoup plus fluide et accéléré la communication entre les équipes.

Qui est qui dans une équipe Kanban ?

Lors de la discussion sur Scrum, j'ai décrit les rôles, responsabilités et compétences exacts de chaque membre de l'équipe (Scrum Master, Product Owner et développeurs). Ici, les choses sont bien différentes. Kanban ne définit pas qui a le plus de pouvoir ou de responsabilités, car pratiquement tous les membres de l'équipe sont égaux et ils unissent leurs forces et leurs compétences collectivement.

De plus, Kanban ne précise pas combien de personnes peuvent travailler ensemble sur un projet, donc toute structure d'équipe est acceptable. Cependant, si vous souhaitez améliorer le flux de travail, vous pouvez envisager de créer une équipe de développement croisé. Grâce à cette solution, les membres de l'équipe avec différents domaines d'expertise peuvent partager leurs connaissances et donner leur avis à chaque étape du développement du produit. De cette façon, il n'y aura pas du tout besoin de consulter d'autres équipes !

Qu'est-ce qu'un tableau Kanban et comment le créer ?

Le tableau Kanban est le cœur et l'âme de cette méthodologie. C'est un outil de gestion de projet créé pour visualiser l'avancement de chaque tâche en temps réel. Si vous vous demandez si vos coéquipiers ont déjà commencé à travailler sur une fonctionnalité importante, ou peut-être l'ont-ils déjà terminée, consultez simplement le tableau et vous savez maintenant !

Cet exemple montre exactement ce qu'est Kanban et comment il visualise le travail :

Ainsi, le concept général derrière les tableaux Kanban est assez simple : vous avez plusieurs colonnes étiquetées et sur chacune d'elles vous placez des cartes visuelles. Ceux-ci peuvent être des stickies ou des tickets. Sur chacune de ces cartes, vous écrivez le nom du projet dans lequel vous êtes actuellement impliqué ou l'élément de travail spécifique que vous construisez. Ensuite, tout ce que vous avez à faire est d'attribuer une carte particulière à une colonne spécifique afin que le reste de votre équipe soit mis à jour et sache exactement sur quoi vous travaillez actuellement.

L'exemple que vous pouvez voir ci-dessus montre des catégories de colonnes typiques, qui sont :

• 'faire'
• 'en cours'
• 'essai'
• 'Fini'

Notez cependant que vous pouvez décrire votre flux de travail plus largement et ajouter des colonnes supplémentaires - leur choix dépendra du projet que vous gérez.

Si vous voulez que votre équipe réussisse, il y a encore une chose dont vous devez être conscient : vous devez définir des limites pour les éléments sur lesquels votre équipe peut travailler en même temps. C'est pourquoi Kanban recommande en outre de définir des limites de travail en cours (WIT) . Comment le mettre en pratique ? Vous devez spécifier combien de cartes peuvent rester dans une colonne (par exemple 'En cours') en même temps. Si votre équipe atteint cette limite, elle ne peut tout simplement pas ajouter plus de cartes. Fixer ces limites est toujours une excellente solution pour faire face à la surcharge de travail.

Scrum vs Kanban : quel framework remporte cette bataille ?

Eh bien, la réponse à cette question n'est en fait pas si simple. Ces deux stratégies Agiles partagent des principes similaires mais les pratiques qu'elles emploient sont deux choses complètement différentes. Alors que Kanban est plus fluide et favorise le changement continu et les retours réguliers, Scrum est beaucoup plus strict et organisé.

Prêt pour votre prochain projet logiciel ?

Travaillons ensemble

Voici les principales différences entre ces deux cadres de gestion de projet :

Alors, lequel de ces frameworks Agiles allez-vous choisir pour gérer vos projets ? Ou aimeriez-vous que les experts le fassent pour vous? N'hésitez pas à nous contacter - en introduisant diverses méthodologies Agiles, nous avons livré plus de 150 produits à succès prêts à l'emploi !