Kanban pour une équipe infra Office

Contexte de l’équipe infra office

Continuons notre tour d’horizon de différents contextes d’utilisation de tableaux Kanban. Aujourd’hui, je vous propose de découvrir une équipe infra Office, en support de l’office management. L’office management a également son propre tableau de tâches, en dépendance avec cette équipe. Cette équipe doit gérer des incidents (messagerie par exemple), des demandes de services (nouveau PC par exemple), des projets (déploiement de nouvelles versions) et de l’amélioration continue. C’est un des pôles de l’équipe infra comprenant entre autre les équipes Data center & hardware et système infra. Elle a des problématiques communes de supports, de demandes qui excèdent sa capacité, de changements de priorité, …

Structure du tableau Kanban de l’équipe infra office

L’équipe a donc mis en place un tableau kanban ayant fortement évolué ces derniers mois. En voici la dernière version : Une des particularités de ce tableau est d’avoir deux flux de tickets traités de manière différente.

La partie flux tiré

Dans la partie haute du tableau, on retrouve la partie correspondante au flux tiré. Ce sont des tickets opportunistes : des incidents et demandes de services qui ne posent pas de problème, sans dépendance, réalisables, maîtrisés, … L’équipe engage des tickets lorsqu’elle en a la capacité.

La partie planifiable

Dans la seconde partie du tableau, ce sont les tickets à planifier/planifiables. On y retrouve tous les tickets non opportunistes (avec dépendance, nécessitant une qualification, …) ainsi que toutes les tâches de désendettement et d’amélioration (correspondant à la classe de service intangible du modèle du coût du délai), et d’autres catégories plus spécifiques (packaging / déploiement, sécurité, …). L’équipe a cadencée son activité de planification/injection de tickets à une semaine. Cette cadence est appelée sprint, pour utiliser le même vocabulaire que les autres équipes, et aussi pour signifier qu’il y a une notion d’engagement sur le périmètre à réaliser, bien qu’elle ne soit pas aussi marquée que dans Scrum (il n’y a pas de démo par exemple). Le tableau est utilisé par l’équipe tous les jours. Pour cette deuxième partie, voici les différents déplacements possibles d’un ticket (cf. schéma précédent) :

• Phase 1 : le ticket est planifié dans un futur sprint (le prochain S ou celui d’après S+1) et passe du backlog au sprint backlog.
• Phase 2 : un équipier tire le ticket et commence le travail.
• Phase 3 : potentiellement, le ticket passe en attente, souvent à cause d’une dépendance externe (besoin d’infos complémentaires par exemple).
• Phase 4 : l’équipier relance le demandeur du ticket ou le fournisseur pour débloquer le ticket et le finir. Il peut le relancer 3 fois. Sans réponse, le ticket peut être archivé. Cette partie avec 3 relances est très intéressante car on ne limite pas le nombre de tâches mais le nombre d’actions sur une même tâche. C’est une limite structurelle.
• Phase 5 : le ticket est débloqué, l’équipier finit le travail.
• Phase 6 : Le ticket est terminé. Il restera dans la colonne « done » jusqu’à la fin du sprint.

Les tickets représentent une charge de travail de quelques heures en général. Et voilà concrètement le tableau en œuvre :

Et les limites dans tout ça ?

Limite Kanban sur la partie planifiable

L’équipe infra office a pu mettre en place une première limite sur la partie ticket planifiable, à savoir le backlog sprint S, plus le WIP et le WIP après attente. La limite correspond à sa capacité à faire sur un sprint.

Les problèmes

La première difficulté liée à la mise en place de limite est la partie WIP après attente. Ce sont les tickets débloqués. C’est une partie que l’équipe ne maîtrise pas. Le choix a quand même été fait de prendre en compte les tickets dans cet état. Ensuite, Les tickets peuvent avoir une Due Date. Cela correspond à la classe de service Date Fixe du modèle du coût du délai. On sait que ce type de tickets perturbent le flux de travail de l’équipe. On sait également qu’il y a en général peu de vrais tickets de ce type, car une Due Date doit correspondre à une contrainte business (passage en vigueur d’une réglementation, début des soldes, période de noël, …) et non une date d’engagement projet (jalon, date d’un contrat). Pour cette équipe, il y a trop de Due dates par rapport à la capacité de l’équipe : la limite de la partie planifiable est atteinte avec seulement ces tickets. C’est peut être, pour les demandeurs, une manière de faire passer des tickets sans qu’ils ne soient toujours prioritaires. Je constate en règle générale une sur l’utilisation des due dates. C’est à vérifier car certains tickets de l’office management ont de vraies contraintes de date : l’arrivée d’un nouveau collaborateur déclenchant l’achat d’un nouveau PC, et tout ce qui s’en suit. Ce point peut être cause de frustration côté Product Owner : quelle est la valeur ajoutée d’un Product Owner lorsque les choix sont mécaniques (la limite est atteinte par les seuls tickets avec Due Date) et ne laissent pas de place à l’arbitrage, la priorisation, …

Les pistes d’amélioration

Le tableau Kanban pour cette équipe infra office va évoluer. Les prochaines pistes d’évolution concernent les limites de la partie flux et la qualification des tickets avec Due Date.

Concernant les limites kanban

Les prochaines cibles pour les limites sont les lignes concernant le flux tiré des tickets opportunistes. Ces limites seront basées sur le débit de tickets (nombre de tickets sortant par semaine). Aujourd’hui, l’équipe est déjà dans un mode de flux tiré, des limites implicites existent. Mais n’étant pas formalisées, elles peuvent varier. C’est le cas lorsque le nombre de tickets ayant des Due Dates pour le sprint est plus important que la limite du sprint. Pour l’instant, ces limites sur la partie flux ne peuvent pas être fixées car elles ne pourront pas être tenues par l’équipe. Le problème d’ajustement Due dates / limites de sprint doit être réglé avant.

Les tickets de type Due dates

Le premier objectif est donc de challenger les demandeurs sur la qualification des demandes avec Due Date pour en diminuer le nombre. Si ce nombre est avéré, il faudra trouver une manière de mieux les gérer. Visuellement, une idée pourrait être de voir à l’avance la charge des sprints en Due Date pour mieux négocier les dates réelles et lisser la charge :