Je discutais de ce point avec le responsable des projets Agiles de l'entreprise. Son opinion est qu'il ne faut pas être trop rigoureux, tout au moins pas rigoriste.
L'Agilité c'est aussi l'adaptation. Il peut arriver qu'un PO demande un changement et s'il a de très bonnes raisons ont peut considérer sa demande.
Du point de vue de ce responsable on a trop souffert dans nos systèmes passés (projets à cycle en V) de l'excés de rigueur.

Je déteste la rigidité, la rigueur, les cadres imposés...je suis par nature un homme de service et de compromis.
Mais je ne suis pas de son avis

Scrum est fait de 2 choses :
  • Un espace de liberté au profit de la création et de l'adaptation au service desquels le chaos est sollicité.
  • Un cadre strict et une discipline forte qui permettent d'empêcher la propagation du chaos au projet lui-même .



C'est le principe du moteur à explosion . L'énergie est générée dans une chambre de combustion qui permet de la contenir.
La récupération de l'énergie est maîtrisée : celle-ci est dirigée pour générer une puissance utile.
Retirez la chambre de combustion et provoquez l'explosion, comme dirait notre ancien président ça fait pschiiiiit.

Nos problème passés venaient il vraiment de la rigidité du process ?
Parmi les raisons qui font que l'on prône la rigueur en gestion traditionnelle de projets on peut ressortir la longueur du cycle de production et la dépendance hiérarchique des tâches. Une gestion rigoureuse était mise en place pour tenter de garder la maîtrise des budgets et des délais.

La contrepartie en est que l'obtention d'un produit à la fois minimal et parfaitement adapté à l'utilisateur tenait du challenge.

Pour tenter de corriger les erreurs d'appréciation initiales, il existe un processus de gestion des exceptions. C'est ce que l'on appelle l'"escalade" auprès du manager.

Les managers ont le pouvoir de briser les règles pour arranger des écarts fonctionnels ou des reports de délai.
En réalité ce processus est un dysfonctionnement qui répond à un dysfonctionnement (mais qui a aussi bien d'autres logiques d'existence)

La philosophie Scrum est de proposer des cycles courts dans lesquels des fonctions finalisées sont livrées.
Le risque de ne pas produire une fonctionnalité prioritaire dans un délai compatible avec un besoin métier réel est sinon nul du moins très limité. Et dans le cas ou il est avéré, ce risque peut sans doute se gérer sans briser le cadre Scrum (par une solution dégradée temporaire).

Le recours à l'escalade doit être vue comme une facilité du projet traditionnel , dans lequel le manager a le pouvoir de déroger au processus.

En passant en organisation Agile le manager a délégué son pouvoir.

S'il veut favoriser la progression vers l'agilité alors il doit aussi se soumettre à la discipline que demande le cadre Scrum.


Comme disait un manager aux débuts de ma carrière : passées les bornes, il n'y a plus de limites.



Crédits : perso: Auguste - Musée du Vatican
http://lemondedekoulou.over-blog.com/40-categorie-705456.html
http://commons.wikimedia.org/wiki/File:Moteur_plan.PNG
http://commons.wikimedia.org/wiki/File:Tableau_SYMPHONIA.jpg ...