L'investisseur légendaire Warren Buffet a déclaré que l'habitude fondamentale qui sépare les personnes qui réussissent des personnes qui réussissent très bien, est que ces dernières disent non à presque tout. De toute évidence, les équipes de marketing agile très performantes empruntent le livre de jeu de M. Buffet, car par rapport à leurs homologues, elles sont suprêmement douées dans l'art de dire non.
Ce qui rend ce trait encore plus impressionnant, c'est que les équipes de marketing conventionnelles - y compris celles qui réussissent très bien - ont généralement été câblées pour dire oui à pratiquement toutes les demandes et tous les changements. En fait, l'assentiment du marketing est tellement présumé dans certaines organisations, que les demandes ne sont pas vraiment des demandes. Il s'agit essentiellement d'ordres, bien que l'on y ajoute, à des fins esthétiques, un bref "cela vous dérangerait-il ?" ou "pouvez-vous nous aider ?".
Pourtant, lorsque des équipes de projet conventionnelles adoptent un paradigme agile, l'une des premières choses qu'elles doivent faire est d'apprendre à dire non. Ce n'est pas parce qu'ils le veulent. C'est parce qu'agile est construit sur trois piliers intégrés :
- Hiérarchiser le travail et se concentrer sur ce qui compte le plus par rapport à ce qui compte le moins.
- Faire passer les travaux prioritaires par un flux de travail normalisé (par ex. créer, revue 1, revue 2, lancement prêt, à lancer, terminé).
- Limiter le nombre de tâches dans chaque phase du flux de travail.
Les équipes agiles qui ne savent pas dire non sapent cette intégration - et ouvrent la porte au chaos et à l'échec. Plus personne ne sait quelles tâches sont prioritaires, car tout est prioritaire. Les flux de travail cessent d'être fluides car les tâches s'entrechoquent. Et les membres de l'équipe subissent une charge de travail écrasante et sans fin qui entraîne un désengagement et un épuisement professionnel, ainsi que des problèmes de qualité, des délais non respectés, des clients mécontents et des résultats médiocres.
Alors, comment les équipes agiles peuvent-elles apprendre à dire non, mais sans déclencher de conflits sans fin, ou être injustement perçues comme chroniquement désagréables et manifestement inutiles ? Franchement, ce n'est pas facile. Mais cela peut (et doit) être fait. Voici quelques conseils pratiques à garder à l'esprit :
1. Éduquer les personnes extérieures
De nombreuses équipes et clients conventionnels en dehors du monde agile pensent qu'agile est essentiellement une gestion de projet conventionnelle, mais avec un peu plus de flexibilité et d'agilité. Mais lorsque leurs demandes sont rejetées au lieu d'être acceptées, ils sont frustrés - et parfois outrés. La meilleure façon d'éviter ces turbulences est que les équipes agiles éduquent les personnes extérieures sur la façon dont agile fonctionne, et comment il ne fonctionne pas. Cette prise de conscience contribue grandement à clarifier les attentes et à transformer des adversaires potentiels en alliés solidaires.
2. Établir la visibilité
Même en ayant conscience de la façon dont la méthode agile fonctionne et ne fonctionne pas, certaines équipes externes et certains clients peuvent encore rechigner à l'idée que leur "demande urgente" soit versée dans un backlog, surtout si cela n'a pas été un problème dans le passé. Pour relever ce défi majeur, les équipes agiles devraient utiliser un outil de gestion des tâches simple et rationalisé comme Planview AdaptiveWork Go qui permet aux dirigeants et au PMO d'accéder à un aperçu actualisé de haut niveau des tâches dans le flux de travail, afin qu'ils puissent voir clairement ce qui se passe réellement - et faire leur part pour maintenir le flux de travail.
3. Appliquer les limites des travaux en cours
Les équipes agiles qui utilisent la méthodologie Kanban ou Scrumban (Kanban + Scrum) devraient se concentrer sur - ou plutôt être obsédées par - l'application de limites réalistes de travail en cours (WIP) pour chaque phase du flux de travail. Par exemple, si les équipes déterminent que le nombre de tâches pouvant exister simultanément dans la phase de "révision" est de 10, alors en aucun cas une 11ème tâche ne doit être ajoutée avant qu'une place ne se libère. Il est vrai que faire respecter les limites d'encours peut être beaucoup plus facile à dire qu'à faire. Mais les équipes agiles qui cèdent du terrain sur ce front auront un mal fou à le récupérer par la suite.
4. Décomposer les demandes pour (éventuellement) transformer les non en oui
Les équipes agiles devraient puiser dans leur boîte à outils diplomatique et voir s'il existe un moyen de décomposer les demandes en quelque chose de plus petit, plus rapide et plus viable. Bien qu'il n'y ait aucune garantie qu'une contre-offre de ce type soit acceptée, cela en vaut la peine.
5. Installer un Scrum Master
Enfin, les équipes agiles devraient mettre en place un Scrum Master (ou toute autre personne dûment autorisée) qui agit en tant que gardien pour examiner les demandes avant qu'elles ne soient ajoutées au backlog. Ces personnes essentielles protègent les membres de l'équipe des fardeaux, du bruit et des distractions, tandis qu'elles éduquent les clients et gèrent les attentes.
En résumé
Le passage de la gestion de projet conventionnelle à la méthode agile peut être difficile ; non seulement pour les équipes agiles elles-mêmes, mais aussi - et parfois surtout - pour les équipes et les clients externes qui veulent faire les choses "comme elles ont toujours été faites". Il n'y a pas de retour en arrière possible. Il faut aller de l'avant, et les équipes agiles qui maîtrisent l'art de dire NON se mettent sur la voie du succès à long terme.
