Je pense que d'autres ont déjà fourni de bonnes réponses, mais j'ajouterai la mienne uniquement parce que je pense que votre équipe vient de passer à Scrum et maintenant vous êtes dans une position très similaire à celle que nous avions lorsque nous avons commencé.
Tout d'abord, notre introduction à Agile et plus précisément à Scrum n'a pas été très fluide. Fondamentalement, la direction est descendue et a dit qu'à partir de ce jour, vous feriez Scrum et c'est un processus que vous suivrez tous. Voilà pour People Over Process .
Le processus que nous avons suivi à l'origine (aveuglément, je pourrais ajouter) s'est révélé très similaire à la façon dont vous l'avez décrit. Les gens se voient assigner des tâches, tout le monde est réservé et nous retournons tous à nos bureaux et nous branchons. Ensuite, nous avons une réunion de stand-up ennuyeuse tous les jours.
La clé à réaliser est que Agile, et Scrum inclus, concerne en fait les gens. Lorsque l'équipe entame la planification des itérations, ne laissez pas votre Scrum master (qui est probablement votre manager) vous assigner des heures, des histoires et des tâches. C'est complètement À L'ÉQUIPE. Je pense que pour beaucoup de gens, c'est un concept très difficile à mettre en œuvre car pendant des années auparavant, ils venaient travailler et ils avaient un patron (manager, responsable technique ...) qui assignerait simplement du travail. Ils plongent dans Scrum mais tout le monde (y compris Scrum Master lui-même) continue de fonctionner dans le même mode.
Un jour, vous en aurez assez, alors vous commencerez à lire des livres, des blogs et continuerez à poser des questions comme celle-ci sur l'échange de pile. La prise de conscience que vous obtiendrez est que vous, en tant que développeur et vos coéquipiers, devriez être la force motrice derrière la validation des histoires et l'attribution des tâches. Si vous pensez que vous bénéficierez de la programmation en binôme, créez certainement 2 tâches pour chacun des ingénieurs et affectez-leur deux heures. La seule chose que Scrum Master devrait faire est de mesurer la vélocité par rapport aux histoires terminées que vous avez livrées EN ÉQUIPE lors de l'itération précédente.
Une autre chose qui me dérange est la façon dont les gens sont informés que leur capacité est TOUJOURS 75% du nombre total d'heures, c'est donc ce à quoi ils s'engagent, puis pendant toute la durée de l'itération, ils se plaignent qu'ils ne peuvent pas a) vous aider ou b) ils ne peuvent pas faire la bonne chose parce qu'on leur a assigné trop d'heures. Les gens ne devraient pas être informés du nombre d'heures à engager et ils devraient certainement reculer si le Scrum Master tente de tirer quelque chose comme ça! Tout le monde devrait s'engager exactement avec quoi il est à l'aise. Par exemple, je suis un chef d'équipe et je me retrouve souvent dans une discussion de conception aléatoire non planifiée, ou pour aider quelqu'un avec du code, ou pour résoudre des problèmes étranges, donc ma capacité n'est jamais supérieure à 50%.
Il a fallu à notre équipe 4 cycles de publication pour apprendre à ne pas faire les choses que je viens de mentionner et même si nous nous sommes définitivement améliorés, si vous demandez aux experts, nous ne sommes même pas à moitié agiles. Donc encore beaucoup d'apprentissage à faire.
Mise à jour 1: réponse au commentaire de Cliff
Eh bien vous avez offert vos oreilles alors la voici ...
Vous avez raison, le changement culturel est essentiel, mais ce changement n'a pas besoin de se produire au niveau exécutif. Votre propre chef de groupe peut changer la culture au sein de votre équipe et vous isoler des BS d'entreprise avec lesquels il doit faire face. Ce que vous décrivez, c'était EXACTEMENT de nous de 2007 à 2010. Notre équipe (et d'autres équipes également) a floppé version après version. Dans l'une des versions utilisant le «processus pour être agile» de la direction, nous parvenons à ce que 9 personnes produisent le travail qui serait généralement effectué par une seule personne et cela nous a pris deux fois plus de temps. J'avais tellement de temps libre que j'ai même mis à jour mon CV.
Ensuite, j'ai eu une conversation avec mon patron et lui ai expliqué toutes ces choses à quel point les gens sont agiles et que si vous voulez que nous nous soucions du produit, laissez-nous prendre des décisions qui affectent la façon dont nous travaillons et livrons le produit. Je pense qu'il a décidé d'en faire une expérience, il a fait chaque changement que nous ... enfin, surtout moi-même, mais je parle beaucoup avec le reste de l'équipe, donc 50% de capacité :) ... proposé. Il est possible qu'il ait pensé que s'il faisait tous les changements que nous demandons et que nous échouions toujours, il reviendrait avec un "Je vous l'ai dit" victorieux.
Donc, au cours des 12 derniers mois, nous avons éliminé tellement de choses "stupides" que ce n'est même pas drôle. Nos réunions debout ont en fait un sens maintenant parce que nous travaillons ensemble, pas isolément. Nous détenons toujours (au moins pour l'instant) des parties spécifiques du produit, mais nous entrons également très fréquemment dans le code des autres. Nous effectuons constamment des révisions de code afin que non seulement les membres de l'équipe apprennent d'autres codes, mais qu'ils apprennent également de meilleures techniques de codage et de conception. Nous avons divisé une équipe monolithique et géante "agile" en 3 équipes différentes, la planification et les autres réunions sont donc beaucoup plus courtes et les gens se soucient vraiment d'eux parce qu'ils ne restent pas assis et écoutent des choses qui ne les intéressent pas. JE' J'ai vu des nuits où 4 sur 5 de nos gars (une des équipes) étaient en ligne à 23 heures du soir et personne ne nous a dit que nous devions travailler dur ou ne nous avait jamais forcés à travailler plus de 40 heures. Les gens qui s'en fichaient il y a six mois, sont soudainement engagés et enthousiasmés par le travail qu'ils font. Et tout ce qu'il a fallu à notre manager, c'était de dire: "vous décidez de ce qui est bien et faites ce que vous devez faire et je garderai le BS d'entreprise hors de l'équipe autant que possible."
Cela a commencé comme une expérience (mes soupçons, il ne me l'a jamais dit), mais maintenant notre groupe donne des coups de pied par rapport aux autres groupes de développement du département et nous avons même d'autres développeurs qui essaient maintenant de venir nous rejoindre.
Le plus grand obstacle pour nous depuis que ce changement s'est produit (et toujours un problème aujourd'hui) était le fait que les ingénieurs dans un environnement d'entreprise normal sont comme des souris expérimentales dans une cage. Même lorsque votre manager décide de devenir vraiment «agile» et supprime la cage, tout le monde est dans cette cage depuis si longtemps qu'il ne se rend même pas compte qu'il est libre. Donc, même avec toute la liberté, ils continuent d'agir comme s'ils étaient toujours contraints. Je pense que ce qui aiderait, c'est d'avoir au moins quelques personnes dans l'équipe (comme vous), qui sortent des limites du groupe et cherchent de meilleures façons de faire les choses. Revenez ensuite dans ce groupe et remuez-le un peu.
Dans votre cas, la programmation par paires n'est peut-être pas une solution si vous recherchez une autre force externe pour faire partie de l'équipe et lui dire comment travailler. Au lieu de cela, jetez les règles, asseyez-vous avec eux, sans direction, et demandez-leur ce qu'ils veulent faire? Qu'est-ce qui les rendra heureux? Productif? Identifiez les plus gros problèmes, puis demandez à l'ÉQUIPE quelle devrait être la solution.