L’Agilité à l’échelle ne fonctionne pas… sans approche systémique.

Fin 2015, j’accompagne une entreprise leader du revêtement de sol dans son projet d’amélioration de l’expérience utilisateur. Une centaine de collaborateurs répartis sur 3 continents doivent œuvrer dans un même but défini par le DSI. Et tout ça en mode agile! Dans une organisation hiérarchique silotée! Rien de mieux que SAFe (d’après le client). Et pourtant. Un cadre agile de conduite de projet ne transforme pas à lui seul une organisation. Cette difficulté de mise à l’échelle de l’Agilité fissure aujourd’hui la communauté agile. Pourquoi le Manifeste Agile ne répond pas aux besoins de l’agilité organisationnelle?

Les individus et leurs interactions plus que les processus et les outils

La première valeur du Manifeste est efficace dans une équipe de 7 personnes. Qu’en est-il pour 700 ? 7000 ? Créer et synchroniser 1000 équipes agiles ? D’autant plus qu’aujourd’hui, les équipes distribuées sont monnaie courante.

Les différentes cultures, les différents fuseaux horaires, les différentes langues sont autant d’obstacles à la mise à l’échelle de l’Agile. Je travaille avec des équipes russes, serbes, irlandaises, brésiliennes, françaises et américaines. De légers compromis sont nécessaires lors des planifications de versions et des synchronisations:

  • Nous nous exprimons tous en anglais. Cependant, de nombreuses incompréhensions sont relevées.
  • L’agenda est personnalisé pour permettre à tout le monde de participer.
  • Notre Team Agreement est partagé.

Travailler de façon collaborative demande de définir un certain nombre de règles, d’outils et de processus. Et SAFe répond en partie à ce besoin. Mais il existe une grande différence entre agilité d’équipe à grande échelle et agilité organisationnelle.

La systémique nous apprend que tout changement de l’état d’équilibre d’une organisation résulte d’une co-construction de l’ensemble de ses éléments. Il est donc préférable de co-construire les règles et les processus. Mais à 7000, pas évident !

Une solution : les Communautés. Au nombre de 3, elles développent la flexibilité de l’entreprise.

  • Les Communautés de Pratiques (comparables aux « Chapters » de Spotify) regroupent des collaborateurs de même métier. Elles définissent les bonnes pratiques, les règles « Métier ».
  • Les Communautés de Produit/Service définissent les règles et les processus relatifs à un produit ou à un service, à la production de valeur de l’organisation (« Tribes » ou « Feature Team »).
  • Les Communautés de But se focalisent sur les process et outils davantage transverses (ex : Communauté de But : Apprenance). Chaque collaborateur fait partie d’une ou plusieurs communautés selon ses propres choix. Au final, une Communauté de But : Gouvernance discute des axes stratégiques de l’organisation.

Des logiciels opérationnels plus qu’une documentation exhaustive

Qu’en est-il quand l’organisation commercialise plusieurs produits ? Plusieurs services ? Avec potentiellement plusieurs modèles économiques par produit. Les équipes perdent de vue la « Big Picture » de l’organisation. Malgré le PI Planning (planification à grande échelle de la méthode SAFe), les Features Teams (équipes auto-organisées) mises en place chez mon client ne voient que les fonctionnalités dont elles ont la charge.

Le partage de la vue d’ensemble doit être porté par le partage de la documentation relative à chaque produit. Elle est partie intégrante du produit, élément essentiel  du « Definition of Done ». Car l’Agilité à l’échelle prend en compte l’ensemble de la chaîne « Produit » en tant que “Proposition de valeur”, de la conception au service après-vente. Cette considération systémique réduit les incompréhensions des véritables besoins des utilisateurs. Ainsi la mise en place d’une Culture Produit, facilitée par l’existence des Communautés,  redéfinit les rôles et responsabilités de chacun. Des profils différents communiquent enfin autour d’une vision et d’objectifs communs.

Être ou devenir une entreprise agile n’a de sens que si cet objectif est poursuivi.

La collaboration avec les clients plus que la négociation contractuelle

Cette valeur est basée sur l’idée que la confiance se développe davantage sur des interactions entre les personnes que sur des méthodes formalisées. Elle ne peut se développer qu’à condition que les personnes passent un temps significatif ensemble. Et si vous aviez 10000 clients, pourriez-vous faire confiance à autant de personnes ? Certes, non. C’est pourquoi les équipes agiles comportent moins de 10 collaborateurs. D’un côté, ce manque de confiance est un moyen de protection de votre organisation. De l’autre côté, il mène au « je m’en foutisme » et dégradent les relations entre l’organisation et ses clients. Et les mêmes schémas sont visibles dans l’organisation lorsque les collaborateurs de la maison mère considèrent leur travail comme plus valorisant que celui des collaborateurs des filiales.

Une communication claire et sincère (via les réseaux sociaux pour une plus large diffusion) augmente la relation de confiance entre chaque protagoniste. Davantage, qu’une relation One-on-One avec chacun. Dans un monde digital, l’entreprise qui ne gère pas cette communication se met en danger.

L’adaptation au changement plus que le suivi d’un plan

Il est sûr que dans un environnement volatil, incertain, complexe et ambigu, un plan sur 5 ans est utopiste. Le darwinisme démontre que plus un animal est gros, moins il s’adapte rapidement. Qu’en est-il pour les organisations ? Aujourd’hui, beaucoup de tentatives sont menées dans les entreprises : start-up internes, digital Lab, Design Sprint… Toutes ces approches sont communes : le mode “Commando”. Isoler l’agilité des équipes du système. Et toute l’erreur est là. Une organisation constituée uniquement d’équipes agiles n’est pas nécessairement agile. La communauté agile s’acharne à mettre à l’échelle en irradiant de bas vers le haut, alors que la solution est un changement par conduction transversale.

Aujourd’hui, la communauté agile s’interroge sur la mise à l’échelle de l’agilité. Autrement dit, comment rendre une organisation agile? Tout naturellement, les solutions proposées reposent sur le déploiement de l’agilité des projets.

Or, l’organisation est un système adaptatif complexe beaucoup plus important. Sans les apports de la systémique, l’agilité à grande échelle ne peut fonctionner.

L’agilité n’est pas une destination mais un chemin, pas un objectif mais un moyen”.

Les dé)codeurs – Challenge dé)codeurs #5

decodeurs-bleu-sur-blanc

Bonjour,

Le retour des dé)codeurs format coding : c’est jeudi 16 février.

Venez coder avec de la bière ou du jus de fruit, tester de nouveaux langages et discuter qualité !

— Inscription ici —

Rappel :

Les dé)codeurs, c’est quoi ?

Tous les mois (souvent le 1er mardi du mois) les dé)codeurs se réunissent au choix pour

-un challenge dé)codeurs : par équipe on s’entraîne sur un sujet avec le langage qu’on veut et on échange ensuite

-un Buzz Light Talks : des talks d’une quinzaine de minutes suivis d’échanges

Booksprint : la suite de mon expérience

Je continue le partage de mon expérience agile du booksprint Agile Rocket Guide à l’aide du Manifeste agile. Après un 1er article balayant les 3 premiers principes, je continue le voyage dans le manifeste.

Travailler en équipe

Communiquer avec les utilisateurs

Pendant ces 4 jours de booksprint, la durée des sprints varie entre 1 et 2 heures donc au plus toutes les 2 heures, nous nous synchronisons avec le reste de l’équipe et notamment Christophe qui est en quelque sorte le Product Owner, pour être sûr qu’on ne dérive pas sur le contenu.IMG_20161217_170732.jpg

Nous avons également le souci de communiquer le plus vite possible avec l’extérieur et certains de nos utilisateurs identifiés. Dès le début du 2ème jour, nous envoyons un mail à nos collègues de Goood! pour leur demander du feedback sur le contenu produit puisqu’ils sont représentés par nos personas Kouigna man le gooodien et Milouz le coach.

Lire la suite

Goood! sponsor d’Agile Lyon 2017

logo-cara-agile-lyon

La journée Agile Lyon 2017 aura lieu le 09 février 2017 dans les locaux de Supinfo à Lyon.
Le sujet cette année : « La Culture ».

agile-lyon-date

Réservez votre place

Notre stand

C’est avec une grande fierté que Goood! sera, pour la première fois, sponsor de l’événement. Vous pourrez nous retrouver sur notre merveilleux stand et discuter avec Céline et Olivier.

Lire la suite

Boooksprint : 4 jours d’une expérience agile

Du 17 au 20 décembre dernier, j’ai participé à Carnac à une super expérience agile comme je n’ai plus l’occasion d’en vivre, un booksprint : écrire un livre en 4 jours en équipe, avec 4 collègues de Goood!.

Le sujet, c’est l’Agile Rocket, une transformation agile modulaire et progressive et l’objectif de ces 4 jours est de produire un guide pour clients et coachs.

Le résultat de ces 4 jours a été publié quelques jours plus tard en PDF et nous avons prolongé l’expérience en janvier avec quelques améliorations, de forme essentiellement, nous amenant à la publication de l’Agile Rocket 1.1 maintenant ! Vous pouvez enfin accéder sur google drive au guide constamment à jour avec les dernières modifications, en déploiement continu.

4 jours, 5 cerveaux, 11 sprints, 25 standups, 11 rétrospectives, 125 pages écrites et un concentré d’une expérience agile avec ses changements, ses doutes, ses rebondissements, ses joies. Notre expérience de booksprint à 5, nous la raconterons le 31 janvier à 18h45 dans nos locaux (les places sont disponibles ici) et je vais commencer par vous raconter ici mon expérience, en quoi elle est agile, et en quoi l’agile, souvent, c’est pas facile !

Pour ce faire, je vais utiliser comme grille de lecture le manifeste agile et ses 12 principes et les 3 premiers pour commencer. Lire la suite

Sculptez vos user stories et critères d’acceptance à l’aide de questions

5047534162_4332d7305d_z

Une idée de fonctionnalité est comme un matériau brut que l’on peut s’amuser à sculpter. Je l’ai remarqué lors d’ateliers en questionnant les équipes que j’accompagne sur les fonctionnalités qu’elles veulent développer et la manière dont elles comptent les valider. J’utilise les trames “User story” et BDD (Behaviour Driven Development) pour capturer l’essence du besoin et la manière dont la réponse pourra être observée une fois la fonctionnalité développée. Je trouve beaucoup de valeur à ce type d’atelier car, d’une part, il permet aux équipes de se former aux user stories et aux scénarios BDD en utilisant leur propres sujets et d’autre part, de s’imprégner du format de l’atelier qu’elles peuvent réutiliser.
Lire la suite