Management proactif des dépendances avec les approches agiles

La planification est une activité récurrente dans les approches adaptatives et les dépendances entre User Stories doivent y être identifiées.

Proactive dependency management with agile approaches

https://kbondale.wordpress.com/2019/04/07/proactive-dependency-management-with-agile-approaches/ par Kiron Bondale

Quand nous manageons des projets en une approche de livraison prédictive, l’identification des dépendances et leur suivi est fait lors de la grande planification amont en utilisant les activités après décomposition des tâches et la sagesse collective des membres de notre équipe et des principales parties prenantes. Si un changement majeur d’approche ou de portée de solution est identifié, on considère les impacts et nouvelles dépendances lors de l’analyse de la demande de changement.

Matchware est partenaire de DantotsuPM
scrum methodologie agile
Voici le diagramme du Modèle Scrum

Mais sur ces projets qui suivent un cycle de vie adaptatif, cela devient un peu plus compliqué. Étant donné la nature émergente des exigences et du design, nous sommes seulement capables de voir les dépendances dans la lumière « des phares » de notre équipe et ceux-ci pourraient seulement nous montrer les deux semaines à venir de travail. Une équipe pourrait avoir considéré “Toutes les dépendances ont-elles été identifiées et capturées ?” dans sa définition de Ready (prêt) mais cela ne signifie pas toujours qu’il est possible de satisfaire cette dépendance dans les temps.

CertYou est partenaire de DantotsuPM

Nous nous efforçons toujours de construire une équipe qui possède toutes les compétences et l’autorité nécessaire pour délivrer la pleine portée du produit ou du projet.

Mais parfois, nous avons besoin d’un expert du sujet pour un petit sous-ensemble des fonctionnalités du livrable et si nous n’identifions pas ce besoin assez tôt, nous ne serons pas capables de livrer ces fonctions au bon moment. De plus, construire une équipe complète dans de grandes organisations est souvent difficile car il y a des équipes en place avec lesquelles travailler pour construire et livrer des fonctionnalités spécifiques, mais elles ne seront pas nécessairement disponibles à la demande.

Une façon de réduire les risques associés aux dépendances qui seraient identifiées trop tard est une combinaison de revue des User Stories avec une planification avancée.

La revue des User Stories fournit une occasion de rassembler les partenaires clés de livraison et de contrôle pour considérer les histoires à un haut niveau avec le Product Owner et l’équipe de développement. Cette revue donne aux partenaires externes une chance d’indiquer quelles histoires les intéressent et aidera l’équipe à savoir avec qui elle doit se synchroniser pour compléter l’une de ces histoires. En fonction de combien ces histoires remontent dans la Story Map, ils comprendront comment elles pourraient devoir être engagées. Les membres de l’équipe peuvent aussi commencer à identifier et capturer les interdépendances entre plusieurs histoires individuelles pour aider le Product Owner dans la priorisation du Product Backlog.

Comme les histoires avec des dépendances commencent à remonter dans le product backlog priorisé, l’équipe peut activement entrer en contact avec les partenaires externes pour demander leur participation un sprint ou deux à l’avance.

La planification est une activité récurrente dans les approches adaptatives car sans cela, un partenaire externe dont votre équipe a besoin va probablement répondre par le vieux cliché : “un manque de planification de votre part ne constitue pas un cas d’urgence de ma part.

Biais Cognitifs – La loi du marteau

Nous avons tendance à porter une confiance excessive aux outils avec lesquels nous sommes familiers même en présence de bien meilleures options.

Attention à ne pas vouloir à tout prix utiliser un outil connu pour une fonction qui n’est pas la sienne.

Ce biais est aussi connu sous le nom de la loi de l’instrument ou le marteau de Maslow. Comme l’avait dit Abraham Maslow en 1966, « J’imagine qu’il est tentant, si le seul outil dont vous disposiez est un marteau, de tout considérer comme un clou ».

En quoi suis-je concerné dans mes projets ?

Si le seul outil que connait votre nouveau manager de projet est Excel, il y a de très fortes chances pour que votre Gantt de projet soit réalisé en Excel. C’est déjà beau d’avoir un échéancier, mais il existe des outils plus flexibles en particulier pour gérer les dépendances, la charge des personnes affectées au projet, calculer le chemin critique…

De même, il peut être contre-productif dans votre projet Agile de vouloir faire de tous les besoins des User Stories.

Comment éviter le plus possible ce travers ?

Avant de commencer une tâche importante que vous n’avez jamais réalisée, cherchez à savoir ce qu’utilisent les professionnels du domaine et pourquoi. Le temps d’apprentissage de tout nouvel outil ou technique est souvent surestimé et ses bénéfices sous-estimés. Ne tombez pas dans ce piège.

Ce biais peut-il vous être utile ?

Il arrive que des outils que vous connaissez déjà puissent remplir la mission. Votre expérience peut vous permettre de valoriser le nouvel outil qui vous est proposé à sa juste valeur puis de prendre la décision réfléchie de changer d’outil ou pas.

Un exemple : Lorsque votre projet Agile est déjà bien avancé et que toutes vos User Stories sont documentées dans un outil, même imparfait, il peut être contre-productif de vouloir basculer vers un nouvel outil même plus performant à cause de la nécessaire reprise des données existantes.

Une variante corrélée à ce biais est la fixité fonctionnelle

Nous avons tendance à utiliser les outils et méthodes de la façon traditionnelle dont nous les avons toujours utilisés. Cette tradition d’utilisation existante peut limiter votre capacité à voir toutes les autres choses que ceux-ci sauraient faire.

Par exemple: La matrice des responsabilités des personnes sur le projet peut être adaptée pour produire une matrice de responsabilité des livrables du projet.

CSP est partenaire de DantotsuPM

Pourquoi devriez-vous prendre le temps d’écouter vos utilisateurs ?

Bien que les besoins des futurs utilisateurs soient parfois difficiles à accoucher et demandent du temps, leur bonne compréhension est la clé de la réussite du projet.

Si vous n’avez pas le temps de discuter d’un besoin utilisateur (ou d’une user story en mode Agile/Scrum), vous n’aurez probablement pas plus le temps de le réaliser.

CertYou est partenaire de DantotsuPM

Certes il faut apprendre à dire NON, mais ce n’est pas toujours la meilleure approche dans le management de projet.

Négocier sur le séquencement des livrables est souvent préférable à dire non d’emblée à une nouvelle demande de changement.

Idem au niveau du portefeuille de projets

Est-ce le bon moment pour lancer un nouveau projet ? Devrions-nous renoncer à un projet ? Ou devrions-nous temporiser un peu et positionner ce projet dans le portefeuille de projets à venir ?

Hexagon est partenaire de DantotsuPM

Commençons bien l’année, faisons un peu de ménage dans notre « product backlog » !

Je ne sais pas pour vous, mais j’ai remarqué que nous indiquons rarement une date ou raison de péremption sur nos besoins utilisateurs et autres user stories…

Hors, il n’est pas si rare qu’après une certaine date, jalon projet ou événements internes ou externes, certains des besoins précédemment exprimés (et toujours en attente dans le product backlog) ne soient plus d’actualité.

Qu’en pensez-vous et comment traitez-vous ce problème ?

Est-ce en amont, en indiquant sur la user story une date ou les raisons pour lesquelles elle pourrait devenir inutile ?

Est-ce périodiquement lors de grands « ménages » saisonniers ?

Ou bien, serait-ce plutôt de manière opportuniste, lors par exemple d’un changement d’application de gestion du product backlog ? Ou d’arrivée d’un nouveau product owner, scrum master… ?

CertYou est partenaire de DantotsuPM

pour identifier les besoins de vos clients, une pile de documentation n’est jamais aussi efficace qu’une bonne discussion collaborative.

Envoyer par email un jeu de documents pour exprimer un besoin ou une histoire utilisateur est rarement efficace.

En effet, de nombreux échanges seront nécessaires par ce média pour parvenir le plus souvent à une compréhension fragmentaire et incomplète du besoin. Les histoires d’utilisateurs Agile comme la description des besoins en méthode Waterfall sont plus efficaces en face à face. Le non verbal est très important et le cycle rapide de questions/réponses que permet l’interaction directe ne saurait être remplacé par l’écrit.

CSP est partenaire de DantotsuPM

Il s’agit donc de collaborer pour bien comprendre quel est le besoin, i.e. quel problème est à résoudre, plutôt que de se préoccuper du format de l’histoire utilisateur ou du document.

Idéalement, vous devez tous sortir de la séance de travail avec une représentation très claire de ce à quoi ressemblera le produit ou résultat du changement.

Si vous parvenez à identifier des éléments de mesure simples et fiables et à utiliser pour capturer la situation actuelle et la future souhaitée, vous aurez déjà franchi une étape clé.