[Lean Kanban France] Emergents Patterns for Kanban in IT Ops

Les 18 et 19 Octobre, j’ai eu le privilège de pouvoir assister au premier évènement Lean Kanban France. L’occasion pour moi de plonger dans le monde très intéressant du Lean et de ses pendants, notamment Kanban. Après la Keynote de David Anderson, père de la méthode Kanban, a démarré la première conférence : Emergents Patterns for Kanban in IT Ops, présentée par Dominica DeGrandis. Une session qui a montré les patterns issus d’équipes non pas dev mais de production. C’est parti pour un compte-rendu.

Dominica DeGrandis s’est spécialisée dans l’utilisation de Kanban au sein des équipes de production (IT Ops) et du mouvement DevOps. Sa session parle des problèmes auxquels font face les équipes opérationnelles, et surtout présente les solutions, les patterns, qui ont émergé des équipes utilisant Kanban pour se sortir de ces ennuis récurrents.

“Like the wave work is a moving target”

Un amer constat

Une belle phrase d’introduction, pour faire un constat assez édifiant : sur les 10 jobs les plus détestés, 3 sont dans l’IT !
Le job le plus détesté est d’ailleurs Directeur de département IT, et en 8e position nous retrouvons le “technical support analyst”. Dominica s’est interrogée sur les raisons de ce mépris pour ces emplois, et a énuméré les principales sources d’insatisfaction, on retiendra le stress (le rush lors des livraisons !), les horaires qui peuvent être très variable (un appel en pleine nuit pour un incident de prod, par exemple), la politique et le copinage, les priorités pas claires et très changeantes, ou encore la désorganisation.

Problèmes d’Ops

Suite à ce constat, Dominica expose les 4 principaux problèmes auxquels sont confrontés les IT Ops, et pour chacun, les solutions qui ont été mises en place dans les équipes IT Ops suivies par Dominica.

Equipes distribuées

Premier problème décrit, la communication au sein des équipes distribuées. Comment faire pour synchroniser tout le monde, et mettre à jour les whiteboards ?

Dominica a posé la question sur le groupe Yahoo ‘kanbanops’, et nous a donné une synthèse des réponses que je vous retranscris :

  • des kanbans électroniques partagés, simples et efficaces, comme par exemple Trello, utilisé chez Atalanta
  • un bon système audio/video avec des outils adaptés comme chat60, ou skype
  • des solutions plus onéreuses comme Beam, outil de visio conférence très haut de gamme

Pour la visio-conférence, une petite astuce pour savoir qui a la parole consiste à utiliser un micro que l’on passe à un membre de l’équipe lorsqu’il intervient dans la discussion.

Interruptions

Second problème identifié, beaucoup plus problématique, les interruptions. Comment faire face à celles-ci ?
La règle d’or à appliquer : Il faut rendre visible les interruptions, en mettant un point rouge sur une tâche chaque fois qu’elle est interrompue par exemple.

Pattern : the Goalie
Le Goalie est un rôle spécial endossé par un membre de l’équipe, pour gérer des petites interruptions. Il se doit également d’étendre la base de connaissances et gagne ainsi en flexibilité. Ce rôle tourne chaque semaine.

Pattern pour les règles de taille des tâches
Une chose importante à mesurer est le seuil de tolérance de défauts, au-delà duquel la création d’un ticket devient nécessaire. Il faut comparer le coût de transaction par rapport à la valeur ajoutée du ticket.

If task < n min, just do it !

C’est-à-dire que si une tâche interruptive est assez courte à faire, et bien faisons-là ! Un pattern simple, avec néanmoins quelques exceptions comme :

  • les tâches ayant des dépendances
  • les tâches que seule une personne dans l’équipe sait réaliser

Dépendances

On parle de dépendance lorsqu’une tâche peut être terminée uniquement si une autre tâche externe est accomplie avant. Quelques exemples ont été donné, comme des changements sur la base de donnée par l’équipe data contraignant votre équipe à changer ses scripts de build rapidement, sous peine de devoir effectuer des actions manuellement. Ou des images commandées pour une campagne marketing qui ne sont pas encore disponibles,
Pour gérer la dépendance de tâches, il faut là aussi rendre visible cette caractéristique :

  • Marquer les dépendances entre tâches, avec des dependency tags, en dupliquant une tâche dev et en la plaçant sur le board des OPs, sous une tâche qui dépend d’elle pour être terminée ou en utilisant des tags dédiés dans le cas d’un whiteboard électronique.
  • Réserver un espace “tâches bloquées” bien visible sur le white board pour que, si jamais un problème intervient sur une tâche, ceci soit très facilement visible.
  • Réserver un espace “En attente“, regroupant les tâches externes à l’équipe mais dont l’équipe a besoin, comme par exemple des images a intégré dans un site web.

Pour moi le clou de la session a été la présentation d’un whiteboard qui sort complètement des sentiers battus, jugez plutôt :

Un white board artistique, c’est possible !

Agréable à regarder, avec un coté très ludique, les tâches avancent sur l’autoroute, avec une voie express matérialisant le chemin des “Expedite”, ces tâches prioritaires à traiter en urgence. J’adore.

Spécialisations

Dernier problème présenté, la spécialisation des membres de l’équipe.

(Anti)Pattern : 1 swim lane par individu. Ce pattern couramment mis en place peut mener à une mauvaise interprétation de la performance si quelqu’un a une ligne complète (est-il très en retard ?) ou au contraire a une ligne vide (se tourne-t-il les pouces ?)

Pattern : 1 swim lane par rôle
Dominica conseille de mettre l’accent non pas sur le nom mais sur le rôle des individus. Elle nous cite l’exemple d’une équipe de 7 personnes composée de 5 personnes spécialisées et de 2 personnes polyvalentes. Ces 2 dernières sont représentées par des avatars, attachés sur les tâches sur lesquelles elles travaillent.

Du feedback !

“Team wants feedback”

Dominica poursuit en rappelant que l’équipe veut du feedback du management. Elle propose une technique intéressante à exploiter pour avoir du feedback. Il suffit de remplir 3 post-its pendant une réunion avec le management :

  • I’d like (une action à faire, ou autre)
  • What if (proposition d’amélioration)
  • I wish (souhait, vision, ex : je souhaite que nous n’ayons plus peur)

Nous avons eu droit également à un petit rappel sur les principales frustrations des clients :

  • manque de confiance
  • attentes non respectées
  • communication inadéquate
  • rapidité de livraison

Conclusion

La conférence se termine sur un disclaimer, dans lequel Dominica nous rappelle qu’il faut faire très attention et bien prendre en compte le contexte dans lequel on travaille. Utiliser un autre design pour sa situation peut être risqué et dangereux ! En résumé, plus on gagne de flexibilité, plus on diminue le risque. De ces patterns se dégagent 3 règles d’or :

  • Montrer le risque
  • Montrer les différents types de travail / rôles
  • Traquer et rendre visible les interruptions

La phrase synthétisant tous ces patterns peut s’énoncer ainsi :

Donner de la visibilité à ce qui nous pose problème

Ainsi s’achève cette très bonne présentation de Dominica DeGrandis, instructive et inspirante, qui nous a donné les clés, les patterns pour Kanban afin de résoudre les principaux problèmes auxquels font face les équipes opérationnelles. Il n’y a pas eu de ROTI à la fin, mais en ce qui me concerne, j’aurais mis un 5 sans hésiter.

Nombre de vue : 83

AJOUTER UN COMMENTAIRE