A la demande de certains forumeurs, je lance ce topic (qui sera sûrement un bide) sur les méthodes de gestion de projet / produit agiles.
 
Je ne compte pas faire un cours, et je vais donc simplifier beaucoup de choses (parfois à outrance).
 
Tout d’abord, qu’est-ce que la productivité ?
C’est le rapport en volume, entre une production, et les facteurs utilisés lors du processus de production. Les vrais problèmes commencent lors de la mesure de ladite productivité.
 
Prenons l’exemple d’un aspirateur.
La productivité d’une usine de fabrication d’aspirateurs se calculerait donc en comparant le volume d’aspirateurs produits sur une année avec un nombre N d’employés, en utilisant une quantité Q d’énergie et une certaine quantité de pièces P.  
 
Mais les choses sont loin d’être aussi simples en réalité. La qualité de fabrication des aspirateurs a un impact direct sur la productivité réelle. Si l’usine produit 10 000 aspirateurs par an, mais que 5000 sont défectueux et sont retournés, la vraie productivité est évidemment fortement impactée… Et les conséquences sont désastreuses car, si 50% des aspirateurs sont retournés, des plaintes apparaîtront en ligne, et l’image ternie de la société viendra compromettre les ventes futures.
 
La vraie productivité devrait donc en toute logique concerner uniquement les aspirateurs fabriqués, vendus et approuvés par le consommateur.
 
Le choix d’une méthode de gestion de projet devrait donc viser non pas à accomplir le maximum de tâches avec le minimum de ressources dans un temps imparti le plus court possible.
Mais il devrait viser à accomplir un travail global qualitatif et constant à même d’accélérer les ventes du produit et à satisfaire les consommateurs de manière à créer un cercle vertueux pour l’entreprise.
 
Quels sont donc les principaux facteurs qui ont une incidence sur la qualité du travail ?

• Qualité des outils (de mauvais outils peuvent fortement impacter la productivité tant quantitative que qualitative)
• Conditions de travail
• Santé physique et mentale des employés

Tout cela peut être réuni dans ce que l’on appelle la satisfaction au travail. Des employés satisfaits et qui aiment leur entreprise vont nécessairement produire, sinon plus, en tous cas mieux et des employés insatisfaits et qui détestent leur entreprise ne vont pas nécessairement produire moins, mais ils vont nécessairement produire moins bien. Or, nous avons vu précédemment que produire beaucoup, mais mal n’est généralement pas souhaitable (sauf peut-être certains produits jetables très bas de gamme).
 
D’agissant du choix d’une méthode de gestion de projet, la chose primordiale à considérer devrait donc être la satisfaction au travail des employés, avant même toute autre considération.
 
Viennent ensuite d’autres facteurs comme :  

• La flexibilité autour du développement du produit (en effet, nous vivons dans un monde où tout va très vite et il est important de pouvoir adapter le produit en conséquence, parfois même durant sa fabrication). Il faut donc que la méthode soit agile.
• La communication et la facilité pour trouver l’information (Il faut pouvoir facilement visualiser où l’on en est, quelles sont les prochaines étapes à accomplir etc.)
• La prise en compte de la demande (parfois urgente) des clients.
• Le renforcement de l’esprit d’équipe et une atmosphère bienveillante.

Il y a bien sûr d’autres facteurs que je ne prendrai pas le temps de détailler.
 
Méthodes Agiles et Sprints récurrents:
 
Je ne vais pas non plus faire tout un exposé sur les méthodes agiles, mais disons pour résumer qu’elles s’articulent toutes plus ou moins autour de ça :

• Fortes interactions entre les personnes impliquées dans le projet.
• Flexibilité et adaptation au changement au lieu de simplement suivre un plan prédéfini.
• Prise en compte de la relation avec les clients et du retour d’information.

Si vous voulez en savoir un peu plus, vous pouvez lire ceci qui est simple à comprendre :
https://slack.com/intl/fr-fr/blog/c [...] hode-agile
 
Qu’est-ce que le « Sprint » dans les méthodes de projets agiles ?
 
Pour simplifier, le Sprint, c’est une période récurrente de temps donné durant laquelle l’équipe constituée par les employés impliqués dans le projet va tenter d’accomplir un certain nombre de tâches.
 
La plupart du temps, les méthodes dites agiles utilisent donc ce que l’on appelle des sprints récurrents et très souvent cette récurrence est hebdomadaire.  
 
Pour visualiser les tâches, une des approches les plus répandues de nos jours consiste à utiliser un Kanban.
 
Kanban est aussi en soi une méthode de gestion de projet (on peut parler parfois de « Pure Kanban »), mais de nos jours, on emploie aussi beaucoup ce terme pour désigner un tableau multicolonnes contenant des tâches et leurs statuts.  
 
Un Kanban dédié aux sprints ressemble plus ou moins à cela :
 

 
Le backlog (répertoire de tâches) contient toutes les tâches « en vrac » qui ont été créées.  Chaque semaine, l’équipe sous la direction d’un SCRUM master (je ne vais pas détailler SCRUM ici) décide d’un certain nombre de tâches qui seront traitées au cours du sprint (généralement les sprints s’étalent sur une semaine) qui seront mises dans la colonne « À faire ». Pendant le sprint, les tâches sont censées passer par la colonne en cours (quand elles sont effectivement travaillées), puis par la colonne « À tester » et enfin, la colonne « Terminée ».  
À la fin du sprint, l’équipe se réunit et fait un état des lieux du sprint, regarde si toutes les tâches ont été terminées, discute des raisons pour lesquelles certaines tâches ne sont pas finies etc.
 
Les sprints récurrents ont de gros avantages mais aussi de très gros inconvénients largement sous-estimés.
 
Ils induisent souvent une grosse pression dans les équipes parce qu’ils forcent les employés à finir leurs tâches (souvent décidées pour eux, même si en théorie ce sont les équipier qui sélectionnent, découpent et choisissent leurs tâches) avant la fin du sprint, même quand ils ont besoin en réalité de plus de temps.
 
Même si tous les membres de l’équipe sont bienveillants (ce qui est loin d’être toujours le cas), les employés qui ne terminent pas les tâches auxquelles ils ont été assignés sont en quelques sortes montrés du doigt. Ils doivent justifier du non-accomplissement de leurs tâches et en détailler les raisons. Il est donc très tentant pour les employés de bâcler leur travail. Dans les cas où ils ne peuvent pas finir, il est aussi tentant pour eux d’en rejeter la faute sur d’autres employés.
Il est alors possible qu’un climat toxique durable s’installe dans l’équipe à cause de toutes les deadlines (dates butoirs) constantes imposées aux employés et à l’équipe.
Quand bien même ce n’est pas le cas, il existe une négativité latente liée au fait qu’on constate que les sprints échouent régulièrement.
 
Également, les sprints sont généralement détachés de la roadmap (feuille de route généralement sur 1 an) ou en tous cas, la roadmap n’est pas représentée dans le kanban qui décrit les sprints hebdomadaires. Il en résulte une perte de repère et de mise en perspective du travail régulier effectué. On finit par avoir des employés « robots » peu impliqués dans le produit avec la sensation pour eux d’être uniquement des pions que l’on bouge sur un échiquier.  
 
Il existe bien d’autres effets pervers liés à cette organisation du travail, mais je ne vais pas toutes les détailler ici.

Pure Kanban
 
Comme je l’ai précédemment énoncé, si le mot Kanban désigne régulièrement un tableau sur lequel sont placées des tâches, c’est aussi à la base une méthodologie à part entière.
 
Voici tout d’abord un Kanban historique tel qu’il a pu être utilisé chez Toyota :
 

 
À la base, c’est donc un ou plusieurs présentoirs qui décrivent quelles pièces (et en quelle quantité) sont utilisées, et de quelle manière elles sont utilisées pour rendre fluide la chaîne de production.
 
Voici maintenant à quoi ressemble un « Pure Kanban » typique (et bien sûr, comme toujours, simplifié pour les besoins de ce poste).
 

 
À première vue, les différences ne sont pas frappantes quand on compare ce kanban au précédent, mais elles sont pourtant importantes.
 
Les deux différences principales visibles ici dans cet exemple, sont le fait qu’il y a différentes colonnes pour le backlog qui permet de regrouper les idées / tâches entre elles ainsi qu’une (ici, mais parfois plusieurs) colonne(s) pour indiquer quand ces tâches doivent être travaillées.
 
Quelques points pour développer (en vrac) :
 

• Dans le « pure kanban », il n’existe pas de sprint récurrent, c’est-à-dire qu’on ne décide pas à l’avance combien de tâches devront être accomplies durant un sprint. Le sprint lui-même disparaît complètement.
• Quand une tâche doit être accomplie rapidement, on la place dans une colonne dite temporelle (« urgent » dans notre exemple).
• On place toutes les idées dans le kanban dès leur apparition, d’où la nécessité d’avoir généralement plusieurs colonnes de backlog.
• On continue à avoir des réunions régulières (souvent journalières) pour faire le point et répondre aux urgences.
• La Roadmap (feuille de route souvent annuelle) n’est toujours pas présente dans le « pure kanban »
• Les découpages nécessaires sont toujours là, mais il n’y a (sauf si c’est urgent) généralement plus de date butoir.  Et les découpages eux-mêmes (la taille des tâches qui en résulte) deviennent également moins arbitraire.
• Les équipiers choisissent généralement les tâches qu’ils veulent accomplir (sauf parfois si celles-ci sont urgentes ou de part la spécialisation des équipiers)

Le plus gros avantage de la méthodologie dite « pure Kanban », tient au fait que l’on cesse de poser des dates butoirs arbitraires concernant l’accomplissement des tâches sélectionnées. Il en résulte que les équipiers prennent le temps nécessaire pour faire leurs tâches. Le travail est mieux fait et le stress des équipiers diminue. Paradoxalement (et j’ai pu le vérifier moi-même), plus de travail est accompli au bout du compte et la productivité augmente.
 
Concernant le découpage des tâches, celui-ci devient plus réaliste et moins arbitraire. En effet, lors de la méthode précédente, l’une des stratégies souvent employées par les équipiers pour réussir des sprints, est l’ultra-découpage des tâches pour montrer aux managers que toutes les tâches qui leur ont été assignées (ou qu’ils ont pris eux-mêmes) ont été réalisées avant la fin du sprint.
Avec le « pure kanban », ce n’est plus (autant) nécessaire, même si certains managers continueront d’évaluer leurs employés (à tort !) uniquement en fonction du nombre de tâches qui auront été accomplies.
 
Un des gros inconvénients de cette méthodologie tient au fait que l’équipe choisit constamment de nouvelles tâches et que psychologiquement, rien n’est jamais fini. Les colonnes ne se vident jamais et on est un peu comme des Sisyphe devant sans cesse travailler.
Également (et c’était aussi vrai concernant la méthodologie précédente), du fait de l’absence de représentation de la roadmap, les équipiers souffrent toujours d’une absence de perspective sur le plus ou moins long terme. On travaille sans cesse, mais on ne sait pas toujours pourquoi. Il existe un manque de ce que l’on appelle en anglais « The Big Picture ».  
Pour les managers, le « pure kanban » peut aussi créer une certaine « insécurité », car pour mesurer les performances de leur équipe, ils continuent de raisonner en termes de nombre de tâches accomplies, de projets réalisés etc… Le tout, dans un temps donné. La productivité réelle augmente généralement, mais elle n’est pas toujours très bien mesurée.

NNL (Now – Next - Later)
 
La méthodologie NNL (Now – Next – Later : que l’on pourrait traduire : Maintenant – Ensuite – Plus tard), consacre l’omniprésence de la roadmap qui se retrouve au centre du kanban.
Elle consacre aussi l’agilité de la roadmap elle-même comme nous allons le voir. Dans ce poste, je vais donner également ma vision concernant l’application de cette méthode et je tiens à préciser tout de suite, que si ça marche extrêmement bien chez nous, je n’ai pas la prétention de dire que ça marchera forcément bien chez vous.
 
À la base on se retrouve donc avec un kanban simplissime à 3 colonnes seulement (c’est juste pour expliquer le principe car on verra ensuite qu’il existe évidemment des variations pour rendre le kanban plus opérationnel et je donnerai ma propre solution à différents problèmes qui peuvent se poser).
 

 
Contrairement au kanban des autres méthodes que j’ai évoquées, celui-ci ne décrit non pas un sprint, ni-même toutes les tâches ajoutées dans des backlogs, mais la roadmap, qui devient donc omniprésente.  
Un autre grand principe de ce système, c’est la distinction entre projets et tâches. Ce qui se trouve dans les colonnes « Ensuite » et « Plus tard », ce sont (la plupart du temps) des projets. Cependant, la colonne « Maintenant » ne contient normalement quant à elle que des tâches.
En réalité, lorsque vient le moment travailler sur un projet pris dans la colonne « ensuite », celui-ci est converti en une ou plusieurs tâches. L’intérêt est de constamment conserver un maximum de clarté et de lisibilité dans la roadmap, au lieu de se retrouver avec un trop grand nombre de tâches.  
 
Détaillons maintenant les 3 colonnes (de manière simplifiée) :

• La colonne « Maintenant » : elle contient les tâches (dérivées de projets) prêtes à être travaillées. Le travail n’a pas obligatoirement commencé, mais il peut commencer. Les tâches contiennent également des tags (je reviendrai plus tard là-dessus) pour indiquer leur statuts (par exemple : « En cours », « En test » etc.)
• La colonne « Ensuite » contient des projets mûrs et approuvés qui attendent que de la place (en réalité des ressources) se libère dans la colonne « Maintenant ».
• La colonne « Plus tard » contient quant à elle les projets que l’on ambitionne d’accomplir dans l’année en cours (s’il s’agit comme c’est souvent le cas d’une roadmap annuelle).

A ce stade, on voit quand même qu’il y a un problème. Il est assez compliqué de visualiser les tâches accomplies (Même si un système de tag existe). C’est pour cela qu’on rajoute généralement une quatrième colonne « Terminé ».
 

 
Il y a deux grandes écoles pour savoir ce qui se trouve dans cette quatrième colonne.
Certains optent pour mettre les tâches terminées de la colonne « Maintenant » et d’autres vont mettre le projet d’où sont issues les tâches accomplies de la colonne « Maintenant », une fois que toutes les tâches relatives à ce projet sont terminées.
 
Mais quid du statut des tâches ?
Là encore, il y a deux possibilités :
En effet, dans les autres méthodes, on avait des colonnes telles que « Urgent », « En cours » ou encore « en test » ce qui nous permettait de connaître le statut des tâches. Il est tout à fait possible de rajouter ces colonnes au système.
Cependant, à chaque nouveau statut dont on a besoin, il faudrait rajouter une colonne.
C’est pour cela qu’utiliser des tags, est à mon avis une solution préférable et plus agile. De plus, une même tâche peut avoir plusieurs statuts complémentaires.
Exemple de tags que nous utilisons dans ma boite :
 

• Amélioration continue (la tâche reste très longtemps dans la colonne « Maintenant » car on continue sans cesse d’améliorer ce sur quoi porte la tâche)
• Projet
• Tâche
• Produit (le nom du produit, ou d’une partie du produit – permet de travailler sur plusieurs produits en même temps)
• Demandé par les clients
• En cours
• En test
• Deadline (et un deadline est alors précisée)
• Petite amélioration (Small Enhancement en anglais) – je reviendrai sur ça un peu plus bas

Comme on peut le voir, on peut très bien avoir une même tâche taguée « en cours », « demandée par les clients » et  « deadline ».
 
On peut aussi mixer les deux solutions : avoir plus de colonnes pour certains statuts et garder les tags pour les autres. Mais finalement, on s’est rendu compte chez nous que le maximum de visibilité et de lisibilité de la roadmap était atteint en gardant seulement les colonnes « Maintenant », « Ensuite », « Plus tard »  et « Terminé ». Le but ici est double :
 

• Constamment visualiser la roadmap et ne pas se perdre dans de multiples colonnes.
• Constamment savoir exactement ce sur quoi nous sommes en train de travailler. (Extrêmement utile pour la communication avec les autres départements hors production)

Le problème des backlogs
 
Dans la première méthode, le backlog appartient généralement au kanban, mais avec l’expérience, quand un très grand nombre de tâches existent, on les met généralement ailleurs et on se contente de placer dans la colonne backlog les tâches susceptibles d’être travaillées à plus ou moins long terme, ou en tous cas, les tâches qui ont pu être correctement définies après découpage.
 
Dans la seconde méthode (Pure Kanban), on place généralement toutes les tâches dans plusieurs colonnes de backlog triées par thèmes. Le backlog est totalement intégré au kanban.
 
Avec cette méthode NNL, il n’est plus possible d’intégrer la ou les colonnes de backlog, car elles viendraient polluer le kanban qui doit être centré sur la roadmap. De plus, les colonnes « ensuite (Next) » et « plus tard (Later) » sont une forme de backlog dans le sens agile du terme, puisque c’est de ces colonnes que seront choisies les tâches pour être placées dans la colonne « maintenant (Now) » pour y être travaillées.
 
Il existe plusieurs solutions pour stocker les idées, projets ou tâches en dehors du kanban NNL
Notre approche chez nous, c’est un second Kankan multi-thèmes uniquement dédié aux backlogs ou chaque colonne traite d’un thème. Il est possible à tout moment de retirer ou d’ajouter des thèmes (et donc des colonnes) qui seraient manquants.
 

 
Ce kanban de backlogs est revu régulièrement (une fois tous les mois chez nous). Et c’est à ce moment-là, qu’on peut décider si une des tâches ou un des projets présents devraient intégrer le kanban NNL.
 
Petites améliorations (small improvements)
 
Même si on a maintenant une méthode agile directement sur la roadmap (Agile Roadmap), on a constaté chez nous qu’il manquait quelque chose.
L’un des grands buts poursuivis par les méthodes agiles, est de permettre des évolutions rapides des produits et surtout centrées sur les vrais besoins (et les plaintes) des clients.
Le but des roadmaps, est d’assurer un développement constant, réfléchi et consistant des produits pour s’assurer de ne pas constamment dériver, et au contraire de garder un focus.
Comment donc pouvons-nous concilier ces deux choses ? Grace au « petites améliorations »  
Chez nous, nous avons ajouté une colonne spéciale aux backlogs qui est revue quant à elle toutes les semaines. Ainsi, nous avons quelque chose qui ressemble à ceci :
 

 
Cette colonne spéciale ne peut contenir que des tâches très simple et très faciles à réaliser qui vont résoudre des problèmes soit détectés par nos équipes, soit demandées par nos clients et/ou nos groupes d’utilisateurs.  
Une fois par semaine, nous décidons de sélectionner quelque « petites améliorations » présente dans cette colonne, directement dans la colonne « maintenant » du kanban NNL.  
 
Mais attends ? Que nous dis-tu là ? Vous avez des tâches que vous passez en revue une fois par semaine et que vous êtes censé finir ? Mais c’est le retour du sprint non ?
 
Eh bien oui, on réintroduit un genre de mini-sprint au sein de la méthode NNL pour avoir une ultra-agilité en direction des clients.
 
Si je récapitule un peu certains des avantages :
 

• Possibilité de traiter plusieurs produits au sein du même système, quand les mêmes ressources de productions sont utilisées pour le développement de ces produits. Nous avons donc une bien meilleure gestion des ressources et surtout des estimations de temps de réalisation qui deviennent beaucoup plus réalistes, car prenant en compte les vraies ressources à disposition.
• Tout le monde, tous les intervenants, des plus petits aux plus grands peuvent garder le focus sur la roadmap et donc sur le produit. Il n’y a plus d’éparpillement et la vue d’ensemble est constamment rappelée aux équipes, y compris celles qui ne s’occupent pas de la production.  
• Une communication facilitée avec les autres équipes qui peuvent visualiser à tout moment le vrai état des lieux du produit.  
• Des backlogs qui sont des réservoirs à idées qui ne viennent plus polluer le kanban, qui par sa simplicité reste très facile à lire et à comprendre.
• Un système de « petites améliorations » dirigées vers les besoins immédiats de nos clients pour accroitre la satisfaction client et avoir une pointe d’ultra-agilité au sein du système.

Drap

Post-It

Drap

Mais drapal quand-même .

Post 1 : = Now ?

Post 2 = Next ?

Post 3 = Later ?

 
C'est un peu l'idée oui.  
 
Le NOW était un mal nécessaire.  

Drapoil  

Agile c'est comme le communisme, si ça fonctionne pas c'est que personne ne l'a appliqué correctement

J'ai un peu aéré le premier poste et mis en gras certains mots / phrases pour plus de lisibilité.
 
Je ne pense pas avoir le temps de continuer aujourd'hui, en tous cas pas avant assez tard cet après midi car ma journée est très chargée. N'hésitez pas à déjà me dire ce que vous pensez de mon intro qui vise à ouvrir ce topic le plus largement possible aux non-initiés.
 
Avant de passer au NNL, je pense que je vais d'abord faire une petite partie sur ce que l'on appelle le "pure Kanban" qui est aussi assez à la mode ici au UK.

On peut raconter nos expériences de mise en place de ces méthodes ?

Calvaires serait plus approprié pour moi

 
Évidemment, ce topic est un lieu d'échange concernant les méthodes agiles, leur application, leurs qualités, leurs défauts et les solutions (s'il y en a )    

Vous pouvez aussi présenter des méthodes (que vous jugez) non agiles en opposition et dire pourquoi elles vous paraissent plus indiquées (ou moins indiquées) dans votre cas.

drap

 Très bonne FP.
Je suis analyste programmeur dans une vieille technologie bien vivante malgré sa tentative de mise à mort. Je travaille chez un client qui a mis en place cette méthode. Les sprint planning durent plus d’une semaine car impossible d’avoir un découpage plus fin. Je me dis que cette méthode n’est pas l’idéal pour cette technologie.

J'ai commencé à bosser en tant que chef de projet d'abord en cycle en V classique, ça se passait relativement bien. Le périmètre s'y prêtait : run et évolution d'un périmètre applicatif.
Ensuite, un grand chef à décidé qu'on était has been dans l'organisation et on est passé du jour au lendemain en Safe (agilité à l'échelle). Je me suis retrouvé embarqué avec mon équipe dans un train Safe. Certains de mes projets n'avaient rien à y faire, d'autres étaient plus pertinents car en lien avec les autres équipes du train.

Globalement, les problèmes que j'ai rencontrés :

• Travailler en scrum quand on dépend d'autres équipes pour déployer, livrer, etc et qui elles ne sont pas en scrum c'est compliqué.
• Quand l'agilité devient un but et non un moyen ça devient un problème. Passer en scrum sans forcément analyser d'abord si le périmètre s'y prête est casse gueule. J'ai déjà eu des mesures de maturité agile de mon équipe où seul comptait le respect des cérémonies et autres préceptes scrum. Aucune question sur la réussite du projet ou pas, l'essentiel est que les équipes soient organisées en agile.
• En kanban ça fonctionnait mieux sur mon périmètre.
• J'étais chef de projet agile : responsable hiérarchique de mon équipe, scrum master et chef de projet. Bref le bazar.
• Maintenant j'ai arrêté les conneries et je fais tout à ma sauce et ça fonctionne bien mieux

drap  

Alors oui mais non, normalement c'est les équipiers qui ont estimé ET découpé les tâches.

Ce que tu décris c'est la méthode qu'on connait tous très bien: la méthode à Gilles.
Aka Agile mis en place par des gens qui ont pas compris comment c'est censé marcher, et surprise, ça marche pas.

 
Alors merci pour cette remarque. PS: Je pense qu'il faut arrêter avec cette fameuse (mais inconnue pour moi ) "méthode à Gilles".
 
Effectivement, en théorie (en même parfois en pratique), c'est l'équipe et donc les équipiers qui estiment et qui découpent les tâches. Dans certains schémas, ce sont même les équipiers qui prennent volontairement les tâches.
En réalité, les choses sont souvent plus compliquées.  
D'abord, il y a toutes les dynamiques de groupe qui entrent en jeu. On est un peu comme au théâtre. Les personnes présentes veulent se faire bien voir. Elles vont vouloir en particulier paraître positives et adopter ce que l'on appelle ici la "can do attitude", se porter volontaire pour des tâches et sous-estimer souvent le temps nécessaire pour que les tâches soient terminées dans de bonnes conditions afin de bien "paraître" devant l'assistance. Il y a ce que l'on appelle communément une surenchère liée au groupe.
Il y a aussi la spécialisation des employés. Tel employé est spécialisé dans telle techno et au final, il n'y a que lui qui peut se porter volontaire.
 
Au final, les employés peuvent ainsi souvent être leur propre bourreau et n'ont à ce moment là même plus la possibilité de se défausser sur une personne extérieure qui aurait mal évalué les choses. En fait, comme ils se sont engagés, ils sont encore plus coincés qu'avant. Certaines personnes feront donc par exemple des heures supplémentaires et/ou bâcleront le travail. On en revient au même point.
 
Le fait que les équipiers décident du découpage, de la durée et même de l'attribution des tâches ne change fondamentalement rien au problème.
 
J'irais même encore un peu plus loin. Le fait de jouer sur les dynamiques de groupe pour inciter les équipiers à en faire plus et à se dépasser, c'est LA perversion du système lui-même, car cela fait croire faussement aux managers qu'on fait plus et plus vite, alors qu'en fait, on augmente la pression sur les équipiers qui continuent de bâcler plus en cachant la poussière sous le tapis. Cela va évidemment ensuite avoir des répercussions sur le support et sur le client final qui utilise le produit. Encore plus grave, c'est l'une des raisons des burnouts des employés.
 
J'aurais d'ailleurs l'occasion de revenir là dessus bientôt quand j'exposerai le "Pure Kanban".
 
PS : Mais j'ai quand même édité mon premier message pour prendre en compte ta remarque.

Drap car le sujet est intéressant.  
 
Ma boite pousse à fond pour passer à l'agile et la plupart des équipes y sont passées.  
 
Apparemment, la plupart des gens sont satisfait des scrum et autre board kanban mais ça me terrorise absolument.  
 
J'y ai eu droit pendant 1 an dans mon ancienne équipe et le nombre de réunion m'a détruit la santé.  
 
Daily tous les jours à la même heure, retro / démo toutes les deux semaines, ça m'a mis une telle pression que je n'arrivais plus à m'en sortir.  
 
Je pense que ce genre de méthodes est bien pour les gens qui sont déjà un peu organisé mais si comme moi, tu as plus tendance à faire un peu tout en même temps dans tous les sens, c'est un enfer absolu.  
 
Je sais tout à fait respecter les deadlines, j'ai une vision macro de ce que je dois faire pour les prochaines semaines/ mois et je fini toujours par m'en sortir mais j'ai aucune idée de ce que je vais faire pendant la journée elle-même le matin.  
 
Je n'arrive pas à voir les projets en 3 millions de sous tache à l'avance et à ce que j'ai vu, l'agile oblige à faire ça tout le temps. Je suis incapable d'avoir une réunion chaque JOUR de la semaine sur un projet, c'est beaucoup trop rapide et épuisant.
 
 
Trouver une équipe qui ne fait pas d'agile m'a enlevé une énorme partie de mon stress quotidien. Malheureusement, ils veulent y passer aussi et je redoute à fond à nouveau.

 
Comme j’espère le montrer, il y a agilité et agilité
 
Je vais d’abord parler du "Pure Kanban" qui élimine les sprints (bon pour toi ) et parler des limites de cette méthode et ensuite, je vais passer au NNL.
 
Ton commentaire est hyper intéressant car dans la méthode NNL, tu vas voir bcp de choses qui résolvent ce tu as énoncé.
 
 

Copain ! Je suis exactement pareil
J'ai rarement été en retard et j'aime être autonome sur le planning et l'ordonnancement des tâches.
Et rien que le fait qu'une personne doit m'imposer ça et le contrôler au quotidien je le supporte pas : même ma mère ne contrôlait pas si je faisais ou pas mes devoirs ou révisait mes cours, du moment que j'avais des bonnes notes.
Heureusement le test n'a pas duré longtemps et la personne a pas fait long feu

On me disputait aussi car je ne m'assignais pas bien sur les taches dans le kanban.  
 
Ba oui, si d'un coup, je pense à la solution pour un soucis qui traine depuis des jours, je ne vais pas aller me connecter à Jira, trouver le bon machin et m'assigner. Le temps de faire ça, j'aurai oublié la solution que j'ai dans la tête.  
 
Et puis on m'avait dit que quand je travaille sur plusieurs projets en même temps, dès que je fais alt tab pour passer à autre chose, je devais aller sur Jira pour m'assigner sur la bonne sous taches.    
 
Mais après, je pense que le pire reste le daily.  
 
Devoir justifier son salaire et son travail de la veille chaque matin .
Et en plus juste ça, car si tu as un "vrai problème", le SM va te dire de faire une réu à part pour en parler car le daily ce n'est pas pour ça. C'est seulement pour dire ce que t'as fait hier et ce que tu va faire aujourd'hui.  
 
(En plus, souvent je ne me souviens pas de ce que j'ai fait hier car j'avance tous mes projets en même temps et je switch dès que ça me soule/ je sature^^ Je devais prendre des notes sur ma propre journée pour m'en sortir, ce temps perdu).

De 2 choses l'une : soit on est cadre et on assume sa répartition du temps et on sait quand faire des tâches critiques.
Soit on est contrôlé en permanence quotidiennement tel un grouillot.

Certains se sentent surement bien dans le 2ème cas et ont besoin qu'on leur donne une liste tous les matins, mais pour moi on est alors un exécutant. Et quand tu as 15 ans de boutique et que tu as mis en place les projets les plus ambitieux de la boite t'as pas envie de ce retour en arrière.

Drap

Bon "pure kanban" expliqué dans le deuxième poste du topic. N'hésitez pas à me dire ce que vous en pensez.  
 
Je vais maintenant m'atteler à tenter de bien expliquer la méthode NNL dans le troisième poste.

A la lecture du premier et second poste, je note qu'au delà des explications théoriques générales sont ajouté des observations sur des cas d'application. Ces observations telles qu'elles sont incluses peuvent faire penser qu'il s'agit d'une réalité générale liée au modèle concerné alors que je pense qu'elles sont plutôt liées à un contexte d'application.

Il serait peut-être mieux que les observations réalisées soient dans une section à part. Cela augmenterait la clarté des explications des modèles tout en permettant de faire la part des choses entre les modèles et les observations qui sont liées au contexte d'application.

Les autres observations qui pourraient être partagées a l'avenir pourraient même venir enrichir cette section.

 
Merci de tes observations.
 
Comme je l’ai énoncé au départ, l’idée pour moi n’est pas de faire un cours, et si tu regardes les deux postes, mes observations sont à la fin dans les derniers paragraphes. Ces observations, elles sont d’ordre très général, mais pour moi, le sprint par exemple porte en lui les défauts dont je parle (mais effectivement, c’est mon avis et au delà de la théorie et de ce que j’ai pu étudier, mon expérience joue forcément un rôle). Il existe des workarounds pour améliorer la situation et ce topic est là (je l’espère) aussi pour en discuter.
Je vais voir si je peux éditer mes messages plus tard pour détacher “mon avis” de la théorie générale.

Je pense également devoir rappeler que tout est simplifié à outrance, comme dit tout au début de mon premier poste. Le sujet est vaste et complexe et si je devais faire les choses vraiment sérieusement, c’est un bouquin que je devrais écrire. Le but de mes postes, c’est aussi finalement de faire un peu réagir et ensuite de laisser les participants (s’il y en a) construire le topic.

Il y a en effet des livres entiers pour décrire chaque modèle.
Dans le cadre de la présentation simple il est peut-être intéressant de mettre un lien vers le manifesto et d'expliquer son origine et son but en quelques lignes.

Pour les modèles, il y a pour ceux que je connais des diagrammes qui peuvent servir de base pour la présentation générale ce qui permet de ne détailler que les termes spécifiques. Termes qui sont parfois un simple changement de nom d'un modèle a un autre.

 
Si tu veux proposer tes diagrammes et/ou n'importe quoi que je puisse ajouter à mon premier post, pas de problème, j'en serai ravi.
 
Je n'ai pas parlé du manifesto agile (à la place, j'ai énoncé quelques principes agiles pour une compréhension globale) ni de SCRUM d'ailleurs, parce que j'ai voulu ouvrir ce sujet autant que possible sans le réserver à des spécialistes. J'ai préféré me concentrer sur le "sprint" (qui est déjà un terme technique) parce qu'il est au coeur de beaucoup d'insatisfaction des employés de nos jours.
Personnellement (et de par mon métier, je rencontre bcp de monde), les seules personnes que je connais qui sont contentes de SCRUM et des systèmes avec des sprint, sont des SCRUM masters et/ou des managers qui appliquent cette méthodologie. Moi-même je suis passé par là, et ce pendant des années, mais vivant au UK, j'ai vu ça arriver très tôt avec toute l'excitation autour de ça et bien évidemment avec tous les excès. Je ne vais pas rentrer dans les détails, car je pourrais écrire des pages et des pages là dessus, mais ici chez nous on a passé des années à tenter de résoudre les problèmes posés par cette méthodologie et à trouver des workarounds.
 
Le constat quand même, c'est une grosse insatisfaction des employés dès qu'on aborde le sujet. Il suffit de voir même ici. Trouve moi un dev de nos jours qui est content de l'application de SCRUM avec un sprint hebdo et un daily. Ça doit bien exister, mais moi, je n'en connais pas.
 
Or, comme je le rappelle dans mon premier poste, une des clés de la vraie productivité, c'est la satisfaction des employés au travail. ça ne sert à rien d'avoir des équipes qui performent avec x nombre de tasks tous les jours, si c'est pour à la fin se retrouver avec un produit qui doit sans cesse être réparé et des employés en burnout et/ou en turnover.  
 
Également comme tu peux le voir, le naturel revient au galop et je réemploie les termes anglais car je vis ici au UK et je me force dans ce poste à traduire certaines choses probablement maladroitement, mais je ne vais pas pouvoir le faire tout le temps car c'est fatiguant.

Ton exemple du gars qui sous-estime puis sue de la raie pour terminer dans le sprint est un peu étrange puisque justement il y a des mécanismes (je parle ici en Scrum) en place pour pallier à cela:
- déjà, c'est toute l'équipe qui estime ensemble et pas une seule personne et en cas de désaccord il faut en discuter et exposer ses points de vue, ce qui mécaniquement diminue la possibilité de sous-estimer puisque plusieurs membres de l'équipe (au moins - je t'épargne "toute l'équipe" ) sont censés vraiment comprendre ce que la tâche implique.
- ensuite, le temps effectivement pris pour chaque tâche/story doit être relevé et utilisé dans un genre de matrice ou outil équivalent qui donne des estimations à la louche de la performance réelle passée de l'équipe selon la taille et le type de story, et qui ensuite sert de base de départ pour estimer lors des backlogs groomings
Du coup avec la montée en maturité de l'équipe ce genre de problème se résoud tout seul: au début ça peut arriver de louper ses estimations, mais une fois mature ça doit rester exceptionnel, et lorsque ça arrive déclencher presque automatiquement une identification des raisons pour affinement de l'outil donnant les estimations de base (typiquement lors de la rétro si personne n'a levé le lièvre avant)
 
Du coup un mec qui fait ce que tu dis de façon récurrente ben... Pas en Scrum et probablement pas en Agile "bien fait" non plus (=pas d'auto amélioration pour accroître l'efficacité, ce qui est contraire à un des principes de base)
Après si tu me dis que le gars en question fait son boulot supplémentaire en cachette bah OK mais c'est plus un problème de méthodologie de gestion de projet.
 
Et du coup pour la petite pique trop tentante et pour laquelle je m'excuse par avance, ce n'est pas surprenant que tu dises d'arrêter avec la méthode "à Gilles" vu que visiblement tu es en plein dedans.
 
Après comme l'a dit quelqu'un il y a quelques posts, l'Agile c'est comme le communisme. Je reprend Scrum parce que c'est le seul que je connais bien, en fait il y a tellement de prérequis qui n'existent quasiment nulle part que je pense que très peu de personnes ont déjà dû faire du "vrai" Scrum.
J'ai probablement un biais; je suis dans de l'IT pour finance et de base il y a TOUJOURS des points assez fondamentaux qui font que dès le départ il est assez facile de prédire qu'Agile ne marchera pas (pas dans le sens où il n'y aura aucun résultat, mais dans le sens où il n'y aura pas de bénéfice à s'en servir):
- Dépendance d'autres équipes avec leurs propres intérêts, typiquement infra, prod, fournisseurs externes...
- Relations hiérarchiques et/ou commerciales entre les membres de l'équipe (interne/presta/consultant, manager/team lead/dev...)
- Types de projets non adaptés (typiquement mise en place, alimentation et configuration d'un soft externe)
- Jamais d'équipe ou "tout le monde peut faire toute tâche" - mais ce point-là c'est clairement Scrum qui abuse
- Incompréhension assez marquée de Scrum par le management: présence de BAs dans l'équipe, exposition directe de l'équipe au client, découpage et estimation du backlog hors du périmètre de l'équipe, j'ai eu un projet avec plusieurs POs une fois aussi...
 
Il n'y a pas tous les points à chaque fois mais c'est au mieux les trois premiers minimum. Et à chaque fois ça finit en gros n'importe quoi mais les chefs s'en foutent parce tout se passe comme le rapport de KPMG leut avait prédit: ces benêts de dev sont contents parce que Scrum c'est à la mode, et on va pouvoir virer plein de CDPs maintenant que les équipes s'autogèrent. Et encore plus quand on sera passés "At Scale".
 
Bon après avec le temps je me fais une raison - j'ai passé les mêmes certifs que tout le monde, sur le coup ça m'avait l'air très clair les tenants, aboutissants et mécanismes de Scrum mais autour de moi l'écrasante majorité semble avoir tout compris de travers... Donc c'est sûrement moi qui ai rien capté.

C'est beau en théorie mais dans le monde réel, les gens ne vont pas à la même vitesse pour chaque tache donc la théorie "exacte" marche qu'avec une équipe de clones ou de jumeaux.
 
Certaines personnes ont plus d'affinités avec une tache ou une autre et c'est un peu ridicule de voir les gens comme des machines identiques ?
 

Et on vient nous dire que le machin est fait pour baisser le niveau d'anxiété de l'équipe alors que de fait on créé des KPI de vitesse par tache.  
 
C'est mon opinion mais t'es en train de prouver l'inverse totale de ta thèse de base.  
 

 
Alors, déjà, merci pour ton partage et ta participation. J'ai un peu souri en lisant ces lignes, parce que je reconnais là tout notre parcours dans ma boite avec les mêmes discours, mais aussi les mêmes solutions qu'on a tenté de mettre en place au fil de plusieurs années.
 
La maturation de l'équipe, c'est un mirage, de même que la sincérité des équipiers. Et ça, c'est la grande leçon qu'on a fini par retenir au bout de plusieurs années de SCRUM + Sprints.  
 
À l'époque où on a démarré avec cette méthode, je n'étais pas encore manager, mais développeur au sein de l'équipe et je devais être à peu près le seul à avoir réussi à suivre et à appliquer ce qu'on nous demandait. J'étais d'ailleurs aussi pratiquement le seul à défendre sincèrement la méthode (et à y croire) au sein de mon équipe (tout le monde faisait semblant d'être cool, mais dès que j'avais des discussions perso avec mes collègues de l'époque, ils crachaient dessus et étaient soit en colère, soit désabusés).
 
Je ne vais pas rentrer dans tous les détails de notre expérience car ça prendrait trop de temps, mais en vrac, ce que je peux dire, c'est que même la mesure du temps passé à accomplir une tâche était une vaste blague, surtout à l'époque où l'on bossait dans des bureaux et où on était sans cesse dérangé. Les gens étaient incapable de mettre en route et/ou d'arrêter le timer et à la fin de la journée, ils ne se souvenaient même pas de ce qu'ils avaient fait. Donc rien que sur cet aspect, c'était une catastrophe.
 
Ensuite, concernant l'attribution des tâches pour les sprints, bah je maintiens que c'était une forme de théâtre et que les gens voulaient se faire bien voir. Surtout, il y avait des grandes gueules qui parlaient beaucoup et d'autres qui ne disaient jamais rien. Au final, au moment de l'évaluation des sprints, c'était échec sur échec avec des tâches même pas commencées...  
 
S'en est suivi une période où les managers de l'époque étaient furax contre l'équipe accusée de ne pas vouloir bosser et avec des menaces... Ce qui a conduit les équipiers à sur-découper les tâches pour pouvoir être sûr à 100% de finir à la fin des sprints. Les sprints n'échouaient plus, mais la productivité était ridicule, les gens bâclaient leur boulot même sur des trucs pourtant faciles. En fait, les gens étaient tout simplement désabusés, ne croyaient pas au système et prenaient les managers pour des cons.  
 
À savoir qu'on a même payé un consultant spécialisé là dedans...
 
À noter qu'en plus, le Télétravail était bien évidemment interdit.
 
Le temps a passé, je suis passé lead dev entre temps, puis depuis quelques années, je me suis retrouvé CTO un peu sur un malentendu. Comme je suis quelqu'un qui prend quand même très au sérieux son travail, je me suis un peu plongé dans le management, les méthodologies etc...
 
Mais évidemment, je n'ai pas fait ma révolution sitôt aux affaires. J'ai d'abord temporisé avant de tenter "autre chose" (qui a été un "pure kanban" dans un premier temps qui a fondamentalement changé l'ambiance dans l'équipe et a permis de réconcilier le management avec le département tech grace entre autre chose à une forte hausse de la productivité).
 
Pour donner une idée, quand j'étais dev dans l'équipe, on avait un turnover affolant. Il ne reste qu'UNE seule personne qui a commencé 1 an après moi. Tous les autres sont partis.
 
Depuis que je suis CTO (on approche des 5 ans), j'ai perdu UN seul N-x qui est parti parce qu'il a trouvé un poste plus intéressant et surtout bien mieux payé et on est toujours en contact aujourd'hui.
 
À noter aussi que c'est moi qui ait réussi à convaincre big boss concernant le télétravail, et qu'en quelques années on est passé en full remote (alors que le boss était 100% contre à la base). On a une équipe maintenant internationale VS une équipe purement anglaise quand je suis arrivé.
 
 

 
Je ne crois pas du tout que tu n'aies rien capté et d'ailleurs je perçois que tu as bcp réfléchi toi aussi, probablement aussi avec des expériences différentes de la mienne. C'est d'ailleurs un peu aussi le grand biais avec ces méthodologies : nos convictions reposent énormément sur nos expériences, même quand on fait l'effort de lire, de se renseigner etc...
 
Ce que je crois aussi fondamentalement, c'est que quand une méthode échoue tout le temps (tous les retours que j'ai des personnes que je connais dans les groupes de discussion professionnels auxquels j'appartiens sont unanimes, avec des raisons d'ailleurs souvent très différentes), c'est qu'elle n'est pas bonne. (ref au communisme )

Par curiosité, pourquoi est-ce que tu te lances dans un topic sur avantages, inconvénients et solutions des méthodes agiles quand tu sembles être convaincu que c'est des mauvaises méthodes tout en reconnaissant à la ligne d'au dessus que tu es biaisé ?

 
Ben je ne pense pas que ce soit contradictoire. Effectivement, sur ce sujet, je pense que les biais sont très nombreux. Ça ne m’empêche pas d’avoir une opinion moi-même et qui n’est pas autant arrêtée que tu sembles le penser. J’ai longtemps défendu SCRUM,  le manifesto (d'ailleurs je continue à en défendre la plus grande partie), et même le principe des sprints.
Le seul reproche qu’on pourrait me faire, c’est de ne pas détacher (pour le moment, je pense éditer mes messages plus tard) mes opinions de mon genre d’exposé qui n’en d'ailleurs même pas vraiment un. Je pose quelques bases pour ouvrir la discussion et comme tout topic sur un forum comme HFR, c’est aussi fait pour faire réagir. J’ai ni la prétention, ni probablement les compétences pour faire un exposé sur un sujet aussi complexe d'une manière parfaitement neutre.
Si tu penses que qu'un SCRUm classique correctement implémenté avec des sprints peut marcher, c'est super, tu peux très bien le défendre ici, et même ça m’intéresse. C’est pas parce qu'on a pas réussi que c'est impossible, et même le fait que je connaisse bcp de monde qui sont contre (pour des raisons souvent différentes d’ailleurs), ça ne prouve rien dans l'absolu. J’ai mon opinion, mais ça s’arrête là.