Matrice de décision d’un ScrumMaster

Dans un projet Scrum comme pour des projets suivants un autre framework, les responsabilités doivent être clairement établies (le plus souvent possible) pour réduire les ambiguïtés dans les décisions (qui décide de quoi).
La matrice de décision d’un ScrumMaster serait la suivante :
 
– Éliminer les obstacles identifiés
– Organiser les tâches périodiques
– Entretenir la communication et la motivation dans l’équipe
– Organiser la prise en compte et le déploiement des améliorations sur le projet
– Guider les acteurs du projet
 
On m’a récemment posé la question suivante : « Dans une équipe Scrum qui ‘vire’ la ressource qui ne va pas au projet ? ». Si je fais une réponse 100% Scrum, je dirai : « C’est l’équipe qui prend une décision commune ». Mais là, on se croirait dans l’émission le maillon faible (The Weakest Link) mais les dérives sont vites possibles si le ScrumMaster n’a pas été vigilant ou si l’équipe n’a pas la maturité requise. Dans notre situation actuelle, la proposition de l’équipe serait évidemment à prendre en compte, mais il faut d’abord compter sur une décision concertée du ScrumMaster, du directeur de projets et du Product Owner. Dans ce framework, le PO a une position plus intégrée à l’équipe qu’un client dans un Cycle en V, il connaît donc bien chaque membre de l’équipe pour participer à cette décision. Dans tous les cas, le ScrumMaster n’a pas un rôle hiérarchique sur le projet qui lui permet de décider seul de la situation de chacun.
Je ne cesse pas de le répéter : « Scrum, ce n’est pas magique ! ». Dans une récente présentation comparative du framework Scrum et de la méthode Cycle en V (/waterfall), je faisais ressortir que la méthode de Cycle en V était pauvre dans tout ce qui était collaboratif. Un « bon » chef de projet pouvait déployer des bonnes pratiques de collaboration sur son projet en Cycle en V alors que le framework Scrum les intégrait en standard. Mais il n’intègre pas tout comme le montre cet exemple sur la gestion des ressources humaines.
 
Mais Scrum intègre un dispositif qui pour moi a beaucoup de valeurs : Rétrospective de Sprint/Release. Même si au départ on considère que la gestion des ressources humaines est du domaine du SM & du directeur de projet, on pourrait imaginer qu’une amélioration continue pourrait être de faire redescendre cette responsabilité dans le choix d’une nouvelle ressource sur le projet un peu comme cela se passe pour un appartement en colocation.
Cette article me donne l’idée du poste suivant : « Que devient un chef de projet avec le Framework Scrum ? »