Charte graphique : de sa création à sa mise en application !
Qu'est-ce que la charte graphique ? Découvrez les étapes essentielles de sa création et de sa mise en application pour une identité visuelle cohérente
La méthode Scrumban est l’une des méthodes agiles qui combine, comme son nom l’indique, les principes clés des frameworks Scrum et Kanban. On y retrouve donc des itérations courtes issues de la méthode Scrum ainsi qu’une dynamique d’amélioration continue évolutive et adaptative drivée par une bonne gestion des flux via la méthode Kanban.
En Scrumban, la priorisation des demandes utilisateurs ou métiers se fait au fur et à mesure de la capacité d’avancement de l’équipe produit. Il ne s’agit pas de planifier à l’avance les fonctionnalités à développer, comme on le pratique en Scrum, mais de prioriser les User Stories en temps réel afin de délivrer aux utilisateurs finaux le maximum de valeur dans les meilleurs délais.
Enfin, cette méthode ne précise pas les rôles attribués aux membres de l’équipe (au même titre que la méthode Kanban). Chaque membre est donc autonome et responsabilisé et c’est à eux qu’incombe le choix des tickets à réaliser au regard de leurs spécialisations.
Maintenant que les bases sont posées, allons plus dans le détail de cette méthode agile.
Il n’est jamais simple de choisir la méthode agile la plus appropriée pour le développement de son produit mais certains contextes sont propices à son utilisation.
Pour passer à la méthode Scrumban, le point de départ sera de mettre de côté la logique par tâches (issue du framework Scrum) au profit d’une logique par flux (issue du framework Kanban).
Représentation graphique du mix des deux frameworks Scrum et Kanban Source :
Il ne s’agit plus de découper des User Stories en sous-tâches fonctionnelles ou tâches techniques mais de faire avancer les User Stories dans leur ensemble du début à la fin du board visuel. Cette absence de détails permet à l’équipe produit de prendre des décisions efficaces au quotidien.
En Scrumban, la définition des différentes colonnes du board visuel de l’équipe par lesquelles les User Stories transitent est capitale.
Généralement, les équipes partent d’un board classique avec les colonnes : “A faire”, “En cours” et “Fini” auquel elles peuvent ajouter les étapes réelles du workflow par lesquelles les User Stories passent.
Source : formation Hubvisory
Il est important de noter que les ajouts de colonnes sur le board visuel ne sont pas toujours nécessaires, chaque projet ayant ses spécificités propres.
Par souci de praticité et dans la majorité des cas, chaque action d'une colonne est attribuée à un membre de l'équipe. Ainsi, le passage d’une colonne à une autre formalise le fait que la User Story passe à un autre état et est prise en charge par une autre personne de l’équipe. Cette convention permet de visualiser en un coup d'œil le “qui fait quoi ?”.
Suivant les sujets et les équipes produit, les colonnes fréquemment ajoutées à un board visuel classique peuvent être les suivantes :
Source : formation Hubisory
Évidemment cette liste n’est pas exhaustive, chaque équipe est libre d’ajouter les colonnes représentant le mieux le workflow réel de son organisation. On peut toutefois inclure au board visuel des colonnes supplémentaires pour d’autres acteurs que les Product Owners et les Développeurs comme pour les UX / UI Designers, responsables métiers et / ou marketing, etc…
En Scrumban, la quasi totalité des rituels du framework Scrum est conservée excepté le rituel du Sprint planning. En effet, comme le Product Owner alimente fréquemment la colonne “A faire” du board visuel, il n’y a donc pas à proprement parler de Sprint planning en début d’itération. L’équipe produit privilégiera alors des ateliers réguliers de présentation de User Stories (on peut même parler de “mini-grooming”) bien plus courts que des Sprints planning classiquement effectués sous Scrum.
Cette façon de faire permet à l’équipe produit de prendre plus de temps pour l’analyse des User Stories et d’éviter ainsi les nombreux allers/retours technico-fonctionnels.
En Scrum, il est important de présenter lors de la démonstration l’ensemble des fonctionnalités embarquées en Sprint planning.
En revanche, en Scrumban, l’équipe décide d’employer ce rituel de démonstration comme un “rendez-vous” durant lequel elle présente ce qu’elle a terminé pendant la période, et c’est tout ! En effet, il est très fréquent qu’en fin de sprint il reste des User Stories dans la colonne “En cours” du board visuel. Ces dernières ne sont donc pas présentées en démonstration et seront donc terminées lors de la prochaine itération.
Il n’est donc pas rare de se retrouver dans le cas de figure ci-dessous :
Source : formation Hubvisory
C’est bien là que réside toute la complexité de Scrumban et que l’on constate la maturité d’une équipe produit.
Pour faciliter et simplifier la tenue des objectifs et maintenir une organisation d’équipe efficace sans cadre fixe, des limites WIP (Work in Progress) sont mises en place. Le principe derrière ces limites WIP réside dans le fait de limiter le travail en cours. On compte ainsi une tâche par Développeur et tant que cette tâche n’est pas terminée, autrement dit, tant que cette tâche n’est pas passée par toutes les étapes du workflow du board visuel, le membre de l’équipe ne passe pas à autre chose. La règle est donnée : on termine ce qui a été commencé.
Cette dynamique de flux tirés et de développement continu provoque une évolution profonde du rythme de travail du Product Owner qui doit alimenter au fur et à mesure l’itération en User Stories dans la colonne “A faire”. Ainsi il n’y a jamais de trou dans la raquette ou de pénurie de travail. Tous les membres de l’équipe produit ont toujours des tickets à se mettre sous la dent permettant d'asseoir un rythme de développement quotidien et constant.
Maintenant que les grands principes de cette méthode sont clairs, parlons des principaux avantages de Scrumban.
La méthode Scrumban a l’avantage :
Une méthode sans inconvénient ça serait bien trop facile.
Ci-dessous plusieurs réticences à partir sur la méthode Scrumban :
Evidemment, les deux listes ci-dessous ne sont pas exhaustives mais permettent d’avoir une vue d’ensemble sur les contours de cette méthode.
La méthode Scrumban est l’une des méthodes agiles les plus agiles puisque son application permet aux équipes de s’auto-gérer, d’accueillir le changement et de prioriser le quotidien afin de répondre dans les meilleurs délais aux besoins des utilisateurs.
La flexibilité de cette méthode permet également à l’équipe produit de gagner du temps sur l’animation des rituels. Fini les Sprints planning interminables, bonjour aux ateliers courts et réguliers vecteurs de cohésion et de productivité !
A vous de jouer maintenant et d'insuffler la dynamique Scrumban à vos équipes produit (si le contexte le permet bien évidemment).
Nous croyons en un nouveau modèle de consulting où l’excellence commence par l’écoute, le partage et une vraie vision