Vous êtes à la recherche du Saint Graal de l'agilité à grande échelle : quel framework faut-il utiliser selon votre organisation ? Et si, comme dans toute aventure, ce n'est pas la destination mais le voyage qui importe le plus ? Avant de définir votre nouvelle organisation, une multitude d'épreuves vous attendent.
En tant que coachs agiles explorateurs, nous avons préparé pour vous le guide ultime pour :
vous poser les "bonnes" questions concernant le pourquoi de l'agilité à grande échelle avant de s'interroger sur le comment,
identifier les contraintes,
simplifier la mise à l'échelle,
enfin piocher les tips d’organisation dans les différents frameworks de façon éclairée.
Nous illustrerons ce guide avec des histoires vécues tirées de nos expériences de mise à l'échelle.
Tentez l’aventure, nous vous éclairerons sur les chemins de l’agilité à l’échelle pour (unFix)er votre organisation tout en restant (Safe). Alors (Less)ez vous faire !
2. Gilles Brieux
Convaincu par les valeurs que véhicule
l’agilité, je transmets mon savoir et mon
énergie pour accompagner des équipes et
des organisations désirant se
transformer.
Qui suis-je ?
Coach Agile
Formateur
Facilitation de groupe
Formation
Techniques de créativité
Pratiques managériales
Quelques références
3. Aurélie ROBERT
Je cherche à (re) donner du sens, créer
des liens et de la collaboration.
Je combine différentes approches (Agilité,
UX, Management 3.0...), pour révéler le
potentiel de chacun et donner un élan
collectif.
Qui suis-je ?
Coach Agile
Product Owner
Vision Produit & Innovation
Organisation
Facilitation groupe
Pratiques managériales
Quelques références
6. L’agilité à l’échelle c’est quoi ?
Elargir les valeurs, principes
et pratiques agiles
Synchroniser les équipes
vers des objectifs communs.
7. Les enjeux de ce voyage ?
Aligner les
enjeux
stratégiques de
l’entreprise
Améliorer la
réactivité sur le
marché
Optimiser les
ressources
Eviter le
gaspillage
9. ..et nous avons face à nous….
Produits complexes TTM
trop élevée
CAF
faible
Ressources humaines
diversifiées
10. Loi de Brooks :
𝑛(𝑛−1)
2
A chaque fois qu’une personne intègre une
équipe, les relations sont démultipliées de
manière exponentielle
The mythical man month
Fred Brooks
12. Charge cognitive
des équipe
La somme d'informations que l'équipe
doit gérer simultanément, incluant
• la complexité des tâches,
• Les tâches non finies,
• les interdépendances,
• les changements constants,
• les outils et technologies,
• le contexte organisationnel
• la vision pas comprise ou inexistante
13. Objectif 1 :
Manœuvre de
CONWAY
inversée
Se baser sur une architecture simple
au service du produit
14. Objectif 2 :
Optimiser les
interactions
entre les équipes
Eviter la charge mentale, la
dispersion cognitive et
l’interdépendance
21. 1 Backlog / Pls Equipe
Value Maximizer
Maintien polyvalence
technico-fonctionnelle
Difficulté d’avoir 1 identité
d’équipe
Complexité du produit non «
diminuée » engendrant
dépendances
22. Mauvais chemins et embuches
Ecueil : Repartition backlog de sprint selon
des spécificités d’équipe non avouées
(silos fonctionnels ou technique)
Objectif Orga : Faciliter la priorisation en
limitant les adhérences technico-
fonctionnelles entre équipes
• Créer des “vraies” équipes polyvalentes
• Minimiser les dépendances techniques et
fonctionnelles
Challenge : Sécurité psy des équipes auto-
apprenantes
23. Diminuer la complexité de votre produit
Partie prenante
(persona)
Pan fonctionnel Process
canal client
24. Pls Backlogs / Pls Equipes
Partition du backlog
Equipes autonome sur leur périmètre
Synchronisation global « produit » à
prévoir
Diminution complexité
Diminution « charge mentale »
Synchro entre équipe et
alignement produit
Value maximizer
25. Mauvais chemins et embuches
Ecueil : Découper par pan technique
(component team)
Objectif Orga : découper pour avoir des
équipes le + autonomes possibles :
• minimiser dépendances fonctionnelles et
techniques
• Spécialiser les équipes sur 1 seul critère
• Alignement fonctionnel et technique
Challenge : « Value Maximizer" attention
à bien réaliser un produit vs alimenter
des équipes
27. Gérer les dépendances
1 backlog par équipe
Synchronisation pour gérer les
liaisons
Dépendances en partie assumée
Gérer les contraintes de
synchronisation
Complexité du SI non diminuée
Pas de synergies des équipes
Création de files d’attentes
28. Mauvais chemins et embuches
Ecueil : Utiliser ces modèles pour aligner
les équipes sur des objectifs stratégiques
Objectif Orga : simplifier la gestion des
dépendances entre produits/équipe
Respecter la diversité des équipes
Challenge : Rassembler seulement les
équipes ayant des dépendances.
29. Dé-Lier les produits
Supprimer les dépendances techniques
ou fonctionnelles
N’est pas préconiser MAIS peu parfois
engendrer de la complexité de
synchronisation
Value Maximizer
Innovation
Diminuer la complexité
Diminuer le TTM
perte liée aux doublons
30. Mauvais chemins et embuches
Ecueil : Généraliser ce modèle de “non-
mutualisation”
Objectif Orga : simplifier la gestion des
dépendances entre produits/équipe
Respecter la diversité des équipes
Challenge : Innover et simplifier les
synchronisation
32. Aligner stratégie entreprise
Gestion de portefeuille produits
(Portfolio management)
Autres outils type
- OKR
- Impact Mapping
- LPM
Donner du sens & laisser les équipes
s’organiser
33. Alignement "clients finaux"
Penser aux contraintes de vos utilisateurs
finaux
Quelle est leur capacité à accepter vos
livraisons de valeur ?
Besoin de formation ? Aisance avec le
numérique ?
Est-ce que livrer régulièrement a réellement
du sens pour cette cible UX ou market ?
Votre besoin ?
Stratégie de formation ?
Stratégie de déploiement ?
Beta testeurs ? 3 release par an ? Ou toutes les 3
semaines ?
34. Alignement “métiers”
Penser aux contraintes
des réprésentants du besoin?
Quelle disponibilité ?
Quel équilibre entre leur quotidien et le
détachement auprès des produits ?
Quelle "maille" de travail ? Epic ? US ?
Sur la solution ou le besoin
Votre besoin ?
Business Owner ? Key user ?
PO ? PM ?
35. Alignement Fonctionnel
Prise de décision par 1 personne
1 équipe => PO
Pls PO => CPO, PM, SPO
Gouvernance Produit
- equipe PO = equipe scrum
(avec ou sans PO)
Priorisation selon critères
propres
36. Alignement organisationnel
Remonter au plus tôt les points de
blocage au niveau où ils peuvent être
traités
Bureaucratie Minimum Viable
• SoS : Coordination équipes
• SoSoS : Coordination de plusieurs SoS
• Executive Action Team : Pilotage de la transfo
Des rôles
• RTE, STE, LACE
37. Alignement du rythme
Scrum : cadencé
Kanban : mode flux
Ou vers un modèle mixte
Ex:
Equipe de réalisation: En scrum
Equipes de prod : En Kanban prod
38. Aligner les types d’équipes
1.Stream-aligned Team : Flux, produit,
rapidité.
2.Enabling Team : Soutien, expertise
3.Complicated Subsystem Team :
Spécialisation, complexité, composants.
4.Platform Team : Infrastructure,
services, échelle.
39. Aligner les relations
1.Collaboration: relation de travail
étroite.
2.X-as-a-Service (XaaS): fournit
quelque chose en tant que service à
une autre équipe.
3.Facilitating: aide une autre équipe à
surmonter un obstacle
41. Alignement des pratiques &
compétences
Communautés de pratiques (CoP)
• communautés de testeurs
• communautés des Dev
• communautés de Scrum Master
VS
Un modèle centre de compétences
(CdC)
43. Repartir des besoins, pas
des solutions
• Connaitre les besoins pour passer d’une
idée à sa livraison aux utilisateur finaux
• Identifier les « vraies » contraintes de
votre organisation (inamovible à court
terme)
Réaliser des interviews des
différents rôles comme si vous
étiez un stagiaire (Pourquoi ?)
44. Miser sur les acteurs du
système
• Explorer les avantages et inconvénients
des futurs possibles
Open Space Technology,
World café et des sessions
d’idéations :
« Et si demain les testeurs n’étaient
plus regroupés dans une équipe As
Service ? »
45. Concevoir VOTRE modèle
Co-construire une
organisation émergente
Définir les flux, les rôles, les
évènements, les rythmes …
• En petit groupe multi compétences
• Pas qu’entre manageurs
Enrichissement progressif
(1er jet à 3 pers. puis à 5 etc.)
Adoptez un coach expérimenté
47. Decider
• Conscient qu’il n’y a pas de solutions
parfaites « moins pire des compromis »
• Décideur(s) vont endosser la
responsabilité de cette décision
imparfaite
Veillez au mode de prise de décision :
pas de consensus mou – pas
de compromis
Posez le cadre de la décision :
ce qui est négociable et ce qui ne l’est pas
48. Conduire le changement
Faire la promotion et la communication
• partager les éléments qui vous ont fait
prendre ces choix pour favoriser l’adhésion
• partager vos doutes
• un modèle d’orga doit être compréhensible
car simple
• appuyer vous sur des rôles clés motivés et
promoteurs, ils seront votre voix et vos
oreilles
=> Vers une organisation apprenante
Les retros pour sécuriser les choix
49. Mesurer la maturité « agile »
Outils d’évaluation « santé » des équipes
Outils d’évaluation maturité
Squad Health Check
Org Topologies ™
50. Une dose de féérie
Tout changement génère un stress, à vous de
l’orienter
Accompagner l’inconfort provisoire mais
luttez contre l’insécurité psychologique
Rien sous le tapis, la transparence est
votre allié
Communiquez évolution
Attitude ni optimiste ni pessimiste
Rappeler le « Pourquoi? » du changement
Choisissez des noms suscitant l’ adhésion
Faites du changement un moment de
cohésion
51. Les refuges du GR
POSEZ VOUS DES QUESTIONS
POUR REPARTIR DES BESOINS ET
DES VRAIES CONTRAINTES
CO-CONSTRUISEZ VOTRE
ORGANISATION
TESTEZ DES HYPOTHÈSES
D’ORGANISATION AUPRÈS DES
FUTURS ACTEURS
DÉCIDEZ ET CONDUIRE LE
CHANGEMENT
61. Diminuer la complexité
de votre produit
• Partition du backlog
• Equipes autonome sur leur
périmètre
• Synchronisation global « produit » à
prévoir
• + Diminution complexité
• + Diminution « charge mentale »
• - synchro entre équipe et
alignement produit
• - Value maximizer
66. Diminuer la complexité
de votre produit
• Découper par pan fonctionnel
• Découper par process
• Découper par partie prenantes (persona)
• Découper par canal
• Découper par client
A FAIRE Gilles
67. Mauvais chemins et
Embuches
• A eviter de mettre une usine à gaz pour
gérer une dépendance stratégique
• Objectif Orga à l‘échelle = simplifier la
gestion des dépendances entre
produits/équipe :
• Rassembler seulement les équipes
ayant des dépendances
• Ne pas utiliser ces modèles pour
aligner les équipes sur des objectifs
stratégiques
• Respecter la diversité des équipes
• Gain gestion des dépendances >
Contrainte de synchronisation
68. Mauvais chemins et Embuches
• A eviter de tout
• Objectif Orga à l‘échelle = simplifier
la gestion des dépendances entre
produits/équipe :
• Rassembler seulement les équipes
ayant des dépendances
• Ne pas utiliser ces modèles pour aligner
les équipes sur des objectifs
stratégiques
• Respecter la diversité des équipes
• Contrainte de synchronisation < Gain
gestion des dépendances
A FAIRE Aurélie
69. Mauvais chemins et Embuches
Simplifier complexité
produits liés
• A eviter : Mettre usine à gaz pour gérer dépendance
stratégique
• Objectif : Simplifier la gestion des dépendances
entre produits/équipes
• Rassembler seulement si dépendances
• Ne pas utiliser pour alignement stratégique
• Respecter diversité des équipes
• Contraintes de synchronisation < Gain gestion des
dépendances
A FAIRE Aurélie
70. Alignement « Projet »
• Illustration ???
• Reprendre scrum at scale
• Ou pm de safe
• Scrum Master /Kanban master
• Sos/ EAT
=> remontée les points de blocage
au niveau où ils peuvent être
traités
71. Alignement Technique
• Illustration ???
• Reprendre scrum at scale
• Ou pm de safe
• Chef archi
• Vs auto orga des équipes
• Avec architecture open source
• Gourvenance Technique
- nexus integration team
73. Alignement des compétences
• Une équipe
• Spotify
• Un centre de compétence
• Si equipe spécialisée maitrise pas
la réalisation de A à Z
• Equipe Scrum de réalisation et
des équipes de prod en kanban
CDC / Equipe pluridisciplinaire /
spotify
AIRE Gilles
74. Si vous êtes pas devops !
Equipe de réali + kanban de prod
Equipe as a Service team topology
77. Aligner produit et technique
Axe X : exhaustivité des
compétences L'axe vertical
Axe Y: appropriation partagée
du domaine du produit qui
78. Aligner produit et technique
La première vague d'Agilité était
axée
sur l'amélioration des équipes.
La deuxième vague d'Agilité se
concentre sur l'amélioration de
l'ensemble du système.
79. Alignement organisationnel
Remonter au plus tôt les points
de blocage au niveau où ils
peuvent être traités
Bureaucratie Minimum
Viable (SoS , SoSoS , EAT)
RTE, STE LACE (SAFe)
80. Aligner les relations
1.Collaboration: relation de travail
étroite.
2.X-as-a-Service (XaaS): fournit
quelque chose en tant que service à
une autre équipe.
Facilitating: aide une autre équipe à
surmonter un obstacle
81. Charge cognitive
des équipe
Team Topologies
Matthew Skleton
Manuel Pais
La somme d'informations que l'équipe
doit gérer simultanément, incluant
• la complexité des tâches,
• la communication,
• les interdépendances.
• …
Notes de l'éditeur
Héros heoine, bienvenue dans cette aventure vers la transformation agile de votre entreprise
Les héros c’est vous et toutes les personnes de l’entreprise qui vont entreprendre cette aventure
Je m’appelle …
Coach, resp pédagogique , ateleir co
Nous n’avons pas la prétention d’avoir la formule magique d’une montée à l’échelle reussi.
Cette conférence est le fruit de nos exp nos mission chez les clients avec aurélie et de nos réflexions
On va partir des valeurs et principes du manifeste su “équipe et on
Elargir les valeurs, principes et pratiques agiles au-delà d’une équipe dans une organisation
Le but va être de synchroniser les équipes pour qu'elles travaillent de manière plus cohérente plus efficiente vers des objectifs communs.
garantir que toutes les équipes, qu'elles soient techniques, marketing, ventes, etc., travaillent en synergie vers les mêmes objectifs stratégiques.
s'adapter rapidement aux changements du marché, (clients, technologies) et pivoter .
meilleure allocation des ressources (humaines, matérielles, financières).
se référer à tout ce qui n'ajoute pas de valeur au produit final ou au client. Cela peut être du temps, des efforts, des coûts ou même des fonctionnalités inutiles.Bref être plus résilient
enjeu d’une organization
C’est comme gravir l’Everest sans s’être préparé
On a été déjà gravi des montagnes plus petites
Une ou plusieurs équipes sont déjà dans une démarche agile
Produit complexes : techniquement et foncitonnelement
TTM trop elevé ; du besoin à la mep
Ressource diversifiés: intégrer la pluridiscilinaire
Capacité à faire
C pourquoi scrum <10
Un daily à 10 c’est l’enfer alors une rétro …à 20…
l'architecture d'un système reflète inévitablement la structure de l'organisation qui l'a conçu.
exemple classique : 4 équipes distinctes —l'interface utilisateur, la logique métier, base de données, et une pour l'intégration
des avantages, comme une spécialisation accrue, mais aussi des inconvénients, comme des silos de connaissances ou des difficultés dans la communication inter-équipe.
Pour faire évoluer son organisation et ne pas subir un modèle d’architecture imposé, il est donc préférable de modifier la structuration des équipes et leurs interactions pour s’assurer qu’elles correspondent à l’architecture que l’on souhaite donner au système. Le véritable défi est donc d’arriver à exploiter la loi de Conway comme moteur du changement souhaité plutôt que de la subir. Mais quel modèle d’organisation mettre en place pour atteindre une cible d’architecture donnée ?
Architecture simple va permettre de définir des produits et des équipes MAIS quelleq interactions, organisations entre tout ce petit monde
Cynefin, Complexity thinking management 3,0 et matrcie stacey
Cynefin, Complexity thinking management 3,0 et matrcie stacey
Gilles on a quoi dans notre sac
Issu de scrum .. Avec Mention spéciale pour Safe qui va jusqu’à la vision entreprise
Spotify culture d'entreprise axée sur l'autonomie, l'alignement et la confiance.
Leanit: amélioration continu, éliminer le gaspi, le flux de valeur
Décrit une progression pour les équipes agiles , la valeur, la livraison, l’optimisation et le renforcement
Le modèle insiste sur le fait qu'il n'y a pas de "niveau supérieur" unique ou d'étape finale. Les équipes et les organisations doivent choisir leur niveau de fluidité en fonction de leurs besoins et des avantages qu'elles souhaitent obtenir.
Org: CONCEVOIR VOTRE FEUILLE DE ROUTE DE TRANSFORMATION sur l’axe métier et technique
On a plein de trucs mais quels sont mes besoins dans mon contexte
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Ces modèles sont faits pour depiler un bakclog sans spécificité d’équipe – il peut arriver que transitoirement on affecte des US à l’une ou l’autre des équipes MAIS on est en train de tordre le système avec le risque d’en perdre le bénéfice de value maximiser
Modèle qui est couteux humainement car demande de rester toujours multicompétents techniquement & fonctionnelement
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Partition du backlog
exemple : si toutes les fonctions sont transverses à toutes les équipes la dépendance est trop forte
exemple : si toutes les équipes travaillent sur un même socle technique la dépendance est forte et difficile à gérer
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Partition du backlog
Exemple Wiztivi
MMB socle unique chiant a synchoniser METROPOLE : DOM/TOMpoint technique … lors de comité de pratique, innovation
Diminuer la charge mentale autour de la communication,
Il faut aligner les profuit,
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
Actuellement de plus en plus de personnes quitte youtube car il est demandé une régularité de création de contenu de petite taille MAIS ce n'est pas adapté à tous les sujes et tous les producteurs de contenus.
Par exemple un de mes clients téléassistance vous savez le spersonnes qui quand vous avez un accident vous parle automattiquement sur les voitures récentes. Ces téléassistants passe en qq seconde du confort du bureau au chaos d'un habitacle de voiture accidentée. Vous pensez que tout les 3 semaines on peut se permettre de changer 2, 3 trucs dans leur outils qu'ils doivent connaitre par cœur sans surprise pour ête serein dans le prise en charge.
Outil son intuitif... oui les grands publics mais les pro, pas toujours évident... besoin de formation et c'est un casse-tete dans les planning de charge surtout si sous-effectif. Et quel est le niveau d'aisance avec le numérique
Market si je livre des petites choses toutes les 3 semaines (déjà bien géré les MAJ que ce soit transparent) est-ce que l'utilisateur se rend compte de la plus-value ? Est-ce qu'un big bang ne m'octroit pas un avantage sur mon marché ?
Votre système - votre organisation de réalisation vas être alimenté par 3 sources
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Partition du backlog
Executive Action Team
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Partition du backlog
Executive Action Team
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
Rappel du manifest
Le code appartient à tous le monde
Les meilleures archi emergent des équipes auto organisé
Chapter "Chapter Lead", qui est en quelque sorte le responsable de cette compétence spécifique au sein du Tribe
Guild : communauté d'intérêt plus informelle et traverse généralement plusieurs Tribes
Foisons de Cop : attention à l’effet soufllé. Kick off qui donne rien
Marche si temps dédié, si un leader sur la communauté
La meilleure façon de monter à l’échelle c’est avec tous les acteurs du système
Et les faire travailler enselmble et faire émerger l’intelligence collective de l’organtion
L'essence de cette méthode open sapce techlogie est d'encourager l'auto-organisation, la participation active et la prise de responsabilité par les participants.
(à l’image d’un guide de haute montagne) n’est pas un luxe pour vous éviter les écueils avec ses REX
identifier les indicateurs d’alerte à suivre pour bien superviser votre modèle d’organisation et éviter les travers
Faire la promotion et la communication
=> partager les éléments qui vous ont fait prendre ces choix pour favoriser l’adhésion
=> partager vos doutes n’est pas un signe de faiblesse mais de la gestion des risques et impacts
=> un modèle d’orga doit être compréhensible car simple
Décentraliser
=> appuyer vous sur des rôles clés motivés et promoteurs, ils seront votre voix et vos oreilles
– elles permettront l’amélioration du système et de pivoter vers d’autres solutions rapidement. Lors de votre prise de décision,
Organisation apprenante
CONCEVOIR VOTRE FEUILLE DE ROUTE DE TRANSFORMATION, une boussole
Axe X : exhaustivité des compétences L'axe vertical
Axe Y: appropriation partagée du domaine du produit qui
Gilles
AURELIE
GILLES
AURELIE
Merci à Dalle-3 pour ces magnifiques illustration. Etau facilitateur grahique
(1 bon point pour celui qui avu qu’il y en avait )
Dessin d’un embranchement de chemin avec 3 paysages, peut-être un des chemins montre un gros arbre immense, l’autre une foret d’une même essence et le 3 ème une foret mélangée chene et sapin
Dans LeSS huge, on a des Area Product Owner
Dans Less Huge, il y a des Area Product Owner
Dessin d’un embranchement de chemin avec 3 paysages, peut-être un des chemins montre un gros arbre immense, l’autre une foret d’une même essence et le 3 ème une foret mélangée chene et sapin
Dans Less Huge, il y a des Area Product Owner
Dans Less Huge, il y a des Area Product Owner
Refaire l’image
cela englobe non seulement les tâches individuelles, mais aussi les défis liés à la coordination, à la communication, à la compréhension des objectifs, aux interdépendances, etc.
Voici une ventilation plus détaillée de la charge cognitive d'une équipe:
Complexité de la Tâche:
Chaque tâche ou projet possède sa propre complexité intrinsèque. Plus il y a de pièces mobiles, d'interdépendances ou de domaines de connaissances nécessaires, plus la charge cognitive augmente.
Interdépendances:
Lorsque les membres de l'équipe dépendent les uns des autres pour accomplir leurs tâches, cela peut augmenter la charge cognitive. Cela nécessite une coordination, une communication et une compréhension claire des rôles et responsabilités.
Communication:
Une communication inefficace ou excessive peut surcharger cognitivement une équipe. Par exemple, trop de réunions, des e-mails inutiles, ou des directives floues peuvent tous augmenter la charge.
Changement Constant:
Si l'équipe est constamment confrontée à des changements de direction, de priorités ou de demandes, cela peut augmenter la charge cognitive car les membres doivent s'adapter en permanence.
Outils et Technologies:
L'utilisation d'une multitude d'outils ou la nécessité d'apprendre de nouvelles technologies peut également contribuer à la charge cognitive.
Conflits et Dynamique d'Équipe:
Les conflits non résolus ou une mauvaise dynamique d'équipe peuvent également augmenter la charge cognitive, car les membres peuvent passer du temps à naviguer dans ces défis interpersonnels au lieu de se concentrer sur les tâches à accomplir.
Contexte Switching:
Passer fréquemment d'une tâche ou d'un projet à un autre peut être épuisant pour le cerveau et augmenter la charge cognitive.
Refaire slide avec découpage par icone
Choix de dupliquer des briques techniques ou fonctionnelle pour avoir une meilleure réactivité et adaptation à des contraintes différentes :
Exemple: site responsive scindé en appli mobile et portail web
Choix de dupliquer des briques techniques ou fonctionnelle pour avoir une meilleure réactivité et adaptation à des contraintes différentes :
Exemple: site responsive scindé en appli mobile et portail web
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
- Pas harmonisation des rythmes partout
TOUS EN SCRUM !
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
Une organisation qui supprime les silos technique
Les équipes choisissent les fonctionnalités a créer
Partition du backlog
Executive Action Team
Si equipe spécialisée maitrise pas la réalisation de A à Z
Equipe Scrum de réalisation et des équipes de prod en kanban
CDC / Equipe pluridisciplinaire / spotify
fait référence à la quantité totale d'informations que le cerveau peut gérer en même temps.