Aujourd’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 … 🙂
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
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
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