Product Owner est un rôle prescrit par le cadre Scrum. On parle de « Product » Owner car dans un contexte Scrum, on gère habituellement un produit qui est généralement un logiciel autonome. Les responsabilités du Product Owner sont de maintenir un carnet de produit (product backlog), de garder un canal de communication avec les parties prenantes et de répondre aux questions de l’équipe. Son objectif principal est de maximiser la valeur apportée par l’équipe en priorisant le carnet (backlog).

Le premier principe de la méthode Kanban est de commencer avec ce que vous faites maintenant. Par conséquent, si vous débutez avec Kanban, il n’est pas nécessaire d’introduire un nouveau rôle appelé « Product Owner ». De plus, la méthode Kanban est généralement adoptée dans un contexte de livraison de services. Il est difficile pour une seule personne de maintenir et de prioriser un carnet lorsque les gens faisant le travail sont bombardés par les demandes de nombreux autres groupes à l’intérieur ou à l’extérieur de l’organisation.

Chacun veut obtenir ce qu’il a demandé MAINTENANT! Alors, comment satisfaire tout le monde? Au lieu de consacrer beaucoup de temps et d’énergie à la priorisation, Kanban offre une alternative simple : les classes de service. Les classes de service sont utilisées pour classer des types de demandes spécifiques en niveaux d’urgence.

Les classes de service

La méthode Kanban propose quatre archétypes de classes : Standard, Date fixe, Intangible et Accélérée. Chaque fois que vous recevez une nouvelle demande, elle doit être catégorisée dans une de ces classes de service. Pour chacune de ces catégories, le délai de livraison requis sera différent.

La plupart de vos demandes doivent être traitées en utilisant la classe Standard. Les demandes à date fixe ont une date de livraison spécifique et doivent être traitées avec plus d’urgence que les articles standards afin de respecter la date butoir. Les éléments intangibles sont la priorité la plus basse. Ce sont généralement des tâches qui n’affectent pas directement le client, comme une mise à jour logicielle ou une sauvegarde manuelle. Les demandes accélérées doivent quant à elles être seulement occasionnelles et avoir la priorité sur toutes les autres classes de service.

À lire aussi : Quand est-ce que ce sera prêt? Les mesures du flux et le Kanban

Mais comment prioriser plusieurs éléments d’une même classe de service? Vous ne le faites pas! Vous les traitez tout simplement comme suit : premier arrivé, premier servi. Il faut souvent plus de temps pour décider dans quel ordre faire le travail que pour simplement le faire!

Niveaux de service

Gardez à l’esprit que vous n’êtes pas limité à ces quatre classes de service, c’est à vous de déterminer si elles vous conviennent. Vous pouvez définir vos propres classes de service. N’oubliez pas que chaque classe aura son propre niveau d’urgence et que le délai pour livrer les éléments sera différent. Cette information vous aidera à définir l’expectative de niveau de service (SLE — Service Level Expectation) pour chaque classe de service, à partir de laquelle vous pourrez ensuite négocier l’entente de niveau de service (SLA — Service Level Agreement) avec vos clients.

Mais que faire si nous avons vraiment besoin de prioriser les éléments d’une même classe de service? À qui revient cette responsabilité? Cela dépend vraiment de votre contexte. Si vous estimez que vous devez absolument prioriser votre travail, quelqu’un pourrait porter le chapeau du gestionnaire de demandes de service (Service Request Manager).

Bandeau_Campus_Kanban

Le gestionnaire de demandes de service

Le gestionnaire de demandes de service est responsable de comprendre les besoins des clients et leurs attentes. Contrairement au Product Owner dans une équipe Scrum, il ne doit pas nécessairement s’agir d’un rôle formel. Ce pourrait simplement être la personne la plus expérimentée du groupe ou le rôle pourrait être tenu en alternance. Avec l’aide du groupe, le gestionnaire de demandes de service va ordonnancer les tâches du carnet et faciliter la sélection de ce qui doit venir ensuite.

Et si dans mon équipe, nous transformons notre façon de travailler de Scrum à Kanban? Devrions-nous abandonner le rôle de Product Owner? Bien sûr que non! Gardez votre Product Owner si vous y êtes habitué. Rappelez-vous le premier principe de Kanban : commencez avec ce que vous faites maintenant. Cela signifie que vous n’avez pas à introduire de nouveaux rôles, mais aussi que vous n’avez pas à en éliminer! Et si vous êtes dans un contexte où vous gérez un produit, vous avez peut-être besoin de ce Product Owner pour maintenir le canal de communication ouvert avec les parties prenantes.

Alors, avez-vous besoin d’un Product Owner si vous utilisez la méthode Kanban? Vous n’avez pas besoin d’introduire ce rôle si vous ne l’utilisez pas déjà. Par ailleurs, il est possible que le besoin d’un gestionnaire de demandes de service apparaisse par lui-même au fil du temps. Mais si vous avez déjà un Product Owner dans le groupe, vous pouvez conserver ce rôle si c’est sensé dans votre contexte, car il est également possible qu’il disparaisse tout seul au fil du temps.

Si vous souhaitez en apprendre plus sur la méthode Kanban, Pyxis offre du coaching Kanban ainsi que des cours certifiants de la Lean Kanban University : Team Kanban Practitioner (TKP),et Kanban Management Professional (KMP II).

Savoir Agile

Billet précédent

L’écoute active dans le coaching - Partie 2

Billet suivant

Histoires d’Agilité dans les opérations TI

2 Commentaires

  1. jgosselin@investpsp.ca'
    Jonathan Gosselin
    15/03/2018 at 14:24 — Répondre

    Bonjour,

    Je remarque qu’il n’y a pas de date prévues pour KMP I et II, en prévoit-on dans un futur rapproché ?

    Merci,

    Jonathan Gosselin

Laissez un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.