Reprise du message précédent :

Qui a décidé ? Sur quelle base ? Avec quelles directives ? S'agit-il d'une expérimentation ou d'une véritable réorganisation ?
 
Tu dois mettre à l'ordre du jour de la rétro l'ensemble des problèmes que tu rencontres (durée des sprints, durée des dailys, réunionnite, gestion des urgences, etc.) en expliquant que toi tu le vis mal, et tu demandes à l'équipe de réfléchir à une solution qui convient à tout le monde. Tu n'es probablement pas le seul dans l'équipe à mal le vivre.

Le TT que tu veux.  

Mais vous faites des sprint d'une semaine ???
Parce que des daily de 30min, des reu de rétro de 3h toutes les semaines, y a un gros problème.
Déjà les daily, c'est 15min grand maximum, les rétro c'est 1h par semaine de sprint (donc 3h c'est pour 3 semaines de sprint, et il est possible de faire moins).

Je suis pas sur que les autres le prennent aussi mal.  
 
Je pense que la difficulté est qu'on a pas le même job et que c'est peut être plus adapté pour eux (côté dev). Moi je suis tout seul en amont donc il y a personne d'autre que moi qui peut avancer mes Jira dans 90% du temps quand on est avant le dev.  
 
Ca a été décidé en haut. Avant, on avait une version par mois et une demande arrivait en prod en environ 3 mois vu le nombre d'interlocuteurs.  
 
Il a été décidé que c'était trop long (je suis d'accord sur ce point) et qu'on allait passer en agile avec des sprint d'une semaine.
 
Pour le temps, le soucis est qu'on est plus de 10 et que le temps que chacun dise ce qu'il a fait la veille / ce qui bloque / ce qu'il pense faire aujourd'hui et bien ca prend forcément du temps...
 
Pour la retro, c'est la même chose en pire.

 
Ca ne t'interdit en rien de t'exprimer.  

Agile/SAFe:
- daily 15 min max. C'est fait pour dire j' avance bien/mal et demander de l' aide si besoin. Et next. Pas pour raconter sa vie technique ou faire des debats. Ce que j'ai fait/vais faire ca me prend 30s si tout ca va bien. Votre SM dot couper court aux beaux parleurs ou deux qui ailment les debats.
- Un sprint cest deux semaines ou 3. 1 c'est trop court, 4 trop long.
- retro: 1h pour votre sprint de deux semaines, le SM identifie les points majoritaires et les actions qui vont aller avec.

Bref faut vous améliorer la dessus, donc il faut le faire remonter et prendre des actions, tester pour trouver votre rythme et asseoir votre velocity dans  la joie et la bonne humeur. Be Agile donc.    

 
mais ça apporte réellement quelque chose à l'équipe de faire du micro-management comme ça ?

Un sprint d'une semaine c'est n'importe quoi si vous venez de passer en mode agile.
Commencez à trois puis réduisez à deux. Quand vous êtes vraiment mature (équipes (avec un S), process, outils (très très important), alors à ce moment vous pourrez tenter le sprint d'une semaine mais c'est vraiment pas facile.
Réservez vous une quelques jours par mois pour faire autre chose (veille, side project, dépiler le grooming, etc..)

Ça sert surtout à se synchroniser, mais faut être très succinct.

Le problème que j'y vois surtout c'est que tu n'ajoutes pas l'agile à ton orga précédente, ça remplace. Donc si tu avais déjà plein de réunions pour gérer tes sujets, c'est absolument pas normal que ça vienne s'empiler dessus...

Ça donne mal à la tête toutes vos conneries

Je retiens qu'il faut "dépiler le grooming", j'ai l'impression d'entendre un québécois te dire qu'il va te sauter

J’ai bossé pas longtemps avec une équipe en agile chez mon client actuel. Les sprints durent 3 semaines et les daily 15 minutes. Ça rejoint ce qu’ont dit mes camarades. Combien de personnes participent au daily ?

Il y a d'autres trucs completement basiques qui ne vont pas dans son histoire:
- cérémonies Scrum, mais visiblement pas toutes
- céremonies Scrum, mais board Kanban
- taille de l'equipe à 10+
Faut pas chercher, c'est de la méthode "à Gilles" mis en place par des gens qui n'ont rien compris à l'idée derrière.

 
Avec une effectif réduit, ça permet d'évoquer les sujets et à la suite du daily, éventuellement de partager les infos lors d'un point spécifique. Souvent ça permet de débloquer un souci si c'est bien fait.
 
Mais de l'agilité à 10, c'est compliqué...

D'expérience, dans 90% des cas, la méthode à Gilles c'est un truc qu'on régurgite, très mal compris et qu'on essaye d'imposer dans la COGIP car ça fait cool, tout le monde le fait et avec ça on se sent comme Google

l'enfer    
La hiérarchie ne vous fait pas confiance? Ou ne comprend pas votre job?
C'est ouf de passer autant de temps à rendre compte de son travail qu'à réellement travailler....

 
Bha c'est la COGIP.

Remarque, il y a pas que ça, tu as oublié encore une autre possibilité : la hiérarchie est radine. Je me rappelle un moment où on a dû passer plus de temps à reporter qu'à travailler parce que le client voulait nous payer au ticket et donc voulait savoir combien de minutes il fallait pour chaque typologie de ticket, pour pouvoir ensuite diviser 8h par 7 minutes et nous demander pourquoi on n'atteignait pas ces chiffres.

Je ne sais pas trop d'ou c'est sorti. Ca a été décidé assez haut   .  
 
On est tous dans le daily quasiment soit une dizaine voir un peu plus selon les jours.  
 
Ce matin, on a débatu pendant un bon moment des colonnes à ajouter dans le board kanban pour coller à tout les cas de jira possible et tout les endroits "bloquants" dans le process ou elle pourrait se trouver (l'idée de base étant de détecter une jira bloquée trop longtemps dans un statut).  
 
On a pas réussi et après 1h il a été décidé de faire une autre réu plus tard pour choisir les bonnes colonnes.    
 
   
 
Un des problèmes majeur du truc pour moi est que le nombre de tache par colonne est limité mais que tout le monde ne peut pas tout faire.  
 
Il y a deux colonnes ou il n'y a quasi que moi qui peut avancer les jira et d'autres ou je peux absolument rien faire car c'est pas de mon ressort.  
 
On a tous des roles differents et on nous met dans le même board global.  
 
Ca fait qu'il y a plein de moment ou on doit attendre que qqun d'autre finisse son boulot pour faire avancer la jira dans le bon statut sinon ca déborde.  
 
On a eu l'idée de créer des colonnes backlog entre les différentes étapes du kanban pour compenser mais ça fait que les limites fixées n'ont plus aucun sens.  
 
Il y a aussi le cas des tests à la fin. Le QA a été totalement sorti du systeme et on est censé s'arranger entre nous sans lui pour tester. L'équipe de dev fait ses tests seuls par rapport à ce qu'ils ont compris et valident avec la personne qui a pris la demande lors de la réu de fin de semaine si il a bien testé la bonne chose / s'il n'y a pas eu d'oublie.  
 
On part à la cata, on a déjà failli lancer la mise en prod d'un truc qui fonctionne pas demain matin à cause d'un soucis que le QA aurait détecté direct en début de process avec l'ancien systeme.
 
Pour ce qui est des réu, les miennes existantes sont toutes avec des extérieures à mon équipe (autres équipes de la boites & fialiales internationales) donc ca ne rentre pas du tout dans le cadre du process.

Ah ouais. Encore un qui a lu un post linkedin en disant "c'est génial l'agile on va en faire".
 
Faut se faire accompagner quand on commence, sinon c'est direct dans le mur

L'avantage c'est que là vous voyez déjà les goulots d'étranglement.
Ca sert à rien d'avoir une armada de développeur si dans un de vos état kanban vous êtes que 1 ou 2 à dépiler.
 
Mais le fond du problème, je pense, c'est qu'en dehors du fait de mélanger scrum/kanban pour le management visuel, vous avez certainement un problème de définition de processus dans la nouvelle méthodologie.
 
Et vous avez l'air d'avoir plusieurs parties prenantes, là il va falloir repartir de 0 et vous faire accompagner par un coach agile.

J'aimerai savoir si ce topic est ouvert à tous les secteurs d'activité?

Genre on va arrêter de se plaindre juste parce qu'on n'est pas informaticiens

 
Bien entendu.  
Les informaticiens devraient peut-être parler de leurs problèmes d'agilité sur un autre topic  

 
Pour moi, c'est du chinois ce qu'ils disent avec leur acronymie.  

Moi pareil mais j'aime bien car du coup je recherche et j'essaie de comprendre

C'est vraiment intéressant par contre

Si y'avait que l'agilité...  

Je sais pas trop comment l'exprimer, mais sans verser dans la réunionite aigue pour moi c'est important d'avoir un dialogue constant avec les collègues afin de se concerter et d'anticiper les besoins.  
 
J'ai tjs l'impression de devoir tirer les vers du nez de ma collègue en binome.. Je lui ai proposé de faire un point bilatéral hebdomadaire une fois par semaine d'1h, et même ça, j'arrive pas à le ritualiser..  
1h c'est pas la mort quand même ?  
 
On a déjà des points de direction et d'équipe d'1h chacun environ mais c'est pas forcément les moments le plus propice. J'ai constamment l'impression d'être mis devant le fait accompli.  

 
Demande-toi sans concession si ce point bilatéral est réellement indispensable pour toi ou non, et réellement indispensable pour ta collègue ou non...
 
Ta réunion comporte-t-elle un ordre du jour ? Les décisions sont-elles faciles à prendre, si non pourquoi ?  
Si c'est juste un point de synchro, un récap des échanges depuis la semaine précédente dans l'ordre du jour ne suffirait-il pas, afin de réduire le point à 30 voire 15 minutes ?
Etc. etc.
 
Dès que je peux mettre fin à une réunion avant le temps imparti je n'hésite pas, je fais gagner du temps j'évite de faire perdre du temps à tout le monde, y compris à moi-même

Une heure pour moi c'est un très gros point pour deux personnes, ça fait beaucoup si c'est toutes les semaines. A titre d'exemple, c'est la durée de la réunion d'équipe pour redescendre les infos et partager les grandes lignes des sujets de tout le monde qu'on fait à 7.

Ce que j’ai mis en gras n’est pas le but du daily. Ne pourrais-tu pas dire que tu planifieras une réunion pour débloquer ce point ? Il faut être succinct. Dans l’équipe où j’étais temporairement, un développeur disait être bloqué sur un truc et un autre répondait qu’il l’appellerait après le daily. Il faudrait peut-être revoir la taille de l’équipe. Tu dépends de ces dix personnes où ils dépendent tous de toi ? Vous êtes sur le même périmètre ?
Édit : désolée du coup il y a un topic sur l’agile quelque part ? Ça pourrait peut-être l’aider.

Souffrance sur le topic : découvrez comment ces informaticiens agiles ont fait fuir tous les autres corps de métier !
La n°3 va vous scandaliser !

Ils étaient en chômage partiel

 
Merci pour vos retours. Si on a tout dit, ça me dérange pas de boucler avant.
 
Disons qu'on est en binome avec pas mal de sujets qui se chevauchent, et ça risque de rester longtemps comme ça. Et qu'on a pas spécialement d'autres moments d'informels ni de réunions communes sur d'autres dossiers.

Ah? perso je me suis demandé si c'était à la cire ou à la pince...

   
Merci pour la blague, j'ai au moins compris un truc sur ces deux dernières pages.

Bon dans quel sens ? Dans le sens ils t'ont bien soustrait tes congés ?? Si c'est ça j'espère bien que tu vas pas laisser passer le chômage partiel.

Est-ce que le plus pédagogue d'entre vous peut noux expliquer à nous autres béotiens non-informaticiens que qu'est la méthode Agile ? Avec des mots simples, comme si nous étions des enfants

Le problème c'est qu'on voudrait bien, mais comme on bosse qu'avec des managers qui font ça n'importe comment parce que c'est à la mode, on n'a rien compris non plus

 
Un dogme parmi tant d'autres qui permet de faire vivre des consultants. Un peu comme le lean dans l'industrie, mais visiblement encore moins bien maîtrisé