Press "Enter" to skip to content

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.

Photo by Marta Markes on Unsplash

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à ???”

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Top