DantotsuPM.com

The Agile Project Manager – The Cost of Transparency

http://www.pmhut.com/the-agile-project-manager-the-cost-of-transparency
par Bob Galen

Comme j’apprends et cultive mon expérience agile, je continue à trouver de la valeur et de la puissance dans la notion de transparence. C’est un des plus subtils principes agiles et qui est mentionné, mais rarement mis en exergue comme un facteur critique de succès.

Alors, qu’est-ce que la transparence ?

Laissez-moi vous donner un exemple. Dans beaucoup d’instanciations d’Agile, les équipes et de structures ne surgissent pas du néant. D’habitude, des managers fonctionnels ou autres leaders mettent une sérieuse dose de réflexion dans la composition d’équipes :

• Quelle devrait être la taille d’équipe ?
• Quelle est la proportion la plus efficace de compétences, par exemple depuis les développeurs jusqu’aux testeurs ?
• De combien d’expérience l’équipe a-t-elle besoin ? Des Leaders spécifiques?
• Combien de développeurs de quel type (Front-end, Back-end, Middle-tier) devraient être dans chaque équipe ?
• L’équipe a-t-elle les compétences requises pour réaliser leur travail (tel que défini dans l’Arriéré de Produit)?

D’habitude également, la composition d’équipe implique des compromis. Par exemple, quelques membres de l’équipe ne veulent tout simplement pas travailler dans certains domaines. Des points forts individuels entrent en jeu, aussi bien leur préférences professionnelles que personnelles. On pourrait même considérer certains compromis comme privé ou confidentiel.

Quand vous présentez cette composition d’équipe à l’organisation, en expliquant votre raisonnement et vos compromis, vous pratiquez la transparence. Pourquoi le faire ? D’abord, il est utile d’exposer des choses à l’équipe au sens large. Cela vous force à articuler votre raisonnement et les questions pratiques ou les défis. Vous recevrez aussi des suggestions et des alternatives que vous pourrez considérer dans votre réflexion. Donc deux avantages à ce que les décisions soient exposées à l’examen minutieux de l’équipe. Ils vous fourniront aussi un retour d’information sur des alternatives, ce qui d’habitude crée ou favorise des décisions plus robustes, dans ce cas sur la composition finale de l’équipe.

Mais…il y a un danger

Votre niveau de transparence dépend du niveau de maturité de l’organisation qui la reçoit. Dans un monde parfait, vous voulez être entièrement, à 100 % transparent. Mais, si vous vivez dans une organisation qui pour utiliser les mots de Jack Nicholson "Ne peut pas supporter la Vérité!" ?

Ou bien si vos collègues dans d’autres groupes fonctionnels ne fournissent pas réciproquement le même niveau de transparence que vous? Maintenant vous avez exposé les rouages intérieurs de votre organisation et vos processus de prise de décisions ou les vraies raisons derrière des choix, mais les autres restent toujours opaques. Pire, ils profitent de votre transparence pour contester vos décisions ou percer des trous dans votre logique ou utiliser ces informations contre vous dans un débat ouvert.

Mais en même temps, ils n’ont pas partagé au même niveau que vous et n’ont pas l’épaisseur de cuir nécessaire pour venir défendre leurs propres décisions. Ils créent ainsi un déséquilibre de transparence qui est malsain et déloyal. Vous pourriez soutenir que ceci est ok. Cette transparence est en règle générale la bonne chose à faire. Je ne le pense pas. Je pense que la transparence organisationnelle doit être équilibrée, congruente, réciproque et basée sur la maturité et la confiance.

Explorons deux ou trois exemples pour marquer ce point …

Manque de confiance ou d’honorer les frontières de rôle

Une partie importante de la transparence est que les individus comprennent les principes fondamentaux de leurs rôles et responsabilités. Laissez-moi utiliser un exemple Scrum pour démontrer ceci.

Le Propriétaire de Produit est le rôle dans Scrum qui est responsable de définir un arriéré de fonctionnalités « Product Backlog » qui satisfait les attentes du client. Un arriéré que l’on priorise de façon à livrer en premier au client les fonctionnalités de plus forte valeur. Pour que ces fonctionnalités de valeur soient les premières, livrées tôt et souvent.

Maintenant, l’équipe Scrum elle-même contribue à la discussion sur la priorisation des articles de travail et la valeur. Ils collaborent fortement avec le Propriétaire de Produit et cela apporte un débat sain sur l’organisation de l’arriéré. Dans nombreux cas, leurs avis et retour d’information pèsent lourdement sur l’arriéré.

Mais au bout du compte, la responsabilité suprême d’organisation de l’arriéré réside chez le Propriétaire de Produit et l’équipe doit s’aligner sur sa décision après discussion et débat passionnés et supporter totalement ses décisions. Leur faisant confiance pour faire leur travail et honorer leur rôle et ses responsabilités inhérentes.

Mais qu’advient-il si l’équipe continue à challenger le Propriétaire de Produit, tant au sein de l’équipe qu’en public ? Et si quand le Propriétaire de Produit partage son raisonnement de prise de décisions, l’équipe utilise ces informations données en toute transparence contre le « Product Owner » pour saper sa crédibilité ? Ou s’ils défient constamment les décisions encore et encore ?

Cette sorte de comportement sapera finalement la confiance des Propriétaires de Produit en leur équipe. Bien sûr, ils collaboreront avec eux et partageront des informations. Mais ils commenceront à filtrer les informations quand ils les considèrent volatiles ou sujettes à controverse. Ils commenceront à ajouter de l’opacité à leur raisonnement de prise de décisions. Et vous savez quoi ? Je ne peux pas les en blâmer.

Je pense que la transparence doit être gagnée dans les deux directions. Tant l’expéditeur que le récepteur doivent pouvoir croire en chacun d’eux…sinon un filtrage arrivera. Et dans des contextes agiles ceci peut être un obstacle très sérieux.

La leçon #1 – la Transparence a l’équité comme élément sous-jacent; cela et le support fondamental d’une confiance de base de l’équipe.

Un autre exemple – Maturité

Laissez-moi essayer un autre exemple. J’étais autre fois chef de projet dans une équipe traditionnelle. Nous étions dans la phase finale d’un projet, essayant de venir à bout des changements logiciels et des corrections d’erreur avec bon espoir de nous approcher de la livraison de version au client.

Il est remonté à mon attention qu’un composant particulier de notre application ne se stabilisait pas d’un point de vue qualité. Quand nous avons demandé à l’équipe de développement s’ils avaient besoin d’aide ou de ce qui spécifiquement était erroné, ils se dérobaient. Ils devenaient défensifs et nous disaient qu’ils avaient le logiciel sous contrôle et que ceci était seulement un pépin provisoire.

Initialement, nous avons simplement eu confiance en eux. Cependant, plusieurs itérations ont passé et le logiciel ne s’est pas amélioré. En fait, certains des bogues plus récents qui faisaient surface étaient non seulement des régressions, mais ils étaient plus sévères que leur instanciation précédente. Clairement les choses empiraient.

J’ai demandé aux membres de notre équipe de test s’ils avaient une compréhension supplémentaire de ce qui pouvait se passer. J’aurais probablement dû le leur demander beaucoup plus tôt. Pour sûr, ont-ils répondu. Nous savons ce qui ne va pas. Ce sont les changements de Bill et d’Eddie qui déstabilisent le composant. C’est le cas depuis deux mois. Bill était un de nos ingénieurs les plus expérimentés et Eddie était un stagiaire universitaire qui travaillait avec lui.

Il s’est avéré que Bill faisait des heures supplémentaires. Beaucoup trop d’heures supplémentaires, autour de 70 heures par semaine et il avait été sérieusement surchargé sur le projet. Ceci était l’un de trois composants qui lui étaient assignés et Eddie perdait pied à tous les supporter.

Malheureusement, au lieu de demander l’aide, Bill était sur la défensive par rapport à ses capacités et la qualité de son travail. Et son patron est tombé dans le piège de le soutenir, le tout causant des retards du projet. Une fois percé cette défense opaque et cette immaturité, nous avons ajusté la charge dans l’équipe et avons donné un peu d’aide à Bill et Eddie. Presque immédiatement la qualité de ce composant a commencé à s’améliorer et nous étions en position de livrer deux semaines plus tard.

Si nous avions un regret, c’est celui de n’avoir pas forcé cette transparence plus tôt pour mieux comprendre la cause racine et faire un ajustement beaucoup plus rapide! Vous voyez qu’il ne s’agissait pas de Bill ou d’Eddie. Il s’agissait d’une équipe livrant un projet à ses clients.

La leçon #2 – la Transparence a besoin d’un niveau de maturité et de confiance; la réalisation que s’exposer au plus tôt vaut toujours mieux.

Pour conclure

La transparence s’avère être une fondation des principes agiles. Elle sert de base à beaucoup d’activités d’une bonne équipe Agile: stand-up quotidiens, planification de sprint et de version, démonstrations de sprint et rétrospectives. Pratiquement toutes les cérémonies Agiles de vos équipes doivent être transparentes. Cependant, dans beaucoup de contextes, la transparence doit être gagnée.

Il faut jouer franc jeu et partager dans tous les aspects de votre organisation pour amener des niveaux cohérents de transparence. Une ligne de référence pour ceci est la confiance. Chacun doit être au même niveau de confiance dans les rôles et des responsabilités de chacun et honorer la compétence de chacun, ses capacités et ses efforts.

S’il y a injustice, je vous préviens que votre niveau de transparence se normalisera au niveau le plus faible auquel chacun fonctionne. Sinon, il favorisera les comportements incongrus et étranges à travers l’équipe qui continueront encore à réduire votre transparence. La transparence incohérente aura aussi un lourd l’impact sur votre prise de décisions quand vous obtiendrez des niveaux différents d’informations provenant de groupes différents.

Il doit y avoir franc jeu quand on en vient aux informations. Aucun "je vous l’avais bien dit". Au lieu de cela, vous devez favoriser une fondation équitable, égale et de même niveau pour le partage d’information. Celle qui permettra à la nature principale de vos équipes agiles de fleurir comme ils font face à leurs défis et s’adaptent vers l’amélioration et le succès.

Chefs de projet Agiles, êtes-vous prêts à relever ce défi ? Quelle est votre réponse …

Tags:confiance, scrum, Soft Skills, teams