L’agile et l’agile à l’échelle présentent toutes deux de formidables caractéristiques qui toutes deux sont sous-utilisées : l’arrêt des projets et le management par produit. Penser et agir marketing sont un levier pour mieux utiliser ces deux caractéristiques au profit d’un repositionnement de l’IT dans l’entreprise et une meilleure relation avec les directions métiers.
Même dans les principes Agile, il se trouve qu’à un moment comme pour tout projet, ça s’arrête (voir l’excellent article de notre collègue Guillaume sur le sujet). Voire même, si l’on applique les bonnes pratiques, la date de fin devrait être fixée dès le début du projet avec un nombre d’itérations maximum et un budget limité le finançant. Pour mémoire dans un projet Agile, le degré de liberté c’est la proposition de valeur, pas les délais ni le budget. Charge ensuite à l’équipe, client inclus, de délivrer la meilleure proposition de valeur possible.
Dans la pratique, on n’arrête pas un train lancé … ou difficilement !
Il faut alors gérer l’arrêt du projet, le dispatch des équipes, le REX projet, etc.
C’est généralement à ce stade que ça coince.
La mise en œuvre de nouvelles méthodes amène les entreprises à investir dans de nouvelles infrastructures (par exemple le fait de mettre à disposition des plateaux co-localisés avec le client dans les centres villes ou proches de fourmilières digitales où les collaborateurs peuvent se nourrir de la culture et des relations à d’autres entreprises) qui viennent encore augmenter le prix émotionnel et rationnel de l’arrêt de tels projets. Les bénéfices secondaires qui accompagnent ces projets touchent directement les collaborateurs. Cela amène les équipes à se raidir et résister franchement à l’arrêt du projet.
Les middle managers ou les responsables de domaine, souvent orientés ressources et développement de la taille de leur équipe, peuvent alors entrer dans une frustration absolue de devoir rendre des ressources.
C’est le début des aspects pas cools qu’impliquent l’agile et qui sont en fin de compte assez peu joués et mis en avant par les équipes. On les comprend, après s’être auto-organisés, après avoir enfin trouvé l’alchimie parfaite et la vélocité ultime avec le super équipage qu’ils formaient ensemble : s’arrêter et dissoudre l’équipe, c’est un crève-cœur !
Bref l’Agile sans les trucs qui font mal c’est comme un shoot sans redescente ! Et bien ça n’existe pas …
En vrai, c’est là que l’agilité et l’agilité à l’échelle spécifiquement délivrent le plus de valeur, à savoir, en plus de délivrer de manière continue de la valeur, l’agilité permet également d’arrêter les trains qui de toutes les manières n’arriveront pas à l’heure, pas dans la bonne gare et sans couter des millions de subventions aux contribuables métiers.
C’est sans doute dans la façon de gérer cet arrêt des projets qu’il faut progresser et rassurer les collaborateurs. Le fait d’arrêter un projet est une formidable opportunité de redéployer son énergie sur de nouveaux sujets. Les DSI qui réussissent ces arrêts projets démontrent une certaine maitrise de leurs ressources et montrent à leurs équipes qu’elles en sont pleinement responsables. En deux sens au moins, elles ne se voient pas menacées de perdre un budget, elles sont investies dans la sécurisation des collaborateurs (pas des emplois). De ce fait, elles mettent en puissance leur collaborateurs (sécurisation et autorisation) face à des changements fréquents et brutaux : ils sont formés et assurés dans leur appropriation de nouveaux challenges.
Il y a tellement de nouveaux aspects à découvrir et expérimenter dans la mise en œuvre de ces méthodes
Un second aspect sur lequel s’arrêter : le management de produit ! En fait si on tire le fil, les rôles de product owner (dans Scrum) et de product manager (dans SAFe) portent en eux une dimension marketing qui, au-delà de la valeur du produit qu’ils construisent, doivent instruire et amener le métier à investir sur tel ou tel produit nouveau et/ou ancien en fonction de la meilleure valeur à tirer à l’instant t de ses investissements.
Il y a là matière à s’arrêter deux secondes. Il ne s’agit plus de la seule relation Business Partner avec le métier (communication, développement d’une relation d’égal à égal et partage d’orientation ou d’éléments de trajectoire voire de stratégie pour les meilleurs sur le marché). Il s’agit de définir son marché, de le segmenter, d’évaluer ses besoins, étudier différents business plans et finalement évaluer là où les chances de gains et les bénéfices sont le plus en synergie avec la stratégie de l’entreprise. Un ensemble d’activité que de nombreux DSI s’évertuent à essayer de capter mais avec les mauvais outils, les mauvaises méthodes et in fine la mauvaise posture.
Mettre un BRM IT au sein d’un codir métier peut rapidement devenir une façon luxueuse de prendre une commande, à la fin le métier n’attend que le fait que vous serviez le plat !
Si vous voulez vraiment contribuer à la réalisation de la stratégie de l’entreprise, commencez par mettre votre client au centre, analysez et intéressez-vous à son modèle de production de valeur, écoutez le mais ne le suivez pas aveuglement, comportez-vous mieux que le DAF à qui vous pourrez reprocher ses investissements ruineux et calamiteux dans un n-ième outil de reporting impayable. Mettez au centre de votre organisation quelques Product managers à qui vous confiez la programmation tactique et la responsabilité de re-configurer l’organisation et les capacités de réalisation. Couplez à une approche budgétaire capacitaire, une analyse marketing sans concessions des produits que vous gérez pour l’entreprise. Investissez le champ de la création de valeur pour les clients de l’entreprise aux cotés des directions métiers comme véritable partenaire expert du levier technologique.
