Les méthodes agiles telles que Scrum et Extreme Programming ne sont pas adaptées à tous types de projets et demandent une organisation bien différente de la classique organisation verticale. De grands penseurs (Ward Cunningham inventeur du Wiki, Kent Beck fondateur de l'extreme programming...) se sont réunis en 2001 et ont publié le manifeste des méthodes agiles qui met en avant les quatre valeurs fondamentales des méthodes agiles :

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

Le troisième point place le client au centre de ces méthodes. Terminée la relation client vs fournisseur, MOA vs MOE... Le client doit faire partie de l'équipe projet. Un des douze principes de ce manifeste est :

Business people and developers must work
together daily throughout the project.

On comprend donc que la MOA doit être très impliquée et collaborer très étroitement avec les autres intervenants du projet. Voici pour exemple un schéma expliquant le fonctionnement d'une des plus connues des méthodes agiles, SCRUM :

En plus de l'équipe qui va réaliser les développements, Scrum définit deux rôles que pourraient jouer une MOA "classique".

Le Product Owner. C'est celui qui va définir le Product Backlog composé des demandes des parties prenantes du projet, priorisées d'un point de vue business. Dans une organisation classique, sur une application qu'on fait évoluer en mode catalogue, la MOA fait déjà souvent ce travail via un outil comme JIRA par exemple. Là il s'agit de le faire avec une terminologie et une finalité différentes. A partir de ce Product Backlog le Product Owner va définir le contenu de la prochaine itération (le sprint) avec l'aide de l'ensemble de l'équipe : c'est le Sprint Backlog.

Le Scrum Master. C'est celui qui aura pour rôle de faciliter le travail de l'équipe. Ce n'est pas un chef, il n'y a pas de notion de hiérarchie dans ce process. Ce rôle consiste à faciliter la résolution d'éventuels conflits, rappeler les principes de Scrum lorsqu'un membre de l'équipe s'en écarte... Et en tant que MOA on joue déjà le rôle de facilitateur. Par contre je connais peu de MOA ayant des compétences sur ces méthodologies.

En plus de cette organisation, Scrum propose d'utiliser des outils tels que le daily scrum ou daily standup meeting, le burn down chart, les post-it et les grands tableaux blancs pour concevoir... Tous ces éléments font que l'organisation du travail est assez différente d'une organisation classique. Il n'y a pas de chefs, il faut s'auto-gérer, s'auto-motiver... C'est un mode de fonctionnement que tout le monde ne voudra/pourra pas accepter. Et cette terminologie et organisation assez spécifique peut créer un effet de communautarisme dès lors que cette organisation n'est pas celle de toutes les équipes de votre service.

Depuis quelques années on essaie d'utiliser des méthodes adaptées à l'industrie "lourde" comme Lean ou Six Sigma pour des projets SI. Or la maturité de l'industrie informatique est très loin de celle d'autres industries plus anciennes comme l'automobile. De plus, le travail d'un développeur informatique n'est en rien comparable aux tâches effectuées par des opérateurs d'une chaîne de production. C'est pourquoi les méthodes agiles me semblent plus pertinentes. Mais encore faut il trouver sa place en tant que MOA dans ces organisations parfois mises en place par des nerds. Il faut également savoir rester pragmatique pour ne pas adopter n'importe quelle méthode, n'importe comment. On doit s'approprier une méthode publique pour construire sa propre méthode qui sera acceptée par tous les intervenants.

Modernanalyst.com - How new are all those "new" methodologies really?