La responsabilité : clé de l’auto-organisation
Stop au maternage d’équipe
Le serpent qui se mort la queue
La réalité des comportements humains est toujours floue : est-ce que les gens ne sont pas prêts pour le changement ou est-ce que le changement permettrait de devenir prêt ?
Concrètement, c’est comme raccourcir un Sprint, ou passer au Continuous Delivery : on peut se dire qu’on n’est pas prêt pour ça et qu’on verra plus tard, ou on peut se dire que d’y aller facilitera voire forcera de faire le nécessaire.
On pourrait aussi parler du cas de figure où c’est le Product Owner qui teste et non pas l’équipe de développement. Et bien : on peut se dire “non il faut que le Product Owner teste car les dev ne testent pas”, ou on peut justement se dire : “les dev devront bien tester si le Product Owner ne teste pas”.
Cadre et auto-organisation
Pour sortir de ce genre de situation, il faut mettre en place un cadre clair et qui favorise l’auto-organisation.
Ainsi il faut dire clairement que c’est la faute des développeurs s’ils sortent des fonctionnalités qui ne respectent pas les critères d’acceptation.
Imaginons même que ce soit la faute du Product Owner qui n’aurait pas bien défini les critères d’acceptation. Et bien laissons la responsabilité aux développeurs de faire le nécessaire pour que ça arrive ! En refusant des User Stories, ou mieux encore en travaillant avec le Product Owner pour rédiger ensemble ces critères d’acceptation.
D’ailleurs, entre nous, des critères d’acceptation rédigés exclusivement par le Product Owner, ça ne vous fait pas un peu penser à un bon vieux cycle en V ?
Peut-on reprocher au Product Owner une mauvaise livraison ?
Tout ça veut aussi dire qu’en revue d’itération ce n’est pas le Product Owner qui doit se faire défoncer quand l’équipe livre de la 💩
Ou du moins pas le Product Owner tout seul mais bien toute l’équipe.
Je rappelle que le Product Owner est un rôle marketing. Il n’est garant de pas grand-chose de ce que sort techniquement l’équipe. Ce n’est pas un inspecteur des travaux finis.
Le Scrum Master non plus bien entendu même si le Scrum Master a lui par contre pour responsabilité de faire monter en maturité l’équipe de développement sur le sujet si nécessaire.
N’enlevons pas la responsabilité des gens ! Sinon pourquoi s’auto-organiseraient-ils ?
Mais ils le prendraient mal !
J’ai utilisé des mots durs. Je parle de faute, je parle d’accusation. Les questions de faute peuvent être très mal prises selon les personnes. Tout le monde n’est pas prêt à se remettre en question.
Tout est dans le cadre, dans la manière de s’y prendre.
Et pas forcément besoin de pincettes.
Imaginons la situation suivante…
Exemple : la revue d’itération
L’équipe fait une démo aux parties prenantes, aux stakeholders. Peut-être même en présence des clients.
Et lors de cette démo, rien ne marche.
Action-réaction : un des stakeholders pète les plombs et demande ouvertement : “Mais comment on a pu en arriver là ???”
Quelqu’un désamorce alors la situation, peut-être le Scrum Master, en disant que ce sera le sujet de la rétro qui a lieu juste après.
La rétrospective est super tendue mais les vrais sujets sont mis sur la table.
Entre nous, franchement, tout est normal dans cette histoire, non ? Cette situation difficile a-t-elle eu un effet positif ou négatif sur cette équipe ? L’équipe avait besoin de le vivre pour pouvoir sortir de sa routine et se remettre sur les rails.
L’équipe. Pas le Product Owner.
Attention à la forme : le cadre !
On en revient au cadre : on n’accuse jamais les personnes mais bien l’équipe dans sa globalité. C’est écrit dans le Scrum Guide — évidemment sans parler d’accusation mais bien de responsabilité.
Forcément, si on passe au pointage de personne ça va poser soucis.
Mais par contre tant qu’on “accuse” l’équipe dans sa globalité, c’est positif et ça renforce le cadre.
Pour aller plus loin
Tester c’est une activité de l’équipe de développement, pas du Product Owner
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 😊
