Qu'avez-vous vu mal tourner lors de l'introduction de SCRUM?

Quel a été le seul point de défaillance rencontré lorsque votre entreprise a décidé de remplacer les processus actuels par SCRUM?

Pouvez-vous me donner des exemples de choses qui ont vraiment mal tourné lorsqu'une entreprise a essayé de lancer SCRUM? J'aimerais entendre vos anecdotes, quelque chose que vous avez vécu vous-même, le grand échec que vous avez vu venir mais que vous n'avez pas pu empêcher.

J'entends beaucoup de préoccupations concernant la documentation manquante sur les décisions concernant les détails de mise en œuvre, ainsi que sur la taille des histoires et le niveau de détail des histoires.

Le plus gros problème est l'incompréhension. Les échecs courants sont:

• Seule une équipe fait Scrum mais le reste de l'entreprise (y compris les ventes, la gestion, les RH) pense toujours à l'ancienne. Exemples:

  L'interaction continue avec le client et l'implication du client est très importante.

  Les RH doivent comprendre que la performance de l'équipe est plus importante que la performance des individus. KPI doit changer pour cela.

  La définition des fonctionnalités est un processus continu. La définition du projet évoluera au cours du développement grâce aux commentaires des clients. En raison de cette échéance du projet, le budget requis ou l'ensemble de fonctionnalités de résultat peut changer (après approbation par la partie prenante).

  Le changement fait partie du processus.

  L'estimation est un processus continu, vous ne pouvez pas dire au début du projet que vous aurez terminé avec toutes les fonctionnalités (dont beaucoup sont inconnues au début) dans les 5 mois.

  L'équipe est habilitée à prendre des décisions. L'équipe s'engage sur la quantité de fonctionnalités livrées lors du prochain sprint. Cela ne peut être ni exigé ni commandé.

  Le sprint est une zone de sécurité pour l'équipe. Une fois que l'équipe s'engage sur certaines user stories définies, l'engagement ne peut pas être modifié en dehors de l'équipe.

  Une partie de l'ancienne structure organisationnelle n'a pas de sens lors du passage à Scrum. Scrum définit trois rôles: Scrum master, Product owner, team. Il existe d'autres rôles, mais ces trois sont généralement suffisants pour fournir l'application. Le non-sens commun est d'avoir Scrum master, chef d'équipe, chef de produit et un ou plusieurs chefs de projet. Le chef de projet et le chef d'équipe sont des rôles redondants dans Scrum.

• Guy a attribué le rôle Scrum master ne fait pas Scrum master. Scrum master résout les obstacles. Tout ce qui dérange l'équipe est un obstacle qui doit être résolu dès que possible. L'échec le plus courant est d'attribuer ce rôle au développeur sans aucune expérience préalable avec Scrum. Ce rôle remplace partiellement le chef de projet commun, mais Scrum master est sans pouvoir sur l'équipe et Scrum master ne demande aucune fonctionnalité à implémenter. Scrum master protège l'équipe même contre le propriétaire du produit avec des exigences irréalisables.

• Guy affecté au rôle de propriétaire de produit ne fait pas le propriétaire de produit. Le propriétaire du produit a la responsabilité financière du produit. Il est très spécifique et un rôle clé du succès. Le rôle a quelque chose en commun avec l'analytique, le chef de projet et le chef de produit. Le propriétaire du produit recueille et maintient les exigences (généralement sous forme d'histoires utilisateur). Sa responsabilité est de fournir des informations à l'équipe et de définir la priorité des user stories. Il doit être sur place avec l'équipe car la coopération entre PO et l'équipe est continue.
• Changement du nom du processus en Scrum mais en laissant la plupart du processus tel qu'il était à l'ancienne. Le scénario le plus courant est que vous passerez de la cascade à Scrum et le changement le plus significatif est que vous ne faites plus d'analyse et de documentation et que vous dites que vous Scrum.
• Les exigences / user stories manquent dans la définition de done - très commun. Si vous n'avez pas de définition de fait (critères d'acceptation), vous ne pouvez faire aucune hypothèse sur la complexité de la user story lors de la planification du sprint. Si vous ne les avez pas pendant le sprint, vous ne pouvez pas marquer la user story comme terminée car vous ne pouvez pas la valider.
• La qualité est considérée comme facultative. La qualité dans Scrum est un citoyen de première classe. Nous pouvons dire que chaque critère d'acceptation doit être couvert par un test de bout en bout automatisé. Une fois que vous commencez à réduire la qualité et à ajouter des fonctionnalités non testées, vous perdez le contrôle du produit car les fonctionnalités considérées comme terminées peuvent cesser de fonctionner à tout moment en raison de la régression.
• Le résultat du sprint doit être incrémenté (= fonctionnel et testé) pour le produit.

Éditer:

J'ajoute une note importante. Lors de l'utilisation d'une approche agile, le principal objectif est de fournir au client la valeur commerciale la plus élevée le plus rapidement possible. Mais le client (représenté par le Product Owner) décrit quelle est la valeur commerciale. Il n'est donc généralement pas vrai que vous n'avez pas d'analyse ou de documentation lorsque vous utilisez Scrum. Si le client demande une analyse ou une documentation et le marque comme valeur commerciale (par exemple en raison d'un projet à grande échelle ou à long terme qui devrait être amélioré au cours des prochaines années), vous le créerez également. L'approche la plus fondamentale consiste à inclure l'analyse et la documentation dans les critères d'acceptation des user stories. L'analyse dans ce cas est une communication documentée avec le propriétaire du produit d'une manière standardisée.

Le plus gros problème que j'ai remarqué en plus de 10 ans d'XP et de Scrum, c'est quand des équipes qui ne sont pas encore "agiles", décident de "faire preuve de souplesse sur l'agilité" et commencent à le personnaliser, en supprimant certaines parties, etc., sans une compréhension claire de ce que fait chaque partie et pourquoi elle est là.

J'ai vu des équipes réussir plus avec la mêlée quand elles font les choses au début, que les équipes qui changent ce qu'elles ne "reçoivent" pas encore.

C'est alors que vous obtenez des choses comme "premier sprint, nous ferons toutes les exigences. Deuxième sprint tout le design, etc, etc, dernier sprint tous les tests". Aussi connu sous le nom de cascade. Ou même des choses simples comme "asseyons-nous de toute façon, qu'est-ce qui se passe avec cette entreprise de stand-up?".

Quelque chose à voir avec Shuhari ( http://c2.com/cgi/wiki?ShuHaRi ).

Le plus gros problème est toujours l'adhésion. Si aucune équipe ou personne clé n'a adhéré (gestion de projet, assurance qualité, développement, etc.), l'échec est presque assuré.

Un autre problème connexe est en fait de faire prendre conscience à tout le monde de ce qu'est la mêlée réelle et de ce qui ne l'est pas.

J'ai vu des environnements où la gestion de projet a réellement pris cela comme un ticket pour venir directement aux développeurs avec des changements et s'attendre à ce que cela se fasse demain, car nous utilisons le nouveau processus génial. Quiconque a été dans cette situation ou dans d'autres tentatives infructueuses de mise en œuvre de Scrum et a un goût amer dans la bouche. Ces personnes essaieront parfois de dérailler le projet également.

Un autre problème que j'ai vu est celui des réunions debout. Vous aurez toujours le gars qui veut s'asseoir lors d'une réunion de stand ... "J'ai un mauvais dos" ou autre chose. Il semble toujours que c'est le même gars qui n'a aucune idée de l'objectif derrière le standup et ne se taira pas sur la politique ou ce qu'il a fait ce week-end. J'ai trouvé que les réunions debout sont la clé d'une communication efficace. Il est important de ne laisser personne empoisonner ces réunions.

En essayant de faire toute l'analyse du code que nous développions dans le même sprint, nous le codions.

Nous avons déménagé à la mêlée il y a peu de temps, et franchement, la direction qui la dirigeait a traité chaque mêlée comme un processus de cascade de 2 semaines. Il y avait une telle adhésion aux règles de la mêlée qui est devenue un processus en soi!

C'est le problème que je trouve, toutes les méthodologies agiles devraient être axées sur la flexibilité pour travailler efficacement de la manière qui fonctionne pour vous. Pas la façon qui est proscrite par les processus. Par exemple, nous avons eu 2 semaines de mêlée, et une équipe a dit qu'elle sentait que 2 semaines n'étaient pas suffisantes pour faire du bon travail (pas avec le temps d'arrêt causé par la fin de la démo de la mêlée et la révision des exigences initiales) alors ils voulaient passer à 3 la semaine. Choc d'horreur! La direction a refusé car elle avait décidé que 2 semaines par mêlée étaient idéales et cela était désormais documenté dans les procédures qualité.

Scrum est la moins agile des méthodes agiles, c'est peut-être pourquoi elle a été si populaire - elle est plus facile à vendre à la vieille garde. vous êtes censé supprimer des choses que vous n'aimez pas, mais je ne pense pas que cela se produise. Mon conseil est de choisir une solution plus flexible et moins basée sur des règles et d'ajouter des règles dont vous avez besoin à la place. Je préfère Crystal à cause de cela.

En fin de compte, rappelez -vous juste le manifeste agile à moitié arsed .

Le plus gros problème est que votre client doit également accepter le processus SCRUM et devenir agile également. La plupart des clients veulent entendre cela au début du projet:

• Combien cela va coûter
• À quoi cela ressemblera
• Quand ce sera fait

Cela semble raisonnable, mais c'est absolument incompatible avec l'agilité. Vous devez expliquer à votre client pourquoi l'agilité est bonne pour lui au lieu de la cascade.

Nous avons eu deux gros problèmes lors de ma première visite à SCRUM:

1) Nous n'avions pas vraiment de propriétaire de produit. Notre patron a dû jouer ce rôle parce que personne qui aurait dû être propriétaire du produit n'accepterait de le faire. Ce genre de sertissage parce qu'il ne connaissait pas toujours les réponses.

2) Nous ne savions pas bien comptabiliser les composants externes. Nos premiers sprints ont consisté à obtenir des tests entièrement automatisés et à fonctionner, et nous avons rencontré à plusieurs reprises des problèmes d'automatisation des simulateurs que nous utilisions. D'une manière ou d'une autre, nous ne nous sommes jamais mieux rendu compte que cela allait se produire.

Le problème majeur que je rencontre dans mon projet est que la collecte des exigences a lieu après que nous ayons estimé pour le prochain sprint. Nous estimons en fonction des critères d'acceptation. Lors de la collecte des exigences, nous constatons que le courant alternatif finement réglé est beaucoup plus important, de sorte que la tâche initialement estimée à 8 heures est maintenant vraiment de 24 heures! Alors, puis-je modifier mon carnet de sprint et réviser les estimations et réduire mes histoires? Non monsieur! Agile demande que vous ne puissiez pas modifier le backlog de sprint! C'est ce que dit mon TL. Je ne devrais donc pas également coder selon les critères d'acceptation d'origine pour lesquels j'avais estimé le temps à 8 heures! Dieu! Non! Vous ne pouvez pas faire ça! Ce ne serait pas Agile, n'est-ce pas!