Idée fausse n°3 sur le développement logiciel dans une grande organisation : notre équipe doit-elle avoir une vision limitée ou une vision globale du produit ?
Auteur : Michael James (MJ)
Source : Large Organization Software Development Misconception #3: Should Our Team See A Narrow View Or A Whole Product View?
Date : 03/08/2019
Traducteur : Fabrice Aimetti
Date : 25/08/2019
Traduction :
La plupart des entreprises ont plus de 11 personnes qui travaillent sur un produit donné. Juste pour faire en sorte que Scrum soit adapté (une optimisation locale), ils vont redéfinir le mot "Produit" pour signifier quelque chose de plus étroit/limité que l'ensemble du produit. C'est le premier pas dans un "jeu aux miroirs" où les mots signifient le contraire de leur intention originelle.
L'erreur suivante est de donner à chaque équipe un "Backlog Produit" pour lequel des observateurs avertis remarqueront qu'il n'est en fait qu'un Backlog d'Équipe.
Ensuite, donnez à chaque équipe un "Product Owner" distinct qui n'est en fait qu'un Team Output Owner.
Cela nous laisse avec peut-être une douzaine d'"Equipes Scrum" séparées dont les managers s'inquiètent en courant autour comme des poulets avec la tête coupée, à moins que nous ne les rassemblions d'une manière ou d'une autre. La manière traditionnelle de le faire, qui remonte au moins à l'armée de Jules César, est d'ajouter des couches hiérarchiques. Les humains ont du mal à penser à des alternatives aux couches hiérarchiques ; c'est malheureusement ce qui est recommandé à la fin de la vidéo extrêmement populaire de Henrik Kniberg sur le Product Owner (une vidéo géniale jusqu'aux dernières minutes avant la fin). Nous avons donc maintenant un "Chief Product Owner" ou "Business Owner" ou un autre moyen de combler le vide.
Un descendant de l'approche ratée RUP (Rational Unified Process) appelée Scaled Agile Framework (SAFe) ajoute tout une pile de couches de management traditionnel en plus de nos "Equipes Scrum". Il se vend très bien parce qu'il s'agit simplement de renommer tous les rôles traditionnels en rôles à consonance Agile (fr).
Ces approches hybrides traditionnelles/Agile laissent les plus gros problèmes dans l'espace traditionnel plutôt que dans l'espace Scrum de priorisation d'une liste unique et d'auto-organisation des équipes. Avec une vue limitée du produit, seuls nos orteils finissent par être Agile.
Les Scrum Masters (et la le management, si vous l'avez avec vous) devrait vous aider à éradiquer les mesures incitatives actuelles et à encourager plutôt une approche globale du produit (fr).
