Category: Articles

blank

SAFe 5.0 : une posture (enfin) assumée sur l’évolution globale de l’organisation  ?

Comme à son habitude, le framework d’agilité à l’échelle SAFe va proposer une nouvelle version majeure, la cinquième depuis ses débuts.  

Plusieurs évolutions sont au menu, d’importance plus ou moins grandes. Par exemple, un nouvel onglet  Overview  vient résumer les « compétences » sur la page principale, l’étage  portfolio  se complète,  l’orientation client  prend une place centrale dans le framework, la notion  d’agilité business fait son apparition, … 

blank
SAFe 5 preview

Mais est-ce tout ? Pas tout à fait… 

Car là où SAFe 5.0 apporte une grande nouveauté, c’est sur sa posture vis-à-vis de la structure des entreprises. En effet, nous avions jusqu’alors un modèle orienté delivery qui ne présumait pas spécialement de la façon dont l’entreprise était organisée.  

SAFe 5.0 semble (enfin) prendre position, notamment à travers deux introductions majeures : 

  • Un 10ème  principe « Organize Around Value », qui explique ni plus ni moins comment une entreprise grandissante perd son agilité en se structurant, et propose le framework comme un « Second Operating System » pour un regain d’agilité. 
  • Deux nouvelles « compétences » (qui portent le total à 7),  Organizational Agility  et  Continuous Learning Culture, qui mettent l’emphase sur l’agilité au-delà du delivery, comme le faisait déjà la compétence  Lean Portfolio Management.  

On aurait d’ailleurs presque envie de voir cette dualité  agilité du delivery  versus  agilité structurelle  dans l’Overview, toutes deux supportées par le lean agile mindset au service d’une entreprise « orientée client ». 

Si cette tendance se confirme dans la version finale de SAFe 5.0, cela sera une grosse évolution… et sans doute un gros argument de moins pour nombre de ses détracteurs  ! 

Ces éléments nouveaux contribuent à porter l’agilité à l’échelle de l’entreprise en proposant une ébauche pour embarquer les fonctions support (RH, légal, finance, marketing) tout en intégrant la culture d’entreprise comme un facteur clé de succès pendant et après la transformation !

Nous continuerons à vous donner plus détail sur le blog au fur et à mesure que les informations arriverons. 

SAFe 5.0:  https://scaledagileframework.com/# 

Pour aller plus loin :
Nos offres de conseil en entreprise agile.

Read More
blank

Comment tailler votre transformation agile sur mesure ?

« La culture mange la stratégie au petit-déjeuner ! » Cette phrase très célèbre de Peter Drucker, écrivain spécialisé dans le management, illustre à merveille une constante de toutes les transformations : elles échouent inévitablement si l’on ne tient pas compte de la culture de l’organisation. Découvrez comment adapter votre transformation agile à votre contexte.

Read More
blank

Faire de l’agile ou être agile ?

Faire de l'agile ou être agile ?
Faire de l’agile ou être agile ?

De très nombreuses organisations en France et dans le monde adoptent l’agilité à différentes échelles de l’entreprise. Sont-elles néanmoins devenues pour autant plus agiles, plus performantes, plus fiables ou plus résilientes ?

1/ Faire ou Être agile, quelle importance ?

« Faire » de l’agile, est relativement simple, il suffit de choisir une méthode ou un framework du marché, d’identifier les personnes amenées à jouer les rôles nécessaires et de lancer les premières cérémonies agiles.

Par exemple avec Scrum, vous identifiez vos Product Owner, Scrum Master et Team Member puis lancez vos cérémonies de Sprint Planning, Daily Scrum Meetings, Backlog Refinements, Sprint Review et Sprint Retrospective et vous voilà à « faire » de l’agile.

Pour autant, les comportements de vos collaborateurs ont-ils fondamentalement changé ? Avez-vous amélioré la performance de votre organisation ? Avez-vous amélioré la collaboration, la synchronisation et l’alignement ? L’information est-elle transparente et partagée par tous ?

Vous allez constater dans le meilleur des cas une amélioration de la performance de vos équipes, mais allez passer à côté du gain réel proposé par l’agile qui repose plus sur un changement de dynamique interpersonnelle que sur de la méthode.

En effet, pour améliorer la performance de votre organisation, il ne vous suffit pas de « Faire » de l’agile. Il faut réellement que tous vos acteurs impliqués comprennent l’intention derrière chaque rôle, chaque cérémonie, chaque interaction et ajustent leurs comportements à la fois individuels et d’équipe vers cette intention. C’est à cette condition que vous basculez de « Faire » de l’agile à « Être » agile et que vous ancrez durablement ce changement dans l’esprit collectif.

2/ L’essence de l’agilité, un profond changement culturel et comportemental

« Être » agile est essentiellement un changement de comportement individuel et collectif et un changement de culture. Changer de culture ne se fait qu’en ancrant de nouvelles habitudes et s’avère donc bien plus long que de « Faire » de l’agile.

L’agilité repose sur des marqueurs culturels forts : l’esprit d’équipe, la collaboration, le développement humain, le partage du sens, la transparence, l’alignement, l’orientation client ou encore la conscience de la valeur apportée. Cette culture requiert d’améliorer la collaboration, la synchronisation et la pédagogie auprès de vos collaborateurs impliqués et de leur environnement direct.

Pour vos équipes, cela passe aussi par une réelle prise d’autonomie et de responsabilité sur leur travail. Tout le monde n’appréciera d’ailleurs pas forcément cette responsabilité proposée. Pour vos managers un lâcher prise et une dimension humaine plus forte.

Au-delà de ses changements culturels et comportementaux, pour être agile, vous devez comprendre le sens du produit que vous cherchez à construire et l’intention derrière chaque cérémonie des pratiques agiles que vous employez ?.

Par exemple, le Daily Scrum Meeting, qui ne dure que 15min et dont les 3 questions rituelles sont très simples, est certes une vraie opportunité de découvrir et traiter les blocages potentiels de l’équipe, mais c’est aussi un vrai acte d’engagement quotidien de l’équipe sur ses travaux de la journée. Ce n’est certainement pas une cérémonie de reporting ni de contrôle de l’avancement de l’équipe, qui est pourtant le travers que l’on constate régulièrement.

Autre exemple, le Sprint Planning est aussi une cérémonie d’engagement collectif de l’équipe sur un backlog sur la base d’une vision et de priorités exposées par le Product Owner. Ce n’est pas une distribution de tâches à des individus, une obligation à faire l’intégralité du backlog ou l’engagement de faire un exploit individuel pour réaliser une Story ou une autre.

Les travers sur toutes les cérémonies sont nombreux et souvent issus de la culture initiale de l’organisation qui peut être plus portée sur le contrôle ou l’exploit individuel par exemple.

Peter Drucker, auteur renommé sur le management, nous dit que “La culture mange la stratégie au petit déjeuner”. Vous pouvez effectivement mettre en place toutes les cérémonies agiles que vous voulez, tant que les comportements de vos collaborateurs n’ont pas changé pour que vos équipes se concentrent sur la finalité et pas uniquement la forme, vous n’aurez que l’apparence d’agilité et n’obtiendrez au final pas grand-chose de bien différents de vos modes de travail existants.

3/ Quels bénéfices pour votre organisation et vos collaborateurs

« Être » agile va largement améliorer la motivation intrinsèque de tous, qui vont trouver un sens dans leurs actions, une responsabilité ou encore une autonomie qu’ils n’avaient pas forcément. Cette motivation est pour beaucoup le moteur de l’efficacité, de l’engagement et de la qualité.

Pour l’organisation c’est un processus plus fiable délivrant plus rapidement des produits de meilleure qualité que vous allez obtenir et donc des clients ou usagers plus satisfaits au final.

Attention néanmoins à un point, pour tirer pleinement le bénéfice de l’agile, il faut que toute votre entreprise se transforme : le marketing sur son approche produit, les RH sur le recrutement et la mesure de la performance, les achats et le juridique sur les modalités de sourcing et de contractualisation et toute les chaines hiérarchiques existantes.

4/ Où en êtes-vous de votre transformation agile ?

« Faire » ou « Être » agile, comment savoir où vous en êtes ?

Pour changer votre culture et les comportements de vos collaborateurs, vous devez commencer par prendre conscience de votre situation initiale et intégrer cette dimension humaine comme dorsale de votre transformation agile

Concernant la culture, vous pouvez par exemple vous demander : Quels sont les marqueurs culturels forts de votre organisation ? Comment ces marqueurs culturels se marient-ils avec ceux de l’agilité ? Sont-ils compatibles ? Que va-t-il émerger de cette nouvelle culture mélangeant la culture historique de votre organisation et cette culture agile ? Votre culture actuelle est-elle un frein ou un vecteur d’accélération à l’adoption de l’agilité ? Votre culture est-elle homogène dans toute l’entreprise ou bien locale à chaque équipe ?

Exemple 1 :  une organisation dans laquelle la peur d’échouer est très présente ne sera pas à l’aise avec le principe “test and learn” sous-jacent à l’agilité.

Exemple 2 : une organisation hautement hiérarchisée et centralisée aura de vraies difficultés avec la délégation et la responsabilité à accorder aux équipes.

Exemple 3 : une organisation qui érige l’excellence individuelle comme principe de reconnaissance aura du mal à reconnaître l’équipe dans sa globalité comme entité performante. On constate souvent dans ce cas des injonctions contradictoires qui déboussolent les équipiers entre la reconnaissance individuelle issue des modèles d’évaluation annuels et l’attente de collaboration au sein des équipes.

Concernant les comportements, vous pouvez vous demander : Quels sont les comportements dominants de mes collaborateurs ? Comment les évaluer ? Comment votre culture influence-t-elle le comportement de vos collaborateurs ? Ces comportements sont-ils un frein ou une opportunité pour adopter l’agilité ? Comment serait-il souhaitable que ces comportements évoluent ? Comment agir sur ces comportements ?

Pour appréhender cette situation initiale, nous disposons d’une démarche et d’outils d’analyse vous en offrant une lecture simple. Sans cette prise de conscience, il n’est pas possible de changer fondamentalement et d’ajuster votre transformation à votre contexte spécifique. Chaque organisation est en effet unique et sa transformation doit être complètement calée sur ce qu’elle est au départ et souhaite devenir. Sur la base de cette compréhension initiale, nous vous proposons un accompagnement mêlant la fois du coaching professionnel et du mentoring de vos personnes clés ou un coaching collectif d’équipe.

Pour en savoir plus vous pouvez consulter nos offres de conseil et de coaching :

Read More
blank

SAFe Inspect & Adapt, une alliance incontournable RTE / Scrum Masters

Inspect & Adapt
Inspect & Adapt

Le PI Planning de SAFe concentre toutes les attentions tant cet événement est marquant dans la vie d’un incrément de programme. L’Inspect & Adapt, la cérémonie d’amélioration continue de niveau programme, est pourtant toute aussi importante et difficile à préparer que le PI Planning.

L’inspect & Adapt une combinaison de revue et de rétrospective sous la responsabilité du RTE3

Comme dans toutes les cérémonies de niveau programme, c’est le RTE qui est aux manettes de l’Inspect & Adapt. Les participants sont les mêmes que ceux du PI Planning et de par sa nature hétérogène, elle nécessite aussi beaucoup de préparation.

L’inspect & Adapt se déroule en trois parties et dure en général 3 à 4 heures :

  1. Une démonstration système des Features terminés les plus intéressants ;
  2. Une revue des engagements du programme et des équipes ;
  3. La résolution des problèmes systémiques.

1. La démonstration système à grande échelle

La démonstration système de l’Inspect & Adapt se déroule devant toutes les équipes du programme, les demandeurs et le management. Comme pour les autres démonstrations système, elle nécessite la collaboration du RTE, des Product Managers et de la System Team pour respectivement s’assurer de la logistique, des scénarios de démonstration et des environnements. A la différence des autres démonstrations système qui se déroulent en petits comités, celle-ci se déroule devant un large public et nécessite une logistique beaucoup plus importante. En effet, il faut que tout le monde puisse visualiser et comprendre la démonstration.

2. La revue des engagements du programme et des équipes

La revue des engagements de programme (PI objectives) ou d’équipe montre l’atteinte partielle ou totale des objectifs de PI fixés par le Business Owner lors du PI Planning. On y indique les causes d’atteinte partielle et le lien avec les fiches A34 qui vont être traitées dans la partie suivante si le problème doit être adressé.

Cette revue est préparée en amont entre le RTE, le Business Owner, les Product Managers et les Scrum Masters et Product Owner des équipes. Cette préparation permet de déterminer les taux d’atteinte des objectifs de PI et de formaliser les causes d’atteinte partielle des objectifs.

Cette partie fait le lien direct avec la résolution des problèmes qui suit. En effet, la cause d’atteinte partielle d’un objectif peut être due à un problème systémique identifié. L’impact de ces problèmes est d’autant plus criant qu’il concerne plusieurs équipes.

3. La résolution des problèmes systémiques : anticipée dès le début de l’incrément de programme

Les problèmes systémiques (ceux qui concernent plusieurs équipes du programme) sont identifiés lors des 4 rétrospectives des différentes équipes du programme. Lorsqu’un tel problème est découvert, le Scrum Master doit le formaliser sous la forme d’une fiche A3 et la donner immédiatement au RTE. Le RTE se charge alors de voir avec les autres Scrum Masters si le problème les concerne aussi, de valider le degré d’urgence de son traitement (immédiat ou durant l’Inspect & Adapt) et de consolider des métriques pour comprendre son impact.

Le RTE consolidant toutes les fiches A3 au fur et à mesure doit les challenger, les dédoublonner, les rapprocher si elles sont similaires, suivre leur résolution si elles doivent être traitées immédiatement.

Afin d’être efficace, ce travail de constitution des fiches A3 se fait donc tout au long de l’incrément de programme. Il est extrêmement difficile de constituer ces fiches au dernier moment en fin de Sprint 4, les équipes ont en général oublié une bonne partie de ce qui s’est passé en début de PI et sont trop occupées à terminer leur dernier Sprint pour réellement avoir le temps de s’occuper de formaliser ces fiches.

L’animation de la résolution de problème en grande partie déléguée aux Scrum Masters

L’animation de cette troisième partie de l’Inspect & Adapt se déroule en sous-groupes. Dès la fin de la présentation des problèmes, formalisés sous forme de fiches A3, le RTE passe la main aux Scrum Masters pour animer des ateliers de résolution de problème en sous-groupes. Les sous-groupes sont constitués en temps réel autour des problèmes. Les participants d’un sous-groupe doivent avoir la capacité à résoudre le problème par eux-mêmes.

6 étapes de l'Inspect & Adapt


Les 6 étapes du Problem solving de l’Inspect & Adapt

Le RTE garde la main sur le cadencement des étapes 2 à 6, mais ce sont réellement les Scrum Masters qui en assurent l’animation, ils doivent être prêts à animer toutes ces étapes.

Chaque groupe doit ressortir de cet atelier avec une fiche A3 complète, une liste d’actions faisables dans le prochain incrément de programme et des porteurs identifiés au sein du groupe.

La formation nécessaire des Scrums Masters pour animer la partie résolution des problèmes / amélioration

Les outils proposés par SAFe comme l’analyse causale grâce au diagramme d’Ishikawa1 (l’arête de poisson) ou les 5 pourquois2 ne sont pas simples à appréhender pour tout le monde. Avant même l’analyse causale, la formalisation des problèmes sous forme de fiche A34 est en elle-même une vraie difficulté si on n’y est pas formé. Le RTE doit impérativement former les Scrum Masters du train à l’utilisation des différents outils de l’Inspect & Adapt avant que le train ne démarre.

Des problèmes, oui, mais on peut aussi renforcer ce qui fonctionne bien

SAFe recommande l’analyse de problèmes pour la troisième partie, c’est effectivement efficace mais pas très positif. Certaines équipes peuvent mettre en place des outils ou des pratiques qui leur donnent une performance et un engagement meilleurs que les autres. Ce qui fonctionne bien peut être renforcé ou diffusé à d’autres.

Je vous recommande d’identifier plusieurs sujets de ce type avant l’Inspect & Adapt et faire travailler des groupes dessus au même titre que les problèmes, c’est bien plus positif !

Des actions d’amélioration à suivre tout au long de l’incrément de programme

L’Inspect & Adapt terminé, l’amélioration continue ne s’arrête pas là, il faut impérativement suivre l’avancement des actions que les groupes ont pris.

Les actions doivent avoir été planifiées dans des Sprints durant le PI Planning et celles-ci doivent être suivies par le RTE et les Scrum Masters durant l’ART Sync.

Conclusion

L’inspect & Adapt nécessite un véritable travail de préparation et d’anticipation tout au long de l’incrément de programme. Son efficacité a un véritable impact sur le moral des équipes tant lors de l’animation que lors du suivi des actions qui en découlent ; rien n’est plus frustrant que d’identifier des actions qui ne mènent à rien par la suite !

Aller plus loin : Notre offre de conseil en entreprise agile, Vous former à SAFe par la formation Leading SAFe.

Articles connexes :

  1. Le RTE clé voute du PI Planning
  2. Adieu COPILs, bienvenue aux ART Sync

1Diagramme d’Ishikawa : https://fr.wikipedia.org/wiki/Diagramme_de_causes_et_effets

25 pourquois : http://www.wikilean.com/Articles/Kaizen/1-La-resolution-de-problemes-20-articles/2-Le-5-pourquoi

3RTE (Release Train Engineer) : Scrum Master du programme SAFe.

4Fiche A3 : formalisme pour décrire un problème dans sous la forme d’une fiche qui tient au format A3. Exemple.

Read More
blank

Managers, saisissez l’extraordinaire opportunité offerte par une transformation agile !

CIO
CIO

Ou comment passer du savoir-faire au savoir-être d’un leader

L’opportunité résonne comme un paradoxe, comment une transformation agile peut-elle bien être une opportunité pour un manager tant elle bouleverse les équilibres établis ?
La plupart des organisations démarrent leur transformation agile sans se soucier de l’impact sur leurs managers, voire en anticipant une réduction de leurs effectifs, alors comment transformer cette menace en opportunité ?

En quoi l’agilité induit-elle un changement de positionnement pour un manager ?

Le développement logiciel est un travail hautement créatif et intellectuel, les équipes de développement sont en général plus pointues que leurs managers sur leur travail. Elles sont donc plus à même de prendre leurs propres décisions sur leurs activités. L’agilité repose ainsi sur des principes forts de transparence, de responsabilité et d’autonomie des acteurs à tous les niveaux de l’organisation.
Par exemple, les équipiers d’une équipe de développement sont responsables de leurs engagements de Sprint, ils trouvent par eux même des solutions à leurs propres problèmes. Les rôles de Scrum Master et de Product Owner ne sont pas des rôles de management mais de facilitation et de gestion de produit, il n’y a pas à proprement parler de rôle managérial en agile au niveau d’une équipe.
Le constat est le même si l’on examine les frameworks d’agilité à l’échelle, on y retrouve le triptyque de facilitateur, de gestionnaire produit et de sachant sur la solution à tous les niveaux, mais encore une fois pas de rôle de manager.
Quelle est donc la place d’un manager dans un tel modèle ?

Des croyances bien ancrées à déverrouiller

D’après les études, une grande majorité des managers sont promus pour leur expertise ou pour leur capacité à organiser, peu pour leur capacité à développer leurs équipes. La reconnaissance par les pairs passe souvent par celui de son savoir-faire et par le résultat de l’équipe dont le manager s’estime comptable. En agile, le détachement nécessaire du manager face à son équipe le rend beaucoup moins comptable du résultat et cette reconnaissance naturelle par les pairs doit donc se faire autrement. Un autre équilibre de la contribution du manager aux résultats de son équipe est à trouver.

Le modèle d’Hersey-Blanchard1 identifie quatre styles de management communément admis le style directif, l’informatif, le participatif et enfin le délégatif. Là où habituellement le manager se place plus naturellement dans les styles directif à participatif, l’agilité exige un style de management largement plus participatif à délégatif. Ce décalage nécessaire de style de management ne se fait pas sans une prise de conscience de son propre style de management et de l’adaptation nécessaire de son comportement faute de quoi, le manager se retrouve en décalage avec son équipe. Pour y parvenir, seul un coaching personnel adapté permet de prendre ce recul nécessaire et engager le changement comportemental adéquat.

Au final, on se rend compte que le principal changement pour un manager réside dans l’équilibre d’importance entre son savoir-faire et son savoir-être.

Du manager au leader, un nouvel équilibre à trouver

Face à une équipe agile qui a besoin d’autonomie et de confiance, le manager doit trouver un nouvel équilibre. Là où il était souvent attendu sur l’organisation du travail de l’équipe et sur le contrôle de sa réalisation, le manager doit adopter une posture de leader.
Le leader se pose comme le véritable jardiner de l’équipe en s’appuyant sur trois axes principaux :

  1. Sa capacité à donner du sens par une vision stratégique du travail de l’équipe à moyens et longs termes ;
  2. Sa capacité à développer les membres de son équipe en leur offrant les clés pour être autonomes, compétents et efficaces et en s’assurant que rien ne bloque leur travail au quotidien ;
  3. Sa capacité à améliorer en continu le système complet dans lequel l’équipe évolue (le produit, l’organisation, les processus, les outils, les relations …).

Ce triptyque de leader décale fortement les attentes que l’on avait vis-à-vis d’un manager et nécessite un repositionnement du manager vis-à-vis de son équipe, vis-à-vis de sa hiérarchie et vis à vis de ses pairs. Sans accompagnement de coaching adéquat, cela peut engendrer une vraie perte de repères et donc de motivation.
Parmi les différents rôles qu’un manager peut avoir auprès de ses équipes, de manager opérationnel, manager gestionnaire, au manager RH, l’agilité force le manager à se décaler vers un rôle plus humain et plus complet.
A défaut d’adopter un style de leader, un manager peut recentrer son rôle auprès de ses équipes et adopter un des rôles de facilitateur offert par les frameworks d’agilité tel que le Scrum Master ou le Release Train Engineer.

Identifier soi-même les comportements que l’on doit changer pour s’aligner sur ce nouveau triptyque n’est pas simple voire impossible. C’est pourtant possible grâce à l’aide d’un coach utilisant des outils d’analyse comportementale tels que l’Agile Profile. L’Agile Profile permet de repérer les comportements existants et de définir une cible comportementale adaptée au contexte spécifique du manager.

Dans tous les cas, c’est un véritable deuil que le manager doit faire par rapport à ses modes de fonctionnement passés et un véritable changement que doit opérer sa hiérarchie en l’autorisant et en l’accompagnement dans ce changement.

Pour changer, puiser dans ses motivateurs et ses forces

Pour que l’on ait envie de changer il faut que cela ait un sens pour soi-même et que cela nous motive. Chaque individu est différent et possède ses propres motivateurs intrinsèques2 et ses propres forces. Un changement est d’autant plus facile à vivre pour un individu s’il fait appel à ses forces et renforce ses motivateurs intrinsèques.
Autant le sens d’un changement peut être partagé auprès d’une population de managers, autant la motivation et les forces sont individualisées. Un coach peut aider à faire émerger ses motivateurs et un test comme le strength finder, ses forces.
A partir de tous ces éléments comportementaux, motivateurs, forces, envies de changement du manager, le coach peut mettre en place avec lui un plan de coaching personnalisé.

Participer au changement culturel de l’entreprise

Au-delà du changement personnel que chaque manager va vivre, c’est l’entreprise dans sa globalité qui va se transformer. C’est un véritable changement de culture et de comportement global qui va s’opérer.
Chaque manager peut saisir l’opportunité de participer à ce changement culturel et contribuer par sa propre expérience de transformation personnel au changement plus global.

Conclusion
Une transformation agile est avant tout une évolution personnelle à vivre avec les modes de management traditionnels et une vraie opportunité de transformation personnelle où le savoir-être est bien plus important que le savoir-faire. Ayant conscience de cette opportunité et disposant d’un réel accompagnement de l’entreprise, cette transformation peut être une vraie occasion de changement positif.

Notre offre de coaching
Notre offre de transformation agile

1 Modèle d’Hersey Blanchard : modèle de leadership situationnel construit par les experts en management, Paul Hersey et Ken Blanchard.
2 Motivateur intrinsèque : l’action est conduite uniquement par l’intérêt et le plaisir que l’individu trouve à l’action, sans attente de récompense externe.

Read More
blank

L’essentiel de SAFe 4.5

Nouveautés SAFe 4.5
Nouveautés SAFe 4.5

SAFe 4.5, la nouvelle mouture de SAFe dans la continuité de la 4.0

SAFe 4.5 est sorti le 21 juin 2017 et il nous offre une image revue et enfin simplifiée de la Big Picture et un framework destiné aux Lean Enterprises !

SAFe 4.5 apporte en effet 4 éléments principaux :

  1. Une meilleure adaptabilitée à chaque situation au travers des 4 configurations de SAFe ;
  2. Une roadmap d’adoption du framework plus développée que la stratégie 1,2,3 ;
  3. Un focus très fort sur l’intégration de DevOps comme moteur d’agilité global des trains ;
  4. Une intégration de Lean Startup et Lean UX au sein du framework ;

Intro, un nouveau nom qui en dit long

SAFe n’est officiellement plus réservé qu’à l’IT, SAFe for Lean System Engineering devient SAFe for Lean Enterprises. Ce changement de nom n’est pas anodin et démontre s’il le fallait encore que l’on peut appliquer SAFe à n’importe quel type de contexte dans l’entreprise. L’utilisant moi-même depuis des années comme démarche de transformation pour l’implanter lui même comme modèle opérationnel d’entreprise, je ne peux qu’approuver ce changement.

1. Une meilleure adaptabilitée à chaque situation au travers des 4 configurations de SAFe

SAFe se décline maintenant en 4 configurations beaucoup mieux adaptées aux contextes de déploiements que l’on rencontre en entreprise. Dans tous les cas la Big Picture a subit un gros coup de lifting pour faire disparaître les éléments en double et donner plus d’espace à la lecture et la compréhension du schéma.

La version Essential SAFe

Essential SAFe

Cette version essentielle convient à la majorité des implémentations de SAFe ou à une première version d’un déploiement plus important. Fortement dépouillée, elle est beaucoup plus simple et abordable que la big picture précédente.

La version Portfolio SAFe

Portfolio SAFe

Cette version apporte la gestion de portefeuille et correspond au framework par défaut à trois couches que nous avions précédemment. La Big Picture est plus légère qu’auparavant grâce à l’utilisation de la palette sur le côté gauche.

La version Large Solution SAFe

Large Solution SAFe

Cette version ajoute à Essential SAFe le niveau Solution anciennement chaine de valeur, sans la gestion de portefeuille. Ce niveau a été fortement revu et son vocabulaire totalement simplifié afin que tout s’aligne sur le terme de Solution.

La version Full SAFe

Full SAFe

Cette version intègre les 4 niveaux de SAFe équipe, programme, solution et portefeuille. C’est la plus complète et surement pas celle par laquelle on démarre lorsque l’on déploie SAFe pour la première fois dans une organisation.

2. La roadmap d’adoption de SAFe

SAFe Implementation Roadmap

La stratégie d’implémentation 1,2,3 qui consistait à passer quelques formations a vécu, elle était en effet beaucoup trop simpliste ! L’adoption de SAfe dans une organisation est une véritable transformation du modèle opérationnel de l’entreprise et pas seulement une affaire de quelques formations.

Même si cette nouvelle roadmap propose une trajectoire plus complète, elle reste encore bien trop simpliste pour adresser la transformation de modèle opérationnel que l’adoption de SAFe impose. Cette nouvelle version est encore une fois très centrée sur la formation aux différents rôles du framework et n’adresse pas réellement la reconception des processus, de l’organisation, de la gouvernance que l’adoption du framework impose. Elle passe sous silence le besoin fort d’outillage ALM / DevOps nécessaire pour supporter ces processus et encore plus l’effort de conduite du changement pour adopter la culture d’entreprise et les comportements des managers et collaborateurs adaptés à ce type de changement.

La meilleure façon d’adopter SAFe étant de l’utiliser lui même pour s’implémenter. Le pilotage d’une transformation organisationnelle en utilisant Essential SAFe est la meilleure stratégie pour l’adopter tout en validant au fur et à mesure que le framework s’adapte bien au contexte de l’entreprise.

3. Une intégration forte de DevOps

Toutes les implémentations de SAFe nécessitent un fort besoin d’outillage ALM et DevOps pour assurer la performance du système. La 4.5 met l’accent sur le DevOps en introduisant une double boucle en 8 entre le développement et les opérations et met en exergue des pratiques qui étaient essentielles sur le terrain pour assurer la performance de fonctionnement.

SAFe DevOps

Le DevOps est ainsi adressé sur ces différentes dimensions culturelle, d’outillage, d’intégration dans le flux de travail, de mesure et de sécurisation des mises en production.

Le flux jusqu’à la production est introduit dans le Kanban de programme gérant les Features. A mon sens ce flux de Release doit même être séparé de celui des Features pour devenir un Kanban à part entière et se connecter à la fois au Kanban de programme pour Releaser des Features, mais aussi à celui d’équipe pour Releaser Stories d’évolution et anomalies.

4. Une intégration de Lean Startup et Lean UX au sein du framework

Qui ne s’est jamais posé la question : Les features doivent être Minimum Marketable Feature, mais que fait-on s’il faut un ensemble minimum de Features pour avoir un premier produit minimum viable (MVP) ?

La nouvelle mouture de SAFe intègre le Lean Startup au niveau du portefeuille d’Epic afin d’institutionnaliser un constat : un Epic est une très grosse exigence sur laquelle nous pouvons faire tout un tas d’hypothèses qui peuvent se révéler fausses : quel est l’élément le plus petit que l’on peut construire pour valider les hypothèses afin d’éviter la casse et s’orienter dans la bonne direction ?

SAFe 4.5 MVP

Le Lean Startup étant essentiellement basé sur la roue de Deming et pronant un apprentissage très rapide, il s’intègre effectivement parfaitement avec le portefeuille d’Epics. Le débat qui peut ensuite subsister, porte sur le MVP pour chaque Epic ou un ensemble d’Epics pour constituer un MVP …

Enfin dernier apport de SAFe 4.5, l’intégration de Lean UX. L’intégration de l’UX dans le Kanban de programme et le Kanban d’équipe était l’affaire de spécialiste et d’une bonne dose de contextualisation. Sur ce dernier point l’article proposé n’apporte pas de réponses très importantes, mais des pointeurs intéressants vers l’ouvrage Lean UX.

Notre offre de transformation agile

Read More
blank

Evénement CIO DSI Agile

Evénement CIO DSI Agile

Venez me retrouver le 13 juin 2017 à l’événement DSI Agile organisée par CIO événements.
A l’agenda :

1. Agilité

Qu’il s’agisse du Build comme du Run, la DSI doit pouvoir s’adapter aux évolutions des besoins et de la demande. Du développement agile au cloud hybride, tout est bon pour cela.

2. DevOps

Le développement agile se heurtait jadis au mur de la mise en production. Les méthodes de mises en production continues font sauter ce bouton sans mettre en cause la stabilité du SI.

3. API

Si le concept d’urbanisation ou d’APi n’est pas jeune, organiser tout son système d’information autour d’une notion de services publiés permet d’atteindre le Graal de l’agilité fiable.

4. Management agile

L’agilité n’est pas une affaire d’outils ou de méthodes. Ce sont bien les hommes qu’il faut faire changer. Le management doit s’adapter à l’agilité.

Plus d’information ici : http://www.cio-online.com/conferences/lire-la-dsi-agile-245.html

Read More
blank

Des tranchées à l’agilité d’entreprise, IT Expert

Article IT Expert

L’agilité est régulièrement évoquée comme levier de performance globale dans le discours des grands dirigeants du CAC 40. Elle s’inscrit dans les stratégies des grandes entreprises telles qu’Orange, AXA ou le Crédit Mutuel. Mais passer d’une volonté stratégique à une réalité opérationnelle dans toute l’entreprise n’est pas simple. Le management intermédiaire se retrouve souvent perdu face à la transformation à mener et ne sait pas comment décliner opérationnellement cette intention. Vous découvrirez dans cet article comment opérer cet alignement de bout en bout.

Découvrez le nouvel article sur l’agilité d’entreprise publié dans IT Expert.

Read More
blank

SAFe, le Release Train Engineer, clé de voute du train agile

Issu du Framework SAFe, le rôle de RTE (Release Train Engineer) est le plus critique d’un bon déploiement de l’agilité à grande échelle. Le RTE pose le cadre méthodologique et veille à sa bonne application tout en améliorant le système au fur et à mesure. Maitriser le Framework ne suffit pas, le RTE doit aussi disposer de qualités humaines certaines pour pouvoir mener à bien ses missions.

RTE clé de voute du trio de gouvernance programme

La gouvernance du niveau programme de SAFe s’appuie sur le trio Release Train Engineer (RTE), Product Manager et System Architect. Là où le Product Manager est garant du contenu fonctionnel du train et le System Architect, garant de l’architecture, le RTE est garant du cadre méthodologique.
Le RTE met tout en œuvre pour que le train parte toujours à l’heure, qu’il puisse avancer en toute circonstances avec un contenu de qualité fourni par ses deux rôles partenaires.

Release Train Engineer

Le RTE, Scrum Master des Scrum Masters

Pour les adeptes de Scrum, le premier rôle visible et simple à appréhender du RTE est celui de Scrum master des Scrum Masters. Le RTE organise deux fois par semaines des ART Sync (voir l’article sur les ART Sync). Equivalents de Scrum Of Scrum avec les Scrum Masters et les Product Owners, cet événement a pour objectif d’identifier tous éléments pouvant bloquer tout ou partie du train agile et si nécessaire de définir les actions de contournement.

Le RTE veille à la montée en compétence des Scrum Masters des différentes équipes et à leur bonne appropriation des différents événements qu’ils doivent faciliter en commun.

Le RTE facilitateur des principaux événements de niveau programme

Le RTE s’appuie en effet sur les Scrums Master pour faciliter l’événement principal de SAFe, à savoir le PI planning. Véritable grand-messe qui réunit l’intégralité des équipes agiles et des donneurs d’ordre du programme, cet événement réuni des dizaines de personnes qui doivent collaborer de manière efficace durant les deux jours pour débroussailler le travail sur plusieurs Sprints. Le RTE et les Scrums Master s’assurent de leur alignement durant les deux sessions de team breakout. Pour cela ils doivent se coordonner de manière étroite et rapide durant les deux jours. Faciliter un PI Planning revient à surveiller une douzaine de casseroles de lait sur le feu proches de l’ébullition… cela demande une vraie capacité à jongler et un calme olympien.

Pour préparer cet événement le RTE doit s’assurer de la qualité des Features qui lui sont fournis par les Product Managers et System Architects, de la logistique de la salle, des fournitures, de la présence des parties prenantes, de l’agenda des différentes interventions… une telle mobilisation de moyens humains ne peut être freinée par un détail de logistique.
Préparer un PI Planning nécessite une vraie anticipation !

Hormis cet événement majeur, le RTE facilite l’ART Sync, l’Inspect and Adapt, les Systems Demos et potentiellement aussi le Release Management.

Alors à quoi ressemble un bon RTE ?

Vous l’aurez compris, RTE est un job full time les différents événements de niveau programme nécessitent de la préparation, de la coordination et de l’anticipation, son rôle de développeur des Scrums Masters est tout aussi crucial.

Le RTE doit avoir une vrai qualité d’écoute et de pédagogie relationnelle, une grande capacité d’organisation, de synchronisation et d’anticipation et une vraie intelligence de situation pour animer le PI Planning.

Le RTE doit adopter une posture haute pour fixer le cadre dans les différents événements qu’il facilite et une adopter une posture basse quant au contenu de ce qui est produit. Son style de leadership doit être à la délégation, notamment dans le PI planning qu’il ne peut animer seul sans l’aide des Scrum Masters.

Indispensable au bon fonctionnement du train, le RTE ne doit pas se transformer en sauveur et porter sur ses épaules tout le poids du train !

Si vous souhaitez déployer SAFe dans votre organisation, consultez nos offres de conseil en transformation.

Vous souhaitez former votre futur RTE et les autres rôles de management d’un train SAFe, participez à une formation Leading SAFe.

Vous êtes RTE et vous souhaitez continuer à transformer votre posture, le coaching de manager est fait pour vous.

Read More