Reprise du message précédent :

 
Pour le genre de situation que tu décris, c'est le principe même des itérations qui ne fonctionne pas.
 
Par contre, oui, un Kanban agile (appelé pure Kanban, voir mon deuxième post sur ce topic) est bien plus adapté à leurs besoins et sera sans doute bien plus efficace. Il permet aussi de mettre des deadlines pour les tâches qui en ont besoin sans paralyser le système. Mais bon, ils auront peut-être (comme nous) besoin de temps et de faire des erreurs pour changer leur système.
 
Le drame des méthodes agiles, c'est que bien souvent, les gens plongent la tête la première dedans en tentant d'appliquer SCRUM sans considérer les alternatives, sans savoir si c'est adapté à leur cas et sans aucun recul. Et le pire, c'est qu'ensuite, une fois qu'ils ont embauché leur SCRUM master, il est évident que ce dernier ne va pas remettre en cause son propre rôle et usera de tous les moyens dont il dispose pour s'accrocher. C'est aussi cela qui fait qu'on peut rapidement se retrouver dans des situations ultra toxiques.
 
Et pas mal de consultants ne valent pas forcément mieux et vont tenter de vendre SCRUM à tous prix...
 
Bref, alors que l'agilité est VRAIMENT une bonne chose si bien adapté et bien appliqué et que ça peut booster la productivité, souvent ça va produire l'effet inverse.
 
Je finirai en disant que de toutes manières, l'erreur, c'est déjà d'imposer un système sans obtenir l'approbation de ceux et celles qui vont le subir.

 
Je suis naturellement attiré par ce pure Kanban. Le coté pompier rend cela naturel et on pourrait même dire que c'est d'une manière informelle ce que l'on applique déjà avec un petit suivi en plus pour avoir une vision sur les actions long terme et accepter ou refuser les demandes et deadlines des clients. Par exemple pour des projets a 50-70h de boulot on a rarement des deadlines a moins de 3 mois, donc facile de les ventiler sur la période et absorber la variabilité. J'ai du mal a imaginer garder cette capacité de faire trainer une tâche qui prend 10h de boulot sur 1 mois en fonction de contraintes externes avec une approche SCRUM...
 
D'un certain coté, on pourrais voir un refus du changement, parce que la méthode se rapproche le plus de ce que l'on applique déjà    
 
Il y a déjà eu une demande de rajouter une composante plus Kanban dans l'autre équipe agile qui est gérée par notre duo SCRUM/PO, mais ça avait été refusé par le binôme. Je n'avais pas pensé effectivement qu'avec un pure Kanban ils perdaient une grosse partie de leurs raison d'être. Même si on a des aspects organisations et coordinations qu'on aimerais beaucoup leurs déléguer. En tant que technique, ça me fait chier d'organiser des réunions d'alignement et coactivité avec 20-30 personnes par exemple pour certains sujets
 
En tout cas merci beaucoup pour l'avis et les informations. Je vais continuer de me renseigner sur le sujet, j'ai envie d'avoir un dossier en béton a présenter en face  

C'est quand même triste que la plupart des décideurs aient oublies de prendre en compte la première phrase du manifeste agile: "Individuals and interactions over processes and tools"
( bon probablement bien aide par les sales/marketeux des boites de conseils qui vendent des scrum master et qui n'ont rien a foutre dudit manifesto... quand ils sachent qu'il existe )

Imposer Scrum a toute une boite en mode top-down, c'est tout le contraire de la méthodologie agile (ce qui ne veut pas dire que Scrum dans certains cas ne peut pas être adapte a certaines équipes/projets, même si je suis pas un grand fan de cette méthode)

 
Ben...
 

Déjà couvert par nos précédents échanges.
 

La documentation est une obligation réglementaire dans notre domaine, impossible de s'en séparer.
 

Là pourquoi pas, même si les rôles et responsabilités sont toutes établies a l'avance pour pas mal de choses et difficile de trop improviser sur certains sujets.
 

Nos plans sont tracés et documentés et nous sommes obligés de les appliquer jusqu'au bout ou de rentrer dans des flux de déviations très lourds a gérer. On préfère souvent terminer de la manière documentée même si il y aurait eu plus simple techniquement.

 
Oui, jamais réellement compris cette opposition. Je pense que c'est lié à ceux qui ont participé à la rédaction du manifesto et de leurs expériences. Ça ne s'applique pas partout, ni pour tout.  
 

 
Un peu comme précédemment, ça ne s'applique pas pour tout, ni pour toutes les industries. Parfois le moindre changement dans de la fabrication hardware par exemple peut être un véritable casse-tête. Dans un tel cas, c'est donc AVANT d'arrêter le plan final du hardware que l'agilité a du sens. Une fois la fabrication commencée, on est dans le temps longs et l'agilité ne concerne plus que, par exemple, le développement des firmwares pour corriger ce qui peut l'être ainsi que les prochains modèles (et on retombe sur l'agilité au niveau de la conception AVANT d'arrêter les plans).
 
Je réalise que ce que j'écris est sans doute un peu confus.
 
Dans tous les cas, oui, l'agilité n'est pas pour tout, ni tout le temps et il existe différentes manières d'être agile qui ne peuvent intervenir parfois que sur certaines étapes d'un développement.

Pareil, je comprends cette opposition entre documentation/traçabilité et lisibilité/compréhension facile du code
je pense que l'idée, c'est surtout d'éviter une surdocumentation difficile à mettre à jour et de s'y retrouve.

https://agilemanifesto.org/
Je pensais qu'on était sur le forum de l'élite

Y a pas d'opposition de principe entre les deux cotés en Agile, c'est même la phrase juste en dessous des 4 principes:

Bien sur que si réglementairement tu dois faire de la doc, bin tu la fais, ils disent pas du tout que la doc est toujours inutile.

 
C'est quand même faux car la documentation est une partie du produit attendu donc elle est tout aussi importante que le reste. Y a pas de hiérarchisation a faire ou autre, il faut faire les deux obligatoirement et c'est tout. Une documentation erronée c'est potentiellement les périodes de productions depuis le changement remises en question pouvant aller jusqu'aux rappels de lots.
 
C'est comme si je te disais "Working code over comprehensive interface", ça n'a aucun sens de mettre ça en principe de gestion de projet général. Le client a besoin des deux.

Je pense que faut se rappeler l'époque et le contexte ou se manifeste a été écrit avec des cycles de dev très long et très complexes pour tout.
Mais même actuellement, j'ai tendance à être d'accord avec l'essentiel du manifeste.
 
La doc c'est bien, mais encore faut-il qu'elle soit à jour. Je suis pas d'accord quand tu dis que c'est aussi important que le reste. Avoir une appli qui fonctionne, ça me parait plus important qu'avoir une doc parfaite. Avoir une appli sécurisée, aussi... Bref oui c'est mieux quand t'as une bonne documentation, mais comme c'est pas gratuit à produire (et à maintenir), quand tu dois faire des arbitrages, bin ça me choque pas que parfois ce soit la doc qui en fasse les frais.
Quand tout est important/urgent/prioritaire, rien n'est important. On évolue rarement dans un contexte où on a un budget/délai illimité, donc souvent on est amené à faire des choix et des arbitrages.

 
Tu ne semble pas comprendre que dans le domaine où je suis la documentation précise et à jours est une obligation réglementaire, sans elle tu ne met pas en route les machines/systèmes et tes produits ne vont pas sur le marché. Si elle est erroné ou pas a jours, tu te met aux devants de très graves soucis avec les autorités qui peuvent aller jusqu’à la fermeture du site.

Mon poste précédent:

Du coup t'es dans un cas où la doc (et je suppose la QA) ne peut PAS faire partie de l'arbitrage.

Mais c'est un topic général sur l'Agile, pas juste sur le cas de vylkor
Bien sur que si tu bosses sur du nucléaire, de l'aérien ou des équipements médicaux les réglementations et contraintes seront pas les même que si tu fais un blog, une marketplace ou une app mobile...Mais ça représente pas 100% des gens qui font du dev...

 
Désolé, loupé le passage entre les gens qui me répondaient pour m'aider et le retour a l'Agile en général.

Si c'est pas indiscret, tu évolues dans quel domaine, vylkor ? Dans le mien aussi, la doc à jour des softs est très important, je parle même pas des procédures opérationnelles où là, c'est une obligation réglementaire.

 
Industrie pharmaceutique injectable. On a les autorités de santé qui regardent par dessus notre épaule en permanence... Et le système sur lequel on bosse assure le suivis de la qualité produit et l'enregistrement de la production.

Drap, intéressant ce topic.
Je me demandais si l'agilité (ou des gens qui y ont réfléchi) avait des réponses à apporter pour les projets mutiples, avec des dépendances/interactions fréquentes ?
Un truc qui peut marcher, pas SAFe du coup

 
Bah la dernière partie de mon exposé sur le NNL (Now Next Later) permet très précisément ça. On applique l'agilité à la roadmap et aux resources, ce qui permet de toujours suivre les projets en cours et de voir les ressources réellement disponibles. C'est particulièrement efficace dans des contextes où les mêmes ressources sont partagées entre différents projets / produits. Mais bon, c'est une approche particulière assez éloignée de l'approche classique avec SCRUM + sprints.  
Chez nous, on a une petite équipe de développeurs, de designers, data analyst, product manager etc... Et 2 produits principaux + des integrations avec des 3rd parties. Ce sont les mêmes personnes qui bossent sur différents projets même si certaines de ces personnes ont des spécialités.  
On est passé par des systèmes classiques (SCRUM, sprints etc...) et on a progressivement changé notre manière de faire parce que ça ne fonctionnait pas. On a essayé pas mal de méthodes.

Rappel du manifeste Agile: "Responding to change over following a plan"
Du coup ça devrait être particulièrement adapte a des interactions fréquentes. Beaucoup plus qu'un bouzin bases sur des "Sprint" de 4 semaines, qui demande de soumettre ta demande au moins 3 5 semaines avant pour examen pour avoir une chance qu'il soit peut être intégré au prochain sprint
 
( oui, j'aime pas trop Scrum qui a, pour moi, ete beaucoup trop codifie et maltraite par des boites de consulting/certifications pour qualifier ca de methode "Agile" )

Ca fonctionne bien en pratique la "mutualisation" des ressources et le fait de pouvoir les basculer d'un produit à l'autre en fonction des besoins/charge ?
Car bon autant pour certaines professions, ça me parait possibles (infirmier, plombier, médecin...) autant pour d'autres c'est quand même pas simple je trouve car le contexte fonctionnel est important et si tu ne connais pas un minimum, ça ne sera pas aussi efficace. Certains métiers demandent plusieurs mois/années avant de connaître un dossier client.
Dans le cas de l'info-dev, ça va demander un peu de temps aussi

Je confirme que dans mon domaine, c'est pas possible. Là, j'ai une collaboratrice qui est en congé maternité. En accord avec le client, on la remplace pas et on réparti la charge sur les autres et on décale des choses, car pour être efficace sur ma prestation, c'est au minimum 6 à 9 mois de montée en compétences

Alors, désolé pour le retard, mais effectivement, la mutualisation des ressources pour plusieurs produits ne va pas forcément de soi.  
Dans notre cas :  
 
- la stack est la même entre nos deux principaux produits avec quelques spécificités.
- Même si tous nos devs par exemple connaissent nos deux produits principaux, il existe des spécialistes qui vont s'occuper plus spécifiquement de certaines choses (database, APIs etc...)
 
On a pas vraiment le choix car on n'aurait pas les moyens d'entretenir deux équipes dans lesquelles certains postes seraient redontants pour nos deux produits principaux.
 
La mutualisation des ressources ne signifie pas que tout le monde peut ou doit tout faire. Elle signifie qu'il existe un noyau central capable de faire un certain nombre de choses et des spécialistes qui peuvent s'occuper de certaines choses spécifiques (parfois sur nos deux produits)
 
Chez nous, ça fonctionne très bien.  
 
Si par contre, vous avez une équipe spécifique pour chaque produit (donc des designers, des devs, etc...) vous pouvez avoir deux roadmaps séparées. Dans les structures suffisamment grandes, c'est souvent ce qui se passe : un produit = une roadmap, même s'il existe parfois une meta-roadmap, essentiellement pour le haut management et le marketing global de la boite.

Ca confirme ce que je vois sur le terrain dans mon équipe (plutôt Data) et celle de mon homologue (coté applicatif)
C'est quand même beau tous ces "consultants" qui vendent ce rêve aux N+x "oui on pourra mutualiser les ressources et donc en fonction des besoins du produit, on pourra les basculer d'un produit à l'autre.
 

C'est pas la fonction de base d'un consultant de vendre du rêve à un décideur ?  

Ca en fait partie
Avec le fait de créer (pour lui et ceux qu'il va placer), du boulot infini avec pas mal de bullshit pour toujours avoir besoin de consultants pour essayer de mettre ça en place

Ma (grosse) cogip vient d'officialiser l'arrêt total et définitif de toute la gesticulation Agile, après 2.5 ans quand même.
 
On aura enrichi quelques gros consultants en consultance, et experts en expertise, là où la majorité des collaborateurs renaclaient dès le début (surtout que ne nous sommes absolument pas une boîte de dev) etdémontraient le vide abyssal de ce truc.

Combien de personnes ? A la DSI ?
Du coup vous revenez au cycle en V avec les effets tunnel ?
Bon après au moins il y aura des vraies specs et on saura ce qui a été développé, même 2 ans après

 
11.000 FTE, une DSI de ~ 3.000 FTE    
 
Pas une boîte de dev, comme déjà dit. Mais ça doit bien faire 20 ans qu'il n'y a plus ni cycle en V, ni effets machin chose.
 
Il a suffit de débarquer quelques fortes têtes du comité de direction; les nouveaux promus ont dit tout haut ce que la staff claironne depuis le début : c'est du grand n'imp, qui profite surtout à une clique de nuisibles oiseux genre scrum master et autres titres bidons (qu'ils peinaient à expliquer eux-même, ahah). Lesdits nuisibles bien stressés maintenant à devoir retourner faire du vrai boulot... ou prendre la porte (ils ont 60 jours pour choisir).
 
Jouissif (no redface).

Mais du coup en pratique ça fonctionne comment ?  

 
Ils ont réussi à débarquer les fortes têtes en question.  
 
Au delà de ça, ce type d'échecs résulte souvent de l'implémentation et du refus (paradoxal) d'évoluer quand quelque chose ne fonctionne pas. C'est d'ailleurs tout le côté pervers de certaines méthodes agiles... Que faire quand on a un SCRUM master, mais qu'en fait la méthode agile idéale pour la situation/boite devrait éliminer le besoin de SCRUM master alors que c'est le SCRUM master qui est le référent...  L'agilité, c'est JUSTEMENT de permettre les évolutions nécessaires et les remises en question méthodologiques. Dans les faits, c'est souvent le contraire qui se passe. Les process deviennent sclérosés et ne sont plus en adéquation avec les besoins réels des équipes. Ils deviennent juste un poids, un truc pénible qui donne l'impression de perdre du temps et de l'énergie pour rien.

 
C'était exactement ça    

Comme toujours, la méthodo devrait venir de besoins/pbs/irritants remontés par les équipes qui produisent (donc du bottum-up) et pas l'inverse (boss qui a entendu parlé d'une super méthodo à la mode, on va vous la mettre en place que vous le vouliez ou non )...

Encore des réfractaires à l'innovation

Comme toujours, quand l'agilité est un but et non un moyen, ça ne fonctionne pas.

 
AMA le problème vient pas forcément du boss lui-même car il n'est pas un spécialiste. Il vient plutôt du recrutement du spécialiste dont le rôle est parfois lié à une méthode particulière. Pour moi, les boites ne devraient jamais recruter un SCRUM master, mais plutôt un Agile Delivery Manager (ou même seulement un product manager) en faisant en sorte que la personne recrutée puisse évoluer et faire évoluer la ou les méthodes en fonction des besoins réels de l'entreprise.
Car un SCRUM master ne va jamais revenir sur son rôle, alors qu'un Agile Delivery Manager est au contraire une personne payée pour continuellement adapter la méthodologie aux vrais besoins de l'entreprise et là, ça peut devenir bcp plus intéressant.  
 
PS : ceci est un tip gratos pour les C-Suite managers / CEO / HR. Ne me remerciez pas.

On est bien d'accord, on doit adapter la méthodo/outils au besoin des équipes et pas l'inverse (sauf si les équipes font vraiment n'importe quoi ). Mettre en place une méthodo juste pour dire qu'on pratique cette méthodo sans tenir compte des besoins opérationnels, c'est voué à l'échec.

Hello, je cherche des idées parce que là on est entrain de se crasher au boulot et il faut qu'on trouve des solutions.
 
Coté management, on nous a donc poussé un Agile Scrum depuis le top management.
 
On est une équipe qui fait rend des services pour la production.
 
Ces services c'est de l'assistance, mais aussi des projets d'optimisation.
 
Chaque projet d'optimisation doit avoir au minimum une équipe de 3 personnes, 1 de chez nous, 1 de la prod et 1 de l'AQ. Certains projets demandent 2 autres services. Un projet c'est entre 25 a 50% de charge sur une période de 1 a 6 mois (notre soucis déjà avant c'est que nos interlocuteurs avaient souvent le projet assigné a faire en plus d'une charge de travaille déjà a 100%...)
 
Sauf qu'on a 6 départements de productions autonomes. Donc même en m'étant qu'un seul interlocuteur par service et département, ça nous fait 12 obligatoires + 12 autres optionnels. On est 3 dans la delivery team. Donc on nous a dit qu'on aurait personne des services dès quels on est dépendant dans l'équipe.
 
Nos clients sont pas satisfaits de notre réactivité depuis le passage Agile. Il y a qui essayent de trouver des moyens de nous court-circuiter avec la nouvelle orga car on a que 2 Business Owner, qui sont tous deux dans le managent d'un des 6 départements. Il y a des doutes sur l'impartialité de la priorisation.
 
Là on arrive donc même pas a capter la demande des utilisateurs, c'est a travers des discussions de cantine que j’apprends que notre PO refuse des sujets sans nous solliciter où même dimensionner sur la base du "on est déjà chargés". Refus qui font que les sujets ne rentrent même pas dans le backlog.
 
Comment sortir de ce merdier, parce que j'en ai encore fait une insomnie, notre service qui étais a la pointe niveau rendu et satisfaction des utilisateurs est devenu en même pas 3 mois une blague...
 
PS: Pour les projets, plusieurs projets peuvent être en parallèle sur plusieurs département, où même sur le même département mais avec interlocuteurs différents (tous ou partiels). Sachant que certains interlocuteurs peuvent aussi être cross départements, même si eux généralement on compte pas sur trop de présence de leurs part car souvent déjà chargés a 150%.

Là comme ça, je dirais... revenir à l'orga précédente qui semblait bien marcher ?