Gérer les groupes dont les problèmes vous posent des problèmes

Introduction par Jon Terry, COO de Planview AgilePlace

Nous savons - nous nous extasions beaucoup sur les gens qui nous utilisent pour la construction, la fabrication, la logistique, la réparation automobile, la gestion des talents ou autre. Notre activité à Planview AgilePlace s'est vraiment étendue bien au-delà de nos racines gestion du développement logiciel à présent. Mais nous reconnaissons toujours que notre cœur de métier (ainsi que notre cœur et notre héritage) se trouve dans le département informatique. Et, dans ce vaste domaine, certaines des mises en œuvre Kanban les plus réussies (de Planview AgilePlace ou d'une autre saveur) sont des groupes d'exploitation informatique.

Kanban est tout simplement un ajustement naturel pour les personnes de l'Ops qui veulent être Lean-Agile, mais pour qui l'idée des itérations fixes de Scrum n'a aucun sens. En effet, nous avons vu la vitesse accrue de Scrum causer problèmes aux équipes d'Ops qui s'efforcent d'équilibrer la demande concurrente en évolution rapide. Ils se retrouvent coincés comme punching-ball dans la mêlée des mêlées !

La blogueuse invitée d'aujourd'hui, Dominica DeGrandis, est l'un des leaders d'opinion en matière de Kanban pour les opérations. Elle a elle-même longtemps travaillé dans le domaine des opérations et a longtemps été associée au pionnier du Kanban, David Anderson. Dominica intervient souvent sur le circuit des conférences Lean/Agile/Kanban et propose des formations Kanban destinées aux personnes travaillant dans le secteur des opérations. Elle rédige également le Kanban Weekly Roundup sur le blog de David J. Anderson & Associates. Nous sommes ravis d'accueillir Dominica sur le blog !

Gérer les groupes dont les problèmes vous posent des problèmes

J'ai beaucoup réfléchi ces derniers temps à la manière de gérer les dépendances externes.  J'en suis venu à la conclusion que, a) le terme "externe" doit être amplement défini et, b) le terme "risque" doit être examiné en profondeur.

Si nous définissons le site externe comme étant hors du contrôle de notre département, cela signifie-t-il un autre département au bout du couloir dans la même entreprise ? Ou s'agit-il d'un vendeur de 3^rd partie dans un fuseau horaire différent qui ne se souvient pas du nom de notre entreprise ? En effet, il peut y avoir des situations où il est plus facile de travailler avec un 3^rd fournisseur en Pologne qu'avec le service commercial au bout du couloir.

La clé semble résider dans la compréhension du risque associé à la dépendance. Quel est le coût si la dépendance n'est pas reçue à temps ? Quels sont les antécédents de l'entité externe ?  Les exemples pourraient être nombreux. En voici un échantillon :

• Le groupe qui a "contribué" à ce que notre département rate la date de publication d'une exigence réglementaire, le directeur financier a promis au propriétaire de l'entreprise. Stratégie ? Peut-être que les futures dépendances qui dépendent de ce groupe (s'il existe toujours) ne devraient pas être placées dans la file d'attente des prêts du tableau Kanban avant que ce groupe ne confirme que sa partie est terminée.

• Ou le groupe qui respecte généralement ses délais, mais qui a tendance à optimiser localement ? Stratégie ? Placez peut-être ce type de risque de dépendance dans une zone distincte "En attente de" du tableau Kanban avec des accords de niveau de service (SLA) affichés pour que la direction puisse s'en occuper.

• Ou le groupe qui envoie régulièrement un membre de son équipe à notre standup. Ils s'engagent à "optimiser l'ensemble" de l'organisation au lieu de concentrer leur énergie sur la fonction de leur département. Stratégie ? Peut-être qu'une dépendance de ce groupe pourrait être considérée comme un risque faible et nous pourrions permettre à une carte de dépendance d'être suspendue avec sa carte associée dans notre flux de travail standard. Mais peut-être que notre politique ne l'autoriserait que lorsqu'il n'y a pas de problème.

Lorsqu'un problème survient, la carte de dépendance pourrait se voir attacher un sticky rose indiquant un blocage. Mais est-ce suffisant pour signaler une escalade à la bonne personne ? Même si l'équipe transformait la carte de dépendance en voie d'accélération, à quoi cela servirait-il si le problème ne peut être réglé que par une personne extérieure à l'équipe ? Les questions externes qui échappent au contrôle de notre département nécessitent probablement l'attention de la direction afin de minimiser l'impact du risque.

Nous pouvons considérer les dépendances externes comme différents niveaux de risque. Une gamme de risques de dépendance, si vous voulez, où les dépendances à haut risque sont plus évidentes que les dépendances à faible risque. Idéalement, la carte contient suffisamment d'informations, ce qui permet à l'équipe de réévaluer le niveau de risque si nécessaire - une capacité pratique dans un monde en constante évolution, lorsque les décisions prioritaires antérieures sur le risque peuvent avoir changé - et que tout le monde n'était pas informé.

Les dépendances externes nécessitent une visibilité sur le risque. Nous pouvons démontrer ce risque en introduisant une zone de risque pour les dépendances externes dans notre conception du système kanban . Les cartes Kanban proposant des critères pour déterminer le risque devraient mériter des points de fidélité.

Articles similaires

Vision et tendances, gestion du travail en équipe Nouvelles perspectives de l'enquête The 2018 Project Collaboration Survey [Webcast] (en anglais) 21 juin 2018

Gestion du travail en équipe Un plan global de gestion du travail collaboratif [Vidéo]. 22 juillet 2019

Gestion du travail pour les équipes 4 Raisons d'utiliser les solutions de collaboration de projet 29 mai 2018