Équipes Scrum vs équipes organisées traditionnellement [fermé]

Question

Pour ceux d'entre vous qui ont commencé à utiliser Scrum dans vos équipes de développement: avez-vous maintenu les équipes traditionnelles ou en avez-vous créé de nouvelles? Au sein de notre organisation, nous sommes divisés en bases de données, développement de produits et développeurs frontaux (simplifiés!).

Je voudrais savoir si d'autres personnes ont réellement réorganisé la structure de leurs équipes en raison de la mêlée ou si vous avez formé des équipes de projet dédiées (?) combinant, par exemple, des groupes de travail. une personne de chaque " ancien " équipe.

Answer 1

Je ne peux même pas imaginer comment la mêlée pourrait fonctionner si vous mainteniez vos rôles en silo. Dans Scrum, nous créons des coupes verticales dans le produit, de sorte que chaque fonctionnalité fournie lors d'un sprint nécessite toutes les compétences que vous avez mentionnées (plus un contrôle qualité que vous n'avez pas fait connaître). Comment pourriez-vous créer une collaboration continue et inciter les gens à participer au sprint s'ils ne faisaient pas tous partie de la même équipe? Cela semble être le moyen le plus probable de se terminer par "Scrumfall". pour moi. Je ne suis en aucun cas un expert, mais il me semble que le moyen le plus sûr d’échouer chez Scrum est de le considérer comme une solution de gestion de projet plutôt que comme un changement organisationnel complet. Sa culture au coeur.

Pour répondre à votre question sur les "généralistes". La réponse facile est que, si certaines personnes ne peuvent travailler que sur certaines choses, vous créez de gros goulots d'étranglement gras pour arriver à faire. Avec les spécialités, vous êtes toujours contraint à chaque étape par le manque de ressources pour travailler sur quelque chose. Dans le sprint 1, vous pouvez avoir beaucoup de travail de base de données à faire là où il y a plus que ce qu'un dba peut faire. Mais ensuite, dans le sprint 5, où le modèle de données n’a pas du tout changé, votre DBA restera assis à rester ennuyé. Il devient presque impossible en planification de sprint de s’engager dans un délai raisonnable si vous devez vous répartir et attribuer au niveau de la tâche par rôle au lieu de simplement saisir le prochain ensemble de fonctions prioritaires qui correspond à la vélocité de votre équipe. Le modèle généraliste apportera inévitablement une valeur commerciale à long terme. Vous risquez de ne pas le voir tout de suite avant d'avoir atteint la pollinisation croisée.

Je vous avertirais que si vous êtes déjà dans des groupes silo-ed par rôle, vous devez être très prudent dans votre réorganisation agile. Beaucoup de gens ne sont pas prêts et ne veulent pas être prêts à perdre leurs titres spéciaux et à devenir simplement membres de l'équipe. Je pense que vous devriez presque toujours vous attendre à un certain chiffre d'affaires.

Answer 2

Il est préférable que, dans le développement Scrum / Agile, la plupart des membres de l’équipe soient «généralistes», ce qui signifie que tout le monde peut raisonnablement assumer n'importe quel rôle, de sorte que tout le monde puisse supprimer des éléments de l’arriéré au fur et à mesure que personne ne les attend. autres.

maintenant, ce n'est peut-être plus le cas dans votre situation actuelle, mais des activités telles que la programmation par les pairs et les réunions informelles pour voir où les gens rencontrent des problèmes et pour améliorer la pollinisation croisée des connaissances aideront à atteindre cet objectif.

Answer 3

Dans mon entreprise, nous créons une équipe multidisciplinaire temporaire pour chaque projet. Nos équipes existantes sont toujours là, mais il est vraiment important que nous ayons des équipes interfonctionnelles pour la mêlée.

Answer 4

Nous essayons généralement de mélanger un peu pour acquérir des connaissances entre équipes, mais nous travaillons pour la plupart sur nos spécialités. Mais au fur et à mesure que le projet avance, nous pouvons plus facilement aider les différentes équipes

Answer 5

Lorsque je travaillais pour mon ancien employeur, la société a réorganisé l'ensemble de l'organisation de développement et de la gestion des produits. Ils ont mis des ingénieurs, qa et analystes dans chaque équipe. La scission était principalement verticale / fonctionnelle à quelques exceptions près. Ces exceptions étaient une erreur - l'architecture verticale ne convenait pas, car elle était vraiment horizontale. Je pensais que les équipes interfonctionnelles fonctionnaient bien. Dans votre cas, les services de base de données et les services frontaux doivent si possible fusionner avec les autres, et de nouvelles verticales spécifiques à votre produit peuvent être créées

Answer 6

Nous avons divisé notre équipe entre le développement de nouveaux produits et la maintenance de produits existants, avec la possibilité pour tout développeur de passer d’un sprint à l’autre entre les sprints.

Answer 7

Je pense que nous avons maintenu l'équipe traditionnelle, du moins pour le moment. Il existe quelques autres équipes au sein de la branche des applications du département des systèmes d’information où je travaille, bien que celles-ci aient été installées juste avant d’entrer dans Scrum.

Il y a un gros projet sur la plupart d'entre nous qui utilise Scrum et l'équipe semble bien évoluer. Nous avons de nouveaux outils et processus qui semblent nous avoir beaucoup aidés et nous ont donné une idée de "génial". espérons que nous passerons aux autres équipes.

En ce qui concerne les modifications apportées à une base de données, les développeurs peuvent modifier l’environnement de développement, puis transmettre le script à un administrateur de base de données lorsqu’il est prêt pour la production. Pour les modifications apportées au réseau, il existe des responsables de l'infrastructure qui gèrent cela et qui configurent initialement un serveur en termes de système d'exploitation, de réseau, de mémoire, de disques durs, etc.