Sceptique dans une équipe Scrum

Mon entreprise est récemment passée à une méthode de travail agile et, dans le cadre de celle-ci, nous avons commencé à utiliser SCRUM. Bien que je sois très à l'aise avec cela et que je pense que cette méthode est supérieure à une méthode traditionnelle, certains de mes coéquipiers ne partagent pas la même opinion. En fait, ils sont très sceptiques à propos de "toutes ces choses agiles" et ne les prennent pas au sérieux. À titre d'exemple, l'un des coéquipiers est toujours en retard aux réunions et ne s'en soucie pas vraiment. La direction de l'OMI essaie de ne pas le remarquer (peut-être parce que c'est nouveau et qu'il faut du temps pour que les gens s'y habituent).

Ma question est de savoir comment résoudre ce problème sans soulever de conflit au sein de l'équipe?

Face à un sceptisme extrême, j'essaye quelques choses:

1.) Je démonstration des techniques telles que TDD, déploiement continu, Paire programmation, la collecte des besoins avec vos utilisateurs, itérations courtes etc. Je n'appeler ces techniques agiles ou harpe au sujet du Manifeste Agile (je harpe sur le logiciel Artisanat - mais c'est différent; p). Je montre simplement aux membres de l'équipe des outils et des techniques utiles qui leur facilitent la vie. Ils ont tendance à sauter dans le train agile une fois qu'ils en voient les avantages au jour le jour.

2.) Je n'échange pas immédiatement vers une méthodologie SCRUM (ou autre) complète. Il est toujours préférable d'introduire de petits aspects d'Agile à la fois.

3.) Je suis d'accord avec les sceptiques (jusqu'à un certain point). Agile n'est pas une solution miracle et SCRUM, Kanban, Lean, etc. ne sont pas non plus une solution miracle. Au lieu de cela, je travaille avec eux pour voir quels aspects pourraient leur être profitables immédiatement (un serveur CI est généralement une évidence), puis j'essaie le reste "Laissons les stand-ups pendant une semaine, puis passez en revue".

Comme toute méthodologie, SCRUM et d'autres doivent réellement travailler avec l'équipe et l'organisation, pas les aliéner.

Donc, pour passer directement à votre question. Soulevez-le avec l'équipe:

"Je suis aussi un peu sceptique à propos des stand-ups, mais je pense qu'en tant qu'équipe, nous devrions lui donner un bon coup d'essai pendant 1 semaine (pas d'excuses!) Et ensuite le revoir pour voir si cela a fonctionné pour nous. Que font les gens pense?"

Un cas typique de Scrum mal implémenté .

Scrum a été imposé à l'équipe. L'équipe (entière) ne l'a pas choisie.

Lorsque vous souhaitez l'implémenter, vous devez avoir un soutien total de l'équipe et de la direction, sinon cela ne fonctionnera pas du tout.

La résistance au changement est votre ennemi ici.

Je vous suggère fortement de recommencer et de présenter Scrum à l'équipe et de la laisser poser des questions.

Si vous ne vendez pas l'idée, n'essayez pas de les forcer à utiliser une méthodologie dont ils ne veulent pas. Ils feront tout pour le saboter. Arriver tard dans les stand-ups quotidiens est l'un des comportements que vous aurez.

Veuillez noter que Scrum peut ne pas être recommandé pour votre entreprise. Les seules personnes qui peuvent répondre à cette question sont les personnes qui travaillent à la base. L'équipe .

Il se peut que le concept de réunions quotidiennes ne s'applique pas très bien à ce qu'une personne fait. Ces réunions ne sont pas gratuites.

Si ce que vous faites nécessite beaucoup de concentration à long terme, comme les mathématiques, les réunions peuvent vous dérailler et être frustrantes. Je travaille avec quelqu'un comme ça, qui préfère se rencontrer sur une base hebdomadaire, ce qui est parfaitement raisonnable.

En fait, pour être honnête, si j'étais dans votre équipe de programmation, je serais probablement aussi sceptique! J'ai vu une longue lignée de méthodologies qui étaient censées révolutionner les choses et faire en sorte que les projets arrivent à temps, dans les limites du budget et sans bug. Ce n'est que la dernière. Pourquoi devrais-je croire l'huile de serpent? Il y a 10 ans, les mêmes personnes fouettaient autre chose, dans quelques années, quelque chose de nouveau arrivera. Ne vous méprenez pas, je pense que certaines des nouvelles méthodologies apportent des idées utiles. Malheureusement, ils apportent aussi beaucoup de dogmes et d'idées stupides.

Est-ce vraiment important s'il ne monte pas à bord? Attribuez-lui simplement quelques tâches de programmation et laissez-le faire comme il l'entend. Si son travail est satisfaisant, qu'il le soit. Si son travail n'est pas satisfaisant, remplacez-le. Pourquoi est-il si important pour les gens de suivre la mêlée?

Au fil des ans, j'ai vu beaucoup de bons programmeurs quitter ou s'énerver parce que leur manager continuait à introduire de nouvelles méthodologies. Ils veulent juste coder et faire le travail. Croyez-moi dans quelques années, vous maudirez la mêlée et sauterez sur la dernière mode.

Si vous faites de l'agilité, vous devriez avoir un backlog à partir duquel vous travaillez. Utilisez la mêlée pour distribuer des affectations à partir du backlog.

Les choix (les meilleurs) choix sont choisis en premier au début de la réunion. Lorsque vous arrivez en retard, donnez-lui simplement ce qui reste pour la journée.

Peu importe s'il est le don de Dieu pour la programmation, il obtient la tâche de merde que personne d'autre ne voulait. S'il essaie de réaliser une autre tâche ou de travailler sur autre chose, l'équipe dans son ensemble doit s'appuyer sur lui et le forcer à ne travailler que sur sa tâche «choisie». Vous devriez probablement avoir un maître de build qui peut rejeter ses modifications s'il ne travaille pas sur le travail choisi.

L'équipe devrait également fixer des objectifs et éventuellement une compensation. Vous pouvez voter en équipe pour ne pas récompenser ceux qui ne participent pas. Cela dépend du niveau de propriété que votre direction a accordé à votre équipe agile. Rappelez à la direction ceux qui blessent l'équipe et empêchent celle-ci de réussir.

Rappelez-lui que s'il se présente à l'heure, il peut participer au processus.

Les équipes Scrum sont censées s'auto-organiser. Scrum fonctionne également en implémentant une transparence extrême dans tout.

Donc, la réponse évidente est que le Scrum Master appelle une réunion, explique le problème (mais ne vous moquez pas, tout le monde dans l'équipe sait déjà exactement quel est le problème), puis leur dit qu'ils ont 1 heure pour comprendre ce ils vont y faire. Puis il s'assoit dans le coin et garde la bouche fermée.

De toute évidence, il s'agit d'une équipe nouvelle pour Scrum. La clé est donc que le Scrum Master doit accepter la réponse que l'équipe propose. S'il les annule ou impose ses propres idées à la solution, il détruira la confiance dont l'équipe a besoin pour construire avec lui qu'ils sont autorisés à s'auto-organiser. Il est possible que l'équipe décide de ne rien faire.

En tout état de cause, la question doit être examinée lors de la rétrospective Sprint et l'efficacité de la solution proposée peut être discutée.

Éviter les «conflits d'équipe» ne devrait même pas être un facteur du tout.

Renvoyez le coéquipier, il ne provoquera pas de controverse au sein de l'équipe.

Parcourez votre ancien travail, trouvez plusieurs exemples de la façon dont l'approche de la chute d'eau vous a laissé tomber plusieurs fois dans le passé. Présentez ensuite les cas à votre coéquipier. Avec un aperçu du bon sens, il verra la lumière.

La programmation est une activité de précision, donc une personne rare resterait insensible aux faits. Du moins, en théorie.

Qui a pris la décision de changer et pourquoi? Où ces sceptiques ont-ils participé à la décision ou la décision a-t-elle été abandonnée?

Êtes-vous trop rigide et / ou rapide dans la mise en œuvre de vos nouvelles méthodes? Avez-vous sorti de bons produits (pas nécessairement parfaits) en utilisant vos anciennes méthodes? Avez-vous démontré aux sceptiques en quoi cela leur sera bénéfique? Pouvez-vous le démontrer? Ceux qui ont "vu la lumière" ont-ils démontré aux sceptiques en quoi cela profite à eux, à l'équipe et à l'entreprise?

Vous leur demandez probablement de n'accepter tout que sur la parole des croyants. Plus que probable, ces sceptiques ont adopté de nouvelles méthodologies auparavant et aucun avantage n'a jamais été réalisé.

Peut-être pourriez-vous faire un projet ou deux avec seulement les croyants qui y travaillent en utilisant vos nouvelles procédures. Prenez de vraies mesures et démontrez aux sceptiques de réels avantages. Peut-être même mettre en place un peu de concurrence entre les sceptiques et leurs anciennes méthodes et les croyants et leurs nouvelles méthodes.

Bien sûr, que faites-vous si les sceptiques gagnent?

Organisez une réunion d'équipe pour discuter et comprendre pourquoi votre entreprise est passée à SCRUM et demander à tout le monde d'identifier ce qu'ils pensent de SCRUM ajouterait de la valeur au mode de fonctionnement actuel. Parfois, les entreprises effectuent des commutations à tête d'os (j'ai participé à des réunions de mêlée où personne n'écoute vraiment et tout le monde se contente de dire ce qu'il a fait hier et quitte. Ces équipes parviennent généralement à un équilibre comme - "Je ne vous questionnerai pas et vous ne salissez pas avec moi "et se dandiner là-bas. C'est juste une perte de temps), alors prenez ce qui vous convient le mieux.

Les vétérans ont généralement beaucoup de résistance à tout ce qui pourrait changer leur style de travail actuel, vous devez donc vous assurer qu'il y a suffisamment de carottes pour qu'ils puissent sortir de leur inertie. Dans ce cas, j'aurais un 1: 1 avec cette personne ou je ferais de lui le scrum master :). Une fois que vous leur donnez la responsabilité, ils trouveront la paix avec elle ou la supprimeront complètement parce que cela n'ajoute pas de valeur. Les deux sont gagnant-gagnant.