Episode 5 : Le Workflow

Effective PSK — Episode 5

Le guide Kanban pour les équipes Scrum nous indique explicitement l’utilisation d’un board Kanban pour visualiser le Workflow.

Pour commencer, chaque équipe doit avoir défini leur Workflow. Cela signifie, qu’elle doit identifier les règles de visualisation et de fonctionnement de l’équipe mises en oeuvre dans leur système.

Les membres définissent une compréhension partagée au sein de l’équipe Scrum, c’est-à-dire, la façon dont le travail est défini, l’état de début du processus, les états actifs, et l’état fini des éléments de travail. L’ensemble des règles qui régissent le processus a pour effet de renforcer la transparence.

Voici quelques exemples de règles que nous pourrions inclure dans le Workflow :

• Les étapes d’arrivées et de départs et leurs définitions
• Le type des éléments de travail et son unité de valeur
• Les règles de WIP Limit et les mécanismes de tirage
• Le niveau du Service Level Expectation
• Une définition partagée du Done (DoD)
• Les règles de priorisations

Au sein de notre Workflow, il sera nécessaire, au minimum, de représenter un état actif, c’est-à-dire un état où les éléments sont démarrés (WIP), et des WIP Limit, afin de mettre en place un système basé sur un flux tiré.

Notons que Scrum possède ses propres politiques explicites. Par exemple la Definition of Done, la définition d’un Sprint Goal, ou encore, consacrer 10% du Sprint pour le raffinage.

La responsabilité de la définition du Workflow dépend de la portée et des limites du flux de travail. Par exemple, à l’intérieur du Sprint Backlog, la responsabilité appartient à l’équipe de développement. Si une représentation plus élargie du Workflow est décrite, comme l’analyse des éléments du Product Backlog, alors la responsabilité concerne toute l’équipe Scrum. Dans ce sens, il favorise l’auto-organisation des membres.

Certains Workflows pourraient même s’étendre en dehors des limites du projet et impliqueraient également d’autres personnes.

Pratique : “Visualisation du Workflow — Le board Kanban”

La gestion visuelle joue un rôle important dans la culture Lean. Elle fait partie des éléments qui garantit que nous pouvons atteindre le Jidoka (autonomisation). Le Jidoka vise à mettre en évidence les causes des problèmes afin d’empêcher la production de produits ou de services défectueux.

Kanban est un dispositif de signalisation qui tire le flux à travers un processus. Il optimise le Flow en améliorant l’efficacité globale. Un de ces objectifs est de créer une vue visible et claire pour garantir que toute perturbation du workflow puisse être identifiée.

La visualisation du flux de travail réside dans la capacité à voir l’ensemble des étapes de notre processus nécessaire pour livrer notre travail, ceci par l’intermédiaire d’un tableau (board) et de cartes kanban. Ainsi, il renforce la communication et la transparence.

Cette vision élargie du processus représente l’un des avantages pour une équipe Scrum. Généralement, les équipes se concentrent, instinctivement, dans la visualisation du Sprint Backlog, réduisant la transparence à un sous ensemble du système (le développement). Là où le board Kanban pourrait visualiser le flux de travail dans sa globalité, du début de l’idée à la mise en production. Ceci a pour effet d’augmenter la transparence, la détection de problèmes, les goulots d’étranglements, et de favoriser la collaboration.

Les éléments de travail qui circulent au sein du flux de travail représentent les éléments du Backlog Produit (Product Backlog Item) plutôt que des tâches. En effet, les PBI représentent notre valeur. Aucune règle n’indique le sens de transition d’un élément, ni même, si ce dernier doit passer par toutes les étapes (bien que les politiques définies par l’équipe puissent restreindre cela).

Pratique : “Inspecter et Adapter la Définition du Workflow”

Comme il est indiqué dans la dernière pratique du guide, la définition du Workflow peut être inspectée et adaptée à tout moment. Il n’existe pas de règles. Cependant, il serait préférable que cela soit fait au cours d’une Sprint Retrospective.

Comment planifier les éléments de travail dans le Workflow ?

Lors d’un passage vers la méthode Kanban, il peut arriver que les équipes décident d’abandonner le Sprint Planning pour laisser place à la planification des fonctionnalités juste-à-temps (Just-in-Time), jugeant inintéressant la planification sur quelques semaines.

Ici, l’équipe continue d’utiliser le Sprint comme fenêtre de temps, en débutant par un Sprint Planning. D’une certaine manière, le Sprint représente une planification juste-à-temps. La période de développement est réduite à une période plus courte accompagnée d’une demande réelle du client.

Le but de la réunion est de s’aligner collectivement sur un objectif à atteindre. Le Sprint Goal reste toujours nécessaire et obligatoire. Il renforce le focus et donne un sens sur l’incrément à développer. De plus, le Sprint Goal devient plus important dans une stratégie Kanban. Il protège l’équipe sur le travail aléatoire d’élément au cours du Sprint.

Dans le prochain épisode, nous discuterons des WIP Limit et comment ils nous permettent d’optimiser le flux de travail.

Points clés :

• Le Workflow définit les règles du processus
• Chaque équipe doit définir son Workflow
• Définit une compréhension partagée
• Un Workflow possède au minimum un état actif et WIP Limit
• L’équipe est responsable de la définition du Workflow dans sa limite de portée
• La définition du Workflow peut être inspectée et adaptée à tout moment
• Un élément de travail est un item du Product Backlog (PBI)
• Augmente la transparence du processus
• Le Sprint est utilisé comme fenêtre de temps
• Le Sprint Goal reste obligatoire et renforce le focus