Des moyens efficaces pour introduire l'agilité sur le lieu de travail?

D'après votre expérience (anecdotique ou autre), quels sont les moyens efficaces pour introduire Agile dans une organisation ou une entreprise non agile?

MISE À JOUR: Quelqu'un peut-il parler de cas où vous avez essayé d'introduire Agile mais que vous avez été "abattu"? Aussi, avez-vous maintenant une compréhension rétrospective pourquoi vous avez été "abattu"?

C'EST DIFFICILE MAIS PAS IMPOSSIBLE. Sauf si vous vivez au paradis. Pour des actions spécifiques que vous pouvez entreprendre, je vous recommande vivement de vous procurer un exemplaire de Fearless Change.

• D'abord obtenir le soutien de la direction . Si vous ne le faites pas, rien d’autre ne compensera cela. Si le niveau supérieur correspond à «La date limite est hier…», «Week-ends de travail pour les 3 prochains mois», «Pourquoi écrivez-vous des tests alors que vous devriez être codage? .. nous pouvons tester plus tard. Le dodo ne volera tout simplement pas.
• Voyez si la culture de votre organisation convient à l'agilité. C’était quelque chose qui m’avait manqué. Pour reprendre une phrase du livre ... Le processus sera plus facile et plus rapide si la culture soutient et encourage de nouvelles idées, donne aux personnes le temps d’apprendre et de faire de nouvelles choses, est suffisamment patient pour soutenir les innovations avec avantages à long terme et ne considère pas l'échec comme une condamnation à mort
• Les gens : Identifiez les innovateurs: les utilisateurs précoces: la majorité précoce: la majorité tardive: le ratio des retardataires. Les trois premiers sont votre public cible au départ .. devrait se situer autour de 30 à 40% ... ce qui vous donnera la masse critique pour démarrer. Le problème, c’est que Agile braque les projecteurs sur les éléphants dans la pièce… les carences et les problèmes deviennent facilement visibles… si vous vivez dans un endroit qui a connu une «explosion de bozo» (pour reprendre les termes de Guy Kawasaki) , le changement serait vraiment lent et douloureux .. voire pas du tout. Nous avons tendance à penser que si une idée est bonne, elle sera acceptée. Pas vrai. Beaucoup de raisons sociologiques lèvent la tête.
• Ensuite, n'essayez pas trop de choses à la fois. Prends-le lentement ... doucement . L'astuce consiste à utiliser une approche de type refactoring-legacy-code. Trouvez de petites blessures ici et là et corrigez-les avec un bandage agile. Assurez-vous que les gens comprennent la pratique et les avantages et qu'ils devraient les adopter au fil du temps. Tout ne va pas coller, mais bientôt cela va mieux dans l'ensemble. Combien de temps dépend d'un certain nombre de variables dont certaines sont hors de votre contrôle.
• C'est un énorme investissement personnel pour y arriver . Ré-examinez si vous êtes prêt à prendre cet engagement et à traverser les hauts et les bas qu'il apporte. Vous devrez peut-être aussi passer le flambeau à quelqu'un d'autre ou à un supérieur. Soyez prêt à renoncer à la propriété de changement pour le plus grand bien. Ne tombez pas dans le syndrome «C'est mon bébé».
• L'agilité est différente pour chaque équipe, chaque organisation . Tout ce que vous lisez / proposez ne fonctionnera pas. Laissez l'acceptation vous guider vers les éléments qui fonctionneront dans votre scénario. Trouvez d'autres moyens qui compensent les pratiques qui ne s'enracinent pas.

J'espère que cela a du sens… comme vous l'avez peut-être deviné, je suis dans ce domaine depuis un certain temps :)

Écoutez l'équipe, la direction, les parties prenantes et recherchez des indices. Ils ressentent probablement de la douleur dans un certain nombre de domaines directement abordés par Agile.

S'en tenir à des suggestions qui peuvent directement atténuer ces douleurs. "Vous ne pouvez pas guérir ce que vous ne pouvez pas sentir" - pour ainsi dire.

Cela prend un temps fou, mais la confiance est primordiale. Forts de leurs succès passés et de la confiance de votre équipe et de votre responsable, ils se tourneront vers vous au moment de prendre des décisions.

J'ai vu cela se produire de mes propres yeux, après des années de frustration en essayant d'inciter les gens à changer la façon dont nous fournissons les logiciels. Et alors que j'ai des succès maintenant, je suis loin d'être complet. Il y a des tonnes de domaines à améliorer, et je réussis actuellement le mieux avec l'introduction de petits changements qui traitent directement d'un type de douleur que nous ressentons.

Enfin je dirais juste être très empathique. J'ai commis l'erreur de rejeter la plupart des idées avant de les avoir vraiment réfléchies car je n'en avais pas entendu parler dans "XYZ agile book". Écouter votre équipe et essayer de mettre en œuvre certaines de leurs suggestions ira un long chemin.

Bonne chance!

En ignorant les aspects techniques, nous avons constaté qu’il était crucial de trouver un groupe au sein de l’organisation qui puisse souscrire aux méthodologies Agile et fournir un «banc d’essai». De nombreuses personnes de notre entreprise ne comprenaient pas la terminologie Agile, étaient confondues par les termes et les processus, et la crainte était générale.

Mon groupe de recherche était très intéressé à essayer de faire fonctionner Scrum (avec plusieurs autres méthodologies de type Agile). Notre intérêt nous a permis de former un banc d'essai au sein de l'entreprise pour tester les différents éléments. Nous avons d'abord beaucoup enseigné - discussions avec les gens dans le couloir, présentations à l'intention de dirigeants d'entreprise, etc. Nous n'avons pas insisté - nous avons éduqué. Ensuite, nous avons demandé la permission d'essayer avec notre groupe.

Il y aura beaucoup de réponses sur le fait de montrer de manière empirique comment des choses comme la programmation en binôme, le développement piloté par les tests, Scrum, etc. peuvent toutes faire gagner du temps, mais au final, j'estime que la preuve doit venir de votre entreprise. Trouvez un groupe que vous pouvez utiliser comme banc d’essai et demandez-leur de le faire. Rien ne soulagera mieux les peurs que de montrer à votre groupe que cela a été fait.

Cram le dans la gorge, mais sans s'en apercevoir;)

J'ai essayé lentement de mettre en œuvre des principes agiles (principalement de la mêlée) sur mon lieu de travail au cours des 6 derniers mois environ. J'ai d'abord présenté les stand-ups quotidiens, ce qui a pris un certain temps pour s'y habituer, mais ça marche plutôt bien. Puisque nous travaillons tous sur différents programmes qui font tous partie d’un même système, il est un peu difficile de suivre scrum par définition. Ma prochaine étape consiste à démarrer des réunions de sprint pour suivre chacune de nos versions. Nous avons déjà un cycle d'un mois, donc la longueur du sprint n'est pas un problème. Je prévois également de respecter pleinement les principes de Scrum lors de notre prochain grand projet. Je suis l'un des deux développeurs de l'équipe pour le projet et il est tout pour l'amélioration continue. J'espère que la direction constatera les avantages de ce que j'essaie d'accomplir.

Je pense que la clé est de ralentir. Les personnes qui occupent le même poste depuis des années sont généralement opposées au changement intrusif, mais si vous pouvez le faufiler petit à petit, ils ne devraient pas le remarquer. Commencez également par les petites réunions fréquentes. En les gardant courts, la direction ne devrait pas y voir une perte de temps.

Développement piloté par les tests. Démonstration de la façon dont les tests unitaires peuvent accélérer votre développement. Le temps, tout en rendant le code plus stable, est un excellent premier pas vers le Kool-Aid agile.

Améliorez-vous d'abord. Vraiment. Exemple: la manière efficace de parler d’agile. En outre, comme quelqu'un l'a déjà dit, évitez les définitions techniques et utilisez simplement des termes que les gestionnaires et les responsables peuvent comprendre. Deux semaines à la place Sprint; Planifiez plutôt le jeu de planification ou de planification de sprint; Product Manager au lieu de Product Owner, etc. Michele Sliger a fait une présentation incroyable sur Agile dans l’entreprise Waterfall . Vraiment une vidéo à voir. Vous pouvez également être intéressé par d'autres vidéos sur l' adoption agile .

Là où je travaille, j’apprends que Scrum est un bon moyen de commencer agile, car la direction le comprend vite. C'est simple et porte un joli nom. Dernièrement, lorsque vous effectuez des rétrospectives, vous pouvez suggérer des pratiques XP comme améliorations et sera un jeu d'enfant que les gens acceptent au moins de les essayer.

Sincères amitiés

Nous l'avons introduit dans nos tâches de «maintenance» (bugs, modifications à faible impact, etc.) sous la forme d'un sprint de 2 semaines. Les développeurs qui travaillaient sur des projets à long terme sont donc restés tels quels, mais nous avons eu un sprint de maintenance tournant. Donc, tout le monde a essayé d'utiliser des graphiques de burn-down et des estimations de poker sans perturber les grands projets.

Ensuite, à la fin de chaque projet majeur, nous avons commencé le suivant en utilisant des sprints agiles de deux semaines. Tout le processus a pris quelques mois avant que tout le monde ne soit sur des sprints, mais cela signifiait qu'il y avait moins de perturbations et que tout le monde pouvait se "calmer" dans le processus.

Au sein de l’équipe de développement, introduire Agile est bien plus une chose sur laquelle vous avez un certain contrôle.

Cependant, je vois que le problème majeur est l'exigence qu'a Agile d'exiger des commentaires continus de votre "client" ou de son représentant.

Par conséquent, vous devez vraiment vous concentrer sur le volet éducation pour les personnes extérieures à votre équipe de développement directe, car elles devront probablement changer leur façon de travailler (c.-à-d. Beaucoup plus de contact avec l'équipe de développement).

La meilleure façon, à mon avis, est de mettre l’accent sur les avantages inhérents à l’adoption d’un processus Agile et de les communiquer clairement à votre client. Bien sûr, si vous avez un secteur des ventes / comptes dans votre entreprise, il en va de même.

Étape 1: assurez-vous que votre projet a un arriéré important et assurez-vous qu'il est priorisé

Étape 2: introduisez les pratiques SCRUM (itérations gérables, relevés quotidiens, scrum master, propriétaire du produit, graphiques de burndown)

Étape 3: chaque itération présente les résultats de l'équipe avec le burndown

alors ...
implémentez TDD / BDD, programmez les programmes en binôme, les révisions de code (très doucement), et si vous avez une équipe assez bonne, colocalisez tout le monde (une salle d'équipe si possible).

Surtout, comprenez qu'il y aura une résistance (SERA ÊTRE), alors soyez prêt à gérer cela.

Une autre chose à garder à l'esprit est que si vous faites partie d'une organisation (grande ou petite) qui dans son ensemble ne suivra pas ces meilleures pratiques, il faudra peut-être un certain temps (si jamais) pour sentir que vous faites des progrès.

Les gens sont toujours réticents au changement, et passer à la mêlée est un très gros projet. La motivation et la direction sont la clé.

La première étape consiste à motiver les gens à donner une chance à Scrum. J'ai découvert que Google Tech Talk de Ken Schwaber était très utile pour amener les gens à reconnaître les avantages de la mêlée tout en offrant une bonne introduction. Commencez par des personnes qui, selon vous, seront réceptives au changement, qu'il s'agisse de développeurs ou de gestionnaires, afin de créer une dynamique. Obtenir des gestionnaires de votre côté va devenir une nécessité à un moment donné, mais la façon dont vous gérez cela dépend de votre environnement.

Après cela, tout le monde doit être formé, qu'il s'agisse de lire un livre ou d'avoir une série de conférences. À moins que les gens sachent comment fonctionne Scrum, vous ne pouvez pas commencer à essayer de mettre en œuvre le processus.

Une fois que les personnes sont motivées et ont une idée de ce qu’elles doivent faire, vous devez organiser votre première réunion de planification et mettre en place les éléments de scrum nécessaires (scrummaster, réunions quotidiennes, etc.).

Je m'attends à ce que la première réunion de planification ne se déroule pas bien et soit une expérience d'apprentissage pour tous. De plus, les premiers sprints seront très rocheux et probablement en retard. La clé est maintenant la discipline et la persistance. Ne laissez pas les réunions quotidiennes durer trop longtemps, gardez les réunions de planification à la tâche et assurez-vous que tout le monde s'acquitte de son rôle correctement.

Je pense que les personnes les plus résistantes sont celles qui développent des logiciels depuis longtemps ou qui pensent qu'en passant à la mêlée, elles admettent avoir déjà commis quelque chose de mal. C'est un obstacle difficile à surmonter, mais je pense qu'en leur montrant les avantages que vous pouvez les convaincre lentement. Cela prend juste du temps. D'après mon expérience, les chefs de produit sont vraiment résistants car cela les oblige à être plus clairs quant à leurs exigences et à ce qu'ils veulent. Mais une fois qu'ils ont compris les avantages du processus agile et leur ont rendu la vie plus facile, ils se sont rapidement engagés.

Bonne chance!

• Démontrer le succès - voir la réponse de la marque
• Portez une attention particulière aux principes / techniques qui auraient le plus grand impact sur l'entreprise
• Rappelez-vous qu'il s'agit de principes agiles et non d'une liste de contrôle de processus

Avant de penser à introduire le développement agile, commencez par explorer ce qui convient le mieux à votre organisation / projet. Si, par exemple, vous examinez scrum, demandez-vous si vous l'utiliserez de manière stricte ou si une forme de mêlée plus souple, ou même une autre méthode, conviendrait mieux. Ma réponse est alors sur Scrum en tant que méthode agile.

Scrum est idéal pour les projets qui requièrent de l’innovation, où l’on sait peu de choses et où des expériences sont nécessaires. Ce n'est pas la meilleure solution pour des tâches telles que la maintenance de produits existants ou la gestion de travaux de maintenance récurrents. Heureusement cependant, Scrum est un framework lâche et vous pouvez l'utiliser de la meilleure façon possible.

Pour le travail de maintenance, Kanban peut être mieux pour vous ou vous pouvez essayer quelques éléments de mêlée pour gérer le sprint et effectuer des tâches comme les relevés quotidiens. J'appelle ça "scrum-but", "oui on fait du scrum dans notre entreprise mais ...". C'est bien, ne vous en faites pas.

Pour introduire Scrum Propre dans votre organisation, vous devez faire appel au propriétaire du produit et au détenteur de la partie prenante. Si vous êtes une petite entreprise, ce type peut être une personne, le chef, et dans une plus grande une chef de produit et le chef de département. Je suggérerais deux voies pour introduire Scrum:

1) vous pouvez commencer à utiliser scrum sous une forme légèrement plus souple pour gérer immédiatement les files d’attente existantes. Mais examinez également Kanban.

2) commencer à utiliser scrum sous une forme plus stricte sur un nouveau projet qui nécessitera de l'innovation, une première réaction et où on ignore beaucoup de choses. Vous pouvez suggérer au patron / responsable du produit que Scrum serait idéal pour ce nouveau projet.

Mais rappelles-toi! il ne s'agit pas que de code, le responsable du produit a un rôle crucial à jouer et doit comprendre et remplir son rôle. Cela signifie, par exemple, ne pas rédiger toutes les spécifications au début, mais plutôt commencer par le minimum, itérer rapidement, obtenir un retour d’information, apprendre et commenter cela, etc. Essayez de travailler avec un chef de produit qui voudrait présenter Scrum autant que vous, mais du côté du propriétaire du produit. Idéalement, il devrait être assez fort pour repousser les demandes de la direction et protéger le sprint.

Le développement et la gestion des produits nécessitent des efforts concertés pour introduire Scrum.

Sur un tel nouveau projet, essayez de déplacer la nouvelle équipe dans une pièce séparée et utilisez des post-it pour visualiser le travail dans les différents états tels que le carnet de commandes, les travaux en cours, etc. Ne vous perdez pas en outils électroniques à ce stade. , gardez les choses aussi simples que possible. Ne vous sentez pas stupide de planifier le poker avec des cartes lorsque vous débutez aussi, une fois que votre équipe sera au top, vous ne les utiliserez probablement plus, il vous suffira de dire les chiffres.

D'après mon expérience, il est plus facile d'introduire scrum sous une forme pure, puis de l'alléger pour davantage de files d'attente de type maintenance. C'est plus difficile l'inverse.

Mon dernier commentaire est de ne pas penser que Scrum est une panacée pour le développement, ce n’est pas le cas. Scrum est un cadre simple et utile pour l’innovation de produit, mais explorez d’autres méthodes pouvant être combinées selon les besoins de votre entreprise et ne vous en faites pas.

Il y a quelques années, j'étais consultant dans une très grande entreprise (près de 20 000 employés) qui gérait de nombreux projets de logiciels d'entreprise. J'étais sur l'un d'eux. Un assez critique.

Nous avons dû faire face à de nombreux problèmes et la pression était très forte sur nous, l'équipe de développement. Les problèmes étaient courants dans l’industrie du logiciel, mais la direction possédait une expérience davantage axée sur l’infrastructure et très peu d’expérience axée sur le logiciel. Donc tout était concentré sur nous. J'ai pensé que ce serait une bonne idée de parler de Scrum à la direction.

J'ai été confronté à de fortes réticences, j'ai donc abandonné l'idée pendant un moment. Mais les problèmes ont continué à s'aggraver et avec le sponsor du chef d'équipe, nous avons finalement décidé de faire Scrum de toute façon, à notre manière.

N'importe qui, y compris moi, n'avait aucune expérience de Scrum. Nous avons donc découvert le framework en faisant ...

Aujourd'hui, Scrum est généralisé à l'ensemble de l'entreprise via un programme administré par un formateur certifié. Je ne sais pas si notre initiative a été le déclencheur. Cela dit, je sais que ce fut une véritable révolution dans une entreprise assez rigide.

Je pense que pour introduire quelque chose dans une entreprise comme ça, vous devez respecter les principes suivants:

• Cela doit changer est nécessaire . S'il n'y a pas de raison impérieuse pour que le changement soit effectué, il n'y a pas de raison pour que les équipes de gestion en place prennent des risques.

• Nous devons nous concentrer sur les problèmes de gestion et ne pas mentionner les problèmes des développeurs, à moins qu'ils ne fassent partie des préoccupations de gestion. En d'autres termes, vous devez apporter une solution pour eux, pas pour vous. Mettez-vous à la place de la direction. Quelles sont leurs préoccupations?

• Vous ne devriez pas proposer de changer toute l'organisation en même temps . Vous devez proposer un projet pilote dont vous assumeriez la responsabilité. Je vous conseille de donner des objectifs réalistes, tels que l’augmentation significative de la visibilité sur ce qui se passe dans le projet. C’est, à mon humble avis, la principale contribution de Scrum à la gestion des logiciels. Cela permet au bon sens humain de fonctionner et d'aller de l'avant.

• Enfin, il est impératif de s'assurer que des personnes expérimentées maîtrisent cette introduction. Ne vous contentez pas de lire un livre ou deux. Vous devez suivre une formation et je dirais qu'il est plutôt nécessaire de faire appel à un coach expérimenté. Évidemment, cela peut se faire sans, mais ce sera douloureux :)

Si vous suivez les principes et apportez des faits, cela fonctionnera. Vous trouverez de nombreux faits dans le livre Logiciel en 30 jours: Comment les gestionnaires agiles peuvent-ils battre les cotes, enchanter leurs clients et laisser leurs concurrents dans la poussière ? C'est le dernier livre des créateurs de Scrum, Ken Schwaber et Jeff Sutherland .

Dans un article de blog de Ken sur le livre, vous pouvez lire:

Jeff Sutherland et moi l'avons fait. Nous avons écrit un livre ensemble, notre première publication conjointe depuis la publication initiale de Scrum en 1995. Qu'est-ce qui nous a motivés? La question que l'on nous pose souvent:

Comment vendons-nous Scrum à notre direction?

Cette question m'a toujours intriguée. Pourquoi devriez-vous vendre plus de prévisibilité, de productivité, de qualité, de valeur, de maîtrise des risques, de clients satisfaits, d'employés motivés et de moins de gaspillage à tous les responsables de la gestion? Cependant, j’ai parlé avec Jeff et nous nous sommes dit que là où il y avait de la fumée, il devait y avoir un feu.

Nous avons passé la dernière moitié de 2011 à écrire le livre. Tout gestionnaire, de haut en bas, peut facilement prendre et lire ce livre.

[...]

Nous le voyons tout le temps. (divulgation complète: je développe une application de gestion de projet). Le problème est que les méthodologies agiles introduisent une tension inhérente dans les organisations gérées de manière traditionnelle. En règle générale, les directions supérieures veulent pouvoir planifier. Ils veulent des plans de trois ans; ils veulent des projets bien estimés; ils veulent pouvoir budgétiser l'embauche de nouvelles personnes; ils veulent pouvoir s'engager dans des étapes importantes en ce qui concerne leurs partenaires / clients.

Mais ensuite, le département R & D décide qu'il va devenir agile. Il ne s'agit plus de planifier deux mois avant d'écrire du code. Les sprints seront courts et au-delà des sprints, vous obtiendrez des estimations à très basse résolution des éléments contenus dans l'arriéré / feuille de route. R & D est conscient que les exigences changent trop souvent pour que la cascade classique soit efficace, mais les responsables produits ont besoin d'une vision claire, réfléchie et bien budgétisée de ce à quoi le produit ressemblera dans 12 mois.

Le problème est donc de réconcilier les deux. Comme je l'ai dit, nous voyons cela tout le temps se passer avec nos clients. Notre solution consiste donc à unifier les outils utilisés à la fois pour les sprints et la planification à long terme. Ok, maintenant voici la partie de la fiche éhontée, alors n'hésitez pas à la prendre avec un grain de sel. L'une de nos caractéristiques uniques est que nous utilisons une interface utilisateur zoomable pour la gestion des tâches. Cela signifie qu'il est très facile d'explorer une tâche / une histoire d'utilisateur et de l'expliquer. (vous pouvez voir à quoi ça ressemble ici ). En réalité, il n’existe aucun concept de "projet" dans notre système. Ce sont toutes des tâches contenant d'autres tâches, reliées à d'autres tâches (une fractale, vraiment). Cela crée un joli flou entre les histoires d'utilisateurs, les tâches, les projets, les épopées, etc.

En pratique, bon nombre de nos utilisateurs qui appliquent des méthodologies agiles créent un plan télescopique qui fusionne la feuille de route à long terme (ou l’arriéré) avec la gestion des sprints (ou itérations) à court terme. Les gestionnaires ont toujours la possibilité de voir une belle feuille de route contenant les principales fonctionnalités en attente d’ajout, et les développeurs effectuent simplement un zoom plus profond et s’occupent des tâches réelles. Un des avantages est que cela réduit la quantité de "marchandage" qui a lieu lorsque les responsables examinent le plan de travail. Au lieu que l'équipe de développement ne fournisse que des estimations très approximatives ("4-6 semaines!"), Elle a la possibilité d'analyser chaque histoire d'utilisateur en question et de la décomposer en morceaux plus petits. Lorsque vous faites cela, il y a soudainement moins de place pour le marchandage. Vous passez 10 minutes à décomposer une histoire d’utilisateur de 5 semaines en morceaux d’environ 1 jour, et tout à coup l'argument n'est pas "non, vous pouvez le faire plus rapidement. non nous ne pouvons pas. oui vous pouvez." mais "voici ce qui se passe dans cet effort, y compris tout le travail caché que l'estimation initiale n'a pas pris en compte. Que proposez-vous d'éliminer? Assurance qualité? Tester? Former le nouveau type? Configurer l'environnement de construction?".

Cette approche fonctionne tant que vous utilisez un outil qui vous permet de modifier les plans aussi rapidement que vous les avez initialement rédigés. Quelle est la vraie raison pour laquelle les gens détestent ces cascades ces jours-ci? La plupart des systèmes rendent extrêmement difficile la refonte complète des plans existants et les gens refusent de manière très rationnelle de perdre du temps dans cette activité.

D'accord, j'ai l'impression que cela se transforme en argument de vente, alors je vais m'arrêter maintenant. :)