Il est facile de vouloir faire du Scrum mais dans certains contextes le challenge est plus important que pour d’autres.
On pourrait aller vers la facilité et ajouter une autre méthodologie d’agile à échelle ,mais est-ce vraiment agile?
Comment rester sur une méthodologie unique et ne pas tomber dans le piège des faux-amis (SAFe, LESS, Nexus, DaD, etc…)? Donc voici le plan que j’ai proposé cette semaine.
Les grandes lignes
Rappel des principes agiles
Composition de la Scrum Team
Le rôle du Product Owner dans ce type de développement
Roadmap et stratégie de développement
Les challenges du Process Owner
Que fait un process owner?
La boîte à outils pour le faire le job a minima
Résumé:
- un projet ERP livre deux choses: des User Stories pour des utilisateurs interagissant dans le processus et un processus E2E (processus métier ou BPM) pour le client et une autre catégorie d’utilisateurs (Process Owners client par ex.)
- le Product Owner doit prendre en compte ces deux éléments c’est pourquoi celui-ci est secondé par un Process Owner faisant partie de la Scrum Team.
- si le Product Owner est le Process Owner, le risque est de ne satisfaire qu’une petite partie de l’audience utilisateur. Le résultat serait un taux de feedback faible voir nul et peu d’intérêt au développement de la solution entraînant des retards dans la réception. D’une manière générale, ce mélange est à proscrire car cela favorise la procrastination et l’enlisement dans une cascade.
- le Process Owner est un facilitateur et assure la mise en place des tests qui sont idéalement performés par les utilisateurs eux-mêmes.
bonne lecture
la bise
Pierre
The Scrum Coach 