Scrum et le management

Baleine et banc de poissons

Baleine et banc de poissons

Lors de ma formation Scrum, j’ai retenu 2 éléments concernant Scrum et le management :

1 – Le ScumMaster n’est pas un chef de projet qui fait obéir son équipe au doigt et à l’oeil : il ne manage pas l’équipe mais le processus.

2 – Les rôles « utiles » pour le produit sont le P.O, le ScrumMaster et la Team (auto-gérée et possédant toutes les compétences nécessaires à la réussite du projet) : tout autre rôle est inutile à Scrum.

Durant cette première année de pratique de Scrum, j’ai tout de même eu quelques interrogations :

  • En mettant en place un Niko-Niko, en « protégant » l’équipe, en l’incitant à mettre en oeuvre certaines pratique d’ingenierie (BDD, Pair programmning, …), en mettant en place des entretiens OneOnOne, ne suis-je pas entrain de faire du management d’équipe  ?
  • Mon manager, son manager, les autres services ainsi que la direction générale, même s’ils ont compris notre mutation vers l’agilité, fonctionnent toujours de manière traditionnelle. Et pourtant, la communication doit avoir lieu entre « eux » et « nous ». Quelle type de relation dois-je mettre en oeuvre entre mon management hiérarchique (ainsi que celui de l’équipe) ? Est-il possible d’aller plus loin et d’envisager une entreprise agile ?

Scrum ne me permettait pas de répondre à ces questions. Je me suis donc lancé dans la lecture d’une « référence » en terme de management agile : « Le Manager Agile, Vers un nouveau management pour affronter la turbulence » de Jérome BARRAND (Edition Dunod). Je ne vais pas recopier tout le livre tant celui-ci m’a épatté par la qualité de son contenu, ainsi que la grande proximité qui existe entre la définition de l’agilité en management et celle de l’agilité en informatique, notamment avec les notions du Manifeste Agile. Je ne résiste tout de même pas à vous faire partager la présentation que l’auteur fait de « l’Entreprise agile » :

  • Porteuse de sens pour l’ensemble de ses acteurs[...]. Une finalité claire permet de réduire la complexité.
  • Bien établie, réfléchie collectivement, impliquant le plus grand nombre le plus en amont possible de la réflexion afin de minimiser les risques de rejet et les besoins du changement
  • Partagée et entretenue
  • Qui soit à la source de la stimulation de comportements d’anticipation.

On retrouve dans cette rapide description les notions très présente dans Scrum : la vision du produit, l’aptitude à embrasser le changement, l’itération et la fréquence des échanges, l’importance de définir la stratégie (le Afin De !),  etc … L’entreprise et ses « petites unités » doivent être organisées en « banc de poisson » ; plutôt que comme une baleine ! L’image est proche de celle de l’équipe de Rugby qui se réunit régulièrement pour faire une mêlée, qui avance dans le même sens et qui est composée de tous les profils nécessaire pour atteindre l’objectif.

Bref, une lecture formidable qu’il va maintenant me falloir digérer pour en tirer le meilleur. Je conseille vivement cette lecture à tous les ScrumMaster qui, comme moi, se posent des questions sur leur rôle de manager et cherchent à répondre à la questionsuivante : « Comment être un manager Agile » ?

 

Tags: ,

«
»

4 Réponses à “Scrum et le management”

  1. dibus :
    9/05/2011 à 19:43

    Un petit complément : concernant le même livre, voici un article écrit par Frédéric DOILLON il y a déjà 3 ans … http://www.fredericdoillon.com/2008/01/au-dbut-juste-a.html

  2. Alex :
    10/05/2011 à 22:18

    Salut Dibus
    Je ne suis pas vraiment d’accord avec toi, car je trouve qu’il y a beaucoup de différences entre le management agile et la gestion de projet agile.
    Il est intéressant de noter que Jérôme ne connaissait pas l’agilité logicielle avant 2008, et qu’il a fait un chemin propre et personnel pour définir ce qu’est un manager agile.
    Même s’il y a quelques similitudes, il existe cependant de grandes différences entre les 2 approches.
    Par exemple, et à mon avis, le management porteur de sens n’a rien à voir avec le partage de vision de Scrum (« sens » et « pourquoi » sont différents).
    De même la réflexion en amont va à contre sens de l’agilité qui préconise de faire les choses pour d’inspecter et d’adapter.
    Quand à « l’anticipaction » chère à Jérôme, je ne la retrouve pas vraiment dans Scrum qui prone la proactivité et l’amélioration continue.
    Bref je ne suis pas d’accord avec ton analyse … mais je la respecte
    Amitié
    Alex

  3. dibus :
    11/05/2011 à 15:45

    Alex,
    Merci pour ce commentaire qui m’aide, comme souvent, à affiner ma réflexion.

    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 :)

  4. Alex :
    13/05/2011 à 20:28

    Ok pour la bière … des que j’ai moins de boulot :)
    PS : j’ai écrit anticipaction avec un c en non anticipation (cf. Le manifeste du manager agile de Jerome)