Comment acculturer une entreprise à une approche produit ?
Comment passer du “mode projet” au “mode produit” ?
Chaque semaine, j’anime Scrum Life avec Constantin Guay. En particulier, nous faisons un Live tous les lundi à 13 heures. Pendant ce Live, nous répondons aux questions des spectateurs.
La dernière séance a été un peu particulière : le sujet à traiter, désigné par une forte majorité de votes, était d’une telle ampleur que le Live a plus ressemblé à une conférence.
Le sujet n’était pas une mince affaire, le voici :
Comment acculturer une entreprise à une approche produit lorsqu’elle a une culture très ancrée dans un mode projet / waterfall, voire Water Scrum Fall, avec une chaîne de décision très hiérarchique (nombreux niveaux de décision / validation, exemple des banques)
Vous trouverez dans le reste de cet article mes notes qui m’ont servi à préparer la session.
Communiquer le pourquoi
Tout d’abord une question de fond, importante : est-ce que c’est réellement un problème de suivre une approche projet, voire waterfall ? Et surtout, pourquoi on veut s’en séparer ?
Les réponses à ces questions, le pourquoi du changement, seront de très bons points de départ.
Quoi qu’il arrive, il faut toujours y revenir :
Au fait, pourquoi on veut faire ce changement ?
Si les raisons ne sont pas rationnelles… Disons que le patron l’a décidé, et voilà. Il faut alors échanger avec lui pour faire ressortir ces raisons et communiquer dessus.
Si les raisons sont par contre rationnelles, il faut alors les instrumenter au maximum : fresque, affichage, newsletter interne, événements, all-hands… Et rappeler le pourquoi on le fait, en permanence et au maximum, et bien sûr par l’équipe de direction, qui a toute légitimité, et si possible de manière participative avec le reste de l’entreprise.
Bref, de la communication !
D’ailleurs, construire la culture, c’est un des rôles principaux du CEO !
Monter en épingle les succès
De la même manière, il faut instrumenter au maximum les succès de la nouvelle approche.
Regardez, c’est possible !
Ça marche !
Ça fonctionne mieux qu’avant !
On peut aussi organiser des safari agiles : faire visiter les équipes qui ont ce nouveau mode de fonctionnement et qui marchent bien. C’est un élément fort de communication, tout en apportant un côté très concret, qui peut démystifier la mise en pratique.
Dans la même veine, on peut également organiser des BBL internes, où les équipes feront des retours d’expérience, là encore avec le côté de la mise en place en pratique.
Focus sur le flow
Le Value Stream Mapping
Un excellent outil existe : le Value Stream Mapping.
Une Value Stream Map (VSM) permet de déterminer objectivement combien de temps s’écoule entre l’idée et la mise à disposition des utilisateurs — tout compris !
C’est par exemple l’outil idéal pour vendre du DevOps et du Continuous Delivery… Mais aussi pour chercher comment accélérer les prises de décision, et réduire les boucles de feedback.
L’outil nous amène naturellement à trouver comment prendre des décisions plus rapidement, et donc à les déléguer.
Un autre intérêt du VSM : il permet de cibler les actions par rapport aux besoins réels du contexte, tout en restant dans le concret et le factuel.
Le Lead Time
Le VSM nous amène naturellement à mesurer le Lead Time, ce temps nécessaire pour aller d’un bout à l’autre.
Le Lead Time est un excellent indicateur, difficile à détourner, pertinent et global.
C’est un très bon KPI d’entreprise.
Le Lead Time permet aussi de révéler les problèmes de silotage : le passage de bâton entre entités ou département est souvent une raison majeure de perte de temps. L’amélioration du Lead Time mène naturellement à voir tout l’intérêt des équipes pluridisciplinaires.
Kanban plutôt que Scrum
Plus globalement, on a envie de piloter la transformation par du Kanban plutôt que par du Scrum, en se focalisant sur le flow.
Et finalement, Scrum est peut-être à réserver pour la fin de la transformation, quand les pré-requis de Scrum seront là : des équipes stables, pluridisciplinaires, en charge d’un produit de bout en bout.
Il n’est donc pas pertinent de pousser pour une adoption rapide de Scrum !
Il n’est d’ailleurs pas dit que Scrum soit forcément la bonne option pour cette organisation.
La décentralisation des décisions
Pourquoi veut-on décentraliser les décisions ?
- Prendre des décisions plus rapidement
- Prendre plus de décisions
- Prendre de meilleures décisions
Le VSM nous amène naturellement à faire le nécessaire pour prendre des décisions plus rapidement. Qu’en est-il des autres ?
Célébrer les échecs
Pour faire prendre conscience de la nécessité de prendre plus de décisions, il faut célébrer les échecs : construire une culture où prendre la mauvaise décision est normal et permet d’en ressortir grandi.
Une fois que l’entreprise aura réalisée qu’en moyenne on prend autant de bonnes que de mauvaises décisions produits — et ceci sans même parler des décisions à l’impact neutre, qu’il faut quand même tuer pour ne pas complexifier inutilement le produit — , alors il deviendra évident que l’amélioration du produit passe avant tout par la multiplication du nombre de décisions.
Mais cela nécessite avant tout une culture amicale à l’échec !
En cascade, arrive la nécessité d’un environnement où règne la sûreté psychologique et où les équipes doivent évoluer dans un sandbox bien défini.
Il faut également ajouter une bonne dose de communication pour célébrer les échecs !
- Condamner voire punir le status quo (l’absence de changement) plutôt que les échecs et les mauvaise décisions
- Avoir en permanence un focus sur les KPI business, les seuls qui comptent vraiment
- Former les managers et toutes les positions de leadership (tel que le tech lead par exemple) : un manager qui ne sait pas comment faire le métier de manager va se retrancher dans le status quo voire le jeu politique
- Construire ou réparer la sûreté psychologique, procéder à des team building
- Faire un “Hall of Fail” où on affiche clairement les échecs
- Globalement exposer fièrement les échecs et surtout montrer ce qu’on en a appris
Documenter les décisions
Il faut documenter les décisions ! Pour savoir qu’elles existent, pour pouvoir les mettre en avant, afin de réussir à assumer clairement leur échec et à en tirer un apprentissage…
Introspection sur les échecs
Nous savons donc qu’il faut prendre des décisions plus vite, et qu’il faut en prendre plus.
Comment également convaincre qu’il faut prendre de meilleures décisions ? Comment faire comprendre qu’il faut des personnes au contact du terrain pour prendre les meilleurs décisions ? Sans même parler de la force de l’intelligence collective générée par des équipes pluridisciplinaires.
On peut tout d’abord partir des réflexions autour de la célébration des échecs. Si on a effectivement une introspection derrière chaque échec, on devrait arriver à cette conclusion :
– “Là, les dev le savaient”
– “Là, le PO le savait”
Et ainsi de suite…
Réussir à lâcher-prise : sandbox et Moving Motivators
À vrai dire, il n’est pas très difficile de convaincre. La réelle difficulté, c’est le passage à l’acte, c’est la mise en place en pratique. Car cela demande un véritable lâcher-prise !
Pour y arriver, il est essentiel de définir clairement le sandbox des équipes pour pouvoir déléguer petit à petit.
Un bon outil est Moving Motivators qu’on peut utiliser par exemple entre décisionnaires et équipe. Les résultats pouvant tout à fait différer par équipe, par produit, et ainsi de suite.
Toujours plus de communication
Il y aura forcément des équipes avec lesquelles ça marchera mieux que d’autres. Par exemple on laissera plus de latitude à un Product Owner en fonction de sa relation, ou parce qu’il affichera un caractère différent. Ou encore parce que l’équipe travaillera sur un projet ou un produit moins critique qu’un autre. Ou encore parce que l’équipe aura une dynamique qui fonctionne bien.
Dans tous les cas, il faut capitaliser dessus, mettre ces équipes en avant pour montrer que c’est possible, et que ça marche !
- Du côté de l’équipe en question :
“Bravo, soyez fiers, célébrez-le, pointez du doigt à la moindre occasion vos décisions…”
- Du côté des décisionnaires :
“Déléguer les décisions, ça marche… Et si on allait plus loin ?”
- Du côté des autres équipes :
“Être maître de son produit, c’est possible… Vous aussi vous pouvez le faire !”
D’où viennent les mauvaises décisions ? Factualiser les prises de décisions
Il faut aussi bien mettre en avant les cas où l’équipe n’a pas pris de meilleure décision, afin de l’expliquer :
- L’équipe avait-elle toutes les informations en main pour prendre la meilleure décision possible ?
- Les anciens décisionnaires ont-ils bien apporté leur soutien à l’équipe pour qu’il puissent prendre la meilleure décision possible ?
- Qu’a-t-on appris de cette mauvaise décision ? En ressort-on grandi ?
- Est-ce que vraiment c’était une mauvaise décision ??? Ou n’est-ce pas juste une autre décision que celles qu’auraient pris les anciens décisionnaires…
Le dernier point est très intéressant.
On oublie parfois qu’on peut avoir tort soi-même, ou qu’il peut y avoir plusieurs bonnes réponses à une question donnée.
Il faut factualiser les éléments de prise de décision et surtout les mesures de succès et d’échec de la décision.
Les indicateurs mesurés, c’est l’arme par excellence pour autonomiser les équipes. Pour sortir de la hiérarchie pour réellement parler produit !
Modern Agile
Finalement, tout ces éléments rejoignent beaucoup Modern Agile, qui se focalise sur les éléments clés pour construire un environnement propice à cette décentralisation des prises de décision.
Accélérer le feedback
Pour conclure il me semble important de préciser que ce n’est pas intrinsèquement “waterfall” qui est mauvais.
Ce qui est mauvais, c’est l’absence d’itération rapide et surtout de boucle de feedback.
Un véritable cycle en V, tel que l’a conçu son inventeur, est sensé intégrer des boucles — des cycles en V.
On peut aussi se focaliser uniquement sur cet élément plutôt que sur le débat waterfall vs. agile : en intégrant des boucles de feedback, et en les raccourcissant de plus en plus.
Tant que la boucle de feedback est annuelle ou semestrielle, la valeur à décentraliser les décisions n’est pas évidente.
C’est bien là tout l’intérêt du Value Stream Mapping afin de raccourcir tout ce cycle. Un raccourcissement qui est généralement voulu car on veut réduire son time-to-market, augmenter la satisfaction client (en étant plus réactif), ou encore être plus réactif que la concurrence.
Pour aller plus loin
Le Trello où chacun peut voter et proposer des sujets pour les Live de Scrum Life
La vidéo en question, quasiment une conférence en ligne de 45 minutes
Article sur la culture de l’échec et la sûreté psychologique
Mettre en place un sandbox pour les équipes
Voici également un webinar auquel j’ai pris part et dont ma présentation était sur ce sujet de la mise en place d’un sandbox pour les équipes.
Moving Motivators
Modern Agile
Que pensez-vous de cet article ?
Si vous avez aimé cet article, merci d’applaudir 👏 et de le partager !
Et pensez à souscrire à ma future newsletter : je prévois de quitter Medium, et cela sera le meilleur moyen de rester en contact.
À bientôt 😊