Dites-nous en plus sur votre projet

Nous vous proposerons une formule adaptée à vos besoins, ainsi qu’une estimation de devis.
Laissez-vous guider

Pourquoi choisir Aneo pour votre projet ?

Aneo est une agence conseil en transformation qui vous accompagne tout au long de la vie de vos projets sur des problématiques de :

Le +  d’Aneo : le conseil sans frontière !

Notre richesse, c’est de vous proposer des équipes pluridisciplinaires, chaque membre avec une approche, une expérience et une sensibilité différente : coach agile, formateur soft skills, Data Scientist designer, Architecte etc. On mise sur la complémentarité des disciplines pour vous apporter la meilleure réponse !

Pourquoi choisir Aneo  pour votre projet ? - Aneo

Aneo, une organisation à part entière !

Depuis 2015, Aneo est une organisation plate à gouvernance plate. Aplatir la hiérarchie, supprimer les silos, instaurer des bonus collectifs, ce nouveau modèle d’organisation avec comme objectif: apporter plus de valeur  à l’entreprise, aux collaborateurs et aux clients.

Le + d’Aneo : l’inattendu !

La sérendipité, c’est « le don de faire par hasard des découvertes fructueuses ». Chez Aneo, nous croyons fermement que les meilleures solutions sont parfois les plus inattendues. Ne rien s’interdire, expérimenter, oser s’entourer de profils atypiques et avoir une obsession : apporter la juste valeur.

Aneo, une organisation à part entière !  - Aneo

Qui êtes-vous ?

Vous êtes pour

Votre secteur

1 seul choix possible
Assurance & Protection sociale
Banque et Finance
Industrie & Services
Santé

Vos besoins

Plusieurs choix possibles
IT & Digital
Transformation des Organisations
Stratégie Business
Pilotage de projets

Détails

Des précisions à ajouter sur votre projet ? (facultatif)
C'est noté !
Nous avons pris en compte les spécificités de votre projet.
Nos équipes vous contacteront sous 48h pour en discuter plus amplement.
Votre prénom *
Votre nom *
Votre adresse email pro *
Votre numéro de téléphone *
Bien reçu !
Nos équipes vous contacteront sous peu
pour discuter de votre projet.
Article

20 expressions « peu agiles » que vous devriez éviter d’employer !

 

Dans Scrum, on tient à une utilisation précise du langage, d’autant que tout ce qui n’est pas précis concourt à un manque de transparence. Or, quand on essaie d’implémenter Scrum, on peut faire l’expérience d’une certaine pression à adapter les terminologies et leurs significations, pour que les changements soient adaptés à l’organisation qui les accueille.  Les termes de référence de Scrum peuvent alors être tournés et détournés pour coller aux contours existants. La conséquence ne se fait pas attendre : la façon même dont nous pouvons penser le changement agile se retrouve vrillée et contrainte par le poids de l’organisation.

 

Quoi qu’il en soit, nous sommes toujours sujets au poids organisationnel, et aussi rigoureux ou prudent que l’on soit, on ne peut pas entièrement se protéger de son effet.  Un effort de discipline que nous pouvons toutefois mener peut consister à exercer des petites corrections, très vite et très souvent, avant que ne s’installent définitivement des mauvaises pratiques. Voici 20 de ces « petites choses » que nous pouvons être tentés de dire ou bien auxquelles on peut acquiescer silencieusement et qu’il serait peut-être préférable d’éviter…

 

1 – « Sprint Backlog »

 

Évitez de décrire le « Sprint Backlog »  comme un «  engagement ».  C’est un « plan » ou une « estimation »  du travail à accomplir en vue d’atteindre l’objectif du sprint. Il vaut mieux utiliser ces mots.  Et il faut se souvenir que les membres de l’équipe s’engagent sur des buts et non sur des prévisions.

 

2 – « Story Points »

 

Evitez des éléments de langage qui pourraient suggérer que les Story Points sont « livrés » , ou d’une certaine manière constituent une valeur ou bien une façon d’estimer la valeur. L’objectif des Story Points est d’aider une équipe à prévoir quelle quantité de travail elle pense pouvoir embarquer. Dans une pratique agile, la valeur ne se trouve que dans l’incrément de travail qui est livré.

3 – « Vélocité idéale »

 

Évitez de parler d’une « vélocité idéale » quand vous faites des prévisions. À la place, parlez d’une valeur idéale qui peut être livrée dans le Sprint courant et les Sprints à venir. Il faut se souvenir qu’une équipe agile n’est pas constituée de « comptables des Story Points », mais de développeurs.

 

4 – « Objectifs de Sprint »

 

Évitez de parler d’ « Objectifs de Sprint » quand ces objectifs supposés n’ont pas été planifiés et acceptés par l’équipe. Si ce sont des tentatives d’objectifs de sprint, alors appelez-les comme ça.

 

5 – « Sprint et sprints spéciaux »

 

Évitez de parler des différentes étapes de la production d’un travail en tant que « Sprint » si elles ne sont pas comprises dans un time box et qu’elles ne produisent pas un incrément de fonctionnalités. Des sprints « spéciaux » comme le « sprint zéro », le « sprint d’intégration », le « sprint de test », sont en réalité des étapes ou des phases. S’il est nécessaire qu’il y en ait, ce n’est pas grave, mais ayons l’honnêteté de les appeler par leur nom et de ne pas dévaluer des termes de référence dans l’agile.

 

6 – « Démonstration »

 

Évitez de décrire une revue de sprint par le terme « démonstration ». Une démonstration du travail effectué peut tout à fait faire partie d’une revue de sprint. En revanche, l’objectif principal  d’une revue de sprint est de considérer le travail effectué et le travail qui reste à faire est d’inspecter et d’adapter le Product Backlog.

 

7 –  « Kanban »

 

Éviter de parler d’un « Kanban »  à moins que le tableau dont vous parlez ne soit lié explicitement à la description d’un système de flux. Si votre tableau fonctionne en définitive plus comme une « to do list »,  donnez-lui ce nom-là.

8 –  « Definition of Done »

 

Évitez  d’appeler des critères d’acceptance la «Definition of Done ».  Les critères d’acceptance font partie de la « DOD »  pour certains produits du Backlog, mais la  Définition of Done, qui  atteste de la qualité  globale du produit livré dépasse ce cadre.

 

9 – « Equipe »

 

Évitez  de parler d’ « équipe » à moins qu’il n’y ait qu’une claire évidence que l’assemblage de personnes auquel vous faites référence pratique au quotidien une collaboration  directe et continue. Si les personnes travaillent dans des silos qui sont indépendants les uns des autres, et de temps à autres se réunissent sur un projet, il vaut mieux alors parler d’un « groupe de travail » qui est engagé autour d’une production commune.

 

10 – « Outils-support VS pratique »

 

Évitez de faire référence à une initiative agile en parlant de ses outils-support.  Se tourner vers une pratique agile n’est pas du même niveau qu’« avoir Jira » ou bien « utiliser TFS » et ce, quelle que soit la technologie employée.

 

11 – « DevOps »

 

Évitez de parler de « DevOps »  comme si cela était distinct d’une pratique agile ou d’un changement  dans la culture de travail. Si vous faites référence à des pratiques techniques comme l’automatisation ou l’intégration continue ou le déploiement, préférez utiliser ces termes.

 

12 – « Dette technique »

 

Évitez d’utiliser le terme «  dette technique »  si vous n’avez pas défini de stratégie pour la résorber ou même que le risque qu’elle peut représenter n’est ni contrôlé, ni même correctement défini.  Il vaut mieux dans ce cas-là parler d’une « boîte noire ».

 

13 – « Plan de Release »

 

Évitez le terme « Plan de Release »  quand certains sprints ne sont pas destinés à figurer dans une Release.  Ce dont vous disposez  est, en fait, un plan de non-release.  Dans Scrum, chaque sprint  doit produire un incrément de valeur, aussi petit soit-il. La décision de procéder ou non à une Release doit être faite en fonction du respect du Just-In-Time.  Un vrai plan de Release  devrait mettre en avant ce qu’il est vraisemblable de délivrer, pas si une Release va se produire ou non.

 

14 – « Bogues et défauts »

 

Évitez  de parler des « bogues » ou « défauts » comme s’ils étaient séparés du reste du travail à faire. Ils doivent être inclus dans le travail qui reste à faire et donc planifiés et budgétés en conséquence. L’urgence de la réparation et/ou la vitesse à laquelle elle doit être effectuée ne doit pas être un frein à la transparence.

 

15 – « Périmètre fixe »

 

Évitez de parler de  « Périmètre fixe »  quand un Product Backlog est sans arrêt en cours de raffinage et que des options nouvelles peuvent être amenées à surgir. Il vaut mieux considérer que chaque sprint est une opportunité de livrer des éléments contenant de la valeur pour le client, susceptibles de leur apprendre des choses importantes.

 

16 – « Envoyer en test »

 

Évitez  l’effet de langage qui consiste à parler de « envoyer en test » qui suggère qu’on peut attendre autre chose que du flux tiré. Les pratiques agiles et Lean  sont basées sur le flux tiré, qui porte avec lui les notions d’une gestion du travail efficace répondant à des signaux clairs.

 

17 – « Equipes distribuées »

 

Evitez de faire référence à des équipes « distribuées ». Une équipe qui n’est pas co-localisée est une équipe « non regroupée » ou « délocalisée ». Donnez-lui ce nom là et soyez transparent et ouvert à propos des difficultés et des inefficacités du travail en équipe qui peuvent vraisemblablement surgir d’un tel modèle.

 

18 – « Sens de l’expression « être agile » »

 

Éviter  d’utiliser l’expression « être agile » comme un euphémisme d’ « être réactif » ou encore faire le travail « plus vite et moins cher ». Une équipe agile est une équipe qui a le contrôle total de son travail en cours et des tâches qu’elle décide d’embarquer. Les économies qui seront faites viendront de la capacité de l’équipe à pratiquer l’amélioration continue, à grandir dans sa capacité à évaluer sa vélocité de manière empirique, et à réduire le gâchis.

 

19 – « Agile à l’échelle »

 

Évitez de parler de « agile à l’échelle »  alors que la transformation de l’organisation de l’entreprise doit encore être menée pour que, même une seule équipe puisse, dans les faits, arriver à une manière agile de travailler.

 

20 – « Collaborateurs = ressources »

 

Et, enfin,  évitez cette tendance à la déshumanisation des collaborateurs en parlant d’eux comme de  « ressources » ou même « jour/homme ».  Si vous conceptualisez les personnes comme des objets inanimés, vous obtiendrez des mêmes personnes moins que ce qu’elles ont à donner.  Les collaborateurs sont des personnes humaines dotées d’un potentiel de créativité et d’innovation ; traitez-les comme tel.

 

Je remercie l’auteur Ian Mitchell de m’avoir permis de traduire et d’adapter son article en langue française, également consultable dans sa version originale.

 

Crédit : Ian Mitchell, at Scrum.org

Traduit par Guillaume DUTEY HARISPE

 

 

Maintenant que vous en savez un peu plus sur « Comment parler agile ? », n’hésitez pas à aller consulter nos articles précédents pour comprendre notre conception de l’agilité chez ANEO et vérifier que vous n’êtes pas tombés dans le piège des absurdités les plus souvent rencontrées !

 

Ça peut aussi vous intéresser
Les Femmes et le Numérique : une histoire de « Je t’aime, moi non plus … »
17 novembre 2021

Les Femmes et le Numérique : une histoire de « Je t’aime, moi non plus … »

Cet article sur les Femmes et le Numérique fait partie de la série sur le thème « Numérique et RSE ». Ils sont publiés par une équipe de consultants Aneo. Ada Lovelace, la pionnière ayant créé la machine analytique… Grace Hopper, « the Queen of software » témoin du premier…
En savoir plus
Article
DevOps et modèles organisationnels
14 septembre 2021

DevOps et modèles organisationnels

Le mouvement DevOps se présente comme une culture impliquant les process, l’outillage et l’organisation. Si les deux premiers axes semblent couverts par des démarches méthodologiques et techniques éprouvées (lean, agilité, automatisation, craft …etc), l’axe organisationnel manque – quant à lui – d’abaques fiables. De ce fait il devient primordial avant…
En savoir plus
Article
Tech Intelligence #6 – Développement du numérique en Afrique : où en est-on ?
20 juillet 2021

Tech Intelligence #6 – Développement du numérique en Afrique : où en est-on ?

La série Tech Intelligence explore des sujets variés de la tech : cloud, cybersécurité, blockchain … Aujourd’hui, découvrez un rapide coup d’oeil sur le développement du numérique sur le continent africain. Cliquez ici pour retrouver les autres sujets traités par Tech Intelligence.  Tout miser sur la téléphonie…
En savoir plus
Article
Vous avez un projet de transformation
digitale pour votre entreprise ?