Category: Expertise

blank

Comment décliner votre stratégie plus rapidement par une gestion de portefeuille lean-agile

gestion de portefeuille lean-agile

La gestion de portefeuille lean-agile a pour rôle de décliner la stratégie de l’entreprise en initiatives opérationnelles. C’est en quelque sorte une membrane d’échange entre l’écosystème de l’entreprise et son environnement. Elle permet l’implémentation de la stratégie et sa validation ou sa révision suite à sa mise en œuvre.

1. Dans quel but adopter une gestion de portefeuille lean-agile ?

L’essor des nouvelles technologies et l’accélération de la concurrence raccourcissent la durée de vie de s nouvelles opportunités. Cette volatilité accrue du marché vient percuter le mode d’analyse des opportunités des portefeuilles classiques, ainsi que leur capacité à aligner rapidement toute l’organisation à une nouvelle stratégie. Vous devez réduire le temps nécessaire pour lancer de nouvelles initiatives et évitez de perdre en coût d’opportunité.

De plus, la mise en place de modèles de delivery agiles à l’échelle s’accélère. Ceci vient apporter de la flexibilité à l’organisation, avec des équipes qui repriorisent régulièrement leurs taches. La gestion de portefeuille doit gagner en flexibilité pour maximiser votre production de valeur. Ceci se fait en revoyant régulièrement les initiatives prioritaires ainsi que l’effort à allouer à leur implémentation.

2. Quels en sont les mécanismes clés ?

Premièrement, le processus de gestion de portefeuille doit pouvoir gérer plusieurs types d’activité. A minima, il doit traiter distinctement l’analyse des nouvelles opportunités et le pilotage des initiatives engagées.
En amont, le processus doit capter en continu chaque nouvelle opportunité sous forme d’initiatives. Leur affinage se fait progressivement pour ne conserver que celles avec le plus haut retour sur investissement. En aval, le pilotage de l’engagement doit se traduire par une repriorisation régulière des initiatives et une réévaluation de l’effort consenti. De plus, synchroniser ces revues avec un modèle de delivery agile facilite l’alignement de toute l’organisation sur une évolution stratégique.

Deuxièmement, vous devez placer le backlog des initiatives validées au centre du processus. Les hypothèses de résultats business ou technique sont challengées régulièrement, ce vous permet une repriorisation régulière et vous garantit que votre organisation travaille toujours sur ce qui a le plus de valeur pour vos commanditaires.
On constate que ces initiatives, stratégiques, sont très différentes des projets classiques. Celles-ci nécessitent un découpage permettant d’apporter de la valeur le plus vite possible.

Troisièmement, des critères de filtrages doivent supporter ce processus. Ils doivent porter sur l’alignement avec la stratégie d’entreprise (thèmes stratégiques) et sur la disponibilité de financement. A plus haut niveau, c’est un modèle économique de priorisation qui structure l’ordonnancement des initiatives.

En complément, une organisation Produits de l’entreprise facilite le fonctionnement d’un portefeuille lean-agile, grâce  au financement capacitaire. Celui-ci rapproche la priorisation économique de la capacité opérationnelle. Cette organisation facilite aussi l’autonomie des équipes sur les chaînes de valeurs considérées.

3. Pourquoi l’adopter dès maintenant ?

Le temps passé avec une gestion de portefeuille classique représente un manque à gagner potentiel pour l’entreprise. Ce cout d’opportunité perdu joue en la faveur d’une gestion de portefeuille lean agile. D’autant qu’il n’y a pas de raisons techniques à attendre une mise en place d’un modèle agile complet pour finalement “étendre au portefeuille”.
De plus, la gestion de portefeuille regroupe plusieurs parties prenantes clés dans une organisation. Enfin, placer le sujet de sa transformation à l’ordre du jour, c’est vous assurer d’embarquer ces parties prenantes. Elles sauront devenir des agents du changement pour l’ensemble des étapes de transformation qui suivront.

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

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
blank

Adieu COPILs, bienvenue aux ART Sync SAFe

Que deviennent les vieux COPILs lorsque l’on passe à l’agilité à grande échelle avec SAFe ?

COPIL : coordination entre équipes, gestion des risques et dépendances  

Dans une approche classique, les comités de pilotage servent à coordonner piloter les risques, les jalons principaux et les dépendances avec d’autres projets. Ils débordent souvent sur des aspects opérationnels et viennent souvent constater des dérives difficiles à redresser.

Pourquoi sont-ils si peu efficaces ?

La lourdeur de leur préparation et la présence d’acteurs peu disponibles imposent une fréquence assez faible (en général un par mois) qui autorise les projets à dériver sur une durée trop importante. En effet, sur un mois une équipe a largement de dériver du plan établi et se retrouver dans une situation difficile par manque d’arbitrage et d’alignement intermédiaire.

L’ART Sync SAFe

SAFe, le framework d’agilité à grande échelle propose un mécanisme très simple à mettre en place qui permet de créer un alignement quasi permanent entre les équipes et une gestion des risques au plus près : l’ART Sync. Cet événement bi-hebdomadaire de 15 minutes sous l’égide du RTE (Release Train Engineer)  regroupe les Scrums Master et les Product Owners des équipes agiles du train1. L’événement se tient devant le Program Board et le Tableau des risques tous deux construits lors du PI Planning.

Deux questions simples se posent à chacune des équipes : y-a-t-il un Feature en risque dans l’équipe ? existe-t-il un risque systémique actif dans l’équipe ?

Si une équipe a un Feature en risque, le RTE propose alors de traiter en rechercher en séance une solution pour sécuriser sa production. Pour cela il s’appuie sur les autres équipes qui peuvent proposer leur aide ou en cas d’impossibilité, le RTE peut chercher à éliminer un Feature moins prioritaire (WSJF plus faible) et dégager la capacité pour sécuriser celui en risque. Si une solution est trouvée en séance, le train reprend son cours, les Scrum Masters et Product Owner pouvant immédiatement communiquer aux équipes les retours de l’ART Sync.

Si la recherche de solution ne peut-être résolue en séance, elle est traitée en aparté et peut nécessiter de mobiliser les parties prenantes du train pour arbitrer sur l’élimination ou la dégradation d’un Feature important du PI. Dans tous les cas, les risques portant sur le contenu de l’incrément de programme sont immédiatement rendus visibles aux parties prenantes qui peuvent arbitrer au plus tôt.

Se tenant à une fréquence bi-hebdomadaire, les ART Sync, ne laissent jamais dériver le train qui reste en permanence sur ses rails. Cet événement renforce la collaboration entre les équipes et le pilotage par la valeur central au fonctionnement de SAFe.

Pour aller plus loin, consultez nos offres de conseil sur SAFe et nos formations Leading SAFe.

1Train : ensemble des équipes agiles qui participent à la construction d’un incrément de programme dans le framework SAFe.

Read More
blank

Les 4 clés pour réussir son PI Planning SAFe

Le PI Planning est l’événement le plus symbolique du framework d’agilité à grande échelle SAFe. Il regroupe l’intégralité des équipes agiles, le management et les parties prenantes du programme. C’est souvent une centaine voire des centaines de personnes qui collaborent intensivement pour organiser les travaux de l’incrément de programme sur lequel ils doivent travailler pendant plusieurs semaines.
Pour un manager n’ayant jamais vécu un tel événement, il est souvent perçu comme une dépense énorme alors que son ROI est tout juste incroyable !

Les clés pour réussir cet événement sont pourtant simples :

  1. Garder en tète en permanence l’objectif de l’événement
  2. Soigner sa préparation
  3. Commencer par appliquer l’agenda standard puis l’améliorer
  4. Veiller à la motivation de toutes les parties prenantes

Garder en tète en permanence l’objectif de l’événement

Le PI Planning a pour objectif d’aligner toutes les équipes du programme ou des programmes entre elles, de les engager sur des objectifs construits et partagés durant le planning, de les faire travailler sur leurs Backlogs de Sprints respectives et d’identifier leurs dépendances structurantes.

Ce PI planning repose sur le principe du manifeste agile qui pousse à privilégier la communication directe entre tous les membres du programme en un temps très réduit pour obtenir un consensus sur l’incrément à venir.

Les équipes sortent de l’événement avec une première version de leurs backlogs de sprints pour les itérations de l’incrément de programme et des objectifs pour chacun de leurs sprints.

Le management du programme sort avec un Program Board traduisant l’engagement des équipes à livrer leurs features lors des sprints de l’incrément de programme, des objectifs synthétisant cet engagement des équipes et une liste de risques à piloter durant l’incrément.

Les porteurs métier sortent eux en ayant l’assurance de l’engagement et de la compréhension des équipes par rapport à leurs enjeux.

L’important est donc de focaliser les équipes sur l’analyse de leurs features et leur découpage en stories, l’analyse de ces stories à un premier niveau de maille permettant d’en estimer la complexité. Ce travail doit leur permettre rapidement de construire leur Sprint Boards, d ‘identifier les dépendances avec les autres équipes et d’identifier les risques à adresser.

Il faut faut veiller à ce que les équipes ne fasse pas un travail trop en profondeur pour une partie de leurs travaux et ne soient pas en capacité d’avoir une vision large de leurs travaux.

L’événement dure 2 jours complets, mais les bénéfices sont énormes : à la sortie du premier PI Planning auquel j’ai assisté, un des directeurs informatique nous a dit :

« Nous n’avons jamais pris autant de décisions en si peu de temps, si nous avions dû programmer des réunions pour nous caler, nous aurions mis des semaines pour nous accorder et cela aurait couté extrêmement cher ! »

En effet, du fait de la présence de tous les acteurs en un même endroit, les décisions sont prises extrêmement rapidement et en ayant toutes informations pour être prises de manière éclairées.

Soigner la préparation de l’événement

Le PI planning regroupant l’intégralité des équipes agiles et le management, on ne peut se permettre de le rater, sa préparation doit être impeccable et les équipes ne doivent pas être freinées durant leurs travaux par des problèmes de logistique ou de disponibilité d’acteurs clé pour décider.

Concernant la logistique, la salle doit être suffisamment grande pour accueillir tout le monde et doit disposer de surfaces murales permettant de travailler directement dessus avec les Postits géants. Les fournitures à prévoir et à pré organiser sont elles aussi assez nombreuses, l’idéal étant de se référer à l’ART Launch Pack fourni par Scaled Agile pour calculer au plus juste les éléments à préparer si vous ne l’avez jamais fait.

La disponibilité des personnes clé permettant d’arbitrer, de découvrir, de comprendre les features que les équipes doivent s’approprier est fondamentale. L’événement étant à une fréquence connue à l’avance, il faut bien veiller à la présence des Epic Owners, des Product Managers, des Business Owners et de toute personne étant utile aux équipes, la qualité du travail des équipes et leur capacité à s’engager dépend grandement de la présence de ces personnes durant les travaux en équipes.

Pour faciliter la présentation et rappeler à tout le monde le fonctionnement du PI Planning au fur et à mesure, nous vous recommandons de créer un jeu de slides tout préparé que vous pouvez utiliser d’un PI à un autre et qui préciser pour chaque partie de l’agenda le fonctionnement et les règles d’acceptation du travail produit.

Commencer par appliquer l’agenda standard puis l’améliorer

Selon mon expérience, Scaled Agile dispose de suffisamment de recul pour proposer un fonctionnement qui doit marcher du premier coup dans tous les contextes. Il est très tentant d’essayer d’optimiser le PI Planning en cherchant notamment à en réduire le cout en réduisant la durée, les équipes présentes, mais le résultat est très rapidement décevant et l’on se retrouve face à un gâchis.

Commencez donc par suivre à la lettre ce qui est proposé et profitez de la rétrospective en fin de chaque PI Planning pour l’améliorer et le contextualiser à votre organisation.

Veiller à la motivation de toutes les parties prenantes

Le PI Planning est un exercice de transparence et d’explication à grande échelle. Le management vient expliquer les enjeux de l’entreprise qui sont adressés par l’incrément de programme, les Thèmes Stratégiques qui couvrent ces enjeux, les Epics sélectionnés qui réalisent les Thèmes Stratégiques et enfin les Features de l’incrément de programme sur lesquels les équipes vont travailler et qui contribuent aux Epics sélectionnés.

Cette compréhension de bout en bout de la valeur des travaux de chacune des équipes et chacun des équipiers est fondamentale pour leur motivation. L’émulation créée par le travail collaboratif durant ces deux jours à la fois au sein de chaque équipe et entre les équipes crée un réel esprit de corps qui s’aligne à réaliser les objectifs de l’incrément.

Pour atteindre cette motivation, le management doit travailler son leadership, sa pédagogie relationnelle et laisser les équipes autonomes pour travailler selon la vision proposée. Attention à l’interventionnisme, ou au reflexes de commande / contrôle issus des méthodes traditionnelles. La réunion de management en foin de première journée doit être expliquée le lendemain avec pédagogie et les solutions trouvées ou proposées de manière collaborative avec les équipes.

L’idéal pour réussir cet événement est de s’appuyer sur un SAFe Program Consultant expérimenté apte à vous guider dans sa préparation et son déroulé, vu l’enjeu de l’événement vous ne pouvez vous permettre de le rater.

En savoir plus sur SAFe, suivez nos formations Leading SAFe ou SAFe PM/PO.

Read More
blank

Contrat agile et pilotage par la valeur

Le digital impose un nouveau rythme et redéfinit les organisations, les processus, la culture, les valeurs, les pratiques et les comportements. Les entreprises agiles, capables de tirer partie de l’innovation, s’adaptent mieux à ces bouleversements. L’agilité ne se réduit toutefois pas à la capacité d’anticiper,
d’innover et de coopérer.

L’entreprise véritablement agile place la valeur au centre de son processus décisionnel ce qui implique de mettre en place un modèle de contractualisation et un mode de pilotage des projets centrés sur la valeur créée.

Les méthodes agiles de pilotage de programme ou projet privilégient la réalité opérationnelle et invitent à appréhender différemment la négociation contractuelle et la gestion des projets informatiques, dans une démarche collaborative entre client et prestataire. Rompant avec les contrats de développement ou d’intégration classiques qui réservent à l’expression initiale des besoins un rôle déterminant, les contrats agiles permettent d’éviter de nombreux effets pervers : une gestion des ressources à l’économie par le prestataire au détriment de la qualité, une renégociation systématique en cours de projet à chaque changement fonctionnel et la poursuite d’un projet qui dérive. Les méthodes agiles ont ainsi libéré les contrats de développement et d’intégration de leur carcan trop rigide et formaliste. Cependant, même lorsqu’elles ont entamé leur transformation vers l’agilité, les entreprises continuent bien souvent de contractualiser les projets selon deux formes basiques : la régie (mise à disposition de ressources) ou le forfait (engagement du prestataire sur un périmètre et un délai de réalisation pour un montant global), avec la variante de la régie forfaitisée (mise à disposition de ressources dans la limite d’un montant global).

Dans les deux cas, les projets sont abordés sous l’angle de leur coût et non de la valeur qu’ils apportent à l’entreprise et celle-ci n’est donc pas prise en compte dans la relation entre les parties. En régie, le coût est directement proportionnel au temps passé. Au forfait, le coût anticipé repose sur la connaissance a priori du périmètre du projet et de sa stabilité dans le temps, cette analyse prédictive étant particulièrement délicate à manier. Au rythme des changements auxquels sont soumises les organisations, la stabilité du périmètre est devenue un leurre qui fait dériver les projets ou mène au contentieux. Sous la pression des directions achats , la régie tend à disparaître au profit du forfait censé offrir davantage de visibilité.
Néanmoins, l’ambiguïté de ce modèle est qu’il repose bien souvent sur un marché de dupe lié aux incertitudes du périmètre, quand bien même le risque serait réduit en mode agile par la pratique du mini-forfait couvrant un sprint ou des fonctionnalités identifiées.

Replacer la valeur au centre de la relation contractuelle

Dans la perspective de replacer la valeur au centre de la relation contractuelle, quel modèle contractuel faut-il alors mettre en place ?
Le principe est d’adopter un modèle contractuel qui fixe le délai et le coût en fonction de la valeur à produire et de la valeur effectivement produite, en faisant varier le périmètre fonctionnel. Afin de maximiser la valeur produite dans le temps, en suivant le rythme des changements (réglementaires,
concurrentiels, etc.). Selon ce modèle contractuel agile, le projet doit permettre d’atteindre un seuil minimum de valeur acquise lequel peut d’ailleurs fluctuer au cours de l’avancée du projet. Le projet s’arrête lorsque le client estime que suffisamment de valeur a été créée et non plus quand le périmètre est intégralement réalisé avec le risque de dépenser trop et de retarder inutilement la fin du projet. Comme tout contrat agile, ce modèle suppose de manier les concepts de l’agilité pour contractualiser et piloter sereinement les projets (story point , sprint , incrément , done , coût du story point , etc.) mais en gardant à l’esprit que l’enjeu derrière ces indicateurs est de motiver le prestataire à produire de la valeur, en favorisant le changement et l’équilibre entre les intérêts du client et de son prestataire.
Partant de l’idée que le client ne peut obtenir que ce qu’il mesure, il est déterminant de contractualiser et de piloter les projets à partir d’indicateurs pertinents de la création de valeur.

La mesure de la valeur

Si le coût du Story Point est un indicateur pertinent de pilotage des projets, il ne permet toutefois pas de mesurer la valeur créée. Le ROI (ratio valeur / effort), mêlant un indicateur client et un indicateur prestataire, permet de fixer un objectif mais s’adapte mal aux multiples changements qui interviennent au cours des projets et notamment au mécanisme de « change for free » des projets agiles. En revanche, le cost of delay qui représente la valeur et l’envisage dans toutes ses dimensions (valeur métier, criticité temporelle et réduction de risque ou opportunité dégagée) permet de piloter les projets par la valeur et de suivre cet indicateur au fil du temps.
Ce concept permet en effet de modéliser la valeur, tout en permettant de valoriser le bénéfice à réaliser un projet par rapport au gain manqué en cas de non-réalisation et permet donc de comparer différents projets d’un même portefeuille. Concrètement, le cost of delay est déterminé de manière
collaborative entre les représentants métier et l’équipe projet et permet de chiffrer et de suivre la réalisation d’un objectif exprimé en valeur relative pour un projet donné. Le cost of delay ne tient cependant pas compte de l’effort à fournir par le prestataire pour développer la solution qui s’estime par le Story Point. Les Story Points permettent en effet de déterminer initialement l’effort à produire, tant au niveau de la fonctionnalité à développer qu’au niveau des incréments. En général, les Story Points sont estimés de manière collaborative par les équipes qui ont la compétence pour réaliser les incréments. Il s’agit d’évaluer une unité relative qui serve de référence pour évaluer l’effort, indépendamment du facteur temporel pris en compte dans la détermination du nombre et de la durée des Sprints.
La priorisation des projets ou des fonctionnalités s’effectue ensuite en rapprochant le cost of delay et le Story Point ; les projets ou fonctionnalités apportant le plus de valeur pour un moindre effort seront réalisés en priorité.
Enfin, les parties peuvent convenir de faire varier le coût du Story Point en fonction de la valeur créée ce qui permet d’associer pleinement le prestataire
à la réussite du projet et de l’inciter à créer de la valeur.

La contractualisation sur la valeur

Si agilité et contractualisation ne vont pas naturellement de pair, le contrat demeure l’instrument indispensable de la sécurité juridique des projets.
Simplement, le contrat ne doit pas constituer un frein à l’agilité mais  être flexible, s’adapter à ce type de projets. Le contrat a vocation à porter ce type de pilotage par la valeur et à définir les droits et obligations des parties
dans ce contexte. L’articulation entre un contrat-cadre fixant et des contrats d’application permet de piloter un projet par la valeur.
Le contrat-cadre définit les clauses contractuelles générales, la collaboration, la gouvernance et les mécanismes d’arbitrage et de gestion du changement, que ces changements soient à l’initiative du client (évolution de périmètre) ou du  prestataire (évolution de sa performance). Par exemple, le contrat-cadre détermine la capacité à produire du prestataire avec une marge de manœuvre suffisante pour absorber les changements sans nécessité de renégocier le contrat. Le contrat-cadre fixe également la durée du contrat, les cas de sortie et les conséquences de la résiliation du contrat. Il définit enfin le nombre d’itérations par contrat d’application et leur longueur pour inscrire le projet dans une temporalité faite de courtes itérations et faciliter la sortie du projet, en fonction de la valeur créée ou en cas d’échec en associant des mécanismes financiers adaptés au modèle économique du prestataire.
Le contrat d’application formalise une valeur cible, valorisée en cost of delay, ainsi qu’une valeur minimum à produire. Le contrat d’application décrit également le périmètre sous forme de fonctionnalités ou de user stories, valorisées en story point.
Ce périmètre permet de piloter les changements et leur impact sur la valeur produite et corrélativement, le coût du story point.
La contractualisation agile sur la valeur substitue ainsi des mécanismes de partage des bénéfices de la valeur produite, d’arbitrage et de gestion du changement aux mécanismes classiques dont la négociation peut s’avérer longue et difficile. C’est particulièrement le cas des clauses « dures » relatives à la responsabilité, aux pénalités et à la nature de l’obligation du prestataire, à la définition du périmètre et aux cas de résiliation du contrat. Côté client, les mécanismes d’arbitrage et de « change for free » couplés aux mécanismes de gestion du changement et de sortie facilitée du contrat fixent les bornes de manière souple. Côté prestataire, un engagement de valeur acquise minimum vient se substituer à l’obligation de résultat avec une variation du prix de l’unité d’effort en fonction de la valeur produite par itération et de sa qualité. Le prestataire est ainsi incité à augmenter sa productivité et sa capacité à faire pour livrer au plus tôt de la valeur. Attention toutefois à ne pas vouloir pousser à l’excès la vélocité au risque de mettre en péril la qualité !
C’est bien à l’équipe de décider des éléments sur lesquels elle s’engage en début de sprint sur la base d’une vélocité acceptable.

Agilité, flexibilité et création de valeur

Pour être pleinement agiles, les équipes opérationnelles, les acheteurs et les directions juridiques doivent faire évoluer leurs modèles et sortir des mécanismes classiques pour adopter une approche centrée sur la création de valeur au sein de l’entreprise. Mettre en place ce type de contrat, étroitement lié au pilotage des projets, implique une conduite du changement et un accompagnement juridique des acteurs (opérationnelles, juristes, acheteurs) car elle implique une transformation des processus et une plus grande collaboration. Dès lors que l’ensemble des acteurs partage les concepts et les indicateurs, les négociations sont facilitées, la collaboration peut primer sur la négociation contractuelle et cette approche pragmatique se révèle alors extrêmement productive.

En collaboration avec Eléonore Varet.

Découvrez nos offres pour chief légal officer et juriste informatique

Read More