Est-il acceptable d'avoir des personnes avec plusieurs rôles dans une équipe Scrum?

J'évalue certaines méthodologies de style Agile pour une introduction possible à mon équipe. Avec Scrum, est-il permis de faire jouer plusieurs rôles à la même personne? Nous avons une petite équipe de quatre développeurs et un concepteur Web; nous n'avons pas vraiment de lead (je remplis ce rôle), de testeurs QA ou d'analystes métier, et toutes nos tâches de développement viennent du CIO. Les tests automatisés sont considérés comme une perte de temps totale, et tout se concentre sur la vitesse et non sur la qualité.

Ce qui se passera, c'est que le CIO proposera une tâche de développement (que ce soit une fonctionnalité ou un bug) et la confiera à un développeur (pas à toute l'équipe, à un individu, souvent en privé ou à l'improviste) qui est ensuite devrait le terminer. Le CIO ne rassemble pas d'exigences au-delà de l'idée initiale (et cela nous a mordu auparavant car nous allons implémenter quelque chose uniquement pour découvrir qu'aucun des utilisateurs finaux ne peut utiliser la fonctionnalité, car ils n'ont pas été consultés ni même informés à ce sujet. avant de le développer, et dans une panique on nous dira de revenir sur le changement) mais nécessite de dire / approuver tout ce que nous faisons.

Tout d'abord, un style Scrum est-il quelque chose à considérer pour introduire certaines normes et pratiques? À la lecture, Scrum semble s'appuyer sur un peu plus de confiance et de communication et se concentre davantage sur la gestion de projet que sur le développement, ce dont nous sommes complètement dépourvus car nous n'avons actuellement aucun semblant de gestion de projet.

Deuxièmement, si cela peut fonctionner, est-il déraisonnable pour quelqu'un, disons moi-même, d'agir à la fois comme ScrumMaster et comme développeur? Ou pour qu'un développeur soit également le Product Owner (bien que ce soit probablement le CIO, qui n'est pas un développeur)? Je me rends compte que le Scrum Master et le Product Owner doivent être des personnes différentes mais en même temps, je ne pense pas que nous ayons quelqu'un qui ait les qualités d'un Product Owner (les chances sont que cela se transformerait en "J'ai besoin de toutes ces histoires, je ne se soucient pas de savoir comment, mais faites-le "type d'accord et / ou tout gel serait débloqué sur un coup de tête).

Il me semble que je pourrais avoir besoin de choisir des morceaux de Scrum / XP / Lean pour compenser la façon dont les choses sont faites actuellement, car il est très peu probable que la mentalité puisse être modifiée; par exemple, la programmation par paires ne volerait jamais (vu comme un gaspillage, vous accomplissez la moitié des tâches si vous avez besoin de deux personnes pour tout), TDD serait une vente difficile, mais des cycles courts seraient les bienvenus.

Scrum, Kanban ou toute autre méthodologie Agile est principalement une méthodologie centrée sur des projets de développement logiciel . En d'autres termes, c'est une pratique de gestion de projet par sa nature même.

Même si vous voulez désespérément que vous et votre équipe fassiez du travail de projet, vous constaterez qu'Agile ne fonctionnera tout simplement pas dans votre organisation, car vous ne faites vraiment pas de travail de «projet» ou ne vous consacrez pas en équipe à un "engagement de projet".

Vous pouvez organiser un mini-projet autour d'une fonctionnalité complexe, mais en réalité, vous n'avez aucun lien avec les analystes commerciaux ou les utilisateurs finaux, alors comment pouvez-vous vérifier que vous livrez des User Stories lorsque vous n'avez aucun moyen de vraiment savoir de quoi il s'agit? veut?

Votre seul intervenant est votre patron, et il s'assure essentiellement que votre équipe n'existe pas pour servir les autres intervenants du projet, vous existez en équipe pour le servir et répondre à ses besoins quelle que soit la façon dont cela affecte les autres intervenants.

En plus de tout cela, il confie des tâches individuelles à des individus et redéfinit probablement les priorités immédiatement alors qu'il décide qu'elles devraient aller. Vous ne pouvez pas fonctionner dans une méthodologie de projet Agile si les ressources individuelles du projet vont être redéfinies en priorité à un moment donné, ou si le sprint sera suspendu.

Ce n'est pas censé fonctionner comme ça

Un sprint est un engagement de toute l'équipe à fournir un sous-ensemble d'histoires d'utilisateurs à une date spécifiée. Une fois démarré, un sprint doit être achevé avant que toute nouvelle hiérarchisation ou modification ne se produise. Comment un projet est-il censé être géré lorsqu'il est exécuté dans un environnement ad hoc aussi chaotique?

Vous ne travaillez pas dans un environnement propice aux méthodologies de gestion de projet Agile. Vous ne travaillez même pas dans un environnement propice aux méthodologies Waterfall. Vous travaillez dans une monarchie et vous n'êtes que des pions rois faisant ses enchères et éteignant des incendies.

Ce n'est pas la composition d'une équipe de projet de développement logiciel.

Donc, d'une manière très obscure, je réponds à votre question en disant que dans votre situation, peu importe que les individus jouent plusieurs rôles. Vous avez des problèmes beaucoup plus importants. Vous demandez comment enlever les taches d'eau des tapis sur une maison sans toit.

Comme je l'ai noté ici , si le Scrum Master ou le Product Owner ont des tâches exécutables, ils sont également membres de l'équipe.

Cela dit, vous allez avoir de sérieux problèmes pour devenir Agile à moins d'avoir un réel adhésion à la fois de votre CIO et de vos clients. Votre DSI est-il prêt à respecter le fait qu'il ne peut pas ajouter un élément de travail au milieu du sprint, mais devra attendre le prochain? Est-il disposé à prioriser les éléments à développer? D'après ce que vous avez écrit, il semble qu'il possède ce que vous faites et devrait donc être le propriétaire du produit. S'il ne veut pas, vous ne réussirez pas plus que vous ne le faites actuellement.

Scrum pourrait être une bonne solution pour votre problème de l'attribution du travail par le CIO à un développeur ad hoc, mais uniquement si le CIO adhère au processus. Je soupçonne que votre CIO n'aimera pas être sous contrat direct. Mais si vous pouvez faire en sorte que le DSI adhère à l'idée de lui écrire des histoires d'utilisateurs et de les hiérarchiser, il pourrait trouver cela un moyen très efficace de gérer. Mais cela commencera par vous convaincre de votre CIO de s'en tenir au processus.

Scrum est quelque chose à considérer, bien sûr. Cependant, il y a quelque chose à dire pour obtenir tous ceux qui sont impliqués sur la même page et accepter quelques modifications de la structure ainsi que d'obtenir au moins quelques sprints pour résoudre divers problèmes initiaux dans l'utilisation de cette méthodologie.

Le Product Owner doit être en dehors de l'équipe de développement car il y aurait sinon un mauvais conflit d'intérêts présenté ici. Le Scrum Master peut être un développeur car il n'y a pas aussi mauvais conflit dans ce cas.