Management Agile au Valtech Day

Wave backgroundAujourd’hui j’ai présenté la session « Au secours mes équipes veulent être agile et je n’ai plus ma place » lors du Valtech Day.

Au passage, je veux féliciter les organisateurs pour l’organisation de cet évènement et pour la qualité des sujets présentés … même si bon nombre d’entre eux étaient présentés par des gens de Valtech 🙂

La salle était pleine pour ma session et même si Patrick manquait à l’appel, je pense avoir réalisé une prestation de bonne qualité.

Ce sujet est vraiment d’actualité car de nombreuses personnes sont venus me voir pour me demander quelques conseils sur la façon de communiquer auprès de leur management après une démarche de mise en place de l’agilité sur un projet pilote ou quelques projets. La plupart d’entre eux ont fait appel à un coach externe pour les aider à mettre en place les pratiques agiles (souvent des coachs parisiens que je connais bien) mais qui cherchent « curieusement » une autre source d’information pour la partie management … tant mieux pour moi 🙂

Autre sujet de satisfaction pour cette journée pour moi, la présence de Lauren Mathis de Bluecrest Consulting en Keynote d’ouverture qui nous a expliqué les principes du « Blue Ocean Strategy », ou BOS pour les intimes, qui était une vraie découverte pour moi.

Le BOS est une stratégie marketing qui permet à la fois de réduire les coûts et d’augmenter la valeur business (la BVM agile 🙂 ), et qui repose sur les travaux de W. Chan Kim et Renée Mauborgne en proposant des règles et des outils tels que les 4 critères EARC (Exclure, Atténuer, Renforcer, Créer), les 6 leviers d’utilité (Prodcutivité, Simplicité, Commodité, Risque, Amusement & Image, Respect de l’environnement), les 6 pistes d’amélioration ou les 3E du Management équitable (Engager, Echanger, Enoncer les conséquences).

Même si l’agilité semble éloignée du BOS, Lauren a trouvé bon nombre de points communs … que diriez-vous d’avoir Lauren en Keynote lors du prochain Agile Grenoble en Décembre 2010 … Lauren vit à Genève et parle Fançais … et si je vous dis qu’elle est charmante … 🙂

3 réflexions sur « Management Agile au Valtech Day »

  1. Bonjour

    Merci pour la présentation en téléchargements.

    Ceci dit, je dois avouer qu’elle m’a laissé un peu sur ma faim et que je me pose également un grand nombre des questions la concluant…

    Puis je poser mes questions dans ce commentaire ?

    Allez, dans le doute, je me lance 😉

    Sachant que Scrum est assez précis sur la mise en place des équipes, entre développeurs, PO et SM, quelle structure de management est conseillée ?

    Quelle est la place des CP dans une transition vers l’agilité ?

    Merci d’avance

    cordialement,
    joseph

    Alex : je dirais simplement « une autre place » et c’est à eux de trouver quelles plus values ils peuvent apporter à l’équipe et l’entreprise. Certains iront simplement vers le rôle de Scrum Master, d’autres vers le rôle beaucoup plus difficile de Product Owner, d’autres encore vers un rôle de « Programme Coordinateur » dans les structures d’entreprises très complexes … et les derniers iront chercher ailleurs des entreprises qui ne pratiquent pas l’agilité

  2. Merci Alex pour cette réponse.

    Je dois avouer qu’elle est d’une rare franchise : rares sont les écrits sur le sujet qui évoquent ouvertement la possibilité qu’une partie des « ex » CDP quittent le navire.

    Pour ce qui est de la reconversion, je ne suis pas certain de bien cerner la difficulté du passage à product owner : j’ai plus souvent vu des CDP ravis de quitter la technique que le contraire, c’est le genre de ponts qui devrait plaire non ?

    A l’inverse, le passage vers le rôle de scrum master est à mon sens plus dur : à mes yeux ce dernier doit en effet avoir une réelle légitimité en termes d’agilité, ce qui n’est sans doute pas le cas pour un CDP fraichement reconverti.

    Cela soulève également une autre question : j’ai souvent vu des équipes agile où le scrum master était « également » un développeur comme les autres, est ce également le cas dans ce type de reconversion ? Cela semblerait, pour moi, encore ajouter une difficulté à un CDP plus très à jour coté code…

    Pour en revenir au sujet, c’est à dire l’interaction management/équipes agile, quel type de fonctionnement est il le plus souvent appliqué/conseillé ?

    En effet, les équipes Agiles sont sensées être sans leader clairement identifiés, d’où la difficulté pour le management de trouver des interlocuteurs « techniques ». Comment savoir ce qui relève du possible, techniquement ? Comment réaliser les road map ?

    En gros, j’évoque là un rôle d’architecte, donc bien distinct du product owner (non technique à mes yeux), mais ce rôle ne fait pas partie des « règles » agile, d’où ma perplexité.

    La réponse trouvée dans Agile Estimating And Planning, consistant à impliquer toute l’équipe (et par extension toutes les équipes) dans l’élaboration des road maps me semble relativement impraticable.

    Le nombre seul est/serait souvent rédhibitoire, du moins d’après ma propre expérience, le top management venant avec les responsables fonctionnels concernés, le/les products owners : rajouter les membres des équipes correspondantes donnerait au tout un air de conférence loin de toute productivité.

    Mais alors, comment « choisir » les personnes allant à ces préparations de road map ? Où, à défaut, comment procéder pour les élaborer ?

    merci encore !

    cordialement,
    joseph

    Alex : Le passage de CP à SM est difficile car le CP doit « perdre » certaines de ses habitudes et passer du mode (Imposer+Contrôler+Diriger) à (Faire Confiance+Faciliter+Accompagner), mais d’autres qualité du CP sont similaires dans le rôle de SM (résolution de problème, anticipation, coordination). Donc si le CP est « raisonnablement » ouvert à changer de rôle cela devrait pouvoir se faire sans trop de casse.
    Le rôle de PO est bien plus difficile à tenir et nécessite de vraies qualités business et une réelle vision pour le produit … ce qui manque bien souvent au CP traditionnel qui se contente d’être un exécutant (ce qui n’est pas péjoratif).
    Pour ce qui est du SM/DEV … il en était de même pour les CP/DEV, car sur les petits projets, les CP étaient bien souvent impliqués dans la réalisation. Je connais plusieurs équipes ou le rôle de SM est joué par chacun des membres de l’équipe à tour de rôle … et ca marche très bien 🙂
    Pour ce qui est de tes autres questions, je pense que tu te trompes d’approche en essayant de faire des roadmaps avec une approche classique (Architecture upfront – Leader désigné qui sait) tout en utilisant des principes agiles. Il faut radicalement changer ton angle d’approche et adopter une démarche 100% agile sur le produit, y compris pour l’établissement des roadmaps.

  3. merci encore pour toutes ces réponses 🙂

    Qu’entends tu au juste par une démarche 100% agile pour les roads maps ?

    Au plaisir de te lire !

    ++
    joseph

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *