Les trois principales plaintes dont j'entends parler de la part de mes étudiants et que j'ai constatées dans les équipes que j'ai soutenues :
Dépendances
Pression exercée par les parties prenantes pour qu'elles prennent en charge le travail sans tenir compte de leurs capacités
Exigences floues
Cela vous semble-t-il familier ? Nous allons nous concentrer sur les dépendances.
Pour les équipes Scrum, les dépendances sont un vestige de la gestion de projet traditionnelle, où le travail passe par des équipes de spécialistes qui effectuent un travail spécifique : Analyser, Concevoir, Construire, Tester, Déployer. Le projet avance lentement d'une phase à l'autre. Pour "utiliser efficacement les ressources", nous faisons travailler ces membres de l'équipe sur plusieurs projets afin de nous assurer qu'ils ne restent pas inactifs. D'un point de vue comptable, cela permet de maximiser le retour sur investissement des effectifs, en faisant tourner les experts comme des rouages dans une machine, de sorte que les temps morts disparaissent des feuilles de calcul. Cependant, l'accent est mis sur le fait de rester occupé plutôt que de produire un travail sur lequel nous pouvons obtenir un retour d'information ou apporter de la valeur.
Les équipes Scrum s'attaquent toujours à ce même travail, mais le grand changement est que nous allons le faire en un seul sprint. Nous nous concentrons sur la concrétisation d'une idée, ou d'une hypothèse de valeur, en mettant à jour notre produit. Mes étudiants répondent : "Ummmm... ok... ça a l'air intéressant, mais comment ?"
La première chose à faire est de regarder la réalité en face. Vous ne pourrez pas changer le mode de fonctionnement de toute votre organisation en vous basant uniquement sur une idée ; vous avez besoin de preuves. Une tendance intéressante que j'ai observée est que les équipes veulent des études de cas d'entreprises similaires qui ont réussi à le faire. Cela revient souvent à multiplier les excuses ("nous n'avons pas leur financement", "nous n'avons pas leur stack technologique", etc.
Je vous recommande de concentrer vos efforts sur la création d'une expérience. Obtenez l'accord pour réunir toutes les bonnes personnes pour un seul Sprint, sans autres distractions, et voyez ce qu'elles peuvent faire lorsqu'elles sont autorisées à travailler ensemble. L'objectif est de transformer au moins une idée en un travail réalisé qui peut être utilisé pour obtenir un retour d'information, et peut-être même apporter une plus grande valeur à votre client.
C'est le premier domino à tomber pour créer un changement plus important. Démontrez qu'une équipe travaillant ensemble, sans dépendances ou distractions externes, peut transformer une idée en une véritable mise à jour du produit qui invite les parties prenantes à fournir un retour d'information ou, mieux encore, qui permet à l'équipe d'obtenir la validation des clients. La question qui se pose alors est la suivante : "Sommes-nous prêts à réaliser un autre Sprint de ce type ?". Si vos parties prenantes ont constaté un changement souhaitable, cela peut créer une envie d'en faire plus. Ce peut être le pivot qui transforme les sceptiques en partisans, parce qu'ils ont vu que cela fonctionnait pour eux dans leur propre contexte.
Si vous êtes prêt à tester cette méthode lors de votre prochain Sprint, mais que vous avez besoin d'aide pour obtenir l'adhésion initiale, ou de soutien pour que votre équipe se concentre sur la collaboration, n'hésitez pas à nous contacter, contactez-nous à Improving. Nous avons l'habitude d'aider les équipes à réaliser leur premier grand Sprint. Discutons ensemble et faisons tomber votre premier domino.
