ATMTL23 - Comment nos organisations évoluent vers l'agilité : les premiers résultats de l'analyse PhylOrg par Olivier Bertrand
•
1 j'aime•91 vues
Cette conférence fait suite à celle présentée pour la première fois à Agile Tour Montréal 2022 (https://www.youtube.com/watch?v=8LgFgWjkiX8), qui proposait de radicalement repenser la transformation des organisations, sur un modèle inspiré de la Théorie de l'Évolution. Après un an d'analyses, nous viendrons présenter les premières conclusions partielles, et un raffinement du modèle PhylOrg, parmi lesquelles les archétypes évolutifs qui semblent émerger de l'analyse des données du modèle.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à ATMTL23 - Comment nos organisations évoluent vers l'agilité : les premiers résultats de l'analyse PhylOrg par Olivier Bertrand
Similaire à ATMTL23 - Comment nos organisations évoluent vers l'agilité : les premiers résultats de l'analyse PhylOrg par Olivier Bertrand (20)
Plus de Agile Montréal
Plus de Agile Montréal (16)
Dernier
Dernier (16)
ATMTL23 - Comment nos organisations évoluent vers l'agilité : les premiers résultats de l'analyse PhylOrg par Olivier Bertrand
- 2. Bonjour! Nous sommes phylorg El Bachir ARAQI Olivier BERTRAND Garance Richard Une première expérience PhylOrg: basée sur 3 conférences en 2022-2023 Phylogénétique des Organisations #PhylOrg Google Docs La donnée Des réponses "en grappe" l'arbre se construit et s'optimise en continu Comment Utiliser PhylOrg ? www.phylorg.com https:/ /discord.gg/zCuM9vxXrx La suite : Continuons la conversation! Les bases de PhylOrg ↓Small_Batch ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↓Cust_Feedback ↓Archi_Non_Mono ↓Tests_Autom ↓Tests_Autom ↓Small_Batch ↓Archi_Non_Mono ↓Risques ↓Depl_Autom ↓WIP_Limits ↑Archi_Non_Mono ↑Cust_Feedback ↑Tests_Autom ↑Small_Batch ↑Risques ↓Archi_Non_Mono ↓Depl_Autom ↓Vision_Claire ↑Cust_Feedback ↓Vision_Claire|↑Tests_Autom|↑Small_Batch ↓WIP_Limits ↑Risques ↓Risques ↓Small_Batch ↓WIP_Limits ↓Risques ↓Vision_Claire ↓Tests_Autom ↑Cust_Feedback ↑Depl_Autom ↓Vision_Claire ↓Archi_Non_Mono|↑Cust_Feedback ↑Cust_Feedback ↑Risques|↑WIP_Limits ↑Risques ↑WIP_Limits ↑Tests_Autom ↓Risques ↑Vision_Claire|↑Risques ↑Cust_Feedback ↑Tests_Autom|↑Archi_Non_Mono ↑Archi_Non_Mono ↓Tests_Autom ↑WIP_Limits ↓Cust_Feedback ↓Vision_Claire ↑Tests_Autom ↓Depl_Autom ↑Tests_Autom|↑WIP_Limits ↓Risques ↑Cust_Feedback ↑Archi_Non_Mono ↑Vision_Claire ↑Depl_Autom ↓Tests_Autom ↑WIP_Limits ↑Risques ↑Vision_Claire ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↑Small_Batch ↑Tests_Autom ↑WIP_Limits ↓Cust_Feedback|↑WIP_Limits ↓Cust_Feedback ↑Tests_Autom ↓Archi_Non_Mono|↓Risques ↓Archi_Non_Mono ↓Risques ↓WIP_Limits ↑Cust_Feedback ↑Small_Batch ↑Vision_Claire ↑Vision_Claire|↑Tests_Autom ↓Tests_Autom|↑Archi_Non_Mono ↑Risques ↑Vision_Claire ↓Risques ↑Vision_Claire ↑Depl_Autom ↓Depl_Autom ↓Tests_Autom ↑Archi_Non_Mono ↑Risques ↑Archi_Non_Mono ↑Archi_Non_Mono|↑Cust_Feedback ↑Vision_Claire|↓Risques ↓Archi_Non_Mono ↓WIP_Limits ↓WIP_Limits ↑Cust_Feedback ↓Cust_Feedback ↓Risques 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 l'arbre phylorg des Agile Tours (nov 2023) 1 0 Pour récapituler, chemin émergent de « 0 » à « 1 » : Travailler en petits lots Avoir une vision claire Obtenir les commentaires des clients automatisation des tests Permettre aux équipes de prendre des risques Configuration des limites d'en- cours Découplage de votre architecture (ou maintien d'une architecture non monolithique) suivi d'une plus grande capacité à prendre des risques Automatisation des déploiements 1. 2. 3. 4. 5. 6. 7. 8. Le chemin n'est ni définitif, ni le même pour tout le monde! Des données d'agilistes font ressortir en premier le travail en petits lots :) Avoir une vision claire semble être un pré- requis. Mais même s'il apparaît tôt sur l'arbre, il ne s'agit pas d'une bifurcation majeure, ce qui signifie que la majorité de notre ensemble de données a ce trait compris (ou prétend l'avoir). Ceux qui n’ont pas une vision claire s’arrêtent tôt sur le chemin et restent proches de 0. La capacité à prendre des risques apparaît deux fois sur le chemin de l'évolution. Une fois après avoir mis en place la vision initiale, et une seconde fois après avoir découplé notre architecture technique. Une interprétation pourrait être que ces 2 étapes contribuent toutes deux à accroître la tolérance au risque dans les organisations : la vision donne à l'équipe une certaine liberté pour essayer de nouvelles choses, l'architecture découplée réduit la probabilité de mauvaises conséquences. Certaines bifurcations ont plus d’impact que d’autres. Ce sont ceux pour lesquels les trajectoires « ascendantes » et « descendantes » de la population sont significatives. Par exemple, « l’architecture non monolithique » en fait partie. Passer de 0 à 1 n’est pas le seul scénario utile à visualiser. En réalité, la plupart des cas d'utilisation réels ne partiront pas de 0 et ne souhaiteront pas nécessairement atteindre un 1 idéaliste. Cette méthode nous aidera plutôt à identifier les bifurcations clés auxquelles ils doivent revenir avant de pouvoir mettre en œuvre avec succès. plus de changements. Toutes les organisations qui n'ont pas pris le virage « architecture non monolithique » ne seront pas en mesure d'atteindre des caractéristiques plus dérivées si elles ne prennent pas d'abord le virage « vers le bas » à ce stade. Quelques interprétations Cas d’usage Le cas classique : “La Transfo Agile” - Nous voulons devenir Google ou Spotify! Diagnostic et étude comparative : Pourquoi j’y arrive moins bien que mon voisin? Fusion Acquisition : Sommes- nous faits l’un pour l’autre? Fusion Acquisition : Pour le meilleur et pour le pire - on se retrouve à mi- chemin? Organisations complexes, départements en silos - Apprenons à parler le même langage pour fluidifier nos interactions 1. 2. 3. 4. 5. ↓Small_Batch ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↓Cust_Feedback ↓Archi_Non_Mono ↓Tests_Autom ↓Tests_Autom ↓Small_Batch ↓Archi_Non_Mono ↓Risques ↓Depl_Autom ↓WIP_Limits ↑Archi_Non_Mono ↑Cust_Feedback ↑Tests_Autom ↑Small_Batch ↑Risques ↓Archi_Non_Mono ↓Depl_Autom ↓Vision_Claire ↑Cust_Feedback ↓Vision_Claire|↑Tests_Autom|↑Small_Batch ↓WIP_Limits ↑Risques ↓Risques ↓Small_Batch ↓WIP_Limits ↓Risques ↓Vision_Claire ↓Tests_Autom ↑Cust_Feedback ↑Depl_Autom ↓Vision_Claire ↓Archi_Non_Mono|↑Cust_Feedback ↑Cust_Feedback ↑Risques|↑WIP_Limits ↑Risques ↑WIP_Limits ↑Tests_Autom ↓Risques ↑Vision_Claire|↑Risques ↑Cust_Feedback ↑Tests_Autom|↑Archi_Non_Mono ↑Archi_Non_Mono ↓Tests_Autom ↑WIP_Limits ↓Cust_Feedback ↓Vision_Claire ↑Tests_Autom ↓Depl_Autom ↑Tests_Autom|↑WIP_Limits ↓Risques ↑Cust_Feedback ↑Archi_Non_Mono ↑Vision_Claire ↑Depl_Autom ↓Tests_Autom ↑WIP_Limits ↑Risques ↑Vision_Claire ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↑Small_Batch ↑Tests_Autom ↑WIP_Limits ↓Cust_Feedback|↑WIP_Limits ↓Cust_Feedback ↑Tests_Autom ↓Archi_Non_Mono|↓Risques ↓Archi_Non_Mono ↓Risques ↓WIP_Limits ↑Cust_Feedback ↑Small_Batch ↑Vision_Claire ↑Vision_Claire|↑Tests_Autom ↓Tests_Autom|↑Archi_Non_Mono ↑Risques ↑Vision_Claire ↓Risques ↑Vision_Claire ↑Depl_Autom ↓Depl_Autom ↓Tests_Autom ↑Archi_Non_Mono ↑Risques ↑Archi_Non_Mono ↑Archi_Non_Mono|↑Cust_Feedback ↑Vision_Claire|↓Risques ↓Archi_Non_Mono ↓WIP_Limits ↓WIP_Limits ↑Cust_Feedback ↓Cust_Feedback ↓Risques NOUVEAU SONDAGE PHYLORG
- 3. Une première expérience PhylOrg: basée sur 3 conférences en 2022-2023 Phylogénétique des Organisations #PhylOrg Google Docs La donnée Des réponses "en grappe" l'arbre se construit et s'optimise en continu ↓Small_Batch ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↓Cust_Feedback ↓Archi_Non_Mono ↓Tests_Autom ↓Tests_Autom ↓Small_Batch ↓Archi_Non_Mono ↓Risques ↓Depl_Autom ↓WIP_Limits ↑Archi_Non_Mono ↑Cust_Feedback ↑Tests_Autom ↑Small_Batch ↑Risques ↓Archi_Non_Mono ↓Depl_Autom ↓Vision_Claire ↑Cust_Feedback ↓Vision_Claire|↑Tests_Autom|↑Small_Batch ↓WIP_Limits ↑Risques ↓Risques ↓Small_Batch ↓WIP_Limits ↓Risques ↓Vision_Claire ↓Tests_Autom ↑Cust_Feedback ↑Depl_Autom ↓Vision_Claire ↓Archi_Non_Mono|↑Cust_Feedback ↑Cust_Feedback ↑Risques|↑WIP_Limits ↑Risques ↑WIP_Limits ↑Tests_Autom ↓Risques ↑Vision_Claire|↑Risques ↑Cust_Feedback ↑Tests_Autom|↑Archi_Non_Mono ↑Archi_Non_Mono ↓Tests_Autom ↑WIP_Limits ↓Cust_Feedback ↓Vision_Claire ↑Tests_Autom ↓Depl_Autom ↑Tests_Autom|↑WIP_Limits ↓Risques ↑Cust_Feedback ↑Archi_Non_Mono ↑Vision_Claire ↑Depl_Autom ↓Tests_Autom ↑WIP_Limits ↑Risques ↑Vision_Claire ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↑Small_Batch ↑Tests_Autom ↑WIP_Limits ↓Cust_Feedback|↑WIP_Limits ↓Cust_Feedback ↑Tests_Autom ↓Archi_Non_Mono|↓Risques ↓Archi_Non_Mono ↓Risques ↓WIP_Limits ↑Cust_Feedback ↑Small_Batch ↑Vision_Claire ↑Vision_Claire|↑Tests_Autom ↓Tests_Autom|↑Archi_Non_Mono ↑Risques ↑Vision_Claire ↓Risques ↑Vision_Claire ↑Depl_Autom ↓Depl_Autom ↓Tests_Autom ↑Archi_Non_Mono ↑Risques ↑Archi_Non_Mono ↑Archi_Non_Mono|↑Cust_Feedback ↑Vision_Claire|↓Risques ↓Archi_Non_Mono ↓WIP_Limits ↓WIP_Limits ↑Cust_Feedback ↓Cust_Feedback ↓Risques 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 l'arbre phylorg des Agile Tours (nov 2023) 1 0 Pour récapituler, chemin émergent de « 0 » à « 1 » : Travailler en petits lots Avoir une vision claire Obtenir les commentaires des clients automatisation des tests Permettre aux équipes de prendre des risques Configuration des limites d'en- cours Découplage de votre architecture (ou maintien d'une architecture non monolithique) suivi d'une plus grande capacité à prendre des risques Automatisation des déploiements 1. 2. 3. 4. 5. 6. 7. 8. Le chemin n'est ni définitif, ni le même pour tout le monde! Des données d'agilistes font ressortir en premier le travail en petits lots :) Avoir une vision claire semble être un pré- requis. Mais même s'il apparaît tôt sur l'arbre, il ne s'agit pas d'une bifurcation majeure, ce qui signifie que la majorité de notre ensemble de données a ce trait compris (ou prétend l'avoir). Ceux qui n’ont pas une vision claire s’arrêtent tôt sur le chemin et restent proches de 0. La capacité à prendre des risques apparaît deux fois sur le chemin de l'évolution. Une fois après avoir mis en place la vision initiale, et une seconde fois après avoir découplé notre architecture technique. Une interprétation pourrait être que ces 2 étapes contribuent toutes deux à accroître la tolérance au risque dans les organisations : la vision donne à l'équipe une certaine liberté pour essayer de nouvelles choses, l'architecture découplée réduit la probabilité de mauvaises conséquences. Certaines bifurcations ont plus d’impact que d’autres. Ce sont ceux pour lesquels les trajectoires « ascendantes » et « descendantes » de la population sont significatives. Par exemple, « l’architecture non monolithique » en fait partie. Passer de 0 à 1 n’est pas le seul scénario utile à visualiser. En réalité, la plupart des cas d'utilisation réels ne partiront pas de 0 et ne souhaiteront pas nécessairement atteindre un 1 idéaliste. Cette méthode nous aidera plutôt à identifier les bifurcations clés auxquelles ils doivent revenir avant de pouvoir mettre en œuvre avec succès. plus de changements. Toutes les organisations qui n'ont pas pris le virage « architecture non monolithique » ne seront pas en mesure d'atteindre des caractéristiques plus dérivées si elles ne prennent pas d'abord le virage « vers le bas » à ce stade. Quelques interprétations
- 4. ↓Small_Batch ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↓Cust_Feedback ↓Archi_Non_Mono ↓Tests_Autom ↓Tests_Autom ↓Small_Batch ↓Archi_Non_Mono ↓Risques ↓Depl_Autom ↓WIP_Limits ↑Archi_Non_Mono ↑Cust_Feedback ↑Tests_Autom ↑Small_Batch ↑Risques ↓Archi_Non_Mono ↓Depl_Autom ↓Vision_Claire ↑Cust_Feedback ↓Vision_Claire|↑Tests_Autom|↑Small_Batch ↓WIP_Limits ↑Risques ↓Risques ↓Small_Batch ↓WIP_Limits ↓Risques ↓Vision_Claire ↓Tests_Autom ↑Cust_Feedback ↑Depl_Autom ↓Vision_Claire ↓Archi_Non_Mono|↑Cust_Feedback ↑Cust_Feedback ↑Risques|↑WIP_Limits ↑Risques ↑WIP_Limits ↑Tests_Autom ↓Risques ↑Vision_Claire|↑Risques ↑Cust_Feedback ↑Tests_Autom|↑Archi_Non_Mono ↑Archi_Non_Mono ↓Tests_Autom ↑WIP_Limits ↓Cust_Feedback ↓Vision_Claire ↑Tests_Autom ↓Depl_Autom ↑Tests_Autom|↑WIP_Limits ↓Risques ↑Cust_Feedback ↑Archi_Non_Mono ↑Vision_Claire ↑Depl_Autom ↓Tests_Autom ↑WIP_Limits ↑Risques ↑Vision_Claire ↓Archi_Non_Mono ↓WIP_Limits ↓Vision_Claire ↑Small_Batch ↑Tests_Autom ↑WIP_Limits ↓Cust_Feedback|↑WIP_Limits ↓Cust_Feedback ↑Tests_Autom ↓Archi_Non_Mono|↓Risques ↓Archi_Non_Mono ↓Risques ↓WIP_Limits ↑Cust_Feedback ↑Small_Batch ↑Vision_Claire ↑Vision_Claire|↑Tests_Autom ↓Tests_Autom|↑Archi_Non_Mono ↑Risques ↑Vision_Claire ↓Risques ↑Vision_Claire ↑Depl_Autom ↓Depl_Autom ↓Tests_Autom ↑Archi_Non_Mono ↑Risques ↑Archi_Non_Mono ↑Archi_Non_Mono|↑Cust_Feedback ↑Vision_Claire|↓Risques ↓Archi_Non_Mono ↓WIP_Limits ↓WIP_Limits ↑Cust_Feedback ↓Cust_Feedback ↓Risques 0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 l'arbre phylorg des Agile Tours (nov 2023) 1 0 Pour récapituler, chemin émergent de « 0 » à « 1 » : Travailler en petits lots Avoir une vision claire Obtenir les commentaires des clients automatisation des tests Permettre aux équipes de prendre des risques Configuration des limites d'en- cours Découplage de votre architecture (ou maintien d'une architecture non monolithique) suivi d'une plus grande capacité à prendre des risques Automatisation des déploiements 1. 2. 3. 4. 5. 6. 7. 8.
- 5. Le chemin n'est ni définitif, ni le même pour tout le monde! Des données d'agilistes font ressortir en premier le travail en petits lots :) Avoir une vision claire semble être un pré- requis. Mais même s'il apparaît tôt sur l'arbre, il ne s'agit pas d'une bifurcation majeure, ce qui signifie que la majorité de notre ensemble de données a ce trait compris (ou prétend l'avoir). Ceux qui n’ont pas une vision claire s’arrêtent tôt sur le chemin et restent proches de 0. La capacité à prendre des risques apparaît deux fois sur le chemin de l'évolution. Une fois après avoir mis en place la vision initiale, et une seconde fois après avoir découplé notre architecture technique. Une interprétation pourrait être que ces 2 étapes contribuent toutes deux à accroître la tolérance au risque dans les organisations : la vision donne à l'équipe une certaine liberté pour essayer de nouvelles choses, l'architecture découplée réduit la probabilité de mauvaises conséquences. Certaines bifurcations ont plus d’impact que d’autres. Ce sont ceux pour lesquels les trajectoires « ascendantes » et « descendantes » de la population sont significatives. Par exemple, « l’architecture non monolithique » en fait partie. Passer de 0 à 1 n’est pas le seul scénario utile à visualiser. En réalité, la plupart des cas d'utilisation réels ne partiront pas de 0 et ne souhaiteront pas nécessairement atteindre un 1 idéaliste. Cette méthode nous aidera plutôt à identifier les bifurcations clés auxquelles ils doivent revenir avant de pouvoir mettre en œuvre avec succès. plus de changements. Toutes les organisations qui n'ont pas pris le virage « architecture non monolithique » ne seront pas en mesure d'atteindre des caractéristiques plus dérivées si elles ne prennent pas d'abord le virage « vers le bas » à ce stade. Quelques interprétations
- 6. Comment Utiliser PhylOrg ? Cas d’usage Le cas classique : “La Transfo Agile” - Nous voulons devenir Google ou Spotify! Diagnostic et étude comparative : Pourquoi j’y arrive moins bien que mon voisin? Fusion Acquisition : Sommes- nous faits l’un pour l’autre? Fusion Acquisition : Pour le meilleur et pour le pire - on se retrouve à mi- chemin? Organisations complexes, départements en silos - Apprenons à parler le même langage pour fluidifier nos interactions 1. 2. 3. 4. 5.
- 7. www.phylorg.com https:/ /discord.gg/zCuM9vxXrx La suite : Continuons la conversation! NOUVEAU SONDAGE PHYLORG