Voir la source de 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 ?

[[Category: Agilité à grande échelle]]
[[Catégorie:Michael James]]
[[Category: Portail Coach'Agile]]
[[Category: Portail Product Owner]]
Auteur : Michael James (MJ)<br />
Source : [https://seattlescrum.com/misconception-3-should-our-team-see-a-narrow-view-or-a-whole-product-view/ Large Organization Software Development Misconception #3: Should Our Team See A Narrow View Or A Whole Product View?]<br />
Date : 03/08/2019<br />
----
Traducteur : Fabrice Aimetti<br />
Date : 25/08/2019<br />
----
Traduction :<br />
<br />
[[Fichier:Seattle-Scrum-Company-logo.png|left|150px]]Les équipes de petite taille sont formidables et sont prescrites par la définition de Scrum. Scrum prescrit également un Backlog Produit et un Product Owner.<br/>
<br/>
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 [https://seattlescrum.com/local-optimization-bias/ 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.<br/>
<br/>
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''.<br/>
<br/>
[[Fichier:Product-backlog-minus-whole-product-authority-equals-team-backlog fr.png|border]]<br/>
<br/>
Ensuite, donnez à chaque équipe un "Product Owner" distinct qui n'est en fait qu'un ''Team Output Owner''.<br/>
<br/>
[[Fichier:Product-owner-minus-whole-product-authority-equals-team-output-owner fr.png|border]]<br/>
<br/>
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.<br/>
<br/>
Un descendant de l'approche ratée RUP (Rational Unified Process) appelée [http://www.lafable.com/ 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 [https://www.wikiagile.fr/index.php?title=Fans_of_LeSS_-_Nous_nous_opposons_%C3%A0_la_corruption_g%C3%A9n%C3%A9ralis%C3%A9e_d%27Agile_et_de_Scrum renommer tous les rôles traditionnels en rôles à consonance Agile (fr)].<br/>
<br/>
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.<br/>
<br/>
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 [https://www.wikiagile.fr/index.php?title=Less_-_Focus_sur_le_produit_global approche globale du produit (fr)].