Discussion :

[phil89]

Pour apporter ma petite pierre à l'édifice, je ne vois pas comment on peux mettre en place un scrummaster tournant car cela présuppose que tout le monde a la compétence pour être scrummaster, ce qui me semble loin d'être le cas.
Il doit connaitre toutes les ficelles de scrum (et se tenir au courant des pratiques qui évoluent), communiquer régulièrement avec l'équipe mais juste dans son rôle de facilitateur (il doit donc être un bon communiquant) et aussi travailler main dans la main avec le PO, pour éviter que celui-ci ne charge trop la barque ou qu'il fournisse des specs compréhensibles pour tous.
Perso, dans mon équipe quelques uns pourraient le faire mais pas tous, ce qu iveut dire qu'il faudrait gérer les cas d'exclusion lors des tours de scrummaster .. bonjour le merdier.
Dans les exemples de scrummaster tournant que j'ai vu, on se contente juste de tourner pour la gestion de la mêlée, ce qui ne représente qu'une petite part du boulot.

Et pour ton pb de dvp ou pas dans scrum, je te conseillerais plutôt de prendre des petites taches qui dépannent les copains et font avancer le sprint. Rien de plus, rien de gros, rien qui ne demande bcp de temps car tu dois pouvoir être dispo rapidement ailleurs.
Certains scrummaster gère plusieurs scrums simultanés (scrums de scums), il devrait donc te rester du temps si tu n'as qu'1 scrum d'une équipe de 4 personnes à gérer.

[michel.di]

C'est vrai que comme le dit phil89 tout le monde ne peut/veut pas être ScrumMaster. Il faut savoir motiver les gens et se faire comprendre ce qui n'est pas le cas de tout le monde....

[batataw]

Intéressant, peux tu expliquer ce qui a mis en péril un de tes projets ?
SCRUM est plutôt un cadre à adapter à son projet, peut être vous n'aviez pas tout essayer ? Ou peut être que l'organisation SCRUM n'était pas compatible avec l'entreprise ?

En vrac:
- Scrum master pas suffisement formé, réunion scrum avec 2 équipes Scrum plutot qu'une.
- PO pas suffisement investi donc spec changeante trop souvent.
- Choix discutable de certains developpeurs, non remis en cause durant les mélées quotidienne.

En fait il faut dabord etre sur que tout le monde sache ce que cela implique.
En premier lieu ta boite. Ca ne peut pas etre quelque chose d'expérimentale que tu assumerais seul.

Et pour ton pb de dvp ou pas dans scrum, je te conseillerais plutôt de prendre des petites taches qui dépannent les copains et font avancer le sprint. Rien de plus, rien de gros, rien qui ne demande bcp de temps car tu dois pouvoir être dispo rapidement ailleurs.

Oui c'est pas une mauvaise idée pour commencer. Cela dit si la taille du projet et sa nature le permet tu pourras peut-etre t'investir plus dans le developpement. Surtout ne néglige pas les relations avec le PO.

[rad_hass]

Merci encore pour vos réponses, ça m'a permis de mieux appréhender certains points, y a un enthousiasme qui s'install dans l'équipe qui est très plaisant ...

Et puis la curiosité des autres avec notre 'tableau des tâches' en plein milieu de la salle, notre burndown que certains observent lolll ...

On commence déjà à définir certains point à améliorer ... Je pourrais bientôt vous faire un retour ;-)

[foucha]

pour moi aussi, un scrum master qui fait du dev c'est mieux qu'un SM qui n'en fait pas. Ne serait ce que pour mettre les mains dans le cambouis et connaitre les difficultés rencontrées et pouvoir y remédier. Sans parler du role de "coach" en terme de TDD par exemple.

Par ailleurs, autant au début, un SM est un job à plein temps, autant au fur et à mesure que le temps passe, l'équipe s'approprie les concepts, s'affranchit des blocages et propose des choses... le role de SM peut tourner pour chaque developpeur. Il faut juste du temps supplémentaire pour lui, et cela peut etre à base de volontariat.

[michel.di]

Ne serait ce que pour mettre les mains dans le cambouis et connaitre les difficultés rencontrées et pouvoir y remédier

Les difficultés doivent remonter de l'équipe. Le ScrumMaster n'a normalement pas besoin de toucher au code pour s'apercevoir des difficultés!

Sans parler du role de "coach" en terme de TDD par exemple.

Scrum n'impose pas de faire du TDD! Il s'agit d'un complément.

[foucha]

Les difficultés doivent remonter de l'équipe. Le ScrumMaster n'a normalement pas besoin de toucher au code pour s'apercevoir des difficultés!

"normalement pas"... pour moi, rien ne vaut de rencontrer les problemes soit meme pour pouvoir les résoudre. C'est forcément mieux. "Normalement" tout le monde communique clairement et librement, mais si c'était le cas, scrum n'aurait peut etre pas autant de succès.

Scrum n'impose pas de faire du TDD! Il s'agit d'un complément.

Oui c'est juste. Pourtant si on veut mettre ça en place, c'est le scrum master que je verrai en facilitateur technique, plus que tout autre membre de l'équipe.

[rad_hass]

"normalement pas"... pour moi, rien ne vaut de rencontrer les problemes soit meme pour pouvoir les résoudre. C'est forcément mieux. "Normalement" tout le monde communique clairement et librement, mais si c'était le cas, scrum n'aurait peut etre pas autant de succès.


Oui c'est juste. Pourtant si on veut mettre ça en place, c'est le scrum master que je verrai en facilitateur technique, plus que tout autre membre de l'équipe.

Il faut faire attention à cela, je pense.
Car si le Scrum Master joue trop le rôle de référent technique, l'équipe aura du mal à acquérir de l'autonomie et le SM ne jouera plus simplement le rôle de facilitateur, le Scrum Master doit permettre à l'équipe de s'améliorer mais c'est à l'équipe de voter, choisir ...

[foucha]

En fait pour moi il peut guider dans la mesure ou on lui a donné du temps pour se renseigner sur le sujet. Apres s'il y a un roulement de scrum master, tout le monde devient "référent technique" sur quelque chose. Mais meme sans scrum master tournant, du binomage (oui je sais c'est XP mais ce n'est pas une raison pour snober la pratique) permet à l'équipe d'etre de plus en plus autonome aussi dans les pratiques agiles, puis au fil du temps leader elle meme.

[lepinekong]

Ah benh que oui normalement le scrumaster est un développeur, celui pas forcément le meilleur techniquement, mais celui qui organize le mieux dans l'équipe.

Ca c'est en théorie, maintenant avec les traditions du chef de projet, ...

[Maximil ian]

Ah benh que oui normalement le scrumaster est un développeur, celui pas forcément le meilleur techniquement, mais celui qui organize le mieux dans l'équipe.

Ca c'est en théorie

Non, la théorie ne dit rien sur le fait que le Scrum Master doit être un développeur En pratique c'est souvent le cas, mais on peut très bien imaginer un Scrum Master qui n'a pas de compétence en développement.

Peut-on synthétiser les réponses de tout le monde en disant qu'il y a autant de Scrum Masters que d'organisations différentes :

Scrum Master dédié
Scrum Master donnant un coup de main sur des petites tâches de dev
Scrum Master/développeur à mi-temps
Scrum Master référent technique
Scrum Master tournant
...

à chaque équipe de mettre le curseur à l'endroit le plus adapté ?

A propos de ça, dans votre organisation qui choisit le Scrum Master et décide de son degré d'implication ? Le directeur de projet/responsable hiérarchique ? L'équipe ? Le PO ? Le Scrum Master lui-même ?

[lepinekong]

Non, la théorie ne dit rien sur le fait que le Scrum Master doit être un développeur En pratique c'est souvent le cas, mais on peut très bien imaginer un Scrum Master qui n'a pas de compétence en développement.

On peut mais ça tue l'esprit de scrum. Si le traditionnel chef de projet est scrumaster il va s'instaurer un rapport hiérarchique hors ce n'est pas l'esprit de Scrum. Scrum pour l'avoir pratiqué nécessite vraiment une plongée dans l'opérationnel, si le scrumaster n'as pas de compétence de développement alors c'est plus ou un doublon du product owner donc utilité faible. Le traditionnel chef de projet a normalement le rôle de product owner s'il est un minimum fonctionnel.

C'est plus les contraintes ou les habitudes à la française qui fait que ce soit autrement mais comme je l'ai dis sur mon site, il est important de comprendre l'esprit.

[Maximil ian]

On peut mais ça tue l'esprit de scrum. Si le traditionnel chef de projet est scrumaster il va s'instaurer un rapport hiérarchique hors ce n'est pas l'esprit de Scrum.

Je n'ai jamais dit que le Scrum Master devait faire office de chef de projet ! J'ai même dit le contraire (cf posts précédents)... On est d'accord là dessus Par contre j'estime que quelqu'un ayant assuré la fonction de chef de projet dans le passé peut faire un très bon Scrum Master.

Scrum pour l'avoir pratiqué nécessite vraiment une plongée dans l'opérationnel, si le scrumaster n'as pas de compétence de développement alors c'est plus ou un doublon du product owner donc utilité faible.

Je ne suis pas daccord. Un qualiticien, un DRH ou n'importe qui ayant une bonne approche de Scrum peut être Scrum Master. Tobias Mayer, récemment promu Creative Director de la Scrum Alliance, forme même des chômeurs au rôle de Scrum Master (WelfareCSM).

[lepinekong]

Je n'ai jamais dit que le Scrum Master devait faire office de chef de projet ! J'ai même dit le contraire (cf posts précédents)... On est d'accord là dessus Par contre j'estime que quelqu'un ayant assuré la fonction de chef de projet dans le passé peut faire un très bon Scrum Master.

Comme je l'ai dis sur mon Blog, le Fondateur de la Qualité Deming qui a formé les PDGs au Japon à la Qualité dit qu'il n'a jamais réussi à faire la même chose en Occident parce que les gens n'essayent pas de comprendre l'Esprit mais veulent des recettes.

Donc le "Ah mais c'est pas écrit que c'est interdit" est typique parce que justement il y a très peu d'écrit dans Scrum parce que Scrum respecte la philosophie de Deming qui est de ne pas figer les règles dans le Marbre sauf quelques grands principes. Il faut donc être flexible sur la pratique tout en étant intransigeant dans le respect des principes quant à cette pratique .

L'un des principes fondamentaux de Deming et de Scrum est de supprimer les intermédiaires qui n'ont rien à voir avec l'opérationnel. Beaucoup de chefs de projet pour les 3/4 sont des Chefs de Projet "Powerpoint" du moins dans le contexte Grands Comptes donc ils n'y connaissent pas grand chose au développement. En ce qui me concerne je connais bien , mais ceci dit mon vrai rôle de chef de projet est plus de qualifier et prioritiser les besoins ce qui correspond donc plus au rôle de Product Owner.

C'est seulement si par défaut personne ne peut faire Scrumaster mais je ne vois pas pourquoi à part que beaucoup de développeurs dans la tradition française ne sont pas des grands communicants et ne veulent que coder. Mais c'est en forgeant qu'on devient forgeron, il suffit de les habituer.

Je ne suis pas daccord. Un qualiticien, un DRH ou n'importe qui ayant une bonne approche de Scrum peut être Scrum Master. Tobias Mayer, récemment promu Creative Director de la Scrum Alliance, forme même des chômeurs au rôle de Scrum Master (WelfareCSM).

Si je parle aussi souvent de Deming, ce n'est pas sans raison, c'est que j'ai commencé dans la QA en ayant invité un ami personnel de Deming pour donner des conférences alors que j'étais encore en école d'ingénieur avant de m'apercevoir une fois dans la vie professionnelle que six sigma & co qui se réclamait de Deming ne respecte pas en fait l'esprit originel de la Qualité (voir cette vidéo où il dit ce qu'il pense de tous ces intermédiaires six sigma [ame="http://www.youtube.com/watch?v=GXVgsPxQR54"]YouTube- An Evening with Dr. Deming[/ame]) et quand j'en croise en informatique, ils ont très souvent l'esprit waterfall hérité de six sigma (esprit de contrôle et non esprit opérationnel ou d'amélioration) et il suffit de regarder la dernière vidéo ici http://lepinekong.fr/videos/scrum-videos/ d'un séminaire animé par Ken Schwaber, le co-fondateur de scrum, pour constater le dédain qu'il a pour les gens de la QA


Il y a QA et QA. Celui qui respecte l'esprit de Deming et des fondateurs de Scrum qui est réellement de produire de la Qualité et l'autre qui est de juste contrôler et prendre le pouvoir (il suffit de les entendre parler de "Gouvernance" ...). Les gens de QA sont des gens souvent très intelligents et beaucoup ont de la Bonne Volonté mais ils ont été mal inspirés par tout l'esprit commercial qui tourne autour du Consulting dans ce domaine et ils n'ont certainement jamais lu Deming pour la très grande majorité car ceux qui vendent les cours de QA ne veulent surtout pas faire savoir que la vrai QA se passe fort bien de la bureaucratie d'où le Mouvement Lean Management qui est de revenir aux principes de Deming.

[lepinekong]

Tiens quand je disais que Six Sigma c'est à ne pas suivre voilà ca y est après des années l'Armée Américaine le dit enfin officiellement :

http://www.alu.army.mil/alog/issues/...alControl.html