Tu soulèves 2 différences :
1/ « le management porteur de sens n’a rien à voir avec le partage de vision de Scrum » : Certes, il y a différence, mais il y a tout de même une démarche commune : expliquer la finalité. Pour le management, on vient du taylorisme et de la production de masse, où les équipes appliquent « sans réfléchir ». Dans le logiciel, on retrouve dans les démarches « traditionnelles » ce type de raisonnement (sans parler du cloisonnement). Pour moi, il y a donc une approche commune : donner du sens pour que les équipes soient (plus) impliquées dans le produit.
2/ « Quant à «l’anticipation » chère à Jérôme, je ne la retrouve pas vraiment dans Scrum qui prône la pro-activité et l’amélioration continue. », je suis d’accord avec toi. En relisant la phrase anticiper pour « minimiser les risques de rejet et les besoins du changement » je reste perplexe.
Sauf erreur de ma part, Jérôme décrit dans les 100 premières pages que la durée de vie d’un produit se rétrécie, que les entreprises tendaient à être plus réactives et se « battaient » notamment sur la personnalisation du produit (et des services) : je n’ai pas lu cependant qu’une anticipation exhaustive était nécessaire. Si le projet (ou produit) à une durée de vie plus courte, l’ »anticipation » pourrait alors se rapprocher du Backlog de Scrum qui porte la vision (plus ou moins complète, évidemment).
Pour la pro-activité, Jérôme parle de pro-efficience : je pense que l’on est sur des thèmes et des notions assez proches.
En revanche, il manque en effet l’aspect amélioration continue. On pourrait éventuellement l’expliquer par :
* Le changement (de management) peut mettre plus de temps à être organisé et mis en œuvre selon les contextes : Taille de l’équipe (7 personnes pour Scrum, des centaines dans l’industrie), Dépendances (On arrive plus facilement à enlever les dépendances dans le logiciel que dans une chaine de fabrication ou dans la construction d’une maison).
Malgré ces différences, il y a tout de même un état d’esprit commun : l’Humain.

Question complémentaire : pour toi, est-ce que le ScrumMaster a un rôle de manager à jouer avec l’équipe ? Si oui, quelle serait la « limite » à ne pas franchir ?

PS : fait chaud, faudrait aller boire une bière un de ces jours :)