Comment éviter de "heurter le mur" dans votre transformation agile

Je suis un pratiquant et évangéliste agile depuis plus de 20 ans. C’est à peu près les deux tiers de ma carrière en tant que concepteur de logiciels.

Au cours de ces années, j’ai vu les mentalités évoluer sur Agile et pour quoi il devrait et ne devrait pas être utilisé. En général, la liste «ne devrait pas être utilisé pour» a été réduite. Une progression de «ne devrait pas» à «pourrait» à «devrait» à «absolument devrait» est la bonne direction.

Mais au cours de la même période, j'ai observé un certain nombre d'organisations, peuplées de personnes très intelligentes, personnes créatives et passionnées, luttent avec leurs propres voyages Agiles. Par la suite, j’ai passé beaucoup de temps à travailler avec ces organisations et à effectuer moi-même une introspection. Comment rendre le voyage transformationnel Agile plus efficace, fructueux et plus agréable?

Ironiquement, la plupart des organisations cherchent à entamer ou à faire progresser un voyage agile bloqué: elles recherchent une formule ou les «meilleures» pratiques qui contribueront à leur entreprise. plan. Pensez-y un instant – adoptez une approche basée sur un plan pour vous éloigner d'une approche basée sur un plan. C'est un anti-modèle et l'antithèse de la mentalité Agile.

Que devons-nous faire?

Le meilleur moyen d'accélérer votre parcours Agile est et non en lisant des articles, des livres ou des blogs. ou chercher une sorte de formule pour élaborer un plan. Bien que ces choses puissent éduquer et même inspirer, elles maintiennent le chemin le plus lent – bien que celui-ci se «sent généralement plus en sécurité» pour certains.

Une bien meilleure solution consiste à suivre une approche du voyage Agile qui est en elle-même – Agile. 19659002] Maintenant, en quelque sorte, un conseil cruel semble être le conseil le plus clair et long sur votre parcours Agile. Les démarches les plus difficiles à faire dans le voyage Agile sont en effet un «départ» sérieux. Abandonner les mains courantes basées sur les plans d'eau et se lancer dans une nouvelle façon de penser.

Il est en fait assez difficile de prescrire une formule ou de recommander des pratiques spécifiques à suivre, sans une évaluation honnête de votre situation actuelle. votre propre voyage. C'est pourquoi les rétrospectives (en tant que cérémonie spécifiquement définie par Agile) sont particulièrement importantes au début (ou pour se défaire).

Une rétrospective n'est pas la même chose qu'une évaluation.

Une rétrospective est beaucoup moins ambitieuse et est donc beaucoup plus sensible à la découverte et à l’apprentissage inhérents à la prise de mesures progressives. Les rétrospectives sont plus – bien – agiles.

Maintenant, une fois que vous avez eu votre première véritable rétrospective:

1. Choisissez quelques modifications qui équilibrent une valeur importante pour l’organisation avec des résultats ambitieux mais réalisables pour l’équipe.
2. Assurez ces résultats sont quantifiables et mesurables.
3. Commencez à mettre en pratique ces changements avec des rétrospectives hebdomadaires par équipe pour jauger l’évolution des choses.
4. À mesure que l’inconfort et la gêne se dissipent, adoptez un autre changement dans la pratique.
5. les choses ne sont pas à la hauteur de vos objectifs, vous devrez peut-être vous ajuster ou totalement pivoter. Parfois, vous devrez peut-être simplement continuer à vous débrouiller; donner au changement actuel plus de temps pour se fondre dans le vôtre.
6. Répétez souvent

Cela semble simple, n'est-ce pas? Bien sûr, le diable est bien sûr dans les détails. Le long de chaque étape du voyage, il est possible de s’engager dans le mauvais chemin, de rester coincé ou même de s’envoler un peu. Tous parfaitement OK – vous apprenez ! Vous devez simplement évaluer et équilibrer cela avec votre tolérance organisationnelle pour la rapidité. Certainement, si vous voulez aller plus vite, des approches de coaching ou de projet par exemple vraiment expérimentées peuvent vous aider à faire avancer les choses.

Alors pourquoi toute cette désinformation?

Donc, si c'est aussi simple et intuitif que d'adopter une approche Agile d'un Agile pourquoi tant de gens promeuvent-ils une approche de la transformation Agile basée sur un plan? Pourquoi tant de vendeurs proposent-ils une approche basée sur une formule basée sur une formule? Emporte-pièce ("cookie cutter")?

Je suppose que cela est en partie dû à l'inexpérience. Un certain nombre de sociétés de conseil ont pris le train en marche Agile. Heureux de les avoir finalement à bord, mais beaucoup de ces personnes se dissociaient sur Agile ou hybride de couverture-Agile juste quelques années auparavant. Certains le sont encore. Si vous êtes toujours bloqué dans un état d'esprit basé sur un plan, alors tout ressemble à un clou basé sur un plan.

Ohers essaient simplement de monétiser la vague Agile. Bien qu'il n'y ait rien de mal en soi à «vendre Agile» (livres, formation, certifications, outils, etc.), gardez toujours à l'esprit que ce que vous achetez est la capacité [ * d'être agile – pas réellement * étant * plus agile. Je peux lire un tas de livres, m'entraîner et être certifié pour parler une langue étrangère. Cependant, rien ne remplacera la pratique. Surtout, le pratiquer dans des situations difficiles et sans artifices.

Perficient croit qu'il est préférable d'adopter une approche agile pour faire le voyage agile. C’est la base de notre approche de la transformation Agile avec nos clients les plus précieux et les plus stratégiques.

OK, bien sûr….

Ne sachant pas les détails de votre organisation, des membres de votre équipe ou de votre position dans votre propre parcours – il y a des choses générales qui semblent toujours apparaître à la surface dans les rétrospectives des clients I 'ai été une partie de à travers les années. Quelques règles de base qui peuvent ou non s’appliquer spécifiquement à votre situation particulière:

Avez-vous VRAIMENT un parrainage exécutif?

Soyez réaliste quant au montant de votre “parrainage exécutif”. Un véritable parrainage de dirigeants signifie accepter qu’une grande partie du voyage Agile sera axée sur le changement. Changer et apprendre de nouvelles choses est difficile, maladroit et désordonné. Des erreurs seront commises et cela coûtera plus cher pendant un certain temps. Vous pouvez éviter certains pièges courants et accélérer les choses avec un encadrement et une formation appropriés; Si vos dirigeants (entreprises et informatique) n'acceptent pas que soit on en fasse moins, soit que les choses vont coûter plus cher, alors vous n'avez pas parrainé par ses dirigeants.

Commencez au bon endroit…

Les entreprises commencent souvent leur transformation Agile au mauvais endroit. Ils se concentrent trop sur les équipes de développement. Ils forment et certifient les développeurs et les chefs de projet; qui, dans leur premier véritable projet Agile, se heurtent à des scénarios et à des défis du monde réel assez complexes et pour lesquels ils ne possèdent pas encore les compétences et l'expérience *.

* note latérale: obtenir la certification ScrumMaster vous donne seulement une compréhension de Scrum 101 – mais appeler une certification ScrumMaster avec le nom 'ScrumAware' – ne se vendrait pas aussi bien, alors allez-y). Pour reprendre la métaphore linguistique, ce serait comme si vous preniez deux jours d'espagnol au lycée et vous laissiez ensuite tomber dans un village éloigné du Chili où personne ne parle anglais.

Les propriétaires de produits font tourner le monde agile…

Une meilleure approche consiste à commencer par le côté commercial, en se concentrant sur les propriétaires de votre entreprise. Travaillez avec eux pour développer un fort état d'esprit du responsable produit (formation, certification, coaching et pratique). Transformez votre processus actuel de gestion des 'exigences' en un état d'esprit Lean (c.-à-d. Fin, fondé sur la valeur, délai de mise sur le marché plus rapide, autofinancement / perpétuation, mesure et ajustement – voire pivotement).

Même si votre équipe de développement continue de fonctionner en utilisant une cascade, ils commenceront au moins à raccourcir naturellement les cycles de développement (Agile-Fall) – et quand il sera temps de les former, de les certifier / de les transformer – un noir de route énorme sera atténué puisque l'entreprise fonctionnera déjà de manière agile .

Vous éviterez également l'apparition de facteurs tels que les "mandataires" de Product Owner, la décomposition et la reconstitution de récits à partir d'exigences (et de matrices de traçabilité nécessaires), ainsi que le traitement des déchets en raison de lacunes créées avec des approches immédiates basées sur des exigences plus simples. .

C’est pourquoi la plupart des transformations Agiles sont si douloureuses et souvent en perte de vitesse.

DevOps est une rue à double sens.

la dentelle à aborder est le déploiement. Assurez-vous de vous concentrer non seulement sur la mentalité de «pousser à déployer», mais aussi et surtout sur la mentalité de «pousser à reculer». Les deux doivent être automatisés à un point tel que tout le monde a la plus grande confiance: non seulement quelque chose peut être déployé rapidement, mais en cas de problème, il peut être retiré en toute sécurité tout aussi rapidement. Les organisations Agile / Lean comptent absolument sur ces deux éléments. Si vous ne le faites pas, votre voyage Agile sera court-circuité avec un seul mauvais déploiement. Ou à tout le moins, incitez tout le monde à se haïr.

Un test automatisé est un test prévisible

Prochain arrêt – QA / Testing. Tout simplement, vous devez maîtriser au moins 70% des tests avant d’essayer de réduire les itérations à une valeur suffisamment courte pour être appelé Agile. Sinon, la cadence de vos itérations continuera à s’infiltrer à mesure que vous accumulerez de plus en plus de dettes de régression manuelle. Ensuite, vous pourriez même faire quelque chose de vraiment stupide, comme commencer à réduire vos tests de régression et à accélérer à fond pour devenir un désastre et un chaos total.

Ok…. MAINTENANT – vous pouvez commencer la transformation de l'équipe de développement. La vie sera belle.

Equipes distribuées, multi-shore et Agile…

Il y a environ dix ans, ma réponse à une question-clé vous demandait si pourriez-vous

“Non seulement POUVEZ-vous utiliser Agile avec des équipes multi-rivages, mais à mon avis – Agile est la seule méthode à utiliser pour la livraison multi-rivages” [19659046]- moi…. Il y a une dizaine d'années… sur ce panneau…

Je me souviens que c'était un moment plutôt cool. Un groupe de représentants des grandes sociétés de conseil (en particulier offshore) venait de répondre à la même question en évoquant «il n’est pas recommandé» de «absolument pas». J'ai répondu en dernier et j'avais l'impression d'être dans une configuration parfaite. C'était génial.

Je crois toujours ce que j'ai dit et nous avons de nombreuses preuves que cela fonctionne. En fait cela fonctionne très bien. Le sens de la connexion en équipe, la transparence des progrès et la capacité de correction rapide apportée par Agile constituent l'antidote idéal pour ce que les gens n'aiment pas du tout à l'idée de travailler avec des équipes offshore.

Et – voici le kicker: Si vous responsabilisez vos équipes offshore avec Agile , cela les amène à un tout nouveau niveau de valeur dans le cycle de vie. Faire partie de nos équipes de livraison internationales depuis plus de 12 ans a été la collection d'expériences la plus enrichissante de toute ma carrière.

Mais ne vous y trompez pas. Agile distribué n'est pas facile. Ce n’est pas du type «ScrumAware 101». Donc, voici l’avertissement: si vous voulez vraiment réussir dans Agile avec des équipes réparties (en particulier offshore), vous devez d’abord vous assurer que votre Agile sur site est vraiment «Agile». Si votre quotidien sur site n’est pas en ordre, essayer d’injecter une dynamique d’équipe distribuée dans cette zone (en particulier en offshore) va induire le pire des deux mondes (basé sur le plan et pseudo-Agile). Tout le monde finira par se détester et vous en tirerez (à tort) la conclusion selon laquelle Agile offshore ne fonctionne pas. Mais juste pour vous rappeler – ça peut. Cela fait; Et en fait, Agile est le MEILLEUR moyen de tirer le meilleur parti de votre équipe offshore.

Faites attention au «bavardage hybride»…

Si à un moment quelconque de votre parcours Agile, méfiez-vous si quelqu'un commence à utiliser le mot «hybride» (ou chompe un peu trop avec impatience pour introduire une mise à l'échelle Un cadre comme SAFe. Vraiment, vraiment prenez du recul et demandez-vous si vous avez besoin de superposer des pratiques non-Agiles / non-Lean. Ceci est vrai en particulier si vous commencez à entendre. comme: «Eh bien, notre entreprise est unique et nous devons« ajuster »Agile pour la faire fonctionner."

Je ne dis pas que cela ne se produit pas – et honnêtement, je peux faire valoir les deux côtés de la médaille hybride – I Je dis simplement être sceptique et hypercritique à propos de toute rationalisation par "hybridation".

Je souhaite également faire une distinction ici: "Auto-organisation" et "adaptation" doivent être appliqués à l'équipe . méfiez-vous d’institutionnaliser les choses un peu trop agressivement. lizing ’, vous commencez à verrouiller les leviers. Leviers que l’équipe peut tirer (et retirer) au fur et à mesure que les choses évoluent au cours du parcours Agile: accumulation des expériences des membres de l’équipe, nouveaux impératifs commerciaux, distribution de l’équipe (géographique, chronologique et même culturelle) et aspects de l’environnement lui-même. [19659055] C’est simple – équilibrez parfaitement pragmatisme, ouverture d’esprit et scepticisme. Ok.

Quelques dernières mises en garde…

La liste ci-dessus n’est pas exhaustive, et chacune ne fait qu’effleurer la partie supérieure de chaque sujet. Je me réserve également le droit de changer d’avis sur tout ce qui précède à tout moment

. Ils ne sont également pas le seul moyen d’y arriver. Par exemple: pouvez-vous toujours progresser dans votre parcours Agile sans véritable parrainage des dirigeants? Oui. Que diriez-vous sans la possibilité de commencer avec le propriétaire du produit? Vous pariez.

Et ils ne sont certainement pas destinés à être simplement écrits et rassemblés dans un document / jeu géant avec d’autres «meilleures pratiques» provenant d’autres sources et livrées de force à l’organisation. Parce que… ouais… C’est un peu la définition du terme «institutionnaliser» – voir ci-dessus.

Au lieu de cela, l’intention ici est que chacun d’eux mette au point des heures d’exploration saine. Conversation qui mène à de nouvelles choses concrètes et progressives à pratiquer, à mesurer et à ajuster. Tout au long de votre propre voyage agile. Un voyage qui, espérons-le, sera un peu plus fructueux et opportun. Et amusez-vous bien pendant que vous y êtes.