Agile est-il le nouveau microgestion?

Cette question me trottait dans la tête depuis un moment donc je voulais demander à ceux qui suivent des pratiques agiles / scrum dans leurs environnements de développement.

Mon entreprise s'est finalement lancée dans l'incorporation de pratiques agiles et a démarré avec une équipe de quatre développeurs d'un groupe agile à titre expérimental. Cela fait 4 mois avec 3 itérations et ils continuent à le faire sans aller complètement agile pour le reste d'entre nous. Cela est dû au fait que la direction a confiance de pouvoir répondre aux exigences de l’entreprise avec une assez grande demande de type ad hoc émanant d’en haut.

Récemment, j'ai parlé aux développeurs qui participent à cette initiative. ils me disent que ce n'est pas amusant. Ils ne sont pas autorisés à parler à d'autres développeurs par leur maître Scrum et ne sont pas autorisés à prendre d'appels téléphoniques dans la zone de travail (ce qui est peut-être bien dans une certaine mesure). Par exemple, si je veux parler à mon ami pour les coups de pied qui fait partie de l'équipe agile, je ne suis pas autorisé sans l'autorisation du maître Scrum; 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, à partir de toute interruption, et de leur faire passer plus de 6 heures productives. Eh bien, les gars, je ne suis pas un gourou agile, mais ce que j'ai lu dans le document de déploiement agile de Yahoo et similaire pour d'autres organisations, cela me donne le sentiment que l'agile n'est pas bon marché. Il faut des ressources et un budget pour insuffler de l'agilité aux équipes et corriger le problème à mesure qu'elles arrivent pour les remettre sur les rails.

Pour commencer, cela nécessite une formation pour les développeurs et un encadrement pour les gestionnaires, etc. Le maître Scrum actuel était un gestionnaire qui a suivi une formation agile de deux jours payée par la direction et dirige maintenant cette équipe agile. J'ai également entendu au cours de la réunion que le manifeste agile ne dit 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 la raison.

En conclusion, j'ai toujours pensé que l'agile était censé apporter de l'harmonie dans les équipes de développement, ce qui rend les développeurs heureux. Cependant, je ressens un sentiment opposé lorsque je parle aux développeurs de l'équipe agile. Ils sont mécontents de ne pouvoir parler que de travailler, de rester assis tranquillement toute la journée à travailler, et ils estiment que c'est simplement un autre moyen 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 l'avantage égoïste pour plus de dollars? Ou peut-être que nous ne sommes que les développeurs comme moi et cette équipe agile a le sentiment qu'ils n'aiment pas travailler dans un environnement où ils ne respirent que parce qu'ils sont au travail.

C'est une entreprise dans le domaine de la santé qui a des bureaux à travers les États-Unis. Cela ressemble vraiment à un style de cow-boy agile, ce qui me donne vraiment envie de ne pas miser du tout sur l'agilité, surtout 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 aussi mince que possible.

Mon sentiment est que quelqu'un de la direction derrière la porte a lancé cette idée, que l'agile vous permet de produire davantage afin que nous puissions montrer à nos chefs que nous produisons davantage avec le même effectif. Ou peut-être que cela nous permettra de réduire les effectifs si c'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 se concentre sur le travail.

Vous décrivez la dictature managériale, pas agile. Agile concerne le développement progressif dans un domaine où les exigences changent, et non pas de dicter aux gens la manière dont ils s’acquittent de leur travail.

Ils ne sont pas autorisés à parler à d'autres développeurs par leur maître Scrum et ne sont pas autorisés à prendre d'appels téléphoniques dans la zone de travail

Cela ne fait vraiment pas partie des pratiques Agiles - et une question distincte.

Une grande motivation des méthodologies Agiles est une communication accrue entre les développeurs. La restriction de la communication entre développeurs <-> est un problème distinct des pratiques Agiles. Je ne dis pas que cela ne se produit pas - c'est évident, et cela est considéré comme faisant partie du déploiement "agile" de votre organisation, mais il s'agit vraiment d'un problème distinct de l'agile (et quelque peu contraire à l'esprit du développement agile, OMI).

Cela ressemble à une implémentation assez perverse de l'agilité. L'agilité, si tant est que quelque chose, devrait réduire la microgestion, pas l'augmenter. L’équipe s’engage et fait partie du processus, c’est que la direction espère que l’équipe le réalisera. La mêlée quotidienne est un moyen pour les développeurs de communiquer entre eux et d’informer de ce qu’ils ont fait, et non pas de 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 la conservation du temps explicite des estimations, puisque vous devez estimer la complexité relative et non la durée d'une histoire (une autre erreur courante). Contrôler le 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 à de la connerie pseudo-agile de variétés de jardin .

Je me suis impliqué avec Agile avant que ce soit Agile. Circa 2000 J'étais épuisé par le codage, j'ai entendu parler de la programmation extrême, je l'ai essayé et je l'ai aimé. En tant que développeur, cela m'a donné le contexte le plus important pour produire des logiciels performants, ainsi que des outils pour minimiser les conneries qui me rendaient dingue. Je l'ai aimé.

Le problème aujourd'hui, que j'explique en détail ailleurs , est que la plupart des personnes "adoptant Agile" ne sont pas intéressées à améliorer quoi que ce soit si cela les met mal à l'aise. Donc, pour eux, "Agile" est juste un nouveau bâton pour battre les développeurs de la même manière. Par opposition à, par exemple, un moyen d’accroître radicalement la productivité tout en supprimant toutes les conneries qui ralentissent le développement.

Maintenant. Je démarre une entreprise et je vais utiliser beaucoup d’EXP, ainsi que de nombreux autres trucs que j’ai appris dans le monde Agile. Mais justement à cause d’histoires telles que la vôtre, je tergiverse 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 de responsabiliser les personnes qui font le travail pour que ce soit fait. Mais dans votre cas, Agile ressemble au dernier mensonge qu’ils vous disent alors qu’ils se livrent à leur propre instinct. Pour lequel je suis vraiment désolé.

Ce n'est pas agile.

Tout d'abord, Scrum n'est pas agile . Franchement, franchement, c'est des conneries. J'ai été élevé dans une maison de programmation extrême (littéralement - Kent Beck s'est assis sur le canapé de mon père et m'a parlé 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 ne dit rien sur le développement lui-même et très peu sur les exigences, la planification et la relation avec le client. XP a beaucoup à dire sur tout cela; toute autre méthodologie qui se veut agile doit avoir quelque chose à ajouter à la conversation. Les partisans de Scrum l'ont décrit non pas comme un processus, mais comme un wrapper pour un processus. Un homme sage a un jour fait remarquer qu’une enveloppe est la chose que vous retirez et jetez pour obtenir les bonnes choses.

D'accord, mêlez-vous!

Deuxièmement, l'un des principes fondateurs de XP, qui 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 dont ils savent qu'ils ont besoin et que l'on empêche souvent de le faire. Une équipe agile peut être structurée comme une démocratie ou une autocratie, mais les leaders sont des développeurs. Il y a des rôles pour les gestionnaires de projet et ainsi de suite - des rôles essentiels - mais ce n'est pas un rôle de chef d'équipe. Avoir un manager - désolé, 'Scrum Master' - rester assis à diriger des personnes est un signe certain que l'équipe ne fait pas preuve d'agilité.

Je pense qu'il devrait y en avoir une troisième. Il n'y a pas.

Scrum est le bâtard de Agile. C’est la plus agressive des méthodes agiles, et c’est pourquoi elle est la plus populaire parmi les gestionnaires.

Toutes les méthodes agiles consistent à produire du code de travail sans merde. Lisez cela à nouveau. Et encore.

Tout ce qui contrarie cet objectif, quelles que soient les "règles agiles", est mauvais. Si les règles vous gênent, changez les règles f * * ! C'est la manière agile, c'est ce qui le rend pertinent et efficace.

Alistair Cockburn (l’un des auteurs du manifeste agile) en donne le meilleur exemple :

«Mettez 4 à 6 personnes dans une pièce avec des postes de travail et des tableaux blancs et donnez accès aux utilisateurs. Demandez-leur de fournir aux utilisateurs un logiciel en cours d'exécution et testé tous les mois ou tous les deux mois, sinon laissez-les tranquilles. "

Si cela fonctionne pour la qualité des gars que vous avez, 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 êtes assis dans un point de presse quotidien fonctionne pour vous, alors f * * * le faire. Ce qui vous oblige à vous lever, ce n’est que l’abrogation pathétique de votre capacité de penser par vous-mêmes.

Il y a une réponse à votre agilité. C'est ça. Imprimez-le et épinglez-le quelque part lorsque personne n'est là et laissez-le découvrir par lui-même.

L’actuel Scrum Master était un manager qui a suivi une formation agile payée par la direction pendant quelques jours 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 examiné et approuvé par eux si c'est une idée de la direction.

En tout 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 des personnes. OTOH est aussi parfois maltraité pour défendre un travail médiocre.

"Nous sommes agiles" est l'excuse la plus fréquente que j'entends pour manque de planification, manque de réflexion sur la conception, les fonctionnalités, la qualité, les cycles de publication. Cela provient généralement des développeurs et des cadres inférieurs. C'est aussi l'excuse la plus fréquemment utilisée par les cadres moyens, les architectes, les vendeurs, etc. pour une microgestion, des délais en constante évolution et des listes de fonctionnalités, l'obligeant à faire des heures supplémentaires massives (bien sûr, les délais en constante évolution et les listes de fonctionnalités, etc.), etc. .

Les deux bien sûr sont souvent en contradiction directe et peuvent se produire sur le même projet.

Pour répondre à votre question initiale, Agile est-elle la nouvelle micro-gestion, je dirais non.

Commencez par lire ceci (manifeste Agile) et vous remarquerez que ne pas parler à vos co-développeurs ne figure pas dans la liste.

En fait, "individus et interactions" est exactement le contraire de ne pas parler à vos co-développeurs.

Agile devrait être la nouvelle autogestion. Si la mise en pratique agile est correcte, de nombreuses décisions sont prises par un client et un développeur qui travaillent sur une histoire utilisateur relativement étendue qui est ajoutée à l'arriéré à mesure que les tâches sont identifiées.

Le point de presse quotidien concerne la communication, pas la gestion. Il y aura des discussions sur la priorité et l'équilibrage de la charge, mais la personne gérée à la mêlée est, espérons-le, le maître de mêlée. En tant que développeur, j'assiste, dit ce que j'ai fait, ce que je vais faire et l'aide dont j'ai besoin. Ensuite, le scrum master devrait passer à l’action pour éliminer les obstacles à mes progrès.

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 une personne au sommet d'une organisation hiérarchique, l'heure est à la décentralisation de 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 meilleurs moyens de développer des logiciels en le faisant et en aidant les autres à le faire."

Évitez "Rencontrez le nouveau patron, Identique à l'ancien patron." Origine Agile autant que possible au sein de l'équipe. Parfois, cela se produit en choisissant une coalition de personnes désireuses de participer à un projet pilote utilisant Agile. Si vous pouvez former votre équipe Agile à partir de bénévoles ou de membres invités qui ont fait leurs preuves en matière de travail d'équipe, ils peuvent le résoudre. Faites appel à une petite équipe pour un projet de courte durée, par exemple pour un client interne ou hautement accessible.

Embrasser le changement. Vous pouvez peut-être suivre une formation, mais peut-être que votre budget est serré et que l'argent n'y est tout simplement pas. D'autres opportunités peuvent également apporter des améliorations. Faites des lectures, demandez aux membres de l'équipe d'apprendre tout ce qu'ils peuvent sur Agile et enseignez-vous les uns aux autres. 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 entre toutes les parties prenantes. Les gestionnaires / maîtres Scrum ne sont que des facilitateurs de l'équipe et la gestion traditionnelle / micro-gestion tue l'esprit de l'équipe.

Dans les équipes où j'ai travaillé, nous sommes encouragés à jouer à des jeux d'équipe après les heures de travail pour améliorer la camaraderie parmi les membres. J'ai rassemblé ces pensées ici .

Pour répondre à votre question: non. L'agilité n'est pas une forme de microgestion. Mais comme tout outil, les gens peuvent l’utiliser incorrectement. Agile est merveilleux lorsqu'il est correctement mis en œuvre et que les gens le respectent.

Mes pensées sur le sujet "Les développeurs ne parlent à personne, mais au Scrum Master":

J'ai travaillé dans un endroit où c'était une règle auparavant. CEPENDANT, la règle concernait davantage le fait de demander aux personnes d’achever leurs tâches. Par exemple, je ne peux pas aléatoirement faire appel à un testeur de développement et leur demander de faire des tests pour moi dans les prochaines heures. Je dois parler au chef de mêlée afin qu’ils puissent discuter avec leur 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 reporté à l’arriéré pour un prochain sprint).

Dans ce cas, j’ai compris le concept "les développeurs ne se parlent pas" parce que cela se traduisait vraiment par le fait de canaliser les tâches par un point de contrôle afin que les développeurs ne soient pas surchargés ou soient si occupés par des tâches urgentes qu’ils ne puissent pas obtenir leur planification. travail effectué.

Sinon, les développeurs DEVRAIENT être en train de se parler. Toujours. Il vous aide à résoudre les problèmes plus rapidement, à vous rapprocher en équipe et à livrer plus rapidement.

Juste pour offrir un autre point de vue: j'ai également été dans un environnement où les gens pensaient que les développeurs "parlaient trop". Après une séance, nous avons découvert qu’en réalité, "les développeurs ne sont pas assez indépendants pour faire leur propre travail. Comme tout est fragmenté, les développeurs doivent aller voir trois autres personnes pour s’acquitter de petites tâches".

Ainsi, lorsque les responsables ont décidé de passer à l'agile, ils espéraient que cela contribuerait à amener les informations aux bons endroits et à mettre un terme à 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 fussent toujours en train de se faire la navette. Mais, ce qu’ils ne réalisaient pas, c’était de moins en moins ce qui se passait. Cela a pris du temps cependant. Donc, peut-être que si c'est ce qui se passe dans votre organisation, il se peut que les gens s'attendent à être agiles pour régler les problèmes du jour au lendemain. Ce n'est pas comme ça que ça marche.

L'auteur original Smith Janes aurait pu donner de l'expérience. Mais ce sont les problèmes typiques que j'ai trouvés dans le projet Agile.

1. La plupart des organisations, les développeurs sont supposés travailler dans plusieurs projets, en agile / scrum. Les sprints ne sont jamais pris en compte. votre Scrum Master suppose que vous devriez avoir fini vos histoires à la fin du sprint. Votre Scrum Master pourrait être dédié à un seul projet, mais pas aux développeurs. CECI EST LA DISTRACTION - il ne suffit pas de prendre un appel téléphonique ou permettant un appel téléphonique.
2. J'ai vu des projets Agile où Sprint est planifié, des histoires incluses dans Sprint, sans être blotties..à mi-chemin ou au milieu des sprints .. les développeurs trouvant des dépendances non résolues, des exigences ou une histoire non complétées est l'un des abus dans la plupart des projets agiles.
3. Testing: TTD .. oui, c'est très bien .. mais j'ai vu la plupart des projets Agile s'appuyant totalement sur TTD ... aucune portée ou temps imparti pour les tests fonctionnels ou humains .. Un autre abus ... Beaucoup de Scrum Masters également ne sais pas ou ne comprend pas l'importance des tests fonctionnels. Votre code pourrait fonctionner parfaitement, s'il ne répond pas aux besoins de l'entreprise. Il ne sert à rien. Cela se produit lorsque les entreprises ne participent pas suffisamment à l'avance ... ou la participation est là ... mais ne reflète pas la prise de décision. .. À la fin, les développeurs sont blâmés, vous n’avez pas fourni la fonctionnalité..ou cela se terminera par un changement de dernière minute ... de très longues heures parce que votre maître Scrum ne veut pas s’en prendre à une histoire non terminée.

Abuser ici ... soit une faible participation des entreprises, soit un participant qui n'est pas parfaitement informé, ou un homme d’affaires qui abandonne au milieu du sprint.

1. Tous les projets ne conviennent pas à Agile ... La plupart des gestionnaires ou des maîtres de scrum ne le savent pas. Projets de maintenance .. Un défaut peut être supposé au départ, mais peut être effectué en 8 heures, et accepté dans le sprint. Après avoir passé 4 heures, il s’est avéré qu’il s’agissait d’un autre produit Java / ... le financement, la nouvelle version ou la mise à niveau doivent être approuvés par le service d'ingénierie interne, etc. 5. Rétrospection: seule une poignée de projets Agiles réalise cette étape. Si jamais terminée..Gestion, Scrum Master n'a jamais pris aucune responsabilité pour les histoires ratées.
2. Jumelage .. Beaucoup de développeurs considèrent le jumelage comme un lieu d'abus pour les collègues de travail. Critiquent d'autres conceptions, pratiques de codage.

Agile est définitivement une bonne méthodologie. À moins que votre organisation ne suive pas complètement ou n’ait pas été formée…. Elle est malmenée…. Effets secondaires… plus de 60 heures de travail / semaine, jeu de blâme, moral bas.

Agile est une microgestion déguisée. Il n'y a pas de place pour l'initiative ou la créativité dans Agile, cela a permis de supprimer le plaisir de la programmation pour permettre aux gestionnaires incompétents de garder le contrôle, même sans avoir la moindre idée du point de vue technique.