Comment présenter Agile à une équipe qui utilise des méthodes rigides non Agile?

16

Considérez une entreprise qui est fièrement certifiée pour une méthodologie non agile, l'utilise comme argument de vente auprès de ses clients pour démontrer sa responsabilité.

Comment allez-vous introduire progressivement Kanban ou Scrum sans casser tout leur système et leur donner encore la certitude qu'il peut toujours être aussi responsable / vérifiable ?


Je sais que cela est peut-être lié à " Comment introduiriez-vous une méthodologie agile comme Scrum ", mais ici, je me demande comment contourner / contourner le fait que la société impose une certaine façon de gérer le SDLC sous la fausse prétention que c'est la seule façon d'avoir une piste d'audit.

haylem
la source
Qu'est-ce que la certification? Est-ce ISO-9000?
Robert Harvey
1
Vous êtes un peu léger sur les détails; si la certification nécessite un certain niveau minimum d'artefacts pour rester certifié, et que l'entreprise a déjà mappé étroitement ces artefacts à votre processus de développement de manière à minimiser l'impact, il n'y a pas de solution.
Robert Harvey
@Robert Harvey: un ISO-9001 serait un bon exemple. Tout ce qui a besoin d'exigences vérifiables et de spécifications de tests et de traçabilité pour les propriétaires de documents et de tâches.
haylem
@Robert Harvey: Oui, mais une cartographie doit simplement être vérifiable. Pour autant que je sache, la plupart des suiveurs de problèmes / défauts / tâches / bogues peuvent faire partie d'une piste d'audit car ils enregistrent la propriété d'une tâche au fil du temps. Et peut même être lié, dans le cas du développement de logiciels, à un SCM pour le suivi des numéros de révision. De plus, vous pouvez utiliser votre tracker pour identifier également les exigences, les spécifications f et les ID de test et obtenir vos matrices de traçabilité à partir de là.
haylem
@Robert Harvey: en particulier, le suivi d'un ISO-9001 n'est pas si difficile à obtenir et à maintenir, mais il semble souvent être considéré comme quelque chose qui doit être horriblement redondant et verbeux.
haylem

Réponses:

12

Je pense que c'est un mythe que les équipes de projet Agile ne documentent pas leurs applications et c'est le premier point de résistance que vous obtenez dans les entreprises qui sont certifiées pour avoir la meilleure documentation selon leurs normes.

Je travaille dans une entreprise certifiée ISO-9001, mais nous faisons également des Scrums sur un grand nombre de nos projets. Dans notre cas, le changement est venu des chefs de projet (c'est-à-dire des personnes assez âgées) et c'est pourquoi il est adopté - par opposition à un chef de projet ou développeur essayant de pousser ce changement.

Une pratique utile que nous suivons est Documenter suffisamment mais en continu . Cela signifie évidemment que nous ne suivons pas tous les modèles prescrits pour le projet, mais il y a une compréhension consciente et un accord sur les sections / documents nécessaires par rapport à ceux qui ne sont que des frais généraux inutiles.

Vous devez ensuite socialiser ce point de vue et obtenir l'approbation du groupe Qualité ou de la division Normes ou de tout autre nom.

Le principe Agile est une documentation «juste suffisante». Pouvez-vous essayer de le pousser du client pour exprimer à l'équipe combien est juste suffisant? Le chef de projet pourrait parler au client et comprendre quelles sont ses attentes et ses besoins organisationnels, puis documenter la décision et répondre à ces attentes. Si c'est assez bon pour eux (c'est-à-dire les clients payants), cela peut être ce que vous suivez.

S'ils pensent qu'Agile ne se transforme pas en projets de grande envergure, convainquez-les - par décomposition et efforts parallèles.

Dans une grande organisation, le contrôle et la surveillance de grands programmes sont réalisés en gérant des bureaux de suivi de projet (PMO) qui effectuent une planification conventionnelle pour les coûts / la comptabilité / la gestion des ressources, etc. (le tableau de combustion SCRUM pour un). Ils doivent savoir comment des techniques telles que l'intégration continue les aident plus tôt que tard, et il est donc préférable pour la productivité de chacun d'éliminer les documents généraux.

Agile est un ensemble de compétences qu'une équipe peut apprendre et qui est largement orthogonal à nos compétences techniques traditionnelles. Mais si vous ajoutez cela à leurs compétences existantes, vous pouvez bien sûr devenir une équipe plus efficace. Les réunions quotidiennes (c.-à-d. Les réunions Scrum) ne seront pas possibles du jour au lendemain - mais auriez-vous des réunions d'équipe régulières (disons toutes les deux semaines) à l'heure actuelle? Je dirais commencer par convertir ceux-ci en suivant l'agenda de la question Scrum (pas trop sournois;) et expliquer à l'équipe plus large pourquoi cette approche peut fonctionner et ne signifie pas une documentation laxiste / des normes médiocres ou tout autre mythe.

JoseK
la source
Alors que d'autres réponses étaient bonnes, je pensais que la vôtre était celle qui essayait le plus de répondre à la question spécifique, pas seulement de donner des conseils généraux sur l'utilisation de l'agile et d'essayer de comprendre pourquoi nous voulions l'utiliser. Bonne réponse. Merci.
haylem
@haylem: content d'avoir aidé. dans notre cas, nous avons nommé un membre passionné de l'équipe Agile Champion pour faciliter la transition. Il nous a tous fait prendre conscience de beaucoup de ces choses. Vous pourriez peut-être vous porter volontaire pour un tel rôle.
JoseK
8

Je séparerais Scrum de Kanban en premier.

Avec Kanban - et voici une assez bonne source sur la façon de le faire correctement - le principe est que vous respectez le processus de sortie lorsque vous commencez. Kanban n'est pas ce avec quoi vous remplacez le processus existant, mais ce que vous lui appliquez. Cartographiez, visualisez et configurez certaines conditions d'amélioration progressive.

Scrum est fondamentalement différent dans le sens où c'est quelque chose qui va déplacer le processus existant.

Une équipe habituée aux cycles SDLC en cascade de 12 mois (ou plus) va avoir du mal à passer à Scrum. Un raccourcissement progressif du cycle à des trains de lancement de 6 ou 3 mois avec une portée plus petite pourrait être une étape intermédiaire utile.

azheglov
la source
J'aime l'idée de respecter le processus existant. Cependant, je ne suis pas sûr du raccourcissement progressif, il peut causer de la douleur sans beaucoup d'avantages. J'irais pour le buy-in de la haute direction, puis quelques semaines pour habituer les gens au processus agile des mêlées quotidiennes et des itérations de deux semaines.
Michael Durrant
6

Comme toute nouvelle chose que vous tenterez de présenter à une organisation, vous serez confronté à une forte opposition. Êtes - vous prêt à être critiqué et être le responsable si elle échoué? Vous devez être une personne forte. C'est le prix à payer lorsque vous vous exposez.

  • Demandez-vous pourquoi vous souhaitez utiliser Scrum . Avez-vous besoin de résoudre un vrai problème?
  • Assurez- vous que VOUS y êtes attaché , car personne ne le fera pour vous. Vous serez le propriétaire de la chose. Au moins jusqu'à ce qu'il apporte des effets positifs dans l'organisation
  • Entraînez-vous . Les livres et Internet ne suffisent pas. Allez d'abord à un cours, ou vous augmenterez considérablement vos chances d'implémenter Scrum de manière incorrecte. Ce qui conduira probablement votre équipe à de moins bons résultats qu'auparavant
  • Vendez-le d'abord à l'équipe . Vous devez avoir leur plein soutien, évidemment
  • Ne proposez pas de changement, proposez un test . Et considérez-le comme ça. Scrum peut ne pas convenir à votre organisation (ou à votre équipe)
  • Trouver un sponsor dans le top management

la source
+1: "Demandez-vous pourquoi vous souhaitez utiliser Scrum. Avez-vous besoin de résoudre un vrai problème?": Très bon point. Avant d'introduire une nouvelle façon de travailler, il faut se demander ce qu'elle essaie de résoudre. Malheureusement, l'introduction de SCRUM (ou de toute autre méthode) pour résoudre des problèmes inexistants ne fera que créer des frais généraux et réduire la productivité au lieu de l'augmenter (je parle d'expérience directe).
Giorgio
3

C'est presque exactement ce qui s'est passé dans notre entreprise. Nous avons suivi des méthodes strictes et non agiles. Lorsqu'un nouveau Lead Technical Manager a rejoint, qui avait une certaine expérience avec SCRUM , il a pensé qu'il serait bon de l'essayer.

La façon dont nous l'avons fait, a été de prendre un petit groupe de développeurs (et d'analystes) pour former une équipe pilote SCRUM. Nous avons suivi une méthodologie SCRUM stricte pendant environ 4 mois, après quoi l'entreprise a réfléchi à ce que nous avons fait, comment nous l'avons fait, analysé en données (vous savez, tout ce que le BA doit faire).

Ce qu'ils ont découvert, c'est que le pilote a été un grand succès. Ils ont donc constitué une autre équipe qui suit Kanban, et eux aussi ont été un grand succès. Je pense qu'il est question que les autres développeurs forment également des équipes SCRUM / Kanban.

Je pense que le pilote a été crucial. Il donne au côté strict du temps de l'entreprise pour évaluer et voir que cela fonctionne en premier.

Nico Huysamen
la source
1

Je suis un coach Agile et l'une des clés pour changer les initiatives est l'adhésion à tous les niveaux! Cela inclut les cadres, les équipes de développement, les managers, etc. Avant d'annoncer un gros ou petit effort de changement, je vous suggère de faire venir des individus avec vous en premier. Faire cela à travers une conversation à la troisième personne est le moyen le plus simple pour les individus de commencer à lancer de nouvelles idées. Qu'est-ce que la troisième personne? Un blog, une vidéo youtube, une présentation, ... etc. De cette façon, ces gens peuvent commencer à proposer leurs propres idées et avec votre influence, ils se joindront à vous avec une initiative de changement.

Voici deux vidéos astucieuses que j'ai utilisées pour susciter l'intérêt à tous les niveaux de la chaîne alimentaire.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI

KanbAnimation
la source
+1 pour le buy-in, en particulier compte tenu des commentaires dans la question montrant un manque de buy-in.
Michael Durrant
@KanbAnimation: Je pense que vous devriez d'abord vous demander si SCRUM est bon pour l'entreprise dans laquelle vous essayez de l'introduire. (D'après mon expérience directe) SCRUM n'est pas meilleur pour toutes sortes de projets et son introduction ne rend pas toujours une entreprise plus efficace. Convaincre les dirigeants (qui pourraient ne pas avoir les connaissances techniques nécessaires pour comprendre les conséquences) d'introduire SCRUM pourrait à long terme nuire à l'entreprise si SCRUM n'était pas bien adapté au type de projets qu'ils faisaient.
Giorgio