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

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.

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.

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.

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

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.

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