Discussion :

[Grom61736]

Bonjour,
Tout d'abord, j'espère être au bon endroit. Désolé sinon.

J'ai rejoins il y a 2 mois une société qui "fait du vrai Scrum pas comme ton ancienne boite, ca c'est du dilué nous c'est le vrai de vrai" et … je trouve l’ambiance de travail absolument exécrable.

Étant donné que c’est seulement la deuxième boite dans laquelle je travaille, j’aimerais avoir des avis pour savoir si cet environnement est « normal » (et donc que j’ai été pourri gâté par la première) ou si il y a véritablement un problème.

Depuis que je suis arrivé, je n’ai pas fait grand-chose (plus ou moins 4 jours où j’ai été un peu occupé). J’ai demandé plusieurs fois s’il n’y avait rien à faire et l’on me répondait qu’on allait me montrer.
Au bout d’un moment, on m’a expliqué que la méthodologie était une équipe auto-organisée et donc que c’était à chacun de chercher des documents sur intranet pour se coacher, de regarder dans Mantis et de s’assigner les tickets qui l’intéressent puis de chercher soi-même dans le code les diverses corrections.

Bon, donc pour la pomme qui vient d'arriver, pas de chef d’équipe pour faire un topo général de l’application (10 ans d’âge au compteur), de son but ou autre et personne de désigné pour en expliquer le minimum.

Par la même occasion, lorsqu’un projet arrive, il est divisé par un analyste en plusieurs parts et c’est à chacun de se jeter sur une part, de développer, de tester et d’intégrer seul dans son coin avant que l’équipe de test ne teste si tout les bouts fonctionnent ensemble.

Cela a pour conséquence première que
1) Autant donné que tout est subdivisé pour qu'une tâche soit pour une personne, c’est mort. Pour avoir une ambiance pareille, autant aller coder dans une morgue. Et l’absence de Daily meeting n’aide en rien.
2) En tant que nouveau, si on a une question sur un point précis, impossible de savoir quelle est la personne qui s’y connait mieux que les autres et qui pourrait nous répondre.
3) Vu que personne n’est désigné, il n’y a pas de volontaire pour donner les trucs et astuces ou une mini formation aux nouveaux.
4) Impossibilité d’avoir une vue générale de l’application.

Selon ce que je lis ici sur l’intranet, c’est cela leur application de Scrum. Chacun est un élément indépendant donc tout seul qu’on ne met pas sur les mêmes choses car il doit être compétent sur tout (et donc connaisseur sur rien) et c’est fortement tourné vers l’individu.

Le résultat est que les gens se mettent ensemble dans une pièce pour bosser tout seul et ne se connaissent pas. Cela pourrait être 20 indépendants sur des sujets différents partageant juste le même espace qu’on ne verrait pas la différence.

Et cette asociabilité me dérange fortement. Pourquoi bosser en équipe si c’est chacun tout seul ?
Il y a encore 10-20 ans, on voyait les informaticiens comme des asociaux, bigleux et moches. Ca vaut la peine d'aller dire partout que ce n'est pas vrai si on veut isoler chaque personne... Quel est l’intérêt de prôner un tel repli sur soi ?

Dans mon ancienne boite, il y avait l’équipe, le chef d’équipe et l’esprit d’équipe et mine de rien, ca fait vieillot mais je trouvais cela performant.

D’où la question principale : est-ce cela le Scrum, le vrai de vrai et à quel point est-ce appliqué pur jus dans les entreprises ?

Sinon, vu qu'il n'y a plus de chef de projet à proprement parler, qui s'occupe de l'intégration (ne fusse technologique) des nouveaux ? Le ScrumMaster ou est-ce à celui qui en a envie ?

Merci de vos réponses.

[koala01]

Salut,

Juste un petit lien, dont je vais tirer quelques extraits chosis:

Ce processus s'articule en effet autour d'une équipe soudée, qui cherche à atteindre un but, comme c'est le cas en rugby pour avancer avec le ballon pendant une mêlée

Le principe de base de Scrum est de focaliser l'équipe sur une partie limitée et maîtrisable des fonctionnalités à réaliser. Ces incréments se réalisent successivement lors de périodes de durée fixe de une à quatre semaines, appelées sprints. Chaque sprint possède, préalablement à son exécution, un but à atteindre, défini par le propriétaire du produit, à partir duquel sont choisies les fonctionnalités à implémenter dans cet incrément. Un sprint aboutit toujours à la livraison d'un produit partiel fonctionnel. Pendant ce temps, le ScrumMaster a la charge de former le directeur de produit, l'équipe et l'organisation entière à la méthode Scrum.

Une équipe auto-organisée choisit la façon d'accomplir son travail, sans que ce soit imposé par une personne externe. Il n'y a pas non plus de notion de hiérarchie interne : toutes les décisions sont prises ensemble.

Note: Auto-organisée ne signifie pas auto-gérée ! Dans les grandes entreprises, un cadre de gestion doit intervenir si une équipe ne fonctionne pas comme il le faudrait. La gestion est toujours de rigueur. Elle laisse plus de place à l'équipe, surtout si une équipe n'est pas encore prête à assumer les rôles de gestion. Par contre, une équipe prête à assumer ces fonctions peut devenir auto-gérée.

Je suis désolé, mais, si une équipe doit être
soudée
formée
auto-organisée
et que les décisions doivent être prises ensemble, cela implique, à mon gout, que c'est une équipe qui communique de manière incessante.

Comprends par là : pas seulement le matin pour décider de ce qui est fait jusqu'à midi et à 13h00 pour décider de ce qui est fait jusqu'à la fin de la journée, mais tout le temps.

La dernière citation mets bien un point en avant : c'est l'équipe qui s'organise "comme l'équipe le veut", mais cela ne veut pas dire que les membres de l'équipe sont "lâchés dans la nature" comme cela.

On ne peut arriver à lacher une équipe scrum que... lorsqu'elle a montré qu'elle était capable de travailler sans garde fou.

Dans le cas présent, je n'ai vraiment pas l'impression que ce soit le cas, qu'ils n'ont pris que les aspects qui les intéressaient, mais qu'ils n'ont pas choisi les bons

[Luckyluke34]

Pour info :

Individuals and interactions over processes and tools

Première valeur du manifeste agile

et aussi :

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

http://agilemanifesto.org/
http://agilemanifesto.org/principles.html

Je ne vais pas ressortir le Scrum Guide mais j'imagine qu'on y trouve le même genre de recommandations, en particulier sur la bande passante de communication qui doit être ouverte à fond. La transparence est un des premiers piliers de Scrum me semble-t-il.

D’où la question principale : est-ce cela le Scrum, le vrai de vrai et à quel point est-ce appliqué pur jus dans les entreprises ?

Tu as déjà commencé à répondre à la question en pointant le fait qu'il n'y a pas de daily meeting et toutes les autres bizarreries. Personnellement, pour avoir vécu des expériences avec Scrum dans 3-4 boites différentes, je ne l'ai jamais vu appliqué tel que tu le décris.

Sinon, vu qu'il n'y a plus de chef de projet à proprement parler, qui s'occupe de l'intégration (ne fusse technologique) des nouveaux ? Le ScrumMaster ou est-ce à celui qui en a envie ?

Je dirais que le Scrum Master est garant (mais pas décideur) de l'organisation de l'équipe : réunions, coutumes, rythme de développement, dialogue avec le Product Owner, etc. donc il doit au moins te guider dans ta découverte de cet écosystème et être là pour répondre à toutes tes questions.

Sur un plan plus technique, il faut bien que tu montes en compétence aussi donc c'est aux autres membres (éventuellement à un développeur senior/tech lead) de t'accompagner. Je trouve que le pair programming (pratique issue d'eXtreme Programming) est redoutablement efficace sur ce point. En tout cas ça me parait absolument inepte de te lâcher dans le grand bain en te demandant de t'auto-coacher sur la seule base de documents écrits.

Dans "auto-organisation" agile, "auto" désigne l'équipe en tant qu'entité précisément très soudée et cohésive, pas l'individu.

[Bruno Orsier]

D’où la question principale : est-ce cela le Scrum, le vrai de vrai et à quel point est-ce appliqué pur jus dans les entreprises ?

Sinon, vu qu'il n'y a plus de chef de projet à proprement parler, qui s'occupe de l'intégration (ne fusse technologique) des nouveaux ? Le ScrumMaster ou est-ce à celui qui en a envie ?

Eh bien ça ne ressemble pas du tout à Scrum, ni à la théorie, ni à la pratique... Si tu peux, prends tes jambes à ton cou, ou bien essaie de changer la situation.

Les analystes en début de chaine, le test et l'intégration bien à la fin... Les équipes Scrum que je connais essaient au contraire de rapprocher toutes ces activités et de les faire collectivement.

Vu ta description, je suppose que vous ne faites pas de rétrospectives à la fin des sprints pour parler de tout cela ? D'ailleurs faites-vous des sprints ?

Je suis curieux de savoir quelles sont les conséquences de tout ce que tu mentionnes ? Si ta description est juste, le développement doit être relativement inefficace, non ? Est-ce que les travaux mettent beaucoup de temps a être terminés ? Il y a beaucoup de bugs ?

L'intégration des nouveaux, c'est un bon sujet pour le ScrumMaster qui devrait s'y intéresser de près, mais c'est aussi la responsabilité collective de l'équipe.

Cela peut se gérer vraiment très facilement, par exemple nous nous faisons un petit brainstorming avec l'équipe pour identifier tout ce qu'un nouveau doit apprendre, nous rendons ça visible sur un tableau avec les noms des volontaires qui vont à tour de rôle aider le nouveau... Dans un contexte, le rôle du ScrumMaster est de s'assurer qu'une telle réunion d'intégration a lieu, et l'équipe effectue les activités d'intégration, en fonction des compétences de chacun. Voir ce billet que j'ai écris il y a quelque temps http://blog.developpez.com/bruno-ors...ne-quipe-scrum.

Ça marche extraordinairement bien.

Mais je rencontre parfois des équipes qui ne s'intéressent pas à la question. Pour elles, le nouveau n'a qu'à apprendre tout seul, à la dure, comme eux ont appris il y a 20 ans... Seuls les plus intelligents survivront... Reproduisons les conneries du passé, comme cela nous réussirons dans le futur...

Donc il n'y a pas de partage, de capitalisation des connaissances, d'intelligence collective... C'est un gros problème pour l'entreprise qui est ainsi affaiblie.

Pour moi ce sont des équipes qui ne tiendront pas la distance face à de vraies équipes Scrum...

[el_slapper]

Tout est dit, ou presque.

J'ajouterais juste que dès le "nous on est les seuls à faire le vrai", c'était mal barré. Il y a autant de méthodes agiles que d'équipes agiles, et chaque équipe s'adapte à son besoin, en fonction de la taille du projet, de sa criticité, et de spécificités locales. J'ai appliqué des méthodes agiles efficaces. D'autres ont fait complètement différement de moi - et ils ont eu raison.

Malheureusement, ce genre d'imbéciles brillants, au cerveau hyper-rapide pour appliquer des principes inadaptés, on en trouve plein. . Le plus invraisemblable, c'est quand même l'absence de communication : même les consultants les plus obtus ont été sensibilisés aux miracles de la "communication"(même si ils ne savent pas la faire fleurir). A défaut de faire des miracles à ce sujet, au moins ils essayent. Dans ton cas, même pas. Re -

[Grom61736]

Tout d'abord, merci à tous pour vos réponses.

Après avoir cuisiner chaque personne sur ce qu'il fait (c'est con à dire mais dans un endroit où il n'y a pas de discussion et que les gens mangent devant leurs écrans, c'est pas facile de deviner leurs tâches ^^), bah ... il n'y a pas de Scrum Master désigné.
Donc, je trouve cela miraculeux que tout tienne encore debout mais ils ont préféré tout d'abord un ScrumMaster intégré, et non dédié et puis le monsieur est parti. Donc il est tellement bien intégré qu'il est en chacun d'entre nous je suppose

Pour répondre aux questions plus précises de Bruno Orsier :

Je suis curieux de savoir quelles sont les conséquences de tout ce que tu mentionnes ? Si ta description est juste, le développement doit être relativement inefficace, non ? Est-ce que les travaux mettent beaucoup de temps a être terminés ? Il y a beaucoup de bugs ?

Une mise en production tout les 4 mois en moyenne donc je n'en ai vécu qu'une seule et il y a eu plus de 200 tickets le lundi qui a suivi donc c'est effectivement pas top niveau qualité.

Mais vu que le client est une grosse boite et que le produit est là depuis 10 ans, ils se basent sur le fait que la grosse boite ne va pas mettre X euros pour faire refaire tout le système par quelqu'un d'autre.


Enfin, mon but n'était pas de leur dresser un procès mais de savoir si cela était normal et apparemment non. Je peux donc chercher ailleurs sans (trop) craindre de tomber dans pire.

Merci à tous.

[souviron34]

Dans le cas présent, je n'ai vraiment pas l'impression que ce soit le cas, qu'ils n'ont pris que les aspects qui les intéressaient, mais qu'ils n'ont pas choisi les bons

C'est à mon avis encore pire et ce que je répète (malheuresuement jusqu'à la nausée) : le mot-clé "Agile" est, pour beaucoup, un buzzword marketing.... Qui, en externe, permet de vendre du vent, et en interne permet de faire n'importe quoi...

Un exemple de plus dans ma "besace" de contre-exemples..

Et après ça, il est difficile de convaincre qu'une aporoche agile est excellente... Le marketing des diverses méthodologies a porté un coup pas focément mortel, mais en tous cas très sérieux, à l'esprit du Manifeste et son impact possible...