> Que la faute vienne des personnes (souvent le Product Owner ou le Scrum Master), de l’organisation (de sa culture ou des managers qui imposent et contrôlent), de la contractualisation… Alex en parlait déjà il y a quelques années dans ses conférences.
> Que la faute viennent de Scrum parce qu’il est mal compris ou mal utilisé, comme le rappelle Henrik Kniberg (merci Christophe pour le résumé) :
Scrum est un cadre, non une méthode sur étagère, et une démarche empirique. Il faut donc bien l’implémenter, en faisant attention au contexte, aux contraintes, sans dogmatisme…
Tout cela est vrai.
Une question de contexte
Reste qu’il y a des contextes ou Scrum ne marche pas… complètement. Avec des clients, je suis tombé sur deux cas assez proches, un début de pattern donc.
Il s’agit de cas où la partie mûrissement du besoin métier est bien plus que de l’expression, de la spécification, ou de la conception métier. C’est le cas lorsque l’on a une partie de R&D métier (pas IT), par exemple :
Etudier un modèle statistique long terme que l’on va tester sur plusieurs semaines/mois avant de décider de l’implémenter ;
Travailler sur un algorithme spécifique pour un codec pendant plusieurs semaines/mois avant de l’implémenter dans la brique technique.
Le problème à régler
Que deviennent les experts métier travaillant sur ces sujets lorsqu’on parle de semaines ou de mois ?
Et que le thème sur lequel travaille l’équipe Scrum n’a pas grand-chose à voir avec son sujet ?
Les anti-patterns agiles
Bien sûr, on pourra toujours faire du Scrum dans ces contextes sur une partie du processus, mais pas sur l’ensemble. Mais on peut tomber dans différents pièges, qu’il faut éviter.
Ils ne font pas parties de l’équipe Scrum
Puisque pendant une grande partie de leur temps, ils ne travaillent pas sur les mêmes sujets que l’équipe Scrum, et qu’ils sont côté métier, ils ne se considèrent pas comme faisant partie de l’équipe.
D’ailleurs, ils sont suffisamment nombreux (il faut bien alimenter l’équipe Scrum de travail en continu), pour avoir leur propre manager, dans leur propre service. Cela renforce cette idée de ne pas faire partie de l’équipe Scrum.
Mais lorsque arrive le moment où leur sujet va être implémenté, ils ne font toujours pas partie de l’équipe. Alors ils se comportent plus en clients qu’en équipier, et ne s’impliquent pas lors du Sprint. Dommage, surtout qu’il s’agit de R&D, il risque d’y avoir des allers retours.
Ils sont obligés de faire partie de l’équipe Scrum
Ils font parties de l’équipe, tout le temps, même lorsque le thème en cours ne les concerne pas du tout. Le Scrum Master ne leur a pas vraiment donné le choix.
Ah dogmatisme, quand tu nous tiens… Les forcer à être présent aux cérémonies agiles n’est pas concluant. Personne n’y trouve son compte car chacun parle de son sujet sans que cela intéresse les autres. C’est vécu comme une perte de temps, et c’est normal. Cela renforce l’impression que le daily meeting sert à faire du reporting.
L’expert est le Product Owner de son sujet le temps du développement
Ah statut social quand tu nous tiens toi aussi!
Il est tellement important de briguer le poste de product Owner pour être reconnu dans son organisation… Alors tous ceux du métier deviennent Product Owner.
Et bien non, désolé. C’est un rôle opérationnel, pas un grade hiérarchique Product Owner.
L’équipe Scrum a dans ce cas une équipe de Product Owners, chacun poussant son propre développement. Sans responsable pour la priorisation ou les prises de décisions, c’est l’équipe Scrum (voire le Scrum Master) qui prend ce rôle.
Est-ce les personnes de l’IT les mieux placés pour prioriser des besoins métiers ?
Bien sûr que non, c’est le métier, compte tenu des contraintes de l’IT. C’est pour cela, que Scrum donne cette responsabilité au Product Owner, mais qu’il prend ses décisions en connaissance de cause, en étant immergé dans le projet avec l’équipe.
Une solution mixte
Ma proposition dans ce contexte est un mixte Scrum / Kanban. Attention, il ne s’agit pas de ScrumBan.
Implémenter la partie Scrum
Côté Scrum, il doit y avoir un Product Owner unique qui joue son rôle de priorisation, de planification. Il est en discussion avec les experts pour savoir ce qui va bientôt arriver, comment on peut découper le besoin… Ces experts, à ce stade, sont des parties prenantes du projet.
Ensuite, je propose que les experts fassent parties de l’équipe Scrum le temps de la réalisation de leur besoin. Ils assistent à toutes les réunions au même titre que les équipiers, sans rôle spécifique. Ce sont des experts métier sur le sujet en cours. Cela peut durer quelques sprints.
Une fois implémenté, stabilisé, amélioré, bref quand il n’a plus besoin de l’équipe et qu’il repart en quête de son nouveau modèle, il ressort de l’équipe, temporairement.
Un des bénéfices, est que l’expert est disponible et que l’équipe converge plus vite vers la bonne solution; mais également cela pousse l’équipe a se focaliser sur un sujet principal et non s’éparpiller sur plusieurs sujets en parallèle.
Aider le Product Owner avec un Kanban métier
La difficulté pour le Product Owner est dans ce cas de bien anticiper son plan de release, de planifier le bon sprint pour réaliser la solution; sachant qu’il y a une équipe d’experts plus ou moins importante travaillant sur des sujets plus ou moins matures, avec des contraintes plus ou moins fortes.
On met en place un Kanban board métier s’appuyant sur le process R&D qui alimente l’équipe Scrum pour aider le Product Owner et les experts à travailler au bon rythme pour l’équipe.
Ce Kanban est différent d’un Kanban pour Product Owner, orienté sur son Product Backlog. C’est d’expérience un Kanban avec différentes étapes de validation.
Vous avez aimé ? Réagissez !
Vous êtes dans ce contexte et rencontrez les mêmes difficultés ? Quelle organisation avez-vous mis en place pour y répondre ?
Hé hé, exactement la problématique que je rencontre en ce moment en coaching et on travaille pour mettre en place ce Kanban métier … Non sans difficulté car les personnes à impliquer sont nombreuses et évidemment peu disponibles. L’idée est de construire ce Kanban avec tous les acteurs concernés, de définir chaque étape et ses critères de done, de décider comment on va suivre les sujets, à quelle fréquence, etc …
C’est la deuxième fois que je rencontre cette problématique et on avait déjà essayé sur un projet précédent mais d’autres problèmes plus importants étaient présents et finalement, les acteurs concernés avaient laissé tomber ce Kanban. A suivre donc.