La publication du Manifeste Agile en 2001 a marqué la naissance de l’agilité en tant que méthodologie. Depuis, de nombreux Framework Agiles tels que Scrum, Kanban, Lean et Extreme Programming (XP) ont vu le jour.

Chacun, à sa manière, incarne les principes fondamentaux de répétition fréquente, d’apprentissage continu et de haute qualité. Scrum et XP sont privilégiés par les équipes de développement de logiciels, mais Kanban est le chouchou des équipes orientées services telles que l’informatique et les RH.

Aujourd’hui, de nombreuses équipes Agiles combinent des pratiques de plusieurs cadres différents et les complètent avec des pratiques spécifiques à l’équipe. Certaines équipesvadoptent des rituels Agiles (standups réguliers, rétrospectives, backlogs, etc.), tandis que d’autres créent de nouvelles pratiques Agiles (équipes Agile Marketing suivant le Manifeste Marketing Agile).

Les équipes Agiles de demain privilégieront leur efficacité au respect des dogmes.
L’ouverture, la confiance et l’autonomie deviennent des devises culturelles pour les entreprises qui cherchent à attirer et à maximiser les meilleurs talents.

Ces entreprises ont déjà prouvé que les pratiques peuvent varier d’une équipe à l’autre, tant qu’elles sont guidées par les bons principes.

Le Framework

Les gens confondent souvent Scrum et agilité parce qu’il s’agit d’amélioration continue, qui est le principe de base de l’agilité. Scrum est un cadre pour faire le travail et l’agilité est un état d’esprit. Vous ne pouvez pas vraiment « être agile », car changer votre façon de concevoir la création de valeur pour vos clients nécessite l’engagement de toute votre équipe. Mais vous pouvez vous entraîner à penser de cette façon et à intégrer les principes Agile dans votre communication et votre travail quotidiens en utilisant des Framework comme Scrum.

Le Framework Scrum est heuristique. Il est basé sur l’apprentissage continu et l’adaptation aux facteurs changeants. Il reconnaît que les équipes ne sont pas maitres en tout quand un projet démarre et évoluent avec l’expérience. Scrum est structuré de manière que l’équipe puisse s’adapter naturellement aux circonstances changeantes et aux besoins des utilisateurs, avec une redéfinition des priorités intégrée au processus et des cycles de publication courts afin que cette dernière apprenne et s’améliore constamment.

Scrum est structuré, mais pas complètement rigide. Son exécution peut être adaptée aux besoins de chaque organisation. Il existe de nombreuses théories sur la façon dont une équipe Scrum devrait fonctionner pour réussir. Cependant, s’il y a une chose dont nous sommes sures, c’est qu’une communication claire, la transparence et un engagement envers l’amélioration continue doivent toujours être au cœur de tout cadre que vous choisissez pour votre équipe.

Les artéfacts de Scrum

Les artefacts sont des choses que nous créons, comme des outils pour résoudre des problèmes. Dans Scrum, ces trois artefacts sont le Product Backlog, le Sprint Backlog et l’Increment par définition de « done ». Ce sont les trois constantes d’une équipe Scrum qu’on révise et investit en permanence au fil du temps.

Le Product Backlog est la liste principale des travaux que le Product Owner ou le Product Manager doit effectuer et maintenir.

Un Sprint Backlog est une liste d’éléments, de récits d’utilisateurs ou de correctifs de bugs sélectionnés par l’équipe de développement pour être implémentés dans le cycle de sprint en cours.
Un Increment (ou objectif de sprint) est le produit final utilisable d’un sprint.

Comme vous pouvez le voir, il existe de nombreuses variantes que les équipes peuvent spécifier, même au sein des artefacts. Pour cette raison, il est important de faire preuve d’ouverture d’esprit quant à la modification de la manière dont les artefacts sont gérés. Peut- être que votre définition des « faits » cause un stress négatif sur votre équipe et vous devriez revenir en arrière et choisir une nouvelle définition.

Scrum, Kanban, Agile

Étant donné que Scrum est un cadre Agile très populaire, Scrum et Agilité sont souvent mal compris comme étant la même chose. Mais il existe également des Framework alternatifs populaires comme Kanban. Certaines entreprises ont opté pour un modèle hybride de Scrum et de Kanban, appelé « Scrumba » ou « Kanplan » qui est du Kanban non traité.

Scrum et Kanban utilisent des méthodes visuelles telles que les tableaux Scrum et Kanban pour suivre l’avancement du travail. Les deux se concentrent sur l’efficacité et décomposent les tâches complexes en éléments plus petits et plus faciles à gérer, mais ils abordent cet objectif différemment. Scrum se concentre sur des itérations plus petites et de longueur déterminée. Une fois que le temps du sprint est déterminé, les histoires ou les éléments du carnet de produit qui peuvent être implémentés pendant ce cycle de sprint sont déterminés. Kanban, en revanche, a initialement un nombre fixe de tâches ou de travaux en cours (Work In Progress) à mettre en œuvre dans le cycle en cours. Le temps nécessaire à la mise en œuvre de ces fonctionnalités est ensuite calculé à l’envers.

En revanche, Kanban est structurellement différent de Scrum. Scrum a certains concepts de catégorie qui s’appliquent dans le cadre de sa mise en œuvre. Revues de sprint, rétrospectives, mêlées quotidiennes, et plus encore. Il prône également la transversalité, la capacité d’une équipe Scrum à ne pas s’appuyer sur des membres externes pour atteindre ses objectifs. Le but ? Construire une équipe interfonctionnelle. En ce sens, Kanban est adaptable et Scrum peut être vu comme un changement fondamental dans la façon dont les équipes de développement pensent et travaillent.

Mais pourquoi Scrum ?

Le Framework Scrum lui-même est simple. Règles, artefacts, événements et rôles faciles à comprendre. En fait, son approche semi-prescriptive aide à lever l’ambiguïté du processus de développement tout en laissant une grande marge de manœuvre aux entreprises pour ajouter
leurs propres touches personnelles.

En organisant des tâches complexes en user stories gérables, il est parfait pour les projets ambitieux. De plus, une distinction claire entre les rôles et les événements planifiés garantit la transparence et la responsabilité partagée tout au long du cycle de développement. Les
versions rapides gardent l’équipe motivée et les utilisateurs satisfaits, car on peut voir les progrès immédiatement.

Cependant, cela peut prendre un certain temps pour bien comprendre Scrum, surtout si votre
équipe de développement est habituée au modèle typique en cascade. Le concept de petites itérations, de réunions scrum quotidiennes, de revues de sprint et de la désignation d’un scrum master peut être un changement culturel difficile pour une nouvelle équipe.

Mais les avantages à long terme l’emportent largement sur la courbe d’apprentissage initiale.
Le succès de Scrum dans le développement de produits matériels et logiciels complexes dans de multiples secteurs et secteurs verticaux a fait de Scrum un cadre essentiel pour les entreprises.