Agile est-il la nouvelle microgestion?
Cette question me trotte dans la tête depuis un moment, je voulais donc demander à ceux qui suivent des pratiques agiles/scrum dans leurs environnements de développement.
Mon entreprise s'est enfin aventurée à intégrer des pratiques agiles et a commencé avec une équipe de 4 développeurs dans un groupe agile à titre d'essai. Cela fait 4 mois avec 3 itérations et ils continuent de le faire sans être totalement agiles pour le reste d'entre nous. Cela est dû au fait que la confiance de la direction pour répondre aux besoins de l'entreprise avec un peu de demande de type ad hoc d'en haut.
Récemment, j'ai parlé aux développeurs qui font partie de cette initiative; ils me disent que ce n'est pas amusant. Ils ne sont pas autorisés à parler à d'autres développeurs par leur Scrum master et ne sont pas autorisés à prendre des appels téléphoniques dans la zone de travail (ce qui peut être correct dans une certaine mesure). Par exemple, si je veux parler à mon ami pour des coups de pied qui est dans l'équipe agile, je ne suis pas autorisé sans l'approbation du Scrum master; qui est assis juste à côté de l'équipe agile.
L'idée de tout cela ou de l'agile est de fournir un vide complet aux développeurs agiles de toutes les interruptions et de les faire consacrer plus de 6 heures productives. Eh bien, les gars, je ne suis pas un gourou agile mais ce que j'ai lu le document de déploiement agile Yahoo et similaire pour d'autres organisations, cela me donne le sentiment que l'agilité n'est pas bon marché. Il faut des ressources et un budget pour inculquer l'agilité aux équipes et corriger le problème à mesure qu'ils arrivent pour les remettre sur la bonne voie.
Pour commencer, cela nécessite une formation pour les développeurs et un coaching pour les managers et etc, etc ... J'ai également entendu lors de la réunion que le manifeste agile ne dicte pas que l'agile n'est pas figé et qu'il est personnalisé différemment pour chaque entreprise. Eh bien, tout cela sonne bien et raison.
En conclusion, j'ai toujours pensé que l'agile était censé apporter l'harmonie dans les équipes de développement, ce qui se traduit par des développeurs heureux. Cependant, je ressens un sentiment très opposé lorsque je parle aux développeurs de l'équipe agile. Ils sont mécontents de ne pouvoir parler que du travail, assis tranquillement toute la journée à travailler, et ils pensent que c'est juste une autre façon pour la direction de les faire travailler davantage.
Dites-moi s'il vous plaît, si c'est l'un des exemples de bonnes pratiques utilisées dans le but de faire un avantage égoïste pour plus de dollars? Ou peut-être, c'est juste nous les développeurs comme moi et cette équipe agile sent qu'ils n'aiment pas travailler dans un environnement où ils respirent seulement parce qu'ils sont au travail.
C'est une entreprise dans le domaine de la santé qui possède des bureaux aux États-Unis. Cela ressemble vraiment à un style de cow-boy agile, ce qui me donne vraiment envie de ne pas opter pour l'agilité, en particulier dans mon entreprise actuelle.
Tout cela a à voir avec la gestion étant complètement bon marché. Couper le café cher pour une version moins chère, mettre l'accent sur les économies et être productif tout en restant le plus maigre possible.
Mon sentiment est que quelqu'un dans la direction derrière la porte a rejeté cette idée, que l'agilité vous fait produire plus afin que nous puissions montrer à nos patrons que nous produisons plus avec le même effectif. Ou, peut-être, cela nous permettra de réduire les effectifs si tel est le cas.
Ils ont leur réunion quotidienne de 5 minutes. Mais pas autorisé à discuter ou à parler avec quelqu'un en dehors de leur équipe. Tout l'accent est mis sur le travail.
Vous décrivez la dictature managériale, pas agile. Agile concerne le développement incrémentiel dans un domaine où les exigences évoluent, pas la dictée des personnes sur la façon dont elles effectuent leur travail individuellement.
Ils ne sont pas autorisés à parler à d'autres développeurs par leur Scrum master et ne sont pas autorisés à prendre des appels téléphoniques dans la zone de travail
Cela ne fait vraiment pas partie des pratiques Agiles - et un problème distinct.
Une grande motivation des méthodologies Agile est communication accrue entre les développeurs. La restriction de la communication entre développeurs <-> développeurs est un problème distinct des pratiques Agile. Je ne dis pas que cela ne se produit pas - c'est évidemment le cas, et cela est étiqueté comme faisant partie du déploiement "agile" dans votre organisation, mais c'est vraiment un problème distinct de l'agile (et quelque peu contre l'esprit du développement agile, OMI).
Cela ressemble à une implémentation assez perverse d'agile. Agile, le cas échéant, devrait réduire la microgestion, pas l'augmenter. L'équipe prend un engagement et une partie du processus est que la direction a confiance que l'équipe le réalisera. La mêlée quotidienne est un moyen pour les développeurs de communiquer entre eux et un moyen d'informer sur ce qu'ils ont fait, pas sur la façon dont ils ont passé leur temps (ce qui est une erreur que j'ai vue à quelques endroits). Même le processus d'estimation devrait supprimer le respect explicite du temps dans les estimations, car vous devriez estimer la complexité relative, et non le temps qu'une histoire prendra (une autre erreur courante). Le contrôle du temps passé par les développeurs est la marque de la microgestion, et la suppression du temps du processus est l'un des principes fondamentaux de l'agilité.
L'environnement que vous décrivez ressemble à une variété de jardin conneries pseudo-agiles .
Je me suis impliqué avec Agile avant qu'il ne soit Agile. Vers 2000, je brûlais de codage, j'ai entendu parler de la programmation extrême, je l'ai essayé et j'ai aimé. Cela m'a donné en tant que développeur un contexte où la production de logiciels solides était la chose la plus importante, et cela m'a donné des outils pour minimiser beaucoup de conneries qui me rendaient fou. Je l'ai aimé.
Le problème aujourd'hui, qui j'explique en détail ailleurs , est que la plupart des gens qui "adoptent Agile" de nos jours ne sont pas intéressés à améliorer quoi que ce soit si cela les met mal à l'aise. Donc pour eux, "Agile" n'est qu'un nouveau bâton pour battre les développeurs de la même manière. Par opposition à, disons, un moyen d'augmenter radicalement la productivité tout en supprimant toutes les conneries qui ralentissent le développement.
Maintenant. Je démarre une entreprise, et j'utiliserai beaucoup d'XP, ainsi qu'un tas d'autres astuces que je me suis appuyées dans le monde Agile. Mais précisément à cause d'histoires comme la vôtre, je tressaille chaque fois que j'entends parler d'une adoption Agile de nos jours.
Donc, pour répondre directement à votre question: Agile ne devrait pas être la nouvelle microgestion. Il devrait s'agir d'autonomiser les gens qui font le travail réel pour faire de la merde. Mais dans votre cas, Agile sonne comme le dernier mensonge qu'ils vous disent alors qu'ils s'adonnent à leurs mauvais instincts. Pour lequel je suis vraiment désolé.
Ce n'est pas agile.
Tout d'abord, Scrum n'est pas agile. Scrum, franchement, c'est des conneries. J'ai été élevé dans une maison de programmation extrême (littéralement - j'ai demandé à Kent Beck de s'asseoir sur le canapé de mon père et de me parler des tests), et je peux vous dire tout de suite que Scrum n'est pas ça. Scrum est un outil de gestion de projet - un rythme défini pour un projet de développement. Mais cela n'a rien à dire sur le développement lui-même, et très peu à dire sur les exigences, la planification et la relation avec le client. XP a beaucoup à dire sur tout cela; toute autre méthodologie qui veut se dire agile doit avoir quelque chose à ajouter à la conversation. Les partisans de Scrum l'ont décrit non pas comme un processus, mais comme un emballage pour un processus. Un homme sage a fait remarquer qu'un emballage est la chose que vous retirez et jetez pour obtenir les bonnes choses.
D'accord, la mêlée hurle!
Deuxièmement, un principe fondateur de XP, qui je crois est fondamental pour tout processus agile, est qu'il est centré sur le développeur. C'est une façon de donner aux développeurs le pouvoir de faire le travail qu'ils savent devoir faire, et ils sont si souvent empêchés de le faire. Une équipe agile peut être structurée comme une démocratie ou une autocratie, mais les dirigeants sont des développeurs. Il y a des rôles pour les chefs de projet et ainsi de suite - des rôles vitaux - mais il ne s'agit pas d'un leadership d'équipe. Avoir un manager - désolé, "maître de mêlée" - assis là à diriger des gens est un signe certain que l'équipe ne fait pas d'agilité.
Je pense qu'il devrait y en avoir un troisième. Il n'y en a pas.
Scrum est l'enfant bâtard d'Agile. C'est le style le plus en cascade de toutes les méthodologies agiles, et c'est pourquoi c'est le plus populaire parmi les gestionnaires.
Toutes les méthodes agiles consistent à produire du code de travail sans que de la merde ne gêne. Relisez ça. Et encore.
Tout ce qui fait obstacle à cet objectif, quelles que soient les "règles agiles", est mauvais. Si les règles gênent, changez les règles f * * ! C'est la manière agile, c'est ce qui la rend pertinente et efficace.
Le meilleur exemple de ceci est donné par Alistair Cockburn (l'un des auteurs du manifeste agile):
"Mettez 4 à 6 personnes dans une pièce avec postes de travail et tableaux blancs et accès aux utilisateurs. Demandez-leur de fournir aux utilisateurs des logiciels en cours d'exécution et testés tous les un ou deux mois, et sinon laissez-les tranquilles. "
Si cela fonctionne pour la qualité des gars que vous avez, alors c'est tout ce dont vous avez besoin. Vous n'avez pas besoin d'un Scrum Master ou d'une méthodologie "agile". Si vous asseoir dans une mêlée quotidienne vous convient, alors f * * * faites-le. Vous faire tenir debout n'est qu'une abrogation pathétique de votre capacité à penser par vous-même.
Il y a une réponse au genre d'agilité que vous faites. C'est ça. Imprimez-le et épinglez-le quelque part lorsque personne d'autre n'est là et laissez-le le découvrir par lui-même.
L'actuel Scrum master était un manager qui a suivi quelques jours de cours de formation agile payés par la direction et dirige maintenant cette équipe agile.
C'est ton problème. Les directions veulent de l'Agile, elles ne savent pas vraiment ce que c'est, et elles l'imposent aux équipes. C'est à peu près ce que vous devez faire lorsque vous souhaitez réduire considérablement la productivité de vos développeurs;)
La nouvelle proposition de processus devrait venir des développeurs. Ou au moins être révisée et approuvée par eux si c'est une idée de gestion.
Dans tous les cas, si les développeurs le refusent, ne l'implémentez pas! Ou ce sera le désastre que vous décrivez.
"Agile" et toutes les autres "méthodes de gestion" sont fréquemment utilisées pour forcer la microgestion sur les personnes. OTOH, il est également parfois abusé pour défendre une mauvaise exécution.
"nous sommes Agile" est l'excuse la plus fréquente que j'entends pour le manque de planification, le manque de réflexion sur la conception, les fonctionnalités, la qualité, les cycles de sortie. Cela provient généralement des développeurs et de la gestion inférieure. C'est follement aussi l'excuse la plus fréquemment utilisée par les cadres intermédiaires, les architectes, les vendeurs, etc. pour la microgestion, les délais et les listes sans cesse changeants, forçant les heures supplémentaires massiver sur les gens (les délais et les listes sans cesse changeants garantissent cela bien sûr), etc. etc. .
Les deux sont bien sûr souvent en contradiction directe et peuvent se produire sur le même projet.
Pour répondre à votre question d'origine, Agile est la nouvelle micro gestion, je dirais non.
Tout d'abord, allez lire this (manifeste Agile) et vous remarquerez que ne pas parler à vos co-développeurs n'est pas répertorié.
En fait, "individus et interactions" est exactement le contraire de ne pas parler à vos co-développeurs.
Agile devrait être la nouvelle autogestion. Si l'agile est pratiqué correctement, la plupart des décisions sont prises par un client et un développeur travaillant sur une histoire utilisateur de portée raisonnable. qui est ajouté au backlog à mesure que les tâches sont identifiées.
La mêlée quotidienne concerne la communication, pas la gestion. Il y aura des discussions sur la priorité et l'équilibrage de charge, mais la personne dirigée à la mêlée est, espérons-le, la mêlée Maître. En tant que développeur, j'assiste, dis ce que j'ai fait, ce que je vais faire et quelle aide j'ai besoin. Ensuite, le Scrum Master devrait entrer en action pour éliminer les obstacles à ma progression.
Les équipes agiles ne doivent pas avoir l'impression que le travail quotidien est géré de manière hiérarchique. Si les décisions sont prises à distance par quelqu'un au sommet d'une organisation hiérarchique, c'est il est temps de décentraliser la prise de décision! Pour certaines personnes et certaines organisations, cela peut être un pont trop loin. Si ce qui suit n'est pas vrai pour votre organisation:
Vivez le Manifeste Agile
"Nous découvrons de meilleures façons de développer des logiciels en le faisant et en aidant les autres à le faire."
Évitez "Rencontrez le nouveau patron, comme l'ancien patron." Provenez Agile de l'équipe autant que possible. Parfois, cela se produit en choisissant une coalition de personnes disposées à participer à un projet d'essai utilisant Agile. Si vous pouvez former votre équipe Agile à partir de bénévoles ou de membres invités qui ont fait leurs preuves pour un bon travail d'équipe, ils peuvent s'en sortir. Utilisez une petite équipe sur un court projet, peut-être pour un client interne ou très accessible.
Acceptez le changement. Peut-être que vous pouvez suivre une formation, mais peut-être que votre budget est serré et que l'argent n'est tout simplement pas là. D'autres opportunités peuvent également apporter des améliorations. Faites de la lecture, demandez aux membres de l'équipe d'apprendre ce qu'ils peuvent sur Agile et de s'enseigner mutuellement. Vous pourrez peut-être trouver du personnel nouveau ou existant qualifié pour modéliser et diriger l'adoption Agile.
Les équipes agiles sont comme des équipes de football travaillant vers un objectif commun. Je fais partie d'équipes agiles depuis quelques années et la clé est une communication efficace et efficiente entre toutes les parties prenantes. Les managers/Scrum masters sont de simples facilitateurs de l'équipe et la gestion traditionnelle/micro gestion tuera l'esprit de l'équipe.
Dans les équipes dans lesquelles j'ai travaillé, nous sommes encouragés à jouer à des jeux d'équipe après les heures de travail pour améliorer la camaraderie au sein des membres. J'ai rassemblé ces pensées ici .
Pour répondre à votre question: Non. Agile n'est pas une forme de microgestion. Mais comme tout outil, les gens ne peuvent pas l'utiliser correctement. Agile est merveilleux lorsqu'il est correctement mis en œuvre et lorsque les gens y sont cohérents.
Mes réflexions sur le sujet "Les développeurs ne parlent à personne mais au Scrum Master":
J'ai déjà travaillé dans un endroit où c'était une règle auparavant. TOUTEFOIS, la règle était davantage liée à la demande aux gens d'effectuer des tâches. Par exemple, je ne peux pas aller au hasard vers un testeur de développement et leur demander de faire des tests pour moi dans les prochaines heures. Je dois parler au Scrum Master afin qu'il puisse discuter avec son membre de l'équipe de la façon dont ce travail s'intégrera dans le sprint en cas d'urgence (ou s'il doit être poussé dans le backlog pour un futur sprint).
Dans ce cas, j'ai compris le concept de "les développeurs ne se parlent pas", car il se traduisait vraiment par des tâches de transfert via un point de contrôle, de sorte qu'un développeur particulier n'est pas surchargé de travail ou est tellement occupé à effectuer des tâches d'urgence qu'il ne peut pas obtenir son plan travail effectué.
Sinon, les développeurs DEVRAIENT se parler. Toujours. Il vous aide à résoudre les problèmes plus rapidement, à vous rapprocher en équipe et à livrer plus rapidement.
Juste pour offrir une autre perspective: j'ai également été dans un environnement où les gens pensaient que les développeurs "parlaient trop". Après un sit-down, nous avons découvert que cela se traduisait en fait par "les développeurs ne sont pas assez indépendants pour faire leur propre travail. Parce que tout est tellement fragmenté, les développeurs doivent aller à trois autres personnes pour terminer une petite tâche."
Ainsi, lorsque les gestionnaires ont décidé de passer à l'agilité, ils s'attendaient à ce que cela aide à apporter les informations aux bons endroits et à arrêter une grande partie de la fragmentation au sein de l'organisation. Certaines personnes ont été un peu déçues qu'après la mise en œuvre d'Agile, les développeurs se soient toujours échangés. Mais ce qu'ils ne savaient pas, c'est que cela se produisait de moins en moins. Mais cela a pris du temps. Donc, peut-être que si c'est ce qui se passe dans votre organisation, il se pourrait que les gens s'attendent à ce que l'agile règle les choses du jour au lendemain. Ce n'est tout simplement pas ainsi que cela fonctionne.