L’enjeu entourant la définition des rôles et responsabilités est systématiquement un enjeu majeur lorsqu’on implante l’agilité dans une organisation. Et plus l’organisation est bâtie sur un modèle de spécialiste, plus il y a de la confusion. En effet on sait que Scrum nous propose simplement 3 rôles: PO, SM et Équipier.  Sachant que certains cadres méthodologiques traditionnels nous propose une vingtaine de rôles différents on peut imaginer la confusion pour « l’analyste en sécurité » ou « l’architecte en modélisation de données » et autres rôles très spécialisés. En fait, même la simple distinction programmeur et analyste peut parfois être difficile à démêler pour une équipe novice en agilité ou la culture de la co-responsabilisation n’est pas au rendez-vous.

Pour vous aider à appuyer les discussions autour des rôles, je vous propose trois listes de rôles Agile qui vont un peu plus loin que Scrum tout en restant aligner avec les principes directeurs de l’agilité, donc sans tomber dans l’excès de la spécialisation.

Disciplined Agile Delivery

• La présence du rôle de l’Architect Owner (http://disciplinedagiledelivery.com/the-dad-role-of-architecture-owner/) dans les rôles proposés par DAD est très intéressante. Elle vient combler un besoin en terme du rôle de l’architecture dans les organisations TI. À toute les fois que j’ai eu à utiliser ce rôle, ce fût grandement apprécié et fort utile
• J’aime bien aussi la place qui est fait aux spécialistes pour bien montrer leur utilité et leur relation avec les équipes de développement

Although most agile team members are generalizing specialists, sometimes, particularly at scale, specialists are required

• J’aime aussi le modèle multi-équipes proposé par DAD 

DSDM

DSDM est assurément le moins connue (à tout de moins en Amérique) des cadres agile. Il propose tout plein de solution intéressantes pour effectuer de l’agilité en entreprise et les rôles ne font pas exception.

• La présence d’un project manager est entre autre à souligner, un rôle que l’on voit rarement officiellement décrit dans les référentiels agiles.
• Le rôle de l’analyste aussi est bien décrit. Avec son code à « deux couleurs » on le positionne hybride entre les préoccupations du PO et celle des développeurs. Pour nous qui travaillons souvent avec un analyste fonctionnel je trouve cette description intéressante

SAFe

SAFe ne donne pas sa place non plus quand vient le temps de décrire les rôles et responsabilités au delà de ceux définit par Scrum. J’apprécie plus particulièrement dans cet autre coffre à outils toutes les équipes décrites au niveau programme. Très utile pour organiser de grands projets/programmes agile

Bref il y a beaucoup plus à dire que PO, SM et équipier quand vient le temps de parler des rôles dans une livraison logicielle Agile. Je vous invite à rester ouvert aux possibilités présentées par les cadres Agile dit « d’entreprise » et surtout rester à l’écoute du contexte et de la réalité de votre organisation. Peut-être n’est-elle pas prête à décloisonner totalement l’ensemble de ses métiers!