Design Thinking à l’échelle : l’ascension vers l’innovation

design thinking à l'échelle

Le Design Thinking apparaît comme une solution efficace pour accélérer la génération de nouvelles idées. Mais l’utiliser sur quelques projets ponctuels ne suffit pas pour booster considérablement la croissance de l’entreprise et améliorer ses processus en profondeur. Pour accélérer l’innovation, il est urgent de changer d’échelle en déployant le Design Thinking à toutes les strates de l’entreprise.

 

Faire appel à des équipes pluridisciplinaires…

Le Design Thinking à l’échelle aide à fédérer l’ensemble de l’entreprise autour d’une vision stratégique commune et installe un environnement organisationnel propice à l’innovation. En effet, pour mobiliser les ressources nécessaires à la génération de nouvelles idées, le fait de déployer du Design Thinking à l’échelle favorise la dissolution des silos existants dans l’organisation en créant des équipes pluridisciplinaires (marketeurs, développeurs, ingénieurs, créatifs…) et de niveaux hiérarchiques variés (du top management jusqu’aux équipes opérationnelles). 

Cette pluridisciplinarité permet de multiplier les points de vue et d’obtenir ainsi une connaissance riche des marchés, des tendances… Avec cette vision transversale des équipes, les entreprises conçoivent plus facilement des produits pertinents, en phase avec la réalité du terrain. De plus, l’ensemble des salariés s’approprient mieux les projets, puisque tous les départements sont impliqués.

 

… pour accélérer l’innovation et favoriser la collaboration…

Le Design Thinking à l’échelle est une approche résolument centrée sur l’humain plus que sur les processus ou les outils. Et c’est justement l’importance accordée aux pratiques réelles des utilisateurs et les tests concrets qui rendent les innovations pertinentes. Pour cause, les équipes projets pluridisciplinaires, réactives et agiles, mettent rapidement en place des prototypes Lo-Fi (maquette papier-crayon, objets en carton…). Une étape qui permet d’accélérer la mise sur le marché d’innovations, en suivant le principe de Tim Brown, l’un des théoriciens du Design Thinking : “Il faut échouer tôt pour réussir plus vite”.

Mobiliser les collaborateurs pour innover ensemble est un excellent moyen d’ancrer une véritable démarche d’innovation à l’échelle de l’entreprise. Tous les services et tous les niveaux hiérarchiques se trouvent emportés dans cette dynamique.

 

… de façon pérenne

Le Design Thinking déployé à l’échelle a vocation à insuffler de l’innovation sur le long terme. En effet, il redonne de l’autonomie aux équipes de façon à ce qu’elles soient en mesure d’innover continuellement. Contrairement au Design Thinking “en mode projet”, où les groupes se réunissent autour d’un objectif précis (ayant une date de début et de fin), le Design Thinking à l’échelle de l’entreprise a vocation à suivre le rythme des équipes dans le temps, au service continu de la création de valeur et de la croissance.

 

Oui, mais comment ?

Adossé au framework SAFe® (Scaled Agile Framework), le Design Thinking à l’échelle permet d’intervenir sur trois niveaux :

  • Au niveau de la gestion de portefeuilles (top management, comités de direction, responsables de budgets, de roadmaps, de plans marketing), pour approfondir les thèmes stratégiques de l’organisation, identifier les initiatives répondant au mieux à leur raison d’être et aller chercher une meilleure compréhension de la valeur potentielle de chacune de ces initiatives en définissant son MVP, le Minimum Viable Product, c’est-à-dire le plus petit périmètre de l’initiative qui apportera le maximum de valeur à l’utilisateur final.
  • Au niveau de la direction opérationnelle des programmes (management intermédiaire), pour fluidifier la transition entre la conception et le développement et accélérer la mise en œuvre des initiatives priorisées grâce à l’identification, l’exploration et la structuration en continu par les équipes opérationnelles de fonctionnalités à forte valeur ajoutée.
  • Au niveau des équipes opérationnelles, pour leur laisser régulièrement un temps de respiration et d’innovation « libre » et contribuer à l’éclosion d’une intelligence collective, source d’innovation et de motivation pour les équipes.

 

Tous ces niveaux ne sont naturellement pas hermétiques en termes de participants et pour chaque intervention, il conviendra d’adresser un casting pertinent qui saura apporter le maximum de richesse en termes d’idées.

 

À long terme, le Design Thinking déployé à l’échelle a vocation à devenir un élément de la culture d’entreprise et implique donc inévitablement d’importants changements managériaux et organisationnels. L’idéal est de se faire accompagner pour mettre en place une méthodologie pérenne au sein de l’entreprise. Un partenaire expert du Design Thinking, tel qu’inspearit, aura l’expérience nécessaire pour appliquer la méthode à l’échelle de l’organisation et mettre en oeuvre les prérequis indispensables à un bon fonctionnement sur le long terme.

time to market ebook

Le Quoi et le Pourquoi par Thierry Ventadour

Le but d’un daily meeting Agile n’est pas de dire ce que l’on a fait la veille et ce que l’on fera le lendemain, non, ce n’est qu’un moyen ! De même, le but d’une Démo, ou Sprint review, n’est pas de montrer ce que l’équipe a développé pendant le sprint, ce n’est également qu’un moyen.

équipe Agile Scrum Master

En confondant le but et le moyen, de nombreuses équipes déploient une version mécanique de frameworks Agile comme Scrum, sans en comprendre les valeurs et les principes. Ces pratiques perdent alors en efficacité et le risque est fort de les abandonner. Combien d’équipes réduisent la fréquence des daily meetings à une ou deux réunions par semaine, « histoire de perdre moins de temps » ? Combien d’équipes ne font plus de rétrospectives car « on sait bien ce qui s’est mal passé » ? Combien d’équipes ne mettent en place ces cérémonies que pour cocher les cases d’une check-list et pouvoir se dire « Agile » ?

Le rôle des coachs Agile et des Scrum Masters n’est pas tant d’expliquer comment déployer ces pratiques Agile, mais surtout pourquoi, expliquer leurs finalités, ce qu’elles vont, et doivent, apporter à l’équipe. La finalité d’un daily meeting est de créer un esprit d’équipe en faisant que ces membres travaillent ensemble et s’aident mutuellement, de synchroniser les travaux de chacun, et donc d’échanger des informations qui vont faciliter ce travail d’équipe, cette synchronisation. Toute autre information est superflue.

La finalité d’une rétrospective est d’instaurer une boucle d’amélioration à l’intérieur de l’équipe, en identifiant de petites actions qui, petit à petit, vont faciliter sa vie et donc améliorer son efficacité et sa prédictibilité.

En s’assurant que les équipes comprennent la finalité de ces cérémonies, elles pourront mieux les adapter à leurs besoins, comprendre le sens de leurs actions et être ainsi plus motivées, comprendre ce qui doit résulter de ces réunions et être ainsi plus efficaces. Un bon Scrum Master n’applique pas Scrum de manière livresque, mais de manière Agile, au sens des valeurs de l’Agilité.

Beaucoup d’équipes ne confondent pas uniquement but et moyen pour l’implémentation des frameworks Agile (Scrum, Kanban, SAFe, …), mais également pour le développement de nouvelles fonctionnalités. Ainsi, le but d’une équipe Agile n’est pas uniquement de livrer les fonctionnalités demandées par le Product Owner ou Product Manager, mais surtout de livrer des fonctionnalités qui résoudront le problème de l’utilisateur ou lui donneront l’opportunité d’être plus efficace.

Pour cela, il faut non seulement que les membres de l’équipe comprennent ce qui doit être développé, le quoi, mais surtout pourquoi il faut développer ces fonctionnalités, le pourquoi. Comment peut-on développer une nouvelle fonctionnalité sans savoir comment elle va être utilisé et les critères que l’utilisateur va utiliser pour juger si elle est bonne ou non ?

En comprenant la finalité de la fonctionnalité à développer, les membre de l’équipe Agile seront mieux à même de faire des propositions d’amélioration, de mieux tester les développements et seront plus motivés par leur travail.

Quelque soit l’action réalisée, développement d’une nouvelle fonctionnalité, participation à une cérémonie Agile, chaque membre de l’équipe doit en comprendre la finalité, ne pas hésiter à poser la question « Pourquoi ? » Comment saurons-nous que c’était la bonne fonctionnalité, la bonne IHM, le bon traitement ? En fin de cérémonie Agile, comment sauront-nous que nous avons été efficace ? Le rôle du Scrum Master est du coach Agile est de s’assurer que cette finalité est partagée par tous.

REX d’un lancement de train SAFe atypique par Stéphane Déprès

REX de notre consultant Stéphane Déprès qui intervient dans le cadre d’un vaste programme de déploiement de l’Agilité à l’échelle en tant que coach agile@scale et coach lead.

retour expérience d'un train SAFe

Contexte

L’organisation pour laquelle j’interviens possède un data warehouse (entrepôt de données) dont le développement, la maintenance et le support occupe environ 150 personnes.

L’objectif de ce data warehouse est de fournir un ensemble de données servant de référence unique pour le reporting et la prise de décisions dans l’entreprise. Il est alimenté par de très nombreux fournisseurs de données et utilisé par de très nombreux consommateurs de données.

La structure organisationnelle et les mécanismes de synchronisation mis en œuvre autour du data warehouse

Comme beaucoup de data warehouse, ce data warehouse est traversé par plusieurs chaines de valeur métier. Se pose donc la question de la structure organisationnelle et des mécanismes de synchronisation agile permettant à la fois :

  • D’optimiser le time-to-market par chaîne de valeur en synchronisant de manière efficace le développement des applications consommatrices des données, le développement du data warehouse et le développement des applications fournissant les données. En sachant qu’historiquement, les équipes concernées avaient du mal à se coordonner.
  • De garder une stratégie de développement du data warehouse non segmentée par chaîne de valeur et d’adresser la cohérence cross chaînes de valeur.

L’organisation pour laquelle j’interviens prône une approche Spotify pour la structure organisationnelle à laquelle viennent s’ajouter des mécanismes de synchronisation dimensionnés en fonction du contexte allant d’un « light sync » dérivée de LeSS à des trains SAFe. Nous avons donc exploité cette approche.

Nous avons décidé de garder une tribu centrée sur le data warehouse, ce qui permet d’adresser la cohérence cross chaînes de valeur et donc l’optimisation des coûts. Nous avons également déployé des trains SAFe pour synchroniser de manière efficace data warehouse, consommateurs et fournisseurs de données. Ceci permet de tirer parti du meilleur des deux mondes.
Avec cette approche nous avons donc des trains SAFe avec peu de dépendances externes, ce qui n’aurait pas été le cas d’un train SAFe dédié uniquement au développement du data warehouse.

Mais revenons à la structure organisationnelle de la tribu data warehouse et en particulier à l’axe de découpage de la tribu en Feature Teams. Nous avons en fait envisagé de nombreux scénarios pour lesquels nous avons étudié les avantages et les inconvénients dans le cadre d’un workshop impliquant une trentaine de membres de la tribu.

Deux scénarios principaux se sont dégagés :

  • Un axe de découpage par ligne métier qui avait l’avantage d’optimiser le time to market par ligne métier mais qui n’adressait pas la rationalisation du développement (un même type de données étant utilisé par plusieurs lignes métier)
  • Un axe de découpage par type de données qui avait l’avantage d’optimiser la cohérence et les coûts mais qui impliquait que le Product Owner d’une Feature Team doive prioriser pour plusieurs lignes métiers.

Nous avons finalement opté pour la deuxième solution et donc pour des Features Team par type de données.

Un train SAFe atypique

Un premier challenge a été d’identifier le périmètre du train. Nous nous sommes appuyés sur les chaînes de valeur qui correspondaient en fait relativement bien aux projets/programmes traversant le data warehouse (le concept de projet/programme existe encore pour l’instant. Il devrait -à terme- être remplacé par le concept d’Epic au sens SAFe).

Ceci nous a conduit à un périmètre centré sur le Data warehouse traversant 8 tribus et 13 équipes. Il a donc fallu convaincre les responsables des autres tribus et les différents sponsors de lancer le train. Période de plus d’un mois ou nous avons pris notre bâton de pèlerin pour « vendre » le concept du train.

Une contrainte forte était que nous avions le mandat pour réorganiser les équipes au sein de la tribu du data warehouse mais que nous ne l’avions par pour les autres tribus. De cette contrainte a émergé une différence fondamentale avec un train SAFe classique : toutes les équipes ne sont pas dédiées à 100% au train !

répartition equipe train SAFe

Ceci a bien sûr eu des conséquences sur le déroulement des PI Plannings.
En particulier pour les équipes non dédiées à 100% au train :

  • Uniquement une fraction convenue à l’avance de la vélocité de l’équipe est dédiée au train
  • Uniquement la partie de l’équipe concernée par le train participe au PI Planning (la participation du Scrum Master étant quant à elle obligatoire)

D’autre part, autant les équipes au sein du la tribu du data warehouse sont engagées sur le train de manière pérenne, autant nous envisageons que des équipes puissent être ajoutées/retirées du périmètre du train d’un PI Planning à l’autre (avec toutefois des variations faibles).

Ce setup même s’il peut apparaitre bancal de prime abord fonctionne en fait très bien !

Un deuxième challenge a été d’identifier la Product Management Team étant donné que le data warehouse lui-même n’est pas de visibilité métier direct. En l’occurrence nous avons décidé que les membres du Product Management seraient le Chief Data Officer ainsi que l’ensemble des Program Managers ou Sponsors des programmes constituant le périmètre du train.

Un train SAFe multi-régions

Un autre élément de complexité est venu du fait que le train était multi-régions (5 régions dont principalement Paris et Bangalore) et qu’il n’était bien sûr pas envisageable de faire déplacer les équipes pour le PI Planning.

Un program board physique n’était donc pas envisageable. D’autre part, aucun outil dans l’organisation ne permettait de le gérer. Après une courte étude, nous avons décidé d’utiliser l’outil iObeya. L’outil est simple et très souple d’utilisation et nous a donné entière satisfaction.

Lors du premier PI Planning, nous avons également géré les boards des équipes avec iObeya. Cela permettait certes au RTE d’avoir une visibilité multi-régions lors du PI Planning mais cela diminuait la collaboration au sein de chaque équipe. Lors des PI Plannings suivants, nous avons donc utilisé iObeya uniquement pour la gestion du Program Board et nous avons gardé un board physique par équipe.

Malgré ce PI Planning multi-régions nous sommes restés sur un agenda de deux jours avec un team breakout séparé en 3 parties. La première partie où n’intervenaient que les équipes de Paris ; une deuxième partie où n’intervenaient que les équipes de Bangalore et une troisième partie où intervenaient Paris, Bangalore et les petits contributeurs. Cette dernière partie du team breakout étant centrée sur la gestion des dépendances entre les équipes de Paris, de Bangalore et les petits contributeurs.

Conclusion

Malgré un faible budget de coaching, le train est un grand succès. L’ensemble des équipes ainsi que la PMT ont attribué un ROTI de 4,4/5 relativement à la mise en place du train.

En particulier le train permet de :

  • Partager la vision stratégique avec l’ensemble des parties prenantes,
  • Synchroniser de manière efficace le développement des applications consommatrices des données, le développement du data warehouse et le développement des applications fournissant les données,
  • Planifier à moyen terme et donner de la visibilité.

Le RTE est désormais totalement autonome et l’amélioration continue est en place.

Stéphane Déprès

 

Lancement de l’offre Meta Agile Inspearit Approach – M.A.I.A.

La Communauté Agile@Scale d’INSPEARIT souffle sa première bougie d’anniversaire…
… et vous offre un merveilleux cadeau !

Meta Agile Inspearit Approach

1 an !
1 an déjà depuis notre création !
1 an à nous retrouver tous les mercredis après-midi, soit 24 jours seulement !
1 an à tester, échouer, apprendre, réussir, gagner et capitaliser sur l’Agilité à l’échelle !
1 an et c’est nous qui vous offrons un cadeau…
Il y a 1 an, INSPEARIT affirmait son ambition de devenir le numéro 1 des entreprises accompagnant vos transformations Agile à l’échelle en France et en Europe… 9 Coachs Agile@Scale sont alors choisis pour participer à cette formidable aventure !

La Communauté Agile@Scale INSPEARIT était née :

  • Nous fonctionnons comme une start ’up interne, auto-organisée et auto-apprenante
  • Nous travaillons sur tous les fronts (la démarche, l’innovation, le marketing, les dispositifs d’accompagnement)
  • Nous collaborons avec des clients bienveillants pour avoir des retours immédiats du terrain
  • Nous décrochons même un crédit d’impôt recherche grâce à nos innovations !

Mais en toute transparence, nous avons dû faire face à quelques difficultés : ne dit-on pas que les Coachs Agile ont les esprits les plus rebelles ? Alors imaginez un peu une Communauté de Coachs Agile@Scale avec des expériences et des spécialités différentes… il nous a fallu jour après jour :

  • Apprendre à nous connaitre et nous faire confiance (team building, working agreement…)
  • Garder à l’esprit les fondamentaux même qui nous inspirent : valeurs et principes AGILE, démarche itérative, feedbacks clients et amélioration continue
  • Surmonter nos différences et toujours tirer profit de nos échecs

Avec un seul objectif en tête : maximiser la VALEUR que nous VOUS délivrons !

Et alors, quel est ce cadeau ?! Et bien nous vous offrons…

M.A.I.A.
Meta Agile Inspearit Approach

www.inspearit.fr/maia

La Communauté Agile@Scale INSPEARIT
Sebastien CAILHOL, Xavier DEGOULANGE, Stéphane DEPRES, Cédric FOURMY,
Adrien HEMBERT, Sylvain HOCHART, Jacques LABATTE, Damien MADELAINE, Bruno VIVET

#M.A.I.A. #INSPEARIT #AGILE@SCALE #1andéjà #Culture #ValueDrivenScaling #BusinessAgility #OrgaBluePrint #HumanRessources #Exec&Managers #MTOURNEMIRE #JMEYER

inspearit dans le top 50 des sociétés de croissance du Palmarès Women Equity 2018

Depuis 2010, Women Equity est à l’initiative du premier Palmarès annuel des PME dirigées ou codirigées par des femmes. Cette année, ce classement consacre la croissance d’inspearit au titre des résultats 2017 et fait donc parti du Top 50 des sociétés de croissance dirigées par une femme !

Historique du Women Equity Palmarès

En ce qui concerne la création de ce palmarès, il est né de la volonté de la Présidente de Women Equity, Dunya Bouhacene, de saluer l’engagement, la vision et l’agilité qui caractérisent nombre de ces dirigeantes : « Célébrer cet esprit d’entreprendre et favoriser son déploiement par la diffusion de ces modèles de succès permet de mieux les connaître et, ainsi, faciliter leur transformation en champions de leurs secteurs pour renouer durablement avec la croissance. »

Critères de sélection

Ce classement rassemble les 50 meilleures performances nationales issues d’un Index de près de 40.000 entreprises, disposant de 3 années d’existence a minima et d’un chiffre d’affaires compris entre 4 et 150 M€ sur l’une des années documentées. Outre son édition nationale historique, le Palmarès est depuis 2016 décliné en régions.

Les lauréates de l’édition 2018 

Publications

  • L’ensemble du classement des 50 entreprises dirigées ou co-dirigées par des femmes les plus performantes est à consulter : ici
  • Retrouvez tous les portraits des entreprises lauréates au sein du livret du Palmarès Women Equity 2018
  • Lire le portrait d’inspearit : ici
  • Article paru sur ce sujet : Source Ouest France

Innovation Break #1 : La Blockchain en pratique

les petits déjeuners de l’innovation
Innovation Break #1

 La Blockchain en pratique !

21 mars – Paris
8h30-10h30

Depuis 30 ans inspearit accompagne la transformation et l’innovation au sein des organisations.

Avec ce premier petit déjeuner « Innovation Break » sur le thème de la Blockchain, venez comprendre la Blockchain, découvir des cas d’usages, bénéficier d’un REX client, partager et échanger autour d’un café.

Thèmes abordés :

  • La blockchain : principes, fonctionnement et applications concrètes
  • Rex client  : Mise en place de la 1ère Blockchain alimentaire en Europe par Carrefour
  • Blockchain : un potentiel d’innovation technologique à la main de votre organisation
  • Questions/ Réponses

Intervenants :

Sylvain CARIOU,

Président CrystalChain
et Président de la commission Blockchain à l’AFNOR

 

Emmanuel DELERM,
Directeur Organisation & Méthodes Carrefour
Adrien HEMBERT,

Responsable offre innovation inspearit

Ou ? :

inspearit
21, rue de la banque
75002 PARIS

Inscription :

[contact-form-7 404 "Not Found"]

Construire une solution d’agilité à l’échelle optimisée pour votre contexte à partir des briques de base des frameworks existants – par Stéphane Déprès

Il existe de nos jours de nombreux framework Agile@scale disponibles sur le marché : SAFe, LeSS, DaD, Nexus pour ne citer que ceux-ci.

Plutôt que les mettre en opposition, je considère que chacun d’entre eux est le fruit d’une capitalisation d’expérience, a été éprouvé sur le terrain et apporte de la valeur. J’ai d’ailleurs signé depuis longtemps la charte Agnostic Agile

Certains frameworks sont sans doute plus adaptés que d’autre à certains contextes mais l’on peut également considérer qu’ils sont de formidables boites à outils dans lesquelles on peut venir puiser afin de proposer une solution optimisée pour un contexte donné.

Ce qui est important à mes yeux est de ne pas suivre aveuglement un framework mais que les équipes comprennent pourquoi l’on fait les choses. Comprendre quels sont les bénéfices et les inconvénients de tel ou tel mécanisme afin de sélectionner ceux qui sont le plus adaptés, voire d’adapter ces mécanismes pour en tirer le maximum de valeur.

Concernant l’adaptation des mécanismes, garder bien sûr en tête les principes Lean et Agile mais n’ayez pas peur d’être créatif pour répondre au contexte. Expérimentez et prenez en compte le retour d’expérience.

 

 

A propos de la portée temporelle de la planification

Dans cet article, je vais prendre pour exemple les mécanismes de planification cross-équipes qui sont assez différents d’un framework à l’autre, en particulier en ce qui concerne la portée temporelle de la planification. Par exemple, pour LeSS, la portée temporelle de la planification est d’un sprint alors que dans SAFe un Program Increment (PI) adresse en général 4 sprints.

Quelle approche embrasser ? L’argumentaire suivant ne se veut en aucun cas exhaustif mais donne un exemple de réflexion pour choisir la solution la plus adaptée au contexte.

S’il existe des contraintes métier de délai fortes et justifiées (dates réglementaires par exemple), alors une planification plus long terme sur un PI peut être intéressante car elle permet d’avoir de la visibilité et une stratégie sur le moyen terme.

Dans des cas de système complexe avec des dépendances fortes entre équipes, une planification sur un PI peut également être intéressante car elle permet de gérer les dépendances de manière proactive plutôt que de les subir sprint par sprint.

Dans les autres cas de figure et en particulier pour de la maintenance évolutive, une planification cross équipes avec une portée temporelle d’un sprint comme le prône LeSS est sans doute suffisante, plus flexible, plus simple, et permet au passage de réduire le WIP.

 

A propos des participants de la planification cross-équipes 

Autre axe de choix et d’adaptation : une participation de l’ensemble des membres de l’équipe à la planification cross équipes est-elle requise ? Pour SAFe, l’ensemble des membres des équipes participent au PI Planning. Pour LeSS, la participation de l’ensemble des membres des équipes au Sprint Planning One n’est pas imposée. Il est même recommandé de n’avoir que des représentants afin de faire en sorte que le Sprint Planning One soit le plus léger possible. Quant au Sprint Planning Two de LeSS, il englobe tous les membres d’une équipe mais est réalisé équipe par équipe sauf exception.

Là encore les approches LeSS et SAFe sont différentes. SAFe considère qu’avoir l’ensemble des équipes présentes, PO, PMT, architecte et Business Owner inclus est plus efficace car les délais de communication et de prises de décision sont optimisés. C’est effectivement ce que j’ai constaté sur tous les trains que j’ai accompagnés. Mais cette efficacité vaut elle le temps passé et la complexité de mise en œuvre ? LeSS au contraire joue la simplicité et considère une participation à priori nécessaire et suffisante. Mais est-ce vraiment suffisant pour adresser une solution complexe ?

Je ne rentrerai pas dans ce débat. Mais je rajouterai que d’autres variantes sont possibles. J’ai par exemple récemment accompagné une planification multi-équipes et multi-sprints dans un contexte de faible degré de dépendance entre équipes. Mettre en place un vrai PI Planning me paraissait donc surdimensionné et j’ai proposé l’approche suivante qui a été acceptée :

  • Présentation de la vision métier à l’ensemble des équipes
  • Présentation de la vision architecturale à l’ensemble des équipes
  • Planification (team breakout) : chaque équipe planifiant séparément avec l’agenda souhaité. Seules contraintes : un délai max d’une semaine et un Scrum of Scrum journalier pendant cette période
  • Une revue du plan et un arbitrage pour aligner la roadmap souhaitée avec la vélocité des équipes et les contraintes

 

A propos du découplage de la structure organisationnelle avec les mécanismes de synchronisation Agile

Les framework considèrent en général que si des besoins de synchronisation entre équipes existent, ils doivent forcément impliquer chaque équipe dans son entier. Vous allez bien sûr me dire que si ce n’est pas le cas, la structure organisationnelle est incorrecte. Mais il existe des cas de figure où cela n’est pas si simple :

Avant d’aller plus loin, analysons les différents types d’équipes. Les équipes projet sont structurées autour d’un projet ou d’un programme mais elles souffrent d’inconvénients majeurs : en particulier une perte de la connaissance dès le démontage d’une équipe ainsi que la constitution de silos projet / maintenance.

Des équipes par application suppriment ces inconvénients mais le time-to-market n’est pas optimal. En effet, pour un changement impactant l’ensemble de la chaine de valeur métier, toutes les équipes applicatives doivent se coordonner pour délivrer la solution.

Les équipes de type Feature Team alignées sur les chaines de valeur permettent d’éliminer cet inconvénient. Des mécanismes de synchronisation Agile sont alors déployés entre les Feature Teams ayant des dépendances structurelles.

Mais il arrive parfois qu’une initiative éminemment transverse (par exemple réglementaire) induise des besoins de synchronisation temporaire entre des sous-ensembles d’équipe. Il n’est d’ailleurs pas toujours souhaitable de construire des équipes dédiées (grand nombre d’applications impactées et augmentation des dépendances).

Parfois, il s’agit également d’une stratégie pour gérer les backbones transverses comme les data warehouse permettant à la fois :

  • D’optimiser le time-to-market par chaîne de valeur en synchronisant de manière efficace le développement des applications consommatrices des données, le développement du data warehouse et le développement des applications fournissant les données ;
  • De garder une stratégie de développement du data warehouse non segmentée par chaîne de valeur et d’adresser la cohérence cross chaînes de valeur.

Pour plus de détail sur le sujet, je vous invite à consulter l’article « REX d’un lancement de train SAFe atypique » http://www.inspearit.fr/2018/11/19/rex-safe/

Dans ce contexte, j’ai été amené à lancer un train pour lequel les équipes n’étaient pas dédiés à 100%. Le PI Planning a été adapté comme suit :

– Ne viennent au PI Planning que l’Agile Master et les personnes impliquées
– Un % prédéfini de la vélocité de chaque équipe dans ce contexte est dédié au train

 

Ainsi, ce qui compte avant tout est de mettre en place des solutions qui conviennent au contexte. Les frameworks Agile@scale peuvent être utilisés tels que ou comme une boite à outil dans laquelle on vient puiser pour construire la solution.

 

L’exploration continue : une composante indispensable au service de l’organisation apprenante – par Adrien Hembert

 

Dans un article précédent, j’évoquais la pertinence d’intégrer des activités design thinking dans un contexte agile à l’échelle. Un des niveaux sur lequel cette intégration peut prendre forme est celui de la couche programme, c’est-à-dire les unités organisationnelles en charge de faire le lien entre gestionnaires de portefeuilles et équipes opérationnelles. À ce niveau, SAFe évoque l’exploration continue comme un ensemble d’activités favorisant innovation et alignement sur les solutions à développer en explorant continuellement le marché et les besoins des utilisateurs et en définissant une vision, une feuille de route et un ensemble de fonctionnalités pour les solutions répondant à ces besoins.

L’exploration continue a donc plutôt de quoi séduire sur le papier car ses bénéfices semblent évidents. Mais quels enseignements peut-on tirer lors de sa mise en pratique concrète au sein d’une organisation réelle ?

Dans cet article, vous trouverez un éclairage sur quatre points de bon sens. Il convient de les garder à l’esprit lorsque l’on souhaite en tirer un bénéfice maximum lors de sa mise en œuvre.

1. L’exploration continue : une activité pluridisciplinaire et transverse

Trop souvent, l’exploration continue est mal comprise. Elle ne se limite pas qu’aux champs d’intervention des UX designers avec le travail de collecte et de recherche des besoins utilisateurs. Sa portée est bien plus large. En effet, si son objectif ultime est d’aligner les différents participants sur les « bonnes » choses à développer à un instant donné (« Is that the right thing to build now ? »), l’exploration implique également un travail de préparation et de structuration des fonctionnalités.

Par conséquent, plusieurs activités complémentaires sont à mener comme par exemple des analyses au niveau de l’architecture, de l’infrastructure ou de la sécurité, ce qui signifie l’implication d’acteurs divers tels qu’architectes de solution, membres de la system team ou développeurs.

La portée des sujets à explorer étant par définition inconnue, c’est potentiellement n’importe quel membre des équipes qui pourrait être sollicité afin d’apporter son expertise spécifique, sans oublier la sollicitation de personnes extérieures aux trains (utilisateurs finaux, experts externes, etc.).

Le casting des participants aux ateliers d’exploration est donc un sujet important. Il convient de l’aborder sérieusement et de façon spécifique à chaque nouveau thème à explorer. A ce sujet, les critères de pluridisciplinarité et de taille des groupes sont à respecter :
– Pas trop petits pour s’assurer de générer des idées riches et variées ;
– Pas trop grands non plus pour garantir la qualité des échanges, l’écoute et le partage de la connaissance.
De façon générale, un groupe d’environ dix personnes fonctionne bien, sans que ce chiffre soit une règle absolue.

2. L’exploration continue nécessite une démarche structurée 

Il faut se rendre à l’évidence : la mise en œuvre de l’exploration continue soulève encore quelques doutes au sein des organisations. Ils sont fondés notamment sur la peur d’y passer beaucoup de temps sans obtenir de résultats tangibles. Sans une méthodologie structurée, un leadership fort et une prise de conscience collective, il sera effectivement très difficile de bien la mettre en œuvre. L’intérêt d’une approche structurée permet d’amener tout le monde à avoir le même langage sur la manière avec laquelle doit être conduite l’exploration. Il est essentiel d’avoir ce langage commun. Tout le monde peut y contribuer au mieux en comprenant ce qui est attendu de chacun ; quel que soit son rôle dans ou hors du train.

D’un point de vue méthodologique, une sensibilisation en continu doit avoir lieu auprès des trains et du management. C’est nécessaire afin de leur faire prendre conscience de l’importance de l’exploration continue et des bénéfices qu’elle génère. Des interventions doivent notamment avoir lieu dès les PI planning :

  • Identifier auprès des équipes les nouveaux sujets à explorer (une première identification de sujets aura eu lieu avant le PI planning avec l’équipe de Product Management).
  • Spécifier ces sujets en définissant les livrables attendus et les dépendances éventuelles avec d’autres équipes.
  • Faire valider par le Product Management la pertinence d’explorer tel ou tel nouveau sujet.
  • Mettre en place le plus rapidement possible un calendrier d’interventions pour intervenir sur ces sujets.

C’est ensuite durant tout le PI que des ateliers ad’hoc peuvent être menés pour adresser les sujets à explorer. L’intervention de facilitateurs externes peut s’avérer nécessaire pour mener ces activités. Au-delà de l’apport méthodologique, ils pourront garantir une neutralité sur le contenu qui permettra à tous les participants de se concentrer sur le sujet de fond.

Comme toute activité de production, les activités liées à l’exploration doivent :
– posséder des objectifs clairs
– se limiter dans le temps
Ses résultats doivent être présentés lors des démos de fins d’incréments : c’est une question de crédibilité !

3. L’exploration continue est un choix stratégique à assumer !

Autre point à souligner concernant la mise en œuvre de l’exploration continue au sein des trains : celle-ci demande (un peu) de temps. Si la présence d’une méthodologie permet de faciliter sa mise en œuvre (cf. le paragraphe précédent), c’est bien au niveau de l’état d’esprit des membres des équipes du train et du management que doit s’opérer une prise de conscience sur l’importance de consacrer du temps à l’exploration.

Sur un produit très innovant, ce temps peut occuper une majeure partie de la capacité du train. Par contre, ce sera naturellement moins le cas pour des produits établis sur des marchés matures pour lesquels un peu d’innovation incrémentale peut suffire.

Dans tous les cas, c’est un choix stratégique à faire. Qui dit choix, dit forcément renoncer à faire autre chose (en l’occurrence des activités de production). Les équipes sont autonomes sur ce choix et il serait faux de penser qu’une méthodologie permet de « libérer » du temps. Il est donc essentiel qu’une culture assumée de l’exploration continue se mette en place au sein de l’organisation afin de permettre aux équipes de réserver du temps au sein de leur backlog. Ce temps, perçu parfois comme une perte, est en réalité un investissement sur la qualité des développements ultérieurs, la pertinence des fonctionnalités développées mais aussi la motivation des équipes.

4. L’exploration continue renforce la motivation des équipes et l’innovation au sein de l’organisation

Ne pas se donner les moyens de mettre en œuvre l’exploration, c’est faire en sorte que vos équipes ne travaillent que sur des sujets d’exécution immédiate sans jamais leur laisser prendre le temps de réfléchir à là où elles veulent aller. À moyen terme, cela constitue une double menace pour l’organisation :

  • Un risque réel d’essoufflement, de perte de sens et de démotivation des équipes. Les dangers sont évidents tant d’un point de vue humain qu’en termes de productivité.
  • Une occasion gâchée de laisser s’exprimer la créativité des équipes. Ayant les mains dans le produit à longueur de journées, il est difficile d’apporter de vraies innovations.

Dans un contexte de guerre des talents et de course à l’innovation, ce sont deux éléments à ne pas négliger !

Les bénéfices de l’exploration sont multiples

Partage de la connaissance au sein de l’organisation, responsabilisation et motivation des équipes, cocréations plus rapides de solutions répondant mieux aux nouvelles attentes des utilisateurs : les bénéfices de l’exploration sont divers et concernent le plus grand nombre !

Mais au-delà de tous ces bénéfices, il faut percevoir l’exploration continue comme un levier d’innovation et de transformation culturelle durable de l’organisation. C’est par cette activité que celle-ci se met en capacité d’apprendre en continu sur ses clients, leurs usages, et sur l’adéquation de la solution. Elle ne se met pas en place sans une action consciente, explicite et durable. Les managers doivent donc la porter et la soutenir. Si la recette paraît simple sur le papier, il ne faut pas sous-estimer l’importance d’avoir un leadership fort et une méthodologie structurée afin de la mettre en œuvre. En identifiant l’exploration continue comme l’une des trois composantes du pipeline de delivery des trains de release agile, SAFe donne une place de choix à l’innovation et à l’apprentissage continu. Il appartient à chaque organisation qui l’implémente de lui donner corps. Notre conviction est qu’au-delà du concept, le design thinking offre une réelle opportunité pratique de le faire à grande échelle. Encore faut-il rester attentif aux quatre points évoqués ci-dessus.

Adrien Hembert

Time to market : l’art de délivrer le bon produit au bon moment

time to market

Réduire le time to market et innover. Tels sont les mots d’ordre de toutes les entreprises innovantes aujourd’hui. Pour rester compétitive et faire face à la concurrence, toute organisation doit en effet renouveler ses gammes de produits (ou de services) et développer de nouvelles offres de façon régulière. Mais un time to market court ne suffit pas… Le lancement de nouveaux produits doit faire l’objet d’une réflexion profonde. L’enjeu réside surtout dans le fait de délivrer le bon produit, celui qui apporte de la valeur, au bon moment.

 

Le time to market au cœur des préoccupations

Aujourd’hui, le time to market (ou temps de mise sur le marché) se doit d’être aussi court que possible. Un délai de lancement court est vital pour les entreprises innovantes. En cause : les jeunes start-up au time to market très court qui dominent le marché et génèrent ainsi des revenus conséquents. La concurrence n’a d’autre choix que d’adopter la même cadence que ces entreprises capables de lancer de nouveaux produits à une allure effrénée.

Et pour cause, un time to market réduit au minimum présente bien des avantages. D’abord, les produits mis sur le marché en avance de phase rencontrent une concurrence moins féroce au début de la commercialisation, ce qui facilite leur vente, allonge leur durée de vie et permet de pratiquer des prix de vente intéressants. À l’inverse, un lancement trop long expose les nouveaux produits à une obsolescence rapide. 

 

S’adapter rapidement pour améliorer son produit

Directeurs produit, vous avez une grande responsabilité dans le succès commercial des nouvelles offres. Véritable moteur de l’innovation, vous avez un impact fort sur la performance de votre entreprise. Pour cause : le lancement de nouveaux produits, offres ou services constitue l’un de ses principaux leviers de croissance. Votre rôle est donc hautement stratégique, surtout lorsque l’on sait que 90 % des lancements de produits se soldent par un échec (étude Nielsen).

Si le time to market est une préoccupation importante, avoir la capacité de s’adapter rapidement en est une autre. En effet, il est très rare de sortir le produit parfait dès sa première version. Aussi, vous devez constamment rester à l’écoute des utilisateurs pour comprendre rapidement ce qui fonctionne et ce qui fonctionne moins bien sur votre produit. L’objectif étant au final de pouvoir apporter rapidement les ajustements nécessaires pour répondre aux attentes des utilisateurs.

 

Générer des idées innovantes en interne, le casse-tête

Plus votre organisation aura la capacité de sortir des produits rapidement, plus elle devra être en mesure de générer de nouvelles idées.

Et c’est souvent là que réside la principale difficulté des grandes entreprises. Leur capacité à innover est limitée, car elles ont pour habitude de s’appuyer uniquement sur des employés expérimentés pour générer de nouveaux concepts. Les connaissances des sachants en interne sont, certes, nombreuses et intéressantes. Cependant, elles ne seront pas toujours suffisantes pour répondre aux attentes des nouvelles générations d’utilisateurs.

Quelle que soit sa taille, toute organisation doit savoir se tourner vers l’extérieur pour capter du savoir. En effet, la création d’offres et services à forte valeur ajoutée est accélérée par l’ajout de nouveaux “cerveaux”, tout comme la réduction des délais de mise sur le marché. Pour éviter que l’entreprise ne se repose sur ses acquis et continue d’innover, une confrontation à la réalité du terrain et une ouverture sur l’extérieur sont nécessaires.

Pour favoriser l’innovation, rien de tel que de sortir des locaux de l’entreprise (“gemba walk”) pour observer les vrais utilisateurs et découvrir leurs attentes.

time to market ebook

Accélérer l’innovation en levant les freins en interne

accelerer l'innovation

Happées par l’obligation d’innover pour se démarquer de la concurrence, les entreprises doivent lancer de nouveaux produits assidûment pour ne pas péricliter. Pour accélérer l’innovation, une des ressources clés est le directeur produit. Ses premières missions : garantir la création de valeur et s’assurer d’une bonne collaboration entre les équipes de conception et de mise en œuvre des solutions. 

 

Apporter de la valeur aux nouveaux concepts

Accélérer l’innovation est un enjeu de taille pour les entreprises qui souhaitent rester compétitives. Cette tâche repose notamment sur les épaules du directeur produit. Celui-ci travaille en permanence sur le développement de nouveaux produits ou l’amélioration des offres existantes. Son objectif : tenir la cadence face aux jeunes start-up qui imposent un rythme soutenu et un time to market extrêmement court. Le product manager sait que si le lancement de sa nouvelle offre tarde trop, c’est toute l’entreprise qui en pâtira. En effet, rien de pire qu’un produit obsolète dès sa sortie ou qui n’est pas (ou plus) en phase avec les attentes des utilisateurs.

Précipitation, manque de recul, vision du “board” en décalage avec les besoins des consommateurs… Les raisons d’un lancement de produit raté peuvent être nombreuses. Mais en regardant de plus près, elles découlent très souvent d’une même erreur : les produits sont conçus sans prendre en compte les remontées du terrain. Alors, accélérer l’innovation, oui.  Mais développer des produits sans valeur, non !

Pour concevoir des produits/offres à forte valeur ajoutée, qui séduiront les consommateurs sur le long terme, les entreprises ont intérêt à s’appuyer sur des données concrètes, issues de l’observation de clients réels. Pour ce faire, elles peuvent choisir de se faire accompagner par des experts externes. Ceux-ci sauront apporter les compétences manquantes à l’entreprise, sans pour autant prendre la main sur le projet.

L’accompagnement d’un expert peut en effet être bénéfique pour apporter du concret à la réalisation de la démarche (méthodes, outils disruptifs…) et aider les équipes à s’organiser, à aller sur le terrain pour observer les pratiques des utilisateurs.

 

Capitaliser sur l’intelligence collective pour générer de nouvelles idées 

Plus une entreprise grandit, plus elle perd la fluidité d’échanges entre collaborateurs de ses débuts. Les décideurs s’éloignent de l’opérationnel, les équipes se multiplient et il devient de plus en plus difficile d’aligner tout le monde sur une même vision. Cela constitue hélas un frein à l’innovation.

Les interactions entre les équipes en charge des produits et le département IT se raréfient. Pire : leurs relations peuvent parfois être tendues. C’est par exemple le cas lorsque le product manager a besoin des compétences de l’IT pour développer un produit. Le département IT n’a pas forcément de temps à consacrer à de nouveaux projets, ce qui, en plus de freiner l’innovation, peut créer des discordes entre les différents services. Or, les silos qui se créent entre les métiers et l’IT doivent disparaître si l’entreprise souhaite accélérer l’innovation et ainsi faciliter le lancement de nouveaux produits et offres. Il est important d’avoir des groupes de travail pluridisciplinaires dont les castings doivent être méticuleusement préparés et de façon spécifique à chaque nouveau thème à explorer ! C’est une condition essentielle pour que se mette en place une intelligence collective.

L’objectif des facilitateurs externes est d’accompagner les entreprises vers des organisations plus transversales, plus ouvertes et collaboratives, de redonner une vision d’ensemble aux collaborateurs, et de stimuler la créativité pour plus de réactivité.

 

time to market ebook

inspearit academy passe la barre des 10 000 agilistes formés

inspearit academy, centre de formation européen du Groupe inspearit est fier de vous annoncer que nous avons passé la barre des 10 00 personnes formées à l’Agilité !

 

inspearit a formé 10000 agilistes en seulement 30 mois dont 3000 sur SAFe

 

Durant les 30 derniers mois nos consultants/formateurs ont accompagnés et formés plus de 10 000 agilistes dont plus de
3 000 personnes sur SAFe.

Un large portfolio de formation nous permet de répondre aux différents besoins et rôles :

Agile :

  • Sensibilisation Agile pour CODIR/COMEX
  • Introduction à l’Agilité (IT ou non IT)
  • Agile et Scrum fondamentaux
  • Product Owner (avec ou non certification PSPO)
  • Scrum Master (avec ou non certification PSPO)

Agile@Scale :

  • Sensibilisation Agile@Scale pour CODIR/COMEX
  • Introduction à l’agilité à l’échelle
  • Formation officielle SAFe (Leading SAFe, POPM, Advanced Scrum Master, Implementing SAFe…)
  • Design Thinking @Scale

Ces formations peuvent également être personnalisées et adaptées à votre contexte.

Pour en savoir plus sur nos formations :

? Découvrez notre catalogue 

? Contactez-nous

 

 

Design Thinking : capitalisez sur l’intelligence collective !

design thinking intelligence collective

Les entreprises misent aujourd’hui sur leur capacité d’innovation pour entretenir leur compétitivité. Leur performance repose ainsi sur leur faculté à mobiliser les connaissances internes et externes afin de favoriser l’intelligence collective. Le Design Thinking apparaît comme un concept intéressant pour favoriser l’émergence de nouvelles idées.

 

Design Thinking : quel apport pour le Product Management ?

En tant que responsable produit, vous devez comprendre, avec précision, les problèmes, les besoins et les désirs des consommateurs. Le Design Thinking peut vous aider à mieux cerner les attentes des utilisateurs lors des phases de développement de produit. Cette démarche, mix entre l’analytique et l’intuitif, apportera une aide précieuse à votre product management, en vous apportant des données tangibles qui pourront valider ou invalider les idées, étape nécessaire à la création d’une expérience utilisateur idéale.

Le Design Thinking permet de ne pas se lancer tête baissée dans la conception d’un produit (aussi innovant soit-il !), mais de consacrer du temps en amont pour se mettre à la place de l’utilisateur. Le Design Thinking permet de mieux comprendre les « vrais » besoins des utilisateurs et de proposer ainsi un ensemble de réponses qui auront plus de chances d’être réellement utilisées. Pour mieux cerner l’utilisateur, les équipes produit sont donc invitées à l’observer, sans lui poser de question, pour ne pas biaiser les résultats. Qui est cet utilisateur ? Comment vit-il ? Que pense-t-il ? Quelles sont ses attentes non adressées ? L’observateur doit faire preuve d’empathie, afin d’identifier l’élément sur lequel bâtir un élément de réponse.

Le Design Thinking préconise ensuite de générer un maximum d’idées pouvant apporter des éléments de réponses aux besoins clairement identifiés. Pour faire émaner des idées, il est indispensable de mettre en place des groupes pluridisciplinaires garantissant une diversité de points de vue.

Le Design Thinking prévoit alors une phase de prototypage de solutions concrètes. Les prototypes Lo-Fi – basse fidélité – (maquettes papier-crayon, objets en carton…) sont réalisés rapidement, afin de vérifier la faisabilité des idées et mettre au plus vite le produit, ou tout du moins l’idée du produit, entre les mains des utilisateurs. Les feedbacks issus du terrain étant un élément central du  Design Thinking, ils permettent de valider les hypothèses émises, voir si le produit répond bien aux attentes des hypothèses et réitérer le processus de conception si nécessaire…

 

Mais le Design Thinking ne suffit plus !

Le Design Thinking est particulièrement utile au product management. Mais à lui tout seul, il ne suffit pas ! Il amorce seulement la création d’un produit. Il faut bien entendu ensuite passer à l’implémentation et initier les développements. Or, la transition du prototype au développement du produit est une étape charnière, pleine de risques. L’avantage avec le Design Thinking, c’est que les équipes de développement ont été impliquées dans la phase de conception du produit, ce qui limite la perte d’information. Néanmoins, une connexion doit impérativement être établie entre les phases amont du projet (Design Thinking) et la mise sur le marché du produit.

Un bon expert du product management, formé au Design Thinking, sera capable de vous aider à passer de la conception du produit à sa mise en œuvre. Veillez cependant à bien le choisir, car certains prestataires se contentent de délivrer un catalogue de bonnes idées, sans s’assurer de leur mise en œuvre opérationnelle !

 

Chez inspearit, nos consultants accompagnent les entreprises vers un changement d’approche de travail et d’organisation interne, propices à la collaboration, mais ils ne s’arrêtent pas là ! Ce cheminement conduit au développement concret du produit. De cette façon, la conception et la mise en œuvre des produits sont toujours faites au plus proche des besoins des utilisateurs.

time to market ebook

inspearit obtient un prêt croissance de deux millions d’Euros auprès de BPI France et le CIC pour accélérer son développement

Leader des transformations agile à l’échelle, inspearit souhaite compléter son offre Digital sur les dimensions management de produits numériques et accélération de l’innovation au travers de nouvelles technologies telles que IA, robotique, IoT notamment.

   De plus les services de formation largement déployés en Hollande seront étendus aux autres pays Européens en personnalisant le portfolio autour du framework SAFe et de l’éducation aux nouvelles technologies.

Ce prêt nous permet de renforcer nos capacités et nos talents pour accroître encore notre avance technologique. Nous dimensionnons de plus notre organisation commerciale afin d’adresser les organisations sur lesquelles nous observons une traction forte vers le digital.

Innovation produit : comment se faire accompagner pour l’accélérer ?

innovation produit

Parce que développer de nouveaux concepts rapidement est essentiel pour les entreprises souhaitant rester compétitives – face aux start-up dont les cycles d’innovation sont très courts, se faire accompagner par un partenaire expert est incontournable. Un bon accompagnement permet en effet d’accélérer l’innovation produit et de réduire le time to market. Mais vers qui se tourner ? Comment choisir le partenaire idéal ?

 

Innovation produit : comment choisir son partenaire ?

Pour accompagner l’innovation produit dans votre entreprise, vous devrez prendre soin de choisir le bon partenaire. Celui qui connaît votre secteur, maîtrise vos enjeux et comprend vos problématiques.

D’abord, veillez à ce que votre partenaire propose un accompagnement complet. Il doit être capable de gérer les aspects organisationnels, techniques, humains, etc. Du Design Thinking aux développements produit, en passant par l’organisation des équipes et l’optimisation de leurs process, votre partenaire doit maîtriser toutes les étapes de la transformation digitale.

Votre partenaire doit être capable d’aller au-delà des frameworks et méthodes utilisés (Scrum, SAFe, Lean…) : il doit avant tout accompagner l’humain, pour enclencher une dynamique vertueuse vers l’innovation produit. Plus qu’un simple consultant, l’expert qui vous accompagnera devra endosser un vrai rôle de coach pour impliquer pleinement les collaborateurs dans la démarche.

La capacité de votre partenaire à assurer la conduite du changement est également primordiale. Laccélération de l’innovation produit implique un bouleversement organisationnel important qui nécessite un solide accompagnement. Les équipes doivent être associées au changement, le co-construire et en devenir partie prenante. C’est là où le rôle du coach fera la différence.

Enfin, il convient de trouver un partenaire qui vous rende autonome dans l’innovation produit. Ce dernier n’a pas vocation à rester éternellement dans l’entreprise, mais à vous fournir les éléments nécessaires pour engager et pérenniser la transformation. Car l’innovation doit être portée par les collaborateurs en interne avant tout.

 

Accorder de l’importance à la méthodologie

Dans un second temps, nous vous conseillons de porter une attention particulière à la méthodologie utilisée par votre partenaire. En effet, elle aura un impact sur l’accompagnement prodigué. Une méthodologie qui ne conviendrait pas à votre entreprise serait un véritable facteur d’échec pour l’accélération de votre innovation produit.

Quelle que soit la méthodologie utilisée, celle-ci devra être adaptée au contexte de votre organisation. Les frameworks Agiles pour passer à l’échelle peuvent constituer une base solide : SAFe® (Scaled Agile Framework), Less (Large Scale Scrum), Nexus… Mais ils ne seront pas suffisants !

L’idéal est d’opter pour une méthode qui favorise l’innovation produit sur le long terme et prévoit la phase d’implémentation. Prenons l’exemple de SAFe®, le référentiel le plus utilisé dans les démarches de transformation agile à l’échelle (1). SAFe® met en avant l’exploration continue comme vecteur d’innovation. L’exploration continue du marché et des besoins des utilisateurs permet en effet de définir une vision, une roadmap et d’aligner la vision de chacun sur les solutions à développer. 

Quel que soit le framework choisi, ne vous méprenez pas : une méthodologie éprouvée ne se suffit pas à elle-même pour favoriser l’innovation produit.  Votre partenaire et le framework vont de pair. En effet, le framework ne serait rien sans un solide accompagnement. Dès lors, prenez le temps de la réflexion avant de sélectionner votre prestataire.

 

 (1) Rapport Version One sur la progression de l’agilité dans les entreprises

 

time to market ebook

Orange France has chosen to develop Design thinking at the 3 levels of the framework SAFe

« Customer satisfaction is Orange France key priority. So, we have strongly developed the use of Design Thinking to conceive user- centric products and services. We have had the ambition to keep this powerful method in launching agile@scale with SAFe. »
— Emilie Garnier, Head of Design Thinking resource and skill center for Orange France Agile Program.

Lire la suite « Orange France has chosen to develop Design thinking at the 3 levels of the framework SAFe »

REX client : Transformation Agile@Scale avec SAFe

 

Comment un grand éditeur de logiciel réalise sa transformation grâce à l’agilité à l’échelle avec SAFe 

 

Pour répondre aux besoins de ses 45 000 utilisateurs issus du secteur financier dans le monde entier, un éditeur de logiciel majeur décide d’adopter un nouveau mode de fonctionnement basé sur l’agilité à l’échelle.

5 coachs inspearit ont dirigés l’ensemble des opérations de transformation.

Découvrez les étapes, l’organisation, les difficultés rencontrées, les bénéfices et les enseignements.

 

Pour télécharger le document, merci de compléter le formulaire ci-dessous :

[email-download download_id=”2628” contact_form_id=”2627”]

Orange France a choisi de déployer une approche Design Thinking adossée au framework SAFe sur les trois niveaux de l’organisation

« La satisfaction du client est la priorité principale d’Orange France. Nous avons donc fortement développé l’utilisation du Design Thinking pour concevoir des produits et des services centrés sur l’utilisateur. Nous avons eu l’ambition de conserver cette méthode puissante en lançant l’agilité à l’échelle avec SAFe. »
– Emilie Garnier, Responsable du centre d’expertise et de ressources Design Thinking pour le programme Agile Orange France

Lire la suite « Orange France a choisi de déployer une approche Design Thinking adossée au framework SAFe sur les trois niveaux de l’organisation »

Déployer les OKR et les marier avec l’Agilité à l’échelle

Que sont les OKR « Objectifs and Key Results » ? Comment peuvent-ils aider les entreprises à mettre en œuvre leur stratégie et à créer de l’alignement et de l’engagement autour de ces objectifs ? Comment les marier de manière efficace avec les mécanismes d’Agilité à l’échelle ?

Nous allons répondre à ces questions à travers une série de trois articles. Les articles, outre une présentation théorique, intègrent un retour d’expérience d’un pilote dans une grande entreprise.
Cet article est le premier de la série.

 

OKR

 

Article 1: que sont les OKR (Objectifs and Key Results) et quels sont les bénéfices de leur mise en œuvre ?

A quoi sert la méthode OKR ?

La méthode OKR aide les entreprises à mettre en œuvre leur stratégie et à créer de l’alignement autour d’Objectifs mesurables. Et ce à tous les niveaux de l’entreprise.
Elle permet aussi de se focaliser sur ce qui apporte le plus de valeur en lien avec la stratégie de l’entreprise.

Histoire de la méthode OKR

Le développement des OKR est attribué à Andy Grove qui a introduit l’approche chez Intel.
Les OKR ont ensuite été déployés chez Google par John Doerr[1] et font désormais partie de la culture de l’entreprise.
Depuis, de nombreuses autres sociétés les ont adoptés avec succès.

Définition d’objectifs à tous les niveaux de l’entreprise

Dans la démarche OKR, à tous les niveaux de l’entreprise et de manière transparente, sont définis des Objectifs permettant de décliner la stratégie.

L’organisation pour laquelle je travaille débute le déploiement des OKR sur un périmètre de plusieurs dizaines de milliers de personnes. Nous envisageons trois niveaux hiérarchiques d’Objectifs :

  • Les Objectifs stratégiques au plus haut niveau de l’organisation
  • Le niveau tactique
  • Les Objectifs opérationnels au niveau d’une équipe d’une centaine de personnes

Par ailleurs, il est je pense essentiel que les Objectifs d’une structure organisationnelle de niveau n ne soient pas fixés par le manager de la structure organisationnelle de niveau n+1 à laquelle elle est rattachée.

Ainsi chaque structure organisationnelle de niveau n :

  • Propose des Objectifs permettant de contribuer aux Objectifs de niveau n+1
  • Discute avec le niveau n+1 pour s’aligner et identifier les Objectifs les plus pertinents pour répondre aux Objectifs de niveau n+1

 

Schéma OKR

 

Contrairement à une approche purement top-down, cette approche bidirectionnelle permet de gérer des organisations et des systèmes complexes.
Pourquoi ? Car la structure organisationnelle concernée est la plus à même d’identifier des Objectifs qui font sens et contribuent aux Objectifs de plus haut niveau.
Ce n’est pas complètement une gestion décentralisée de la complexité, mais c’est un bon compromis. Cela permet de mettre en œuvre la vision en profitant de l’intelligence collective à tous les niveaux.
L’approche a également l’avantage de laisser de l’autonomie tout en contribuant à la vision, ce qui soutient la capacité d’innover et la motivation des équipes.

Limiter le nombre d’Objectifs

Limiter le nombre d’Objectifs par élément organisationnel permet de se focaliser sur ce qui est important. Donc de prioriser par la valeur et de limiter le WIP (Work In Progress) inféré par les Objectifs.
Ce qui permet donc d’améliorer l’efficacité et le Time To Market.

Néanmoins, Google prône une démarche 70 20 10 laissant de la place au long terme et à l’innovation pour préparer le business de demain. C’est exactement ce que propose le modèle SAFe avec le concept d’investissement par Horizon[2][3] où :

  • L’Horizon 1 (investissement dans les solutions en cours de développement) correspond à la première tranche des objectifs de Google
  • L’Horizon 2 (investissement dans de nouvelles solutions émergentes et prometteuses) correspond à la deuxième tranche
  • L’Horizon 3 (investissements dédiés à la recherche de nouvelles solutions potentielles) correspond à la troisième tranche[2].

Bien sûr, la partition 70 20 10 est fonction du secteur économique et du degré de concurrence.

Mais ceci veut dire que le nombre d’Objectifs ne doit pas être trop faible non plus, afin d’éviter de se focaliser uniquement sur le court terme. Généralement, 3 à 5 Objectifs représente un bon compromis.

Autant que faire se peut, les Objectifs doivent être inspirants. Il n’est pas non plus interdit d’identifier des Objectifs ambitieux voire challenging : (les « Moonshots » – objectif Lune) afin de tirer l’organisation vers l’avant. Evidemment, ce n’est pas l’objectif que tous ces Moonshots soient atteints à 100%. Une cible de 60 à 70% est un bon objectif.  Par contre, c’est bien l’objectif d’atteindre à 100% les Objectifs plus standard, les Roofshots. Afin d’éviter le surmenage et la démotivation des équipes, Google préconise d’avoir une distribution de 30% de Moonshots et de 70% de Roofshots.

Des Key Results pour caractériser l’atteinte des Objectifs

Afin de caractériser et de mesurer l’atteinte de ces Objectifs, nous identifions des Key Results permettant de mesurer les bénéfices apportés (outcomes) et non les livrables produits (outputs). Les Key Results doivent donc être mesurables et une cible quantitative doit être identifiée pour une date cible donnée. Comme le disait Marissa Meyer de Yahoo « it’s not a key result unless it has a number ».

En général, plusieurs Key results sont nécessaires pour adresser toutes les facettes de l’Objectif et le mesurer suivant des angles de vue complémentaires. Il peut s’avérer également crucial d’ajouter des mesures permettant de s’assurer que l’atteinte d’un Objectif n’engendre pas d’effets de bord indésirables. Par exemple qu’une réduction des coûts n’engendre pas une baisse de la qualité. En général, il est préconisé de définir 2 à 5 Key Results par Objectif.

Une gouvernance à mettre en place

Nous venons de voir la structure des OKR. Mais il convient aussi de mettre en place une gouvernance propice à son implémentation. Typiquement, des cérémonies cadencées permettant d’identifier les OKR, de passer en revue et célébrer leur atteinte.

Des Initiatives pour mettre en œuvre les Objectifs

D’autre part, les Objectifs sont supportés par des initiatives qui sont les actions permettant d’atteindre ces Objectifs. Nous verrons dans le troisième article comment ces initiatives correspondent aux éléments de backlog lorsque de l’agilité à l’échelle est mis en œuvre.

Conclusion

La démarche OKR est particulièrement intéressante car elle permet :

  • De systématiser un pilotage par les objectifs à tous les niveaux de l’entreprise,
  • De travailler sur les objectifs en amont des initiatives,
  • D’avoir une approche à la fois top down et bottom-up permettant : de l’autonomie à tous les niveaux et qui permet donc innovation, gestion de la complexité et motivation des équipes.

Le déploiement des OKR apporte finalement beaucoup de bénéfices. Il convient néanmoins de s’assurer que les mesures associées aux Key Results sont simples et peu coûteuses à mettre en œuvre. Challengez systématiquement toute mesure dont la collecte ou l’analyse serait coûteuse !

 

 

Dans les prochains articles, nous verrons :

  • Comment marier les OKR et le framework d’agilité à l’échelle SAFe
  • Le retour d’expérience de mise en œuvre des OKR dans une grande organisation

A propos d’Inspearit

Inspearit est un cabinet de conseil en management de la performance et de la transformation des entreprises.
Nous pouvons vous accompagner pour mener à bien votre transformation Agile à l’échelle et le déploiement des Objectives and Key Results dans votre organisation.

Nous avons des coachs et consultants experts dans ces domaines avec une forte expérience.

 

Références :

  1. Doerr, John (2018). Measure What Matters: How Google, Bono, and the Gates Foundation Rock the World with OKRs.
  2. SAFE – Lean Budget – https://www.scaledagileframework.com/lean-budgets/
  3. SAFE – Lean Budget Guardrails – https://www.scaledagileframework.com/guardrails/

Business Agility Day 2019

 

Le Business Agility Day de BNP Paribas c’est une journée intense avec plus de 50 talks en français et en anglais sur des themes liés à l’agilité. Cette année, il a eu lieu le lundi 25 novembre 2019.
A l’image de l’année dernière, nous avons eu le plaisir de pouvoir contribuer au programme mais cette fois à travers deux talks :

  • Comment booster en continu les flux d’innovation au sein de l’organisation ?
    Emilie Garnier Outurquin (Orange France) et Adrien Hembert (Inspearit)
    Basé sur un retour d’expérience d’une mission menée pendant 18 mois chez Orange dans un environnement SAFe, ce talk permet de découvrir comment le Design Thinking a été déployé aux trois niveaux de l’organisation pour adresser les enjeux suivants : alignement sur la valeur, innovation, réduction du time-to-market et bien-être organisationnel.
    La démarche mêlant acculturations, ateliers, coachings spécifiques, toujours dans le respect du contexte de l’organisation, a permis la diffusion d’une culture de l’innovation en continue, levier incontournable pour appuyer durablement la transformation du groupe.

 

  • Comment agiliser durablement une chaine de valeur 100% Métiers ?
    Laurent Lamé (Orange) et Moïra Degroote (Inspearit)
    Notre approche de transformation d’une chaine de valeur de bout-en-bout permet d’introduire du P.E.P.S (People, Energy, Performance, Synergies) dans votre organisation pour :

    • gérer la dimension politique
    • susciter l’envie du terrain et du management
    • transmettre que ‘Accélération’ ne rime pas avec ‘Pression’
    • traiter les particularités liées à une activité opérationnelle (sans IT)

Ce REX est une illustration concrète de notre démarche décomplexée appliquée chez Orange France sur 20 équipes réparties dans 6 Directions. Une performance durable… obtenue en 3 mois seulement !

Merci à Jean-Pierre Saugère pour son invitation et toute l’organisation !

 

 

 

Retour sur Agile en Seine édition 2019

Témoignage de Pascal Hagnéré, consultant Senior

Thales Digital Factory: Disrupting culture across the group

A travers mes différentes expériences d’accompagnements de transformation d’entreprise, il y a un constat majeur qui ressort.
Trop souvent, de nouvelles organisations, méthodes et pratiques sont déployées, sans promouvoir et accompagner les changements culturels. C’est une condition indispensables pour réussir et pérenniser la transformation.

Le retour d’expérience sur la transformation digitale de Thales mettait l’accent sur les changements culturels. C’est pourquoi il a retenu mon intérêt.

Les éléments suivants ont, en particulier, attiré mon attention :

  • Ampleur de la transformation : 8000 personnes réparties du 56 pays
  • 7 workstreams de transformation dont un consacré à la culture
  • Création de la Thales Digital Factory comprenant 4 entités
    • Thales Digital Platform
    • MVP delivery
    • Startup incubator
    • Digital Academy
  • Vision des changements culturels synthétisée par un manifeste et 3 valeurs propres à la Digital Factory
  • Déploiement des changement culturels par une communauté de Captain

Digital Transformation Workstream and Manifesto

 

J’ai apprécié la forme très dynamique du retour d’expérience présenté en 3 points d’étape (Vision, Lancement, et Rétrospective) rejoués pour l’occasion par : Oliver Flous VP Digital Transformation et Clara Juanes-Vallejo (Culture Captain).

Par ailleurs, le manifeste et les 3 valeurs sont d’excellents vecteurs pour l’appropriation culturelle de la transformation. A condition, toutefois, que ceux-ci ne soient pas imposés par le top management, ce que la présentation pouvait laisser penser.

Une implication large des collaborateurs dans l’émergence du manifeste et des valeurs me paraît ainsi indispensable pour garantir leur appropriation par l’ensemble des collaborateurs.

 

RH et Agile ?

Dans la transformation agile d’une entreprise, les ressources humaines jouent un rôle clé pour accompagner la mise en place d’une nouvelle organisation. L’un des enjeux repose sur l’acquisition par les collaborateurs de nouveaux savoir-faire et savoir être.

Lors de cette conférence, Emmanuelle Pays et Laurence Urquilo, Directrice et Responsable du développement RH, ont présenté comment les principes Agiles étaient transposés à l’univers des Ressources Humaines, à la société Extia.

L’intérêt de la présentation, selon moi, est de montrer comment les RH peuvent servir la transformation tout en s’appropriant les principes agiles pour mieux atteindre ses objectifs.

Ainsi, dans un contexte d’incertitude et de changement permanent, l’amélioration de l’employabilité et de l’engagement des collaborateurs, sont des objectifs majeurs pour les RH.

Pour atteindre ces objectifs, Extia s’efforce de :

  • Répondre aux principales motivation intrinsèques des collaborateurs : besoins de compétences, besoins de relations sociales , besoin d’autonomie (voir le postulat de Deci et Ryan en 2002)
  • Créer un environnement garantissant une sécurité psychologique et favorisant la confiance, la prise de responsabilité, l’amélioration continue

La démarche est illustrée par un travail sur le parcours collaborateur misant sur la qualité de l’expérience du collaborateur depuis le recrutement jusqu’au-delà de la fin du contrat.

Voici des exemples inspirants des changements mis en œuvre :

  • Expérimentation entretien de recrutement à Lille : Donner le choix entre 3 type d’entretiens au candidat (Classique, Moving motivator, Dessiner son CV)
  • Mise en œuvre d’une plateforme digitale pour favoriser l’accueil et la prise de fonction d’un nouveau embauché
  • Implication des collaborateurs lors de la mise en place du SIRH
  • Feedback : Boucle rapide et réciprocité (manager vers collaborateur et collaborateur vers manager)
  • Réseau Alumni (Des liens sont conservés avec les ex-collaborateurs après la fin du contrat)

Pour conclure, un large choix de conférences intéressantes. Des approches dont peuvent s’inspirer les transformations en cours ou à venir.

 

Retour vidéo : talk « Agiliser durablement une chaine de valeur 100% Métiers »

Vous n’avez pas pu être présent ?
Revivez en vidéo comme si vous y étiez le REX sur l’agilisation d’une chaine de valeur de bout en bout chez Orange France… en 3 mois seulement !
Avec Laurent Lamé (Orange) et Moïra Degroote (Inspearit)

 

Inspearit sponsor Gold de la conférence FlowCon

Inspearit Sponsor Gold Flowcon

 

Après plusieurs années qui l’ont positionné parmi les conférences incontournables en France, Lean Kanban France change de visage en devenant la FlowCon.
Cette nouvelle identité reflète davantage les sujets qui tiennent à cœur les organisateurs. A savoir le Kanban, l’agilité, le continuous delivery, l’expérience utilisateur, le management décentralisé, etc.
A travers ce nom, c’est la notion de flux qui ressort. Afin d’aider les organisations qui le souhaitent à être plus flexibles. C’est parce que nous croyons en ces valeurs qu’Inspearit devient Sponsor Gold de la conférence en 2019.

Vous avez des questions sur le lean, l’agilité, le Product Management et autres ? Venez nous rencontrer sur notre stand les 12 & 13 décembre pour échanger autour d’un café.

Comment marier les OKR et le framework d’agilité à l’échelle SAFe ?

OKR et SAFe

Dans l’article précédent, nous avons vu :

  • Ce que sont les OKR « Objectifs and Key Results »
  • Comment ils peuvent aider les entreprises à mettre en œuvre leur stratégie et à créer de l’alignement et de l’engagement autour de ces objectifs

Dans ce nouvel article, nous allons voir comment marier les OKR et le framework d’agilité à l’échelle SAFe.

Etendre la gestion par les objectifs des frameworks d’Agilité à l’échelle

Les OKR et les frameworks d’agilité à l’échelle ne sont pas de même nature. Cependant, des frameworks comme SAFe incluent une gestion par les objectifs. Lors d’un déploiement des OKR, attention donc de ne pas doublonner ce que l’Agilité à l’échelle adresse déjà. En particulier, la gouvernance mis en place autour des OKR doit s’insérer dans la gouvernance mis en place au niveau de l’Agilité à l’échelle.

A noter néanmoins qu’il est tout à fait possible de déployer les OKR sur l’ensemble de l’entreprise, y compris sur des périmètres où l’agilité à l’échelle n’est pas déployée. Les OKR doivent donc être vu comme un mécanisme permettant d’améliorer la gestion par les objectifs déjà présente au sein des mécanismes d’Agilité à l’échelle.

Les OKR au niveau des Strategic Themes

Depuis la version 5.0, SAFe inclue le concept d’OKR au niveau des Strategic Themes, donc au niveau Portfolio.

Il ne s’agit pas d’une révolution. En effet, dans les versions précédentes, SAFe évoquait déjà les objectifs et les mesures au niveau des Strategic Themes. Il ne mentionnait simplement pas le terme ‘OKR’.

Piloter les Epics par des OKR

Même sans les nommer, SAFe va plus loin et décline en partie les OKR au niveau Program. Ainsi, SAFe préconise que la description d’un Epic inclut des Business outcomes hypothesis et des Leading indicators. Les business outcomes hypothesis sont les impacts souhaités de la mise en œuvre de l’Epic. Par contre, les leading indicators ne sont pas les Key Result de ces objectifs. Ils incarnent plutôt des indicateurs précurseurs permettant de valider les premières hypothèses de faisabilité et de bénéfice du MVP et de décider de continuer ou de pivoter. Voir en particulier l’article de SAFe sur l’innovation accounting présentant comment le cycle ‘build-measure-learn’ permet de réduire le gaspillage et d’optimiser la valeur produite.

Dans une approche où l’on systématise l’utilisation des OKR à tous les niveaux de l’organisation comme décrit dans le premier chapitre, on peut en fait étendre le framework SAFe en considérant qu’un Epic est drivé par une succession temporelle d’Objectives et de Key Results définis en amont de chaque PI Planning et faisant partie du cycle build-measure-learn de l’innovation accounting.
Ces OKR peuvent être considérés comme faisant partie de la vision présentée lors des PI Plannings.

Des PI Objectives formulés sous forme d’OKR

D’autre part dans SAFe, les PI Planning permettent d’identifier les PI objectives. Ces PI objectives représentent normalement des outcomes (bénéfices apportés) et non des outputs (livrables produits). Dans la réalité, c’est en fait peu souvent le cas. Ma proposition est que ces PI Objectives soient formulés sous la forme d’OKR ce qui permet de pousser des PI Objectives orientés outcomes.

Conclusion

A mon sens, les propositions suivantes évoquées dans l’article permettent de pleinement marier les OKR avec SAFe:

  • Formuler les Strategic Themes sous forme d’OKR
  • Piloter les Epics par des OKR
  • Formuler les PI Objectives sous forme d’OKR

Dans le prochain et dernier article de la série, je présenterai le retour d’expérience de déploiement de la méthode OKR au niveau d’un train SAFe.

Retour d’expérience de déploiement des OKR sur un train SAFe

OKR implémentation

 

Dans le premier article de la série, nous avons vu :

  • Ce que sont les OKR « Objectifs and Key Results »
  • Comment ils peuvent aider les entreprises à mettre en œuvre leur stratégie
  • Comment ils peuvent aider à créer de l’alignement et de l’engagement autour de ces objectifs

Dans le deuxième article de la série, nous avons vu comment marier les OKR et le framework d’agilité à l’échelle SAFe.

Ce dernier article est consacré au retour d’expérience d’un workshop d’identification des OKR sur le périmètre d’une tribu. Cette tribu est d’ailleurs pilote en ce qui concerne le déploiement des OKR au sein d’une organisation de 20.000 personnes.

Il se trouve que cette tribu est également un futur train SAFe dont je vais bientôt accompagner le lancement. Ceci est intéressant car l’identification des OKR va contribuer à la préparation du PI Planning et à la formalisation de la vision métier.

Méthode retenue pour identifier les OKR

J’avais besoin de mettre en place un workshop de définition des OKR sur le périmètre de cette tribu. J’avais également besoin de préparer le premier PI Planning et donc construire le backlog des features.

Il serait en fait logique d’identifier les OKR dans un premier temps. Et dans un deuxième temps de travailler sur le backlog de niveau Epic et Features. Cependant, le travail sur les deux sujets dans le même workshop m’a semblé intéressant car il permet :

  • De challenger le backlog existant avec les OKR. Ceci permet de se focaliser sur ce qui apporte le plus de valeur en lien avec la stratégie de l’entreprise
  • De challenger les OKR avec le contenu du backlog existant afin de s’assurer qu’un sujet important n’a pas été oublié
  • D’assurer la traçabilité entre les OKR et les éléments du backlog

J’ai opté pour un workshop qui pourrait ressembler à un Story Mapping mais dont les couches hautes ne sont pas comme dans le Story Mapping, le processus métier, ou le flux narratif mais les OKR.

J’ai fait utiliser une couleur de post-it par type d’objet (Objective, Key Result, Epic, Feature) comme présenté dans le schéma ci-dessous:

Retour d’expérience

Dans les faits, le workshop regroupant une dizaine de personnes s’est très bien passé. L’approche s’est avérée constructive aussi bien en termes de définition des OKR, qu’en termes de construction du backlog de niveau tribu.

 

Volontairement non lisible pour raison de confidentialité

 

Lors de ce workshop, nous avons identifié les axes d’améliorations suivants qui sont autant de conseils pour vous qui souhaitez mettre en œuvre une telle démarche :

  • Les Objectifs initialement identifiés n’étaient pas suffisamment disjoints. Ainsi, de nombreux Epics contribuaient à plusieurs Objectifs pour une même période temporelle.
    Ce workshop couplant définition des OKR et Story Mapping nous a permis d’identifier cette problématique au plus tôt. Nous avons donc décidé de restructurer les Objectifs dans le cadre d’un deuxième workshop.
  • Les participants avaient tendance à identifier des Key Results qui étaient plus des outputs (les livrables) que des outcomes (les bénéfices du livrable). Il est donc important qu’un facilitateur challenge les équipes de manière à ce que les Key Results expriment bien les bénéfices et non les livrables eux même.
  • D’autre part, lors du workshop, il n’a pas toujours été simple de faire émerger des Key Results mesurables. Lors du workshop suivant, j’ai donc proposé les templates ci-après pour détailler les Objectifs et les Key Results sur des feuilles A4. Certes les templates n’ont pas toujours été remplis complètement, mais ils ont incité les équipes à définir une mesure et à quantifier la valeur cible.

 

 

  • La définition de valeur cible réaliste de Key Result pour une date donnée s’avère complexe pour de nombreuses raisons. En particulier :
    – des facteurs exogènes peuvent influencer les outcomes,
    – les outcomes peuvent être décalés temporellement par rapport aux outputs
    – et bien sûr les outputs et donc les outcomes sont dépendants des priorités et de la vélocité des équipes


Conclusion

La définition des OKR s’est avérée être un exercice compliqué notamment en ce qui concerne l’identification des Key Results. Ceci doivent en effet :

  • Exprimer les bénéfices attendus
  • Etre mesurable
  • Etre réaliste
  • Ne pas être trop cher à mesurer

Néanmoins, l’exercice a été fortement bénéfique car il nous a permis de :

  • Prendre du recul en mettant en correspondance la stratégie métier et les éléments du backlog
  • Se focaliser sur ce qui apporte le plus de valeur
  • Créer de l’alignement et de l’engagement autour des objectifs

 

Inspearit est un cabinet de conseil en management de la performance et de la transformation des entreprises qui peut vous accompagner pour mener à bien votre transformation Agile à l’échelle et le déploiement des Objectives and Key Results dans votre organisation. Nous avons des coachs et consultants experts dans ces domaines avec une forte expérience. N’hésitez pas à nous contacter : info.fr@inspearit.com

Business Agility: What Got Us Here … – by Jan Bosch

During the last months, I have run into several situations where folks outside of R&D considered this concept of agile a nice little toy for the propeller-heads in software, rather than something that is in service of the company. In many cases, these people are stuck in a waterfall mindset and feel that it’s perfectly fine to release products once per year, if that often, and to keep selling what they’ve always been selling. The basic perception seems to be that the slow, planning-economy based approach has worked well so far and there really is no reason to change. All this talk about agile, speed, data and disruption is just noise and it’s best to ignore it and carry on.

At these occasions, I explain that the main reason why we care about agile in software is because it is an enabler for business agility. Business agility is concerned with the ability of the company to rapidly respond to changes in its business environment. This means rapidly stopping to do something that we’ve been doing for a long time when it becomes clear that it’s the wrong thing to do going forward. And it means rapidly starting to do something when an opportunity presents itself. Being able to constantly direct the resources of a company to the highest priority and most valuable activity at a moments notice is critical in an increasingly competitive world.

Traditional companies use plans as a tool to align the different functions in the organization. In the yearly planning cycles, the various functions prepare their plans based on the company strategy and then spend lots of time in alignment meetings to make sure that the plans of the different functions result in a successful execution of the overall company plan. Once the plans are approved and budgets allocated, everyone is focused on executing their respective plans. Incentives and rewards are provided based on the ability of everyone to deliver on their respective plan.

Each plan is based on a best guess of the state of the outside world at the point when the plan was created. However, the world is a dynamic entity and the guess might not have been very good to begin with. To paraphrase my favorite definition of “theory”, a plan is a beautiful thing killed by a gang of ugly facts. The reaction by those in favors of plans is the quote from Benjamin Franklin: failing to plan is planning to fail. But here’s the thing: I am totally in favor of planning. It is the blind, static execution of plans without constant adaption to the reality that I care about. No plan survives first contact with the enemy, as the military like to say. To quote one of the product managers in one of the Software Center companies said: I love agile because it allows me to change my mind every three weeks (the length of their sprint).

Imagine the organizational ability to redirect resources every couple of weeks. Assuming you have the right instrumentation to decide what to adjust the resource allocation to, everyone in the organization would always work on the most important goal. The challenge in traditional, hierarchical companies is that to enable this level of responsiveness in the organization requires empowering the rank-and-file in your organization. It means that individual teams can decide what to work on next based the information that they have collected during the previous sprint. In principle without any manager approval, which of course dis-empowers many managers in the organization and, in fact, makes their roles superfluous.

In addition, as most work requires competencies from different functions, we need to organize in cross-functional teams. Within the team we can adjust the direction on a continuous basis. Between several teams, adjustment can still be achieved quickly. Between different functions in large organizations, responsiveness is all but impossible. The only times where it has worked to some extent is where the leaders of the different functions have a very good relationship and have asked their staff to operate in informal, de-facto cross-functional teams.

Concluding, although in many organizations, the adoption of agile practices starts in software R&D, the principles apply to every part of the organization. The goal is to achieve business agility and for this we need cross-functional teams that are empowered to constantly adjust their activities based on their interpretation of the data coming from the market, customers, technology developments, competitors, partners and others. As the saying goes: what got us here, won’t get us there. It’s true for business agility too.

Follow me on  janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
And you might like www.software-center.se!

Stop Trying to Change Your Company! by Jan Bosch

As I work a lot with driving change in software-intensive companies, the people that I work with typically have already an idea of what needs to happen. However, many of them struggle with organizations that are incredibly resistant to change. In fact, someone recently shared his view with me that organizations are designed to be resilient in the face of different forces that are exerted and that the resistance to change is a feature.

One of the reasons why change is so difficult is that the leaders in the company want to have their cake and eat it too. On the one hand, they seek to implement a change, e.g. an agile transformation, adoption of continuous deployment, new data-driven services, etc. and they want this to positively affect the entire organization in one go. On the other hand, of course, these leaders want the benefits associated with the change but without needing to change anything that is the norm today. The Germans have a great saying for this that translates as “wash me, but don’t make me wet”.

The result of all this is that the people that I work with and that are trying to realize change in their organization often are frustrated and tired because of their constant battling of what often feels like windmills a la Don Quichotte. Driving change in organizations is an area where reams of paper have been filled with wonderful conceptual notions, but where my favorite definition of “theory” applies: A theory is beautiful thing killed by a gang of ugly facts. For all the books, theories and experts, in my experience, change management in practice is messy, inefficient and frustrating for everyone involved.

So, what is going on here? To me, there are at least three issues that are at the root of this problem, i.e. risk averse leaders, the gap between responsibility and authority and the mismatch in incentives. Below, I discuss each of these issues in more detail.

First, in most hierarchical organizations, individuals get promoted to higher positions because of their predictability and reliability. Imagine you are a higher level leader who has an open position in your leadership team. Who will you pick to fill the spot? A noisy troublemaker or a reliable employee who always dots the “i”s and crosses the “t”s? In practice, most of us will pick someone who will not rock the boat and can be relied upon. As a consequence, however, the result is that the higher up you go in the Christmas tree of the company’s hierarchy, the more risk averse the individuals tend to be.

Second, because of the risk averse nature of leaders, these leaders tend to avoid taking personal responsibility for implementing relevant changes. The arguments are often very convincing and leaders have learned to rely on delegation as an effective mechanism to increase reach. However, when it comes to driving change, the model falters as there are no existing processes, ways of working and tools to fall back on. Most leaders appoint an individual, typically the person that has been clamoring the loudest, to drive a transformation and assume that this person can magically drive the necessary changes by sheer belief and personality, but without the necessary authority. The gap between responsibility and authority tends to lead to a stalemate in the organization or, as one of the people that I work with calls it, a guerilla war.

Finally, because the individual or team looking to drive the change is different from the teams that actually need to change their behavior, ways of working, tooling and often even their norms and values. As the organization at large is responsible for delivering on the current business priorities, their incentives are focused on short-term business results. The change team’s incentives are concerned with long-term effects of the changes that they are looking to realize. The conflicting incentives will only slow down the change. The operational teams are made up of well-intended people that often want to realize the required changes, but are incentivized to maintain the status quo. And as humans, according to research, experience the pain of loss about three times as strong as they experience the joy of gains, changes that are not obviously improvements are generally resisted by our basic, human traits.

Realizing effective change requires, in my experience, at least three key elements: charismatic leadership, focus and time constraints. As long as we have hierarchical organizations, leaders will model behavior that is emulated by the rank and file. If the leader interested in accomplishing the change does not take personal responsibility to drive this and makes this his or her most important task, the rest of the organization will be even less inclined to get into motion. And the leadership has to be charismatic as there is a significant need to paint the bright new future to overcome the fear of loss in people.

Second, in many organizations there are many change initiatives ongoing in parallel and each of those have very long running periods. The typical argument is that change is hard and we need to give it time. In practice, however, many change initiatives means that the organization is unable to set priorities and because there is no real, short-term deadline and these change initiatives may actually negatively affect each other, the end result is often no change whatsoever.

My recommendation is that organizations, at the relevant scope (team, business unit, etc.), should have one and only one change initiative ongoing and the time period for this initiative should not be longer than 12 months and preferably significantly less, such as three or six months. The change initiative should be carefully planned, committed and executed as a project with full backing of management. Often, the period before kicking off the initiative can be used to create awareness and build understanding in the organization. However, once the initiative is set in motion, the execution will happen come hell or high water.

Concluding, in many organizations, everyone talks about change and has their own pet change project. Many are trying to influence the organization, but the end result in most cases is exactly nothing. We need to stop trying to change the organization and start to really change the organization. As Yoda famously said: Do or do not. There is no try!

Follow me on janbosch.com/blog,
LinkedIn (
linkedin.com/in/janbosch)
or Twitter (@JanBosch)!
you might like www.software-center.se!

L’évolution de l’environnement de travail, une question stratégique

Omniprésent, le terme de transformation digitale est trompeur, car il semble signifier que les entreprises n’auraient à s’adapter qu’à l’évolution des technologies. Or c’est tout leur environnement qui est bouleversé : non seulement technologique, mais aussi économique, culturel, sociologique, démographique, environnemental, réglementaire…

Avis d’expert sur la thématique du #workplace par Daniel Milelli
La suite à lire dans Lesechos.fr du 3/11/17

It’s Not Technology That Is Holding Us Back – by Jan Bosch

During another week on the road (Zurich, Paris and Stuttgart this time) and after discussions with dozens of people at the conferences and meetings, I noticed a pattern that repeats itself again and again in technology driven companies. For the latest major digitalization technologies, such as big data, IoT and deep learning, I have observed the large technology companies respond. Interestingly, the incorporation and adoption of these technologies is treated as a technology problem. So, initiatives are kicked off to build infrastructure, build up competencies around the technology, architectures are designed, scalability is confirmed, etc.The moment the first activities are underway, plans are requested detailing when which part of the technology stack will be available and ready for deployment, budget are estimated and, after the normal political hassles, resource allocations are approved and made available. Once this is in place, the normal project management follow-up takes place with project meetings, steering board meetings, etc. that are all tracking progress, following up on resources and finances and admiring the shiny demos of the technology that are shown by project members. And, at the end of each meeting, everyone basks in the glow of the bright future that the company can expect to have with all these exciting technologies becoming available.

In all this, there is one big glaring party missing: the customer. With all the focus on the technology, there is very little attention to the customer and the ways in which this technology is expected to add value to customers. Of course, there are a couple of dreamed up use cases, but these have never really been confirmed with customers. And as everyone keeps telling each other about these fabulous use cases that customers are just going to love, the use cases start to lead a life of their own and everyone in the company just knows that these use cases are the ones that are going to allow the company to disrupt the market.

Then, when the first early deployments with customers are getting ready to be put in operation, we notice the next stage: customers are not interested, the solution does not provide the promised benefits or the technology solves a non-existent problem. Initially, the lack of maturity of the solution is blamed and the company doubles down on its investments as the technology is viewed as strategic and critical for its future success. As the solution matures and the market adoption still is lackluster and fails to deliver on the inflated expectations, the belief in the technology in the organization starts to wane and the technology falls into the “trough of disillusionment”. The good news, however, is that by that time there will be some other cool, exciting technology on the horizon and the attention of everyone in the organization shifts to the next promising, cool thing. And before you know it, similar to a dog chasing shiny bumpers and getting distracted every time a new car with a shiny bumper appears, the organization runs off after the next thing.

The key lesson is that technology adoption is not about technology. Adopting a new technology is about innovation. It’s about finding the use cases where the new technology adds real, tangible value for customers. It’s about trying out dozens of different use cases and accepting that in the end, the majority of these will fail to deliver on the promise. And it’s about realizing that even though customers say they love the innovation and can’t wait to use it and promise to pay you good money for it, it’s about what customers do that really matters. The gap between espoused theory and theory in use is large and this is even more true when it comes to adopting new, exciting technologies.

The problem is that in many of the technology driven organizations that I work with, everyone has an engineering background and to a large extent believes in the mantra of “build it and they will come”. Consequently, the adoption and evolution of new technologies is viewed and treated as an engineering problem rather than an innovation and business development problem. Companies invest millions upon millions to build infrastructure, architectures and competencies without a single truly validated use case. We build fantastically strong foundations for businesses that may never realize.

Instead, we have to accept that it’s not about technology. It’s about the benefits we can offer to customers through the use of these new technologies. And it’s our customers that are the judges of what is beneficial to them. So, instead of building the foundations, we should build dozens of use cases with the ricketiest, scrappiest, duct tape and bailing wire technology solutions below them. Then we verify whether customers actually do with our solutions what they said they would do. And only in the minority of cases where this turns out to be the case do we strengthen, productify and scale the technology basis below.

Concluding, adopting new technologies is not about technology, infrastructure, architectures or competencies. Every technology oriented company that I know and work with is able to solve the most complex and exciting technology problems. It is the innovation processes that are the weak spot: going out with a rickety prototype to a customer to verify that it indeed solves a real problem is something that technology companies find incredibly difficult. However, if a solution solves a real problem, customers will use it no matter how scrappy it is. And if it doesn’t solve a real problem, customers will not use it no matter how glossy and shiny the solution. So, accept that it’s not technology that is holding us back; it’s the lack of an experimentation and innovation culture that is the real problem.

 

inspearit : Annie Combelles, La Femme Qui Diffuse Le Lean Et L’Agilité

Annie Combelles inspearit

Lire la suite

Ecrit par Audrey Chabal
Journaliste chef de rubrique management / Entrepreneurs / Femmes@Forbes
Parue le 18 décembre 2017

Pourquoi le manager doit-il s’intéresser au lean management ?

Depuis quelques années, on parle beaucoup du lean management. Certains managers ont adopté le lean. D’autres hésitent. Pourquoi ne doivent-ils plus hésiter ?

Par Christophe Coupé, expert principal Lean Management &
Jérôme Meyer, consultant senior chez Inspearit.

Que demande-t-on essentiellement au manager ? De rechercher et d’atteindre un niveau de performance pour sa direction, son département, son équipe, son unité de production… Pour réussir ce challenge, il va devoir rechercher l’efficacité, éviter la répétition d’erreur, satisfaire son ou ses clients, donner du sens et un cap, faire progresser son équipe, rendre des comptes…

Article paru dans Courrier Cadres
Cliquez sur ce lien pour en savoir plus

Design thinking et Agilité à l’échelle – une bonne alliance !

Des philosophies proches, des logiques collaboratives, des approches itératives, la mise en place d’équipes multidisciplinaires et un souci constant de placer l’utilisateur au cœur de la démarche de conception : sur beaucoup de points, Design Thinking et Agilité partagent de grandes similitudes.

Design thinking

Si le Design Thinking consiste à favoriser l’identification du « vrai » besoin et la solution à y apporter (le « Quoi »), l’agilité se concentre principalement sur la façon de mettre en œuvre cette solution (le « Comment »). Toutes deux complémentaires (le Design Thinking étant une très bonne façon d’amorcer une démarche agile), ces deux approches permettent de s’assurer le plus tôt possible via des retours utilisateurs que le produit développé répondra réellement aux besoins de ceux-ci, en évitant gaspillages d’argent et efforts inutiles.

Si l’association entre une approche Design Thinking et un accompagnement Agile reste relativement simple à mettre en œuvre au niveau d’une seule équipe, qu’en est-il dans un contexte d’agilité à l’échelle où plusieurs équipes agiles sont amenées à collaborer ? Dans cet article, nous nous baserons sur le modèle d’agilité à l’échelle SAFe afin de voir comment il est possible d’y insérer une approche Design Thinking pour rendre vos efforts de développement encore plus efficaces.

Une alliance du bon sens

Une image vaut mille mots. Le Design Thinking qui met en avant le prototypage sommaire de solutions (via le sketching ou le wireframing notamment) constitue une démarche extrêmement efficace pour rendre tangibles les périmètres et apparences physiques du produit à développer, faciliter la compréhension entre équipes et aligner la vision de celles-ci. Par définition, un contexte d’agilité à l’échelle implique que plusieurs équipes agiles soient impliquées. Plus le nombre d’équipes va être important, plus l’information sera diffuse entre les équipes, plus il sera crucial que chacune d’entre elle ait une vision claire et partagée du produit à développer. C’est une question de bon sens !

A ce sujet, on peut regretter le nombre encore trop faible d’équipes agiles prenant le réflexe d’afficher sur les murs des plateaux de travail les wireframes et/ou maquettes représentant les interfaces en cours de réalisation. Les bénéfices en termes de compréhension et de qualité d’échanges sont pourtant énormes.

Une alliance pertinente pour gérer son portfolio Backlog

Le Design Thinking a toute sa place dans le modèle SAFe au niveau de la gestion du Portfolio Backlog auquel il est recommandé de faire appel à un tableau de suivi très simple (appelé « Portfolio Kanban ») représentant les étapes principales pour concevoir, développer et déployer un nouvel Epic.

Six étapes composent le Portfolio Kanban : « Funnel » (liste de mes Epics), « Review » (Premier niveau d’analyse sommaire des Epics), « Analysis » (niveau plus poussé d’analyse des Epics avec décision d’investir ou non), « Portfolio Backlog » (Epics validés et priorisés), « Implementation » (développement des Epics), et « Done » (Epics réalisés).

C’est en général à l’étape « Analysis » que les organisations décident d’investir (parfois plusieurs millions d’euros) ou non dans un Epic. Il convient donc de faire un choix éclairé et à ce titre, effectuer une session de Design Thinking pour tester la faisabilité et la désirabilité de l’Epic à un niveau macro constitue une option fiable, rapide et économique afin de s’assurer que ce que nous comptons développer corresponde bien à un réel besoin de la part des utilisateurs. Sur le Portfolio Kanban, les étapes « Review » et « Analysis » seront particulièrement adaptées pour accueillir des sessions de Design Thinking dans l’optique de optimiser, une fois de plus, vos efforts de développements.

Une alliance pour apporter plus de créativité dans vos features

Continuous delivery pipeline

À un niveau plus micro, le modèle SAFe évoque l’exploration continue (« Continuous Exploration ») qui est le processus consistant à explorer en permanence les besoins du marché et des utilisateurs afin de définir une vision, une feuille de route et un ensemble de fonctionnalités (« Features ») répondant à ces besoins. C’est la première étape du pipeline de livraison continue d’un train Agile (« Agile Release Train ») structuré en quatre parties, et précédant l’intégration continue (« Continous Integration »), le déploiement continu (« Continuous Deployment ») et la « livraison à la demande » (« Release on Demand »).

Lors de cette exploration continue, les équipes sont invitées à émettre des hypothèses de bénéfices (« Outcomes hypothesis »), initier une démarche de conception collaborative (« Collaborative Design »), construire un MMF (« Minimum Marketable Feature ») et à en évaluer le résultat (« Evaluate ») pour savoir si la fonctionnalité répond réellement aux bénéfices que nous nous étions fixés. Plus que jamais à cette étape, l’adoption d’une démarche de Design Thinking sera particulièrement judicieuse. Le modèle SAFe a d’ailleurs bien intégré cette connexion en remplaçant le terme « UX » (utilisé dans la version 4.0) par le terme « Lean UX » dans la version 4.5 (pour rappel, Jeff Gothelf englobe à la fois Lean Startup, Design Thinking et développement agile pour définir la notion de « Lean UX » dans son livre « Lean UX »).

Dans un contexte d’agilité à l’échelle, le Design Thinking semble donc particulièrement adapté. Que ce soit pour aligner la vision de toutes les équipes impliquées, prioriser le Portfolio Backlog ou définir avec plus de précision les Features, il constitue une approche économique, fiable et rassembleuse pour mettre sur le marché dans les meilleures conditions et le plus rapidement possible des livrables à forte valeur ajoutée pour les utilisateurs. Nous ne pouvons donc que nous réjouir que le modèle SAFe ait pleinement pris la mesure de la force de cette alliance en allant jusqu’à réserver spécifiquement une itération (« Innovation and Planning Iteration ») lors de chaque Program Increment (« PI ») pour permettre aux équipes d’innover. Mais au-delà de la théorie, c’est désormais aux grandes organisations de prendre le relais pour implémenter de façon opérationnelle cette association gagnante au sein de leurs équipes : un point qui constituera de plus en plus un impératif stratégique dans les marchés ultra-concurrentiels et disruptifs de demain.

Adrien Hembert

Implementing SAFe® with SPC Certification – Rome – 6 – 9 March 2018

Based on Version 4.5 of SAFe

This four-day course will prepare you to lead an enterprise Agile transformation by leveraging the Scaled Agile Framework® (SAFe®). You will learn how to effectively apply the principles and practices of SAFe, including training with SAFe courseware, and coaching teams, launching Agile Release Trains, and building and managing an Agile portfolio. The first two days of the course – Leading SAFe – will provide you with the basis to teach SAFe to others, and if certified you’ll be eligible to teach the Leading SAFe course. The next two days focus exclusively on implementing SAFe

implementing SAFE Course in EnglishAudience:

The course is intended for those who will be materially and directly involved in a SAFe adoption. This includes enterprise leaders, practitioners, change agents, and consultants responsible for implementing Agile programs and portfolios as part of an enterprise Lean-Agile change initiative

[icon name= »arrow-right » class= » » unprefixed_class= » »] Professional Services Consultants
[icon name= »arrow-right » class= » » unprefixed_class= » »] Business and Technology Executives and Leaders, Managers, Directors
[icon name= »arrow-right » class= » » unprefixed_class= » »] Portfolio Managers and Fiduciaries, Project/Program Management Office (PMO) personnel
[icon name= »arrow-right » class= » » unprefixed_class= » »] Development, QA and IT management
[icon name= »arrow-right » class= » » unprefixed_class= » »] Program and Project Managers
[icon name= »arrow-right » class= » » unprefixed_class= » »] Product and Product Line Managers
[icon name= »arrow-right » class= » » unprefixed_class= » »] Process Leads and Lifecycle Governance Personnel
[icon name= »arrow-right » class= » » unprefixed_class= » »] Enterprise, System and Solution Architects
[icon name= »arrow-right » class= » » unprefixed_class= » »]Internal Change Agents, Lean-Agile Center for Excellence, Agile Working Group

Training Goals:

After this course, you should be able to:

[icon name= »arrow-right » class= » » unprefixed_class= » »] Lead an enterprise Lean-Agile transformation
[icon name= »arrow-right » class= » » unprefixed_class= » »] Implement the Scaled Agile Framework (SAFe)
[icon name= »arrow-right » class= » » unprefixed_class= » »] Implement and manage a Lean-Agile portfolio
[icon name= »arrow-right » class= » » unprefixed_class= » »] Align the organization to a common language and way of working
[icon name= »arrow-right » class= » » unprefixed_class= » »] Perform value stream analysis and identify value streams
[icon name= »arrow-right » class= » » unprefixed_class= » »] Launch and support Agile Release Trains and coordinate value streams
[icon name= »arrow-right » class= » » unprefixed_class= » »] Build and execute the implementation rollout strategy
[icon name= »arrow-right » class= » » unprefixed_class= » »] Configure the Framework for a specific enterprise context
[icon name= »arrow-right » class= » » unprefixed_class= » »] Train managers and executives in Leading SAFe and act as a SAFe Agilist (SA) certifying agent (SPCs only)
[icon name= »arrow-right » class= » » unprefixed_class= » »] Train teams in SAFe for Teams (S4T) and act as a SAFe Practitioner (SP) certifying agent (SPCs only)

Prerequisites

All stakeholders in a Lean-Agile transformation are welcome to attend the course, regardless of experience. However, the following prerequisites are highly recommended for those who intend to take the SPC4 certification exam and operate in the field as a SAFe Program Consultant:

[icon name= »arrow-right » class= » » unprefixed_class= » »] 5+ years of experience in software development, testing, business analysis, product or project management
[icon name= »arrow-right » class= » » unprefixed_class= » »] 3+ years of experience in Agile
[icon name= »arrow-right » class= » » unprefixed_class= » »] One or more relevant Agile certifications

SAFe® Certification

Attending the class prepares you to take the SAFe 4.0 Program Consultant (SPC4) exam. Those who attain their SPC4 certification will receive:

[icon name= »arrow-right » class= » » unprefixed_class= » »] Access to license the course materials needed to train aspiring SAFe Agilists, SAFe Practitioners, and SAFe PM/POs
[icon name= »arrow-right » class= » » unprefixed_class= » »] Access to no-cost license materials, videos, and artifacts that support launching Agile Release Trains
[icon name= »arrow-right » class= » » unprefixed_class= » »] Inclusion in the SPC4 directory listing (optional)
[icon name= »arrow-right » class= » » unprefixed_class= » »] Access to the private SPC LinkedIn Group

Location: ROME

Duration: 4 days, 6-9 March 2018

Price: 2.900,00€*

Early-bird price: 2.720€,* before 6 February 2018

*All price are VAT excluded

The training will be held in English.

Enrollment Form

Go to Italian version

Why Fast Feedback Cycles Matter – by Jan Bosch

When studying software-intensive systems companies, one of the interesting observations is that they all evolve in the same way. In earlier research, we have referred to this as the “Stairway to Heaven”. In the figure below, the speed dimension of the Stairway to Heaven model is shown. This model is a descriptive model based on our research with dozens of companies and it follows a logical sequence of activities. First, starting as a classical company, the organization adopts agile practices. Subsequently, continuous integration is adopted and rolled out in the company. Once continuous integration and test have established a situation where all software is always at production quality, the company will move towards continuous deployment. Finally, it will start to use its deployed products for innovation purposes, for instance through A/B experimentation.

speed dimension
Figure: Speed dimension of the Stairway to Heaven

Although one can easily argue that companies evolve through these levels, the question one should ask is WHY this happens in the first place. Our research has shown that this is because companies benefit from shortening the duration between decision and the feedback on the outcome of the decision. In general, the shorter the feedback cycle, the more accurate the decisions can be as a shorter feedback cycle allows for a more rapid learning loop. In the case of software-intensive systems companies, we have identified six feedback cycles that are shortened when climbing the Stairway to Heaven:

Development: When adopting agile development practices, the first principle is that the team works in sprints of four weeks or less. This means that at the end of every sprint there will be working software. This leads a development cycle that is much shorter than during waterfall development as all work in progress is wrapped up into complete code every sprint.

Requirements: The second practice when adopting agile development is that teams conduct sprint planning. This means that for every sprint, there is an opportunity to reschedule requirements and to change the content for the next sprint. This is a fundamental difference from traditional release planning where release content is defined and agreed upon before freezing it until the release of the system.

Quality assurance: Continuous integration and test allows for much faster feedback on the quality of the system under development as compared to traditional testing approaches. In addition, once the company adopts continuous deployment, internal quality assurance is complemented by quality assurance from the field.

Governance: Every R&D organization has at least three types of activities, i.e. feature development, defect management and refactoring. Even with the most advanced CI system, there will be defects that slip through and that need to be managed and repaired afterwards. Similarly, the design of the system will erode over time, often referred to as technical debt, and require investment in refactoring to maintain an acceptable design quality. Operating in short cycles allows the R&D organization to dynamically reallocate resources on short notice and for short(er) periods of time.

Deployment: When adopting continuous deployment, the basic benefit is that our software is rolled out frequently, which provides feedback on the quality of the software. It also provides a solution to the problem where finished features are kept “on the shelf” for far too long without providing benefit for the customer as well as the company that built them. No modern factory would produce goods just to have these sit on the shelf for months at end because of the associated waste, whereas in many software development organizations, that is exactly what happens.

Value creation: The final cycle is concerned with confirming that the value that we predicted would be delivered by new functionality indeed is created. For instance, a new feature may improve some quality attribute or change user behavior in a desirable way. When using a traditional release model, this feedback becomes available often several quarters or years after the decision to prioritize the development of the feature has been taken. When using continuous deployment, we have access to this feedback in a small number of weeks.

In the table below, we related the stage of the Stairway to Heaven model to the feedback cycles that are shortened at that stage. The key reason why shorter feedback cycles are so important is that companies take opinion-based decisions when the feedback cycles are long as the relation between a decision and its effects is too far separate in time. When feedback cycles are short (such as one sprint), decision processes also become data-driven. In earlier articles, I stressed that for a typical software-intensive company, half of all the features built are waste in that the provided value does not justify the R&D effort that was needed to create the feature. Shorter feedback cycles provide a very powerful solution to reducing that waste.

feedback cycles

Table: feedback cycles

Concluding, shorter feedback cycles allow companies to transition from opinion-based to data-driven decision making. That allows allows for a step-function change in the quality of the decisions that are made which, in turn, improves the competitiveness of the company significantly versus competitors that are stuck in traditional ways of working and opinion-based decision making. Climbing the Stairway to Heaven is not a “nice to have” for the R&D organization but rather a critical factor for maintaining the competitiveness of the company.

Follow me on  janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
And you might like www.software-center.se!

Transformation Agile : Des pistes pour réussir le changement – Thierry Ventadour

Avant d’aborder le sujet des transformation Agile, faisons un rapide rappel historique des transformations dans l’IT

Il faut attendre les années 1980 pour que l’industrie informatique connaisse les premiers déploiements de processus, avec des démarches basées sur l’ISO 9001 ou le CMM. Le postulat est alors que la mise en place de processus efficaces résultera nécessairement en la livraison de produits de qualité, tout en tenant délais et budgets.

Les années 2000 voient alors l’arrivée des méthodes et principes Agile, notamment avec la publication du manifeste Agile en 2001 : Si les processus sont nécessaires, ils seront vains sans prendre en compte la dimension humaine des équipes de développement. Il apparait alors nécessaire de motiver et responsabiliser les équipes afin que celles-ci délivrent des produits de qualité.

L’Agilité est orientée utilisateur. Vu de l’utilisateur, l’important est le produit livré, et non pas la manière dont le projet a été mené. Les organisations IT, orientées projets, se transforment donc en organisations orientées produits : les Chefs de Projets font place à des « Product Owners », les plans projet à des Product Backlog.

Quelques conditions pour une transformation Agile réussie

La première condition est d’avoir un objectif de transformation précis, partagé et orienté business, supporté par un sponsor fort : Pour quelles raisons l’organisation doit-elle évoluer ?

Donnons un exemple : vouloir développer un produit modulaire afin d’être en capacité de répondre plus rapidement aux besoins des clients. L’objectif est alors précis, concret, vérifiable et orienté clients. A contrario avoir comme objectifs de se transformer pour supprimer les silos dans l’entreprise ou améliorer la satisfaction des employés est certes louable, mais vagues et peu tourné vers les utilisateurs. Quel sponsor investirai durablement pour une démarche non liée au business de l’entreprise ?

La deuxième condition a été formalisée par Kotter : il faut un sentiment d’urgence : Sans urgence, il y aura toujours quelque-chose de plus prioritaire à faire ! Il ne s’agit pas la de l’urgence réelle, mais de l’urgence ressentie par les membres de l’organisation.

Il faut ensuite reconnaitre l’importance des différents axes de la transformation Agile :

  1. L’axe organisationnel : Agile nécessite une transformation des organisations au niveau équipe, par exemple avec Scrum, et au niveau organisation, avec la mise en place de frameworks comme SAFe ou LeSS. Sans changement d’organisation, pas de transformation Agile.
  2. L’axe humain : Agile nécessite un changement des valeurs et des comportements à tous les niveaux de l’organisation : mise en place d’un management plus bottom-up, responsabilisation et confiance dans les équipes, transparence, décentralisation des décisions. Sans changement de valeurs, pas de transformation réelle des comportements, et pas de transformation Agile.
  3. L’axe technique : pour livrer fréquemment, il est nécessaire de mettre en place de nouvelles méthodes de développement, comme l’intégration continue et les tests automatiques. Pour cela, il est nécessaire de « refactorer » les produits pour les rendre plus modulaire et testables, d’en revoir l’architecture. Sans transformation des méthodes de développement et de l’architecture des produits, pas de transformation Agile.

Comment s’assurer que la transformation Agile progresse ?

Un premier signe est d’observer que l’organisation IT orientée projet disparait au profit d’une organisation orientée produit : Les équipes projet se restructurent autours de composants pour former des « component teams », ou de fonctionnalités utilisateurs pour former des « feature teams ». Les budgets ne sont plus gérés par projet mais par produit.

Dans le même temps, les anciens rôles associés aux projets (Program Managers, Project Managers) font place à des rôles associés aux produits (Business Owners, Product Managers, …). Il ne s’agit pas uniquement d’un changement de nom, mais d’un changement de rôle, cette évolution s’accompagne d’une montée en compétence autours de la gestion de produit.

Les méthodes de développement, historiquement souvent définies par des équipes transverses sont prises en charge par des membres des équipes concernées, organisées en communautés. Le rôle des équipes transverses est alors de faciliter et s’assurer que les décisions prises sont alignées avec les objectifs de l’entreprise.

Enfin, une transformation Agile n’est jamais confortable : Managers et membres d’équipes doivent faire évoluer leurs valeurs, comportements. Une transformation facile est le signe d’une transformation de façade ou qui ne progresse pas.

Conclusion

Les transformations Agile s’accompagnent d’une revalorisation du rôle de développeur, pris au sens large, incluant les activités de conception et de test. Elle favorise également l’émergence de leaders, c’est-à-dire de personnes indiquant la direction à prendre et entrainant les équipes vers cette cible. Des leaders apparaissent à tous les niveaux de l’organisation : développement, architecture, management.

Enfin, une transformation Agile prend du temps, la mise en place de frameworks type Scrum ou SAFe n’est que la face immergée de l’iceberg. L’évolution des comportements des équipes et managers, de même que la mise en place de nouvelles techniques de développement ne se fait pas en quelques mois.

 

Conférence d’Alistair Cockburn – Heart of Agile les 31 mai et 1 Juin à Paris

Venez nombreux à cette conférence sponsorisée par inspearit qui se tiendra au CNAM, 2 rue Conté à paris de 9h à 19h

Moïra Degroote, speaker,  animera l’atelier participatif sur la Priorisation et se fera également un plaisir de vous retrouver sur notre stand.

La conférence en quelques mots

Heart of Agile a été créé par Alistair Cockburn, co-fondateur du mouvement Agile. Il s’agit de revenir aux valeurs et fondamentaux de l’Agilité : l’humain au cœur, Collaborer, Délivrer, Réfléchir, s’Améliorer.
Alistair pensant que lors des implementations, on s’est un peu perdu en chemin et peut être avons-nous perdu de vue le sens premier de l’Agilité

Heart of Agile conference 2018

Le format de cette conférence est basé sur la Communication et la collaboration entre tous les acteurs présents et non pas essentiellement sur celle de l’orateur, de manière à exacerber l’Intelligence Collective et faire émerger de ce colloque quelque chose d’unique qui est la somme des contributions de tous.
D’où les 4 formats interactifs avec les participants : World Café- Openspace, Tutoriel, Conversation collaborative , Retour d’expérience. Apprêtez-vous a mouiller vos chemises [icon name= »smile-o » class= » » unprefixed_class= » »]

Une des Questions ouvertes de ce Colloque est :  » Comment l’Agilité peut-elle s’épanouir dans le cadre de la culture France?
Nous souhaitons y répondre à travers un Open Space/ Worldcafé géant sur 5 sessions de 90 min sur 2 jours où à l’issue de ce colloque HoA émergera un Manifeste Agile Français qui y répondra et pourra être signé par l ensemble des participants

Alistair souhaite faire honneur à la culture Française, l’ensemble de ses interventions , keynotes , plénières seront en FRANCAIS,

Information et inscription sur http://www.heartofagile.fr

Egalement à ne pas manquer, la masterclass Advanced Agile avec Alistair Cockburn le 30 mai à Paris

Digitalisation & Lean management : le ticket gagnant – Christophe Coupé

Pourquoi associer Lean management & digitalisation ? En quoi le Lean management peut-il être utile à la digitalisation ?

Le Lean management n’a jamais été une fin en soi. Jusqu’à présent il a été considéré comme une démarche de management reconnue pour son efficacité. Il pourrait désormais s’imposer comme un des facteurs clés de succès de toute transformation digitale.

Article paru sur Silicon.fr
Lire la suite

How to design your IT organization to optimize the delivered value? by Stéphane Déprès

This article provides a synthesis of an over a year experience designing IT organization in the scope of an agile@scale transformation involving 7000 persons.

It explains how to align your IT organization with business Value Streams and business strategy to optimize the Time to Market on a given axis (or any other optimization axis derived from your business strategy).

Value Streams

1/ Identify your business Operational Value Streams and the associated IT Organization Units

This chapter is dedicated to the identification of IT Organization Units. By Organization Unit, I mean a group of people whose size is less that the Dunbar’s number – a suggested cognitive limit to the number of people with whom one can maintain stable social relationships (the commonly used value of the Dunbar’s number is 150 people; sometime 125 is also used).

First, you should identify your Business Operational Value Streams – high-level business processes providing value to customers. The schema below presents an oversimplified value stream example.

Patient Management

The golden rule is “IT Organization Units should be based on one or a set of Value Streams but a value stream should not cross several IT Organization Units”.

Why? As a change to the system(s) supporting the value stream is managed in a single IT Organization Unit, there is less synchronization need to build the change, leading to better time to market.

Unit management

But what if several Value Streams cross some centralized big components like data warehouses or referential (these centralized components needing several hundreds of people to maintain)? Should you integrate slices of the data warehouses and referential into each Organization Unit or keep the data warehouses and referential into a centralized Organization Unit? In the first case, you optimize the time to market and in the second case you optimize the coherence and the cost. It’s up to you to choose the best solution keeping in mind the advantages and drawbacks of each scenario.

Note that this article doesn’t address the design of transverse departments that may be needed.

2/ Identify the Feature Teams of each Organization Unit
We will then dive into the design of each Organization Unit and think about how to split an Organization Unit into Feature Teams.

We will first start to define what a Feature Team is: a long live group of 5 to 9 persons, responsible for a range of features, collocated, autonomous, multi-skilled and cross-functional.
Firstly, why organize your Organization Unit into Feature Teams? Because Feature Teams are aligned with value stream and lead to a better time to market. Furthermore, in opposition to a team dedicated to a project, Feature Teams are long lived so they allow the capitalization of team skills and knowledge.

The first split axis of your IT Organization Unit into Feature Teams should be by Value Stream to optimize time to market. Then for a given Value Stream – if the Value Stream encompasses multiple teams – what should be the second split axis? An optimal solution would be that Feature Teams be interchangeable (the blue, the green, the red team) with no scope specialization, allowing with the help of Agile at Scale synchronization mechanisms a dynamic allocation of features to Feature Teams. In practice, this is difficult to achieve because of functional and technical specialization. It is always a compromise: if your split axis leads to a feature team with a narrow scope along a value stream, the feature team may be in charge of too many applications, leading at least temporarily to many specialization silos inside the teams. Bad! An alternative is to have a set of Feature Teams on a less narrow scope but with Agile@scale synchronization mechanisms: there will be less specialization silos and the time to market will still be great due to these Agile@scale mechanisms that will enable teams to coordinate on transversal features.

Before addressing the different split scenarios, I highly recommend that you elicit the business strategy, especially the business transformation expectations and their prioritization.
For instance, I have recently organized a workshop with the business of an Organization Unit on this topic and the results were: for some identified types of features, one should optimize the time to market along the Value Stream. For the other types of features, one should optimize the time to market by activity of the business process as for this kind of feature types, if an activity of the business changes, the probability that it may impact other activities of the business process is low. Moreover, the systems supporting the different activities of the business process were on different development streams. This gave me a first split strategy.

Another important point is to identify the constraints: the ones related to the team localization and the ones related to the team specialization.

After having identified the business strategy and the constraints, you should identify the Value Stream split axis scenarios (again only if the Value Stream involves several teams): for instance, a split may be by client, by group of feature types, by business object, etc… Another split axis may be obtained by analyzing the IT urbanization. If the degree of coupling between two systems is low, it is better to dedicate each system to separate teams. But if you change the organization, the Conway law may play against you.

Constraints

I highly recommend that you formalize each scenario including, for each one, the advantages and the drawbacks. In the case of my data warehouse example where the Organization Unit is mapped to the data warehouse, the split axis can be either by business line or by using a data type partition. In the first case, you optimize the time to market and in the second one, you optimize the coherence and the cost – however in this case, you will also need Product Owners being able to manage the priorities across several business lines.
You should also pay attention to the fact that split axis leads to long live Feature Teams with a constant distribution of work. This means you should consider the evolution of the business strategy.

I also highly recommend that you involve all stakeholders to select the best scenario. I recently involved all the members of an Organization Unit: it led to many advantages. Firstly, people identified other advantages, drawbacks and constraints we had not discovered. Secondly and most importantly, it involved everybody in the transformation and brought intrinsic motivation.

Chosen split axis leads to Feature Teams or groups of Feature Teams. At this stage, the Feature Teams should only be logical and the team members should not be allocated to them. It avoids political and personal pressure.

3/ Map team members to Feature Teams

The next step is to map team members to Feature Teams. I recommend organizing a workshop in which each Organization Unit member selects his own Feature Team. Of course, during this workshop the Product Owners/Scrum Masters/Managers should present each Feature Team and describe the Feature Team scope, the team size and the required skills. I recently facilitated such a workshop and it was a great success!

organization unit

 

Stéphane Déprès

Member of inspearit Agile@scale community (community designing an Agile@scale transformation approach)

More detail is available in the inspearit Agile@scale transformation approach including guidelines of the different workshops to be performed.

Et si le Design Thinking tuait l’innovation ? par Arthur Duchet-Suchaux

Arrêter de résoudre les problèmes connus de clients connus

Aujourd’hui, on entend parler du design thinking comme de « La solution ultime » pour innover : l’utilisateur est désormais la clé de voûte de la transformation digitale des grandes entreprises qui peuvent devenir aussi « disruptives » que des startups.

Seulement, pour ceux qui ont déjà pris part à des sprints design ou à des projets de mise en œuvre du design thinking, on constate que bien souvent, le résultat n’est pas si innovant : on crée tout au plus une version digitale des activités existantes de l’entreprise, une plateforme web, une application mobile, qui améliore certes l’expérience de l’utilisateur, du client, du collaborateur…

Pour comprendre ce phénomène, il faut retourner à la définition de l’innovation : l’innovation est le fait d’introduire sur un marché un nouveau produit, service, process. Elle peut être incrémentale : l’innovation vient améliorer l’existant, ou radicale : on crée une offre à la fois nouvelle pour le marché et pour l’entreprise.

L’innovation est un processus qui a pour but d’aligner la conception d’un produit/service sur les attentes d’un marché : mais dans le cas d’une innovation radicale, le marché ne préexiste pas à l’innovation : qui pouvait prédire le business modèle de Facebook ? Qui pouvait prétendre anticiper les comportements des utilisateurs ? Comme disait Henri Ford : « Si j’avais demandé aux gens ce qu’ils voulaient, ils m’auraient répondu des chevaux plus rapides ».

L’innovation peut partir de deux grands axes :

  • « L’idée » : une nouvelle technologie, un nouveau produit, un concept importé de l’étranger. Un exemple est l’iPad d’Apple : il n’y avait à l’origine aucune demande des utilisateurs pour ce mélange d’un smartphone et d’un ordinateur.
  • Les besoins du marché : une évolution des attentes (sociales, politiques, environnementales…). Uber en est un cas typique : « Par une soirée enneigée de mars 2008, Travis Kalanick et Garrett Camp ont eu toutes les difficultés du monde à héler un taxi à Paris.»

Bien souvent, le problème de nos démarches de Design Thinking, c’est que l’on étudie les clients actuels de l’entreprise, que nous cherchons à résoudre les problèmes qu’ils rencontrent aujourd’hui au contact de l’entreprise, et/ou que nous cherchons des solutions avec des expertises internes à l’entreprise.

Ouvrir le champ des possibles

Ainsi, pour innover de manière plus radicale, il faut ouvrir le champ des possibles :

  • Changer le périmètre de l’étude :
    • En imaginant de potentiels nouveaux utilisateurs, segments de marchés
    • En étudiant les besoins d’un utilisateur existant, au-delà de son expérience actuelle avec l’entreprise
  • Impliquer de nouvelles expertises, de nouveaux avis.

Dans le process du design thinking, deux étapes sont clés : le cadrage de la phase d’empathie, et le recrutement des participants au design, et plus particulièrement pendant la phase d’idéation.

Concrètement la première chose à faire est de revenir aux enjeux stratégiques de l’entreprise, voici quelques exemples :

Si l’objectif pour l’entreprise est de trouver de nouveaux relais de croissance, il peut être pertinent d’aller servir de nouveaux clients : lors du cadrage de la phase d’empathie, il s’agira de mettre une emphase particulière sur les populations à étudier. Cela peut se faire en organisant une idéation spécifique à l’identification de nouveaux utilisateurs, potentiellement inconnus jusqu’ici, puis en priorisant les cibles à étudier en fonction du potentiel business.

Si l’enjeu est de se différencier par rapport à la concurrence, on peut générer plus de valeur pour les clients actuels en étudiant leurs problématiques de manière plus globale : étudier une semaine, une année type d’un client. Un autre moyen est de changer la manière dont on lui apporte de la valeur aujourd’hui : pourquoi ne pas faire travailler des experts en technologie (intelligence artificielle, blockchain, impression 3D), des partenaires, fournisseurs, ou les clients eux-mêmes, sur la résolution des problèmes identifiés ?

Et pour finir, n’oublions pas ce que nous disait Albert Einstein : « une personne qui n’a jamais commis d’erreurs n’a jamais tenté d’innover. » L’innovation est par nature incertaine, et donc risquée. Le design thinking, s’il est bien utilisé, permet de limiter ces incertitudes et ce risque, et ainsi d’innover à moindre coût.

 

https://philippesilberzahn.com/2010/01/13/opposition-radical-incremental/

https://www.uber.com/fr/our-story/

 

Arthur Duchet-Suchaux, Consultant digital

Transformation Agile : Transformational leadership versus Transactional leadership – par Thierry Ventadour

Dans un précédent article « Transformation Agile : Des pistes pour réussir le changement » je décrivais les 3 axes qui, selon moi, sont à la base d’une transformation Agile. Dans cet article, je voudrais me focaliser sur l’axe humain.

Dans la plupart des entreprises, les managers dirigent leurs équipes en se basant sur deux principes :

    1. Le « management by Objectives » : des objectifs sont fixés une fois par an, une récompense ou bonus est donné si l’objectif est atteint
    2. Un pilotage des actions réalisées par l’employé par rapport à un plan établi à l’avance. Des actions correctives étant décidées quand le réalisé s’écarte du plan.

Transformational transactional leadership
Cette forme de management à été théorisé par le « Transactional leadership ». Il est adapté lorsque l’employé évolue dans un environnement stable, ne nécessitant pas d’innovations rapides car les objectifs fixés doivent toujours avoir du sens une année après avoir été fixés, pour pouvoir être évalués. D’autre part, ce mode de management permet de limiter le turn-over quand les bonus sont donnés, l’employé prenant le risque de gagner moins en changeant d’employeur.

L’effet sur la motivation est plus complexe : le fait de ne pas recevoir son bonus démotivera durablement l’employé, alors que le fait de le recevoir le motivera sur le court terme : on se souvient bien plus longtemps des mauvaises nouvelles que des bonnes.

Ce mode de management résulte donc dans le meilleur des cas en des entreprises dans lesquelles les employés partent peu, sans être durablement motivés. Ce mode de management a donc souvent pour conséquence un manque d’engagement des salariés. Ce manque d’engagement est identifié par différentes études, comme par exemple celle réalisée par Malakoff Médéric « L’engagement des salariés au travail ne cesse de s’éroder depuis 2009 (étude) »

Un manager voulant motiver, responsabiliser ses troupes doit donc changer de méthode de management, et appliquer typiquement des principes issus du « Transformational leadership » :

  • Stimuler intellectuellement ses équipes : les pousser à acquérir de nouvelles compétences, non seulement par des formations, mais aussi en favorisant le travail en binômes, l’organisation de communautés de pratiques, la participation à des événements en dehors de l’entreprise, l’essais de nouvelles méthodes de travail, l’innovation
  • Adopter une posture de coach et de mentor : Non seulement être un manager, mais également un coach et un mentor : comprendre les forces de ses employés pour les développer et les valoriser, les faiblesses pour les combler, les envies pour faire évoluer ses employés vers de nouveaux postes, faire preuve d’empathie.
  • Apporter une vision, un but : définir le but de l’équipe mais également encourager, motiver chaque membre de l’équipe afin que chacun atteigne ses propres objectifs
  • Enfin, agir avec intégrité, authenticité : ne pas avoir de double discours, être transparent

La question ne se pose pas dans une équipe Agile, dans laquelle le « Transactional leadership » ne peut pas s’appliquer puisqu’il n’y a par nature pas de manager et donc pas de lien hiérarchique. La seule solution pour avoir une équipe motivée est de mettre en place du « Transformational leadership ». Ce type de leadership est applicable à tout membre d’une équipe Agile : chacun doit faire preuve de curiosité, d’innovation, avoir des qualités de mentor partager la vision de l’équipe et faire preuve d’intégrité, afin de faire progresser les autres membres et donc l’ensemble de l’équipe.

Du coaching est alors utile pour permettre à chacun d’améliorer son « Transformational leadership » et de s’éloigner de la culture traditionnelle « top / down » : Sur chacun des quatre axes listés précédemment, comment est-ce que je me situe et comment les personnes avec lesquelles je travaille me situent ? Que puis-je faire pour m’améliorer ?

Dans un environnement Agile, ce coaching doit se faire simultanément au niveau individuel et au niveau de l’équipe via des ateliers, citons par exemple le « Strength boat » permettant de fédérer les actions d’une équipe pour atteindre un objectif partagé, ou lors de rétrospectives afin de créer une dynamique d’amélioration continue.

Pourquoi l’identification des chaînes de valeur métier va bien au-delà d’une simple modélisation statique de processus ? par Damien Madelaine

Les transformations agiles à l’échelle s’appuient sur l’alignement, à l’échelle de toute une organisation, entre les fonctions support et le métier.modelisation agileComme illustré dans la figure ci-après :

  1. Un processus opérationnel peut être décrit sous forme d’une chaîne de valeur dont le point de départ est une demande et qui se poursuit jusqu’à la livraison de valeur au client de ce processus. Il peut regrouper métier et fonctions support (RH, finances, achats, …).
  2. Les étapes du processus peuvent s’appuyer sur des systèmes (ensemble d’outils dont IT).
  3. Enfin l’alignement plus spécifique de l’IT avec le métier consiste à mettre en face de chaque processus opérationnel le ou les processus de livraison IT faisant évoluer les systèmes à leur service. (Visualisés à travers des chaînes de valeur de développement).

alignement a l'échelle

L’expérience de mise en œuvre de plusieurs transformations agiles à l’échelle a montré que cette première étape de modélisation des chaînes de valeur, souvent négligée ou accélérée, est une étape clé pour la réussite de la transformation et sa pérennité, notamment à travers l’embarquement, autrement dit l’implication des métiers.

Cette modélisation de la chaîne de valeur s’effectue lors d’un atelier collaboratif, qui nécessite de s’assurer que :

  • Soient réunis l’ensemble des parties prenantes couvrant le processus, ou a minima un groupe représentatif.
  • Les bornes (point de départ et point d’arrivée) de la chaîne de valeur soient clairement identifiées.chaîne de valeur
  • L’atelier ne se limite pas à la modélisation de la chaîne de valeur, mais doit se prolonger par une réelle phase d’analyse du processus.
  • La chaîne de valeur doit pouvoir décrire non seulement les processus, mais aussi permettre de visualiser les parties prenantes et utilisateurs de chaque processus et/ou sous processus.

Les bénéfices d’une démarche remplissant ces 4 critères sont :

  • Prise de conscience collective et appropriation du processus dans son intégralité.
  • Identification à l’échelle globale des failles, goulots d’étranglement et des améliorations possibles du processus métier couverts ou non par des systèmes IT (par exemple, une tâche manuelle bureautique effectuée par une seule personne détentrice de la connaissance).
  • Aide à la priorisation des évolutions futures basées sur des arguments factuels et alimentant la feuille de route d’évolution de l’architecture (fonctionnelle et/ou technique). Cela peut avoir un impact sur la structuration et le séquencement de la transformation.
  • Identification des parties prenantes, des entités ou personnes à impliquer dans la mise en place du « Product Management ».
  • Identification de dépendances externes et bornes des processus mal identifiées.

Mes recommandations sont les suivantes :

  • Temporiser la suite des étapes de la transformation, le temps de lancer toutes les actions résultantes de cette première analyse, peut constituer un piège bloquant la transformation.
    Si certains leviers sont effectivement à actionner tôt sous peine d’un coût ultérieur, il convient de les séparer d’autres éléments qui pourront être actionnés plus tard dans la transformation.
  • Dans le cadre de l’amélioration continue, le processus métier modélisé doit continuer à être visualisé au fur et à mesure de ses évolutions et donner l’opportunité d’améliorations globales en évitant le piège des optimum locaux.
  • Il ne s’agit pas ici d’appliquer tel ou tel modèle cible de transformation : la valeur réside dans la réalisation d’un exercice collaboratif facilité par des coachs aux postures adaptées. Ces deux facteurs sont essentiels pour permettre aux parties prenantes de devenir ensemble les acteurs engagés de leur transformation et leur permettre de faire évoluer leurs processus. C’est le prélude à l’agilité dans les métiers et fonctions supports bien au-delà de l’IT.

Chaîne de valeur métier

Damien MADELAINE
Membre de la communauté Agile@scale d’inspearit.

Plus de détails seront disponibles dans l’approche de transformation the inspearit Agile@scale.

Comment aligner la structure organisationnelle des départements informatiques avec les chaînes de valeur et la stratégie métier afin d’optimiser la valeur délivrée ? par Stéphane Déprès

Cet article présente une démarche pour concevoir la structure organisationnelle de votre département informatique afin d’optimiser votre Time to Market sur un axe donné (ou tout autre axe d’optimisation découlant de votre stratégie métier).

Optimisation de la valeur

Il constitue mon retour d’expérience de coaching d’organisation visant à définir la structure organisationnelle informatique dans le cadre d’une transformation « d’agilité à l’échelle » impliquant 7 000 personnes !

Structure organisationnelle

Mise en œuvre dans le cadre de la définition de la structure organisationnelle des départements informatique, la démarche est sans doute en partie généralisable au reste de l’entreprise. Elle consiste à identifier dans un premier temps la macrostructure organisationnelle puis la microstructure logique et enfin d’associer les personnes aux équipes. Les chapitres suivant correspondent aux différentes étapes :

1 / Identifiez les flux de valeur opérationnels de votre entreprise et les unités organisationnelles informatique associées

Ce chapitre est dédié à l’identification des unités organisationnelles informatique. Par unité organisationnelle, j’entends un groupe de personnes dont la taille est inférieure au « nombre de Dunbar ». Ce nombre est une limite cognitive qui définit le nombre de personnes avec lesquelles une personne peut maintenir des relations sociales stables (la valeur couramment utilisée du nombre de Dunbar est de 150 personnes ; parfois le nombre de 125 est également utilisé).

Selon les organisations, leur taille et les mécanismes d’agilité à l’échelle mis en œuvre, ces unités organisationnelles peuvent s’appeler départements, divisions, services, tribus, trains, groupe produit….

La première étape est d’identifier vos flux de valeur opérationnels. C’est-à-dire, des processus métier de haut niveau, fournissant de la valeur aux clients. Le schéma ci-dessous présente un exemple simple de flux de valeur.

 

gestion patient

La règle d’or est la suivante : “Une unité organisationnelle informatique peut être basée sur un ou plusieurs flux de valeur, mais un flux de valeur ne doit pas traverser plusieurs unités organisationnelles“.

Ainsi, étant donné qu’une modification du ou des systèmes supportant le flux de valeur est gérée dans une seule unité organisationnelle, les mécanismes de synchronisation à mettre en œuvre sont plus simples ce qui conduit à un meilleur délai de mise sur le marché.

flux de valeur

Mais que se passe-t-il si plusieurs flux de valeur traversent certains composants centraux de taille importante tels que des entrepôts de données ou des référentiels (ces composants pouvant nécessiter plusieurs centaines de personnes à maintenir) ? Devez-vous intégrer des tranches d’entrepôt de données dans chaque unité organisationnelle ou bien conserver les entrepôts de données dans une unité organisationnelle dédiée ? Dans le premier cas, vous optimisez le temps de mise sur le marché et dans le second cas vous optimisez la cohérence et le coût. C’est donc à vous de choisir la meilleure solution en gardant à l’esprit les avantages et les inconvénients de chaque scénario.

A noter que cet article ne traite pas de la conception des départements transversaux qui peuvent être nécessaires.

 2 / Identifier les équipes constituantes de chaque unité organisationnelle.

Nous allons maintenant plonger dans la conception de chaque unité organisationnelle et réfléchir à la manière de la diviser en équipes et si possible en « feature teams ».

Mais définissons d’abord ce qu’est une feature team : c’est un groupe pérenne de 5 à 9 personnes, responsable d’un périmètre fonctionnel, colocalisé, polyvalent et autonome sur son périmètre fonctionnel.

Mais pourquoi organiser votre unité organisationnelle en feature teams ? Parce qu’elles sont alignées sur les flux de valeur et permettent donc de développer une fonctionnalité potentiellement multi-applications à vitesse optimale.

De plus, contrairement à une équipe dédiée à un projet, les feature teams sont pérennes ce qui permet de capitaliser sur les compétences et les connaissances de l’équipe.

Le premier axe de découpage de votre unité organisationnelle en feature teams doit être a priori basé sur vos flux de valeur afin d’optimiser le temps de mise sur le marché.

Mais il faut souvent envisager un deuxième axe de découpage lorsque le flux de valeur correspond à la taille de plusieurs feature teams. Une solution optimale serait que les équipes soient interchangeables sans spécialisation particulière, permettant, à l’aide des mécanismes de synchronisation d’agilité à l’échelle une allocation dynamique des features aux différentes feature teams. En pratique, cela n’est pas aussi simple que cela en raison des spécialisations fonctionnelles et techniques.

Ceci dit, il faut souvent trouver un compromis : si votre axe de découpage conduit à une feature team avec un périmètre trop étroit le long d’un flux de valeur, la feature team devra sans doute gérer un trop grand nombre d’applications, conduisant au moins temporairement à des silos de spécialisation au sein des équipes ; ce qui n’est pas une bonne chose. Une alternative est d’avoir un groupe de feature teams sur un périmètre moins étroit mais avec des mécanismes de synchronisation d’agilité à l’échelle : il y aura moins de silos de spécialisation et le temps de mise sur le marché restera encore bon grâce aux mécanismes d’agilité à l’échelle (qui permettront aux équipes de se coordonner pour le développement des features multi-équipes).

Avant de travailler sur les différents scénarios de découpage, je vous recommande fortement de prendre connaissance de la stratégie métier, d’identifier les attentes du métier vis-à-vis de la transformation et de les hiérarchiser avec le métier.

Par exemple, j’ai récemment organisé un atelier sur ce sujet avec le métier d’une unité organisationnelle et les résultats ont été les suivants :

  • Pour certains types de fonctionnalités, il était préférable d’optimiser le délai de mise sur le marché le long des flux de valeur (afin qu’une fonctionnalité traversant plusieurs activités du flux de valeur soit développée au plus vite)
  • Pour d’autres types de fonctionnalités, il était préférable d’optimiser le délai de mise sur le marché par activité du processus métier. En effet les fonctionnalités de ce type correspondaient principalement à une seule activité du flux de valeur et la probabilité qu’elles aient des impacts sur des fonctionnalités d’autres activités du flux de valeur était faible. Cela m’a donné une première stratégie de découpage.

Un autre point important est d’identifier les contraintes :

  • Celles liées à la localisation des membres de l’organisation unit
  • Celles liées à la spécialisation technique et fonctionnelle des membres de l’organisation unit

Après avoir identifié la stratégie métier et les contraintes, vous devez identifier les différents axes de découpage par flux de valeur (seulement si ce flux implique plusieurs équipes) : par exemple, un axe de découpage peut être par client, par groupe de types de fonctionnalité, par objet métier, etc …

Un autre axe peut être obtenu en analysant l’urbanisation IT. Si deux systèmes informatiques sont faiblement couplés alors il est préférable de dédier chaque système à des équipes distinctes. Si vous prenez un autre axe de découpage, la loi de Conway peut jouer contre vous. En effet l’architecture du Système d’Information étant influencée par la précédente structure organisationnelle, le changement de structure organisationnelle risque d’engendrer un couplage plus fort entre les équipes.

Vous devez également faire attention au fait que l’axe de découpage conduise à des features teams avec une distribution constante du flux de demandes afin que la feature team ne soit pas régulièrement en sur ou sous capacité. Cela signifie que vous devez également prendre en compte la stratégie métier et sa possible évolution.

axe de découpage

Comme vous le voyez, les paramètres sont nombreux et trouver la meilleure solution n’est pas toujours évident. Je vous recommande donc fortement de formaliser chaque scénario incluant, pour chacun, les avantages et les inconvénients.

Dans le cas de mon exemple où une unité d’organisation correspond à l’entrepôt de données, nous avons identifié deux axes possibles de découpage :

  • Soit par ligne métier,
  • Soit par type de données.

Dans le premier cas, vous optimisez le temps de mise sur le marché. Dans le second, vous optimisez la cohérence et le coût mais l’inconvénient est que les Product Owners doivent gérer les priorités entre plusieurs lignes métier.

Je vous recommande également fortement d’impliquer toutes les parties prenantes et si possible tous les membres de l’unité d’organisation pour sélectionner le meilleur des scénarios. Cela comporte de nombreux avantages. Premièrement, ceux-ci peuvent identifier des avantages, inconvénients ou contraintes qui n’avaient pas été identifiés. Mais surtout, le fait d’impliquer une personne est bénéfique du point de vue de la conduite du changement car la personne se sent acteur de la transformation ce qui apporte de la motivation intrinsèque.

L’axe de découpage sélectionné permet d’identifier les « feature teams » ou les groupes de « feature teams ». À ce stade, les « feature teams » doivent être logiques sans ses membres nominativement affectés. Cela évite les pressions politiques et personnelles.

3 / Associer les membres de l’équipe aux « feature teams »

L’étape suivante consiste à associer les membres de l’équipe aux feature teams. Je recommande pour ce faire d’organiser un atelier dans lequel chaque membre de l’unité d’organisation sélectionne sa propre équipe. Au cours de cet atelier, les Product Owners / Scrum Masters / Managers doivent présenter chaque « feature teams », décrire leur périmètre, leur taille et les compétences requises. J’ai récemment animé un tel atelier et ce fut un grand succès !

feature teams

Stéphane Déprès
Membre de la communauté Agile@scale inspearit (communauté concevant une démarche de transformation agile à l’échelle)
Traduction française par Franck Arsene et Stéphane Déprès —

Nos 5 conseils pour vous lancer dans l’agilité à l’échelle

par la communauté d’experts inspearit

Avec la technologie, tout peut aller très vite. Une innovation mal négociée et tout peut basculer en quelques mois. Dans la banque, l’énergie et les transports notamment, la menace est chaque jour plus précise. Pour pouvoir affronter les nouveaux entrants sur leur terrain de l’innovation, les acteurs traditionnels sont d’urgence sommés de se réorganiser. Car, pour l’heure, la plupart des grandes entreprises ne sont pas en mesure de relever le défi.

5 conseils lancer agilité à l'échelle

L’agile n’est pas qu’un ensemble de méthodes réservées aux développeurs. C’est une approche de l’organisation et des processus de développement qui permet de casser les barrières – organisationnelles, géographiques, culturelles, métiers, fonctions … – qui grippent les collaborations indispensables pour innover efficacement. En mettant en place des organisations plus transversales, plus ouvertes et collaboratives, l’agile permet de (re)faire travailler ensemble des gens de points de vue différents, de (re)donner une vision d’ensemble aux collaborateurs, et de (re)mettre de la fluidité et de la réactivité.

1 – regarder loin

Pour une petite équipe projet, l’agile peut sembler une approche originale, mais pleine de bon sens et assez facile à mettre en œuvre. Mais à l’échelle d’une organisation, il en va tout autrement. Comment gérer les problématiques transversales ? L’architecture ? La sécurité ? Les budgets ? Les difficultés que l’on rencontre lors des transformations agiles proviennent rarement des équipes de développement elles-mêmes, plutôt réceptives à une approche qu’elles jugent valorisante, mais de frictions mal anticipées à la périphérie.

2 – mettre l’accent sur la conduite du changement

Pour les équipes, l’agile est une façon radicalement nouvelle de travailler. Pour certains, cela signifie désapprendre des années d’habitudes, ce qui n’est pas une mince affaire. Pour accompagner un tel bouleversement culturel, il faut mettre un accent très fort sur la conduite du changement, bien au-delà de quelques sessions de formation. Les collaborateurs doivent être associés au changement, le co-construire et en devenir partie-prenante, de manière à se l’approprier.

3 – repositionner les managers

Dans la structure hiérarchisée traditionnelle française, les managers tirent souvent leur autorité et leur légitimité de l’expertise technique qui leur a permis de gravir les échelons. Fréquemment en déficit de « soft skills », ils ne tirent pas toujours le meilleur de leurs équipes, voire en précipitent la démotivation par des attitudes autoritaires et autocratiques. Dans l’organisation agile, un manager doit donc apprendre à déléguer, à accompagner des équipes pluridisciplinaires, à fixer un cap plutôt qu’à décider de tous les détails, à être un arbitre plutôt qu’un chef.

4 – impliquer les RH

Pour les collaborateurs, l’agile est une révolution, mais aussi une source d’opportunités. Soudain, on sollicite de leur part de nouvelles compétences (soft skills, initiative, créativité…), ce qui suscite souvent beaucoup d’attentes chez ceux qui en font preuve. Pour amplifier et prolonger cette dynamique, les Ressources humaines ont, dans une période où attirer et conserver les talents devient un enjeu crucial, un rôle clé qui reste encore à préciser.

5 – adopter SAFe Scaled Agile Framework (SAFe®)

Le rapport Version One, vaste enquête planétaire de la progression de l’agilité dans les entreprises, dans sa dernière version montre que ce référentiel est maintenant adopté dans 29% des transformations agile à l’échelle, loin devant toutes les autres méthodologies.

SAFe synchronise l’alignement, la collaboration, et les livraisons d’équipes agiles multiples. Ce corpus de bonnes pratiques permet à une organisation de coller au plus près à ses exigences business. Enrichi progressivement par de nombreux retours d’expériences, SAFe 4ème version, crée un véritable lien avec la stratégie de l’entreprise qui déploie l’agilité à l’échelle au travers de principes de pilotage par la valeur.

 

Afin d’aller plus loin, nous proposons des formations SAFe. N’hésitez pas à visiter inspearit Academy

 

 

Le Chief Happiness Officer, un catalyseur pour les organisations ? par Thu-Thuy Trinh

Pour les entreprises, attirer les meilleurs talents, les retenir et de les placer dans les meilleures conditions pour qu’ils expriment tout leur potentiel sera l’enjeu crucial des années à venir. Mais comment développer et entretenir une culture partagée dans les organisations ?

CHO catalyseur pour les organisations

Apparue dans les start-up californiennes, la fonction de Chief Happiness Officer (CHO) gagne peu à peu tous types d’entreprises qui constatent en leur sein un même manque de liant, de cohésion et de qualité de vie. Les cabinets de conseil sont un exemple de ces organisations où le nomadisme, la pluridisciplinarité et le fonctionnement par projets ont pour contrepartie l’affaiblissement de la culture commune. Or, le sentiment d’appartenance né de l’expérience collective est le fondement de la loyauté et de l’engagement des collaborateurs. Ne pas leur offrir un environnement épanouissant, c’est risquer la démotivation, voire la désinvolture et, finalement, la fuite des cerveaux et de ce qu’ils contiennent. Face à des turnovers à deux chiffres, le bien-être au travail, loin d’une question accessoire, constitue un véritable levier de performance.

La mission du CHO est par conséquent de créer au sein de l’organisation des liens qui la renforceront. Son action se déploie sur trois axes principaux : créer de la cohésion entre les collaborateurs, développer et promouvoir la marque employeur, et faciliter la communication verticale.

 

Disposant de toute latitude dès lors que ses initiatives respectent la stratégie et les valeurs de l’entreprise, il dispose de deux outils principaux, efficaces et peu coûteux : l’événementiel et le digital. Grâce à des événements thématiques, des rendez-vous réguliers, des incitations à se rencontrer, il va à la fois créer de l’animation, et favoriser les rencontres et les échanges. Son maître-mot doit être la créativité car il lui faut parvenir à renouveler sans cesse l’intérêt et à toucher de nouvelles populations. Il peut par exemple prolonger de manière plus conviviale ou inspirante des événements existants, ou activer le ressort puissant de la gamification pour stimuler la participation. La création et l’animation de communautés digitales internes répondront aux mêmes logiques, sans toutefois pouvoir se substituer aux rencontres réelles.

 

À l’occasion de ces événements et de ses rencontres individuelles, le CHO va glaner énormément d’informations. Cela lui fournira une précieuse matière première pour communiquer et valoriser la marque employeur, mais ces informations lui permettront aussi de déceler toutes sortes de besoins collectifs ou individuels. Il doit aussitôt rebondir, soit en se proposant de résoudre lui-même le problème, soit en usant de ses contacts privilégiés au sein de l’organisation pour transmettre l’information à la bonne personne, y compris jusqu’à la direction générale qu’il rencontre régulièrement. Dans beaucoup d’entreprises, les collaborateurs déplorent en effet l’éloignement de la direction et sa méconnaissance de la réalité du terrain. En complément des voies hiérarchiques, le CHO offre un canal de communication informel qui permet à la direction de prendre le pouls de l’entreprise et, par exemple, de prendre conscience de l’importance de certaines préoccupations quotidiennes.

 

C’est en jouant ce rôle de médiateur et de facilitateur, en étant toujours disposé à apporter son aide, mais aussi en expliquant inlassablement son rôle et en tissant lui-même des liens personnels avec les collaborateurs que le CHO démontre son utilité et gagne sa légitimité. Il est confiant dans son importance et respecté de tous car chacun, quel que soit son rang, sait qu’il pourra faire appel à lui. Pour autant, aucune tâche ne lui paraît ni trop minime ni trop ingrate si elle contribue à éliminer les grains de sable qui finissent par gripper les rouages de l’entreprise. Factotum au service de tous mais ne dépendant de personne, le CHO est un électron libre qui navigue entre les lignes de l’organisation, au croisement de la communication interne, de la communication externe, des ressources humaines et des services généraux. Cette indépendance et cette transversalité justifient d’ailleurs que son rôle ne puisse être rempli par l’une de ces fonctions traditionnelles. En revanche, pour créer une culture d’entreprise forte, il a besoin dans son action de l’étroite coopération de ces fonctions support.

 

Autonome, dynamique, constructif, bienveillant, le CHO se distingue avant tout par son savoir-être au service des autres qui lui permet non seulement de consolider jour après jour la culture de l’entreprise mais aussi, très vite, de l’incarner. Fonction créée pour combler le déficit humain des organisations modernes, le CHO ne peut dès lors exister que dans la durée car, sans son inépuisable activité, tout ce qu’il aura créé risque de se dissiper.

 

Article paru dans le Journal du net (juillet 2018)

Does Agile Kills innovation?

During a recent conversation with a journalist, the downsides of agile came up in the interview. The questions were centered around stress levels of team members, the frustration with not being able to do a proper design before building features, the perceived reduction in innovation and other factors. During the discussion I realized that there still are many people that seem to have missed an important aspect of agile: the transition of tasks from being implicitly performed to explicitly scheduled.

Does Agile kill Innovation?

When companies employ more traditional, waterfall style approaches, there typically is a certain amount of slack in the weeks after a release. Of course, there are issues from the field that need to be resolved and some are busy with that, but a significant number of people has time for activities that we didn’t get around to when pushing out the release. These activities include managing technical debt, experimenting with new, innovative ways of doing things in the system, becoming familiar with potentially relevant new technologies, trying out new product or feature ideas, etc.

The interesting thing is that these activities occur organically and provide a valuable source for innovation, both customer- and technology-driven, as well as a natural way to manage maintainability of the system by paying off technical debt. However, as these activities occur organically, are implicit and consequently not actively managed, the company learns to rely on these activities taking place.

When adopting agile, the structure of sprints causes a situation where teams are constantly driving for feature development. Well functioning teams want to do right by the company, which means that if teams are asked to build features prioritized in a seemingly infinite backlog then teams will do so. The process of sprint planning provides a much higher degree of transparency in resource allocation and, as a consequence, there is no slack in the system. As soon as the sprint is over, the next one starts.

The consequence of the lack of slack is that the company needs to explicitly allocate resources to activities that used to take place implicitly and organically before the adoption of agile. This means that if you want to have a maintainable system over time, resources need to be explicitly allocated to managing technical debt. If the company is relying on a constant flow of bottom-up innovations from its R&D staff, then time for innovation activities needs to be explicitly scheduled.

Once leaders in the company realize the need to explicitly schedule time for results that used to come “for free”, this typically leads to a situation where the relationship between R&D and the rest of the company is made explicit. In those organizations that view R&D just as a supplier from which you order features, the willingness to provide time for managing technical debt or for innovation is typically non-existent. In those companies where there is a true partnership between R&D and the rest of the company, this leads a situation where explicit resourcing decisions are taken not just concerning feature and product development, but also around quality, technical debt and innovation activities.

Concluding, agile does not kill innovation, but as with many other aspects of software intensive businesses, agile makes the problems so blatantly visible and explicit that the organization has no choice but to address these concerns. There is no such thing as a free lunch! Quality, maintainability and innovation all require resources and not allocating these resources will give you exactly what you asked for.

Follow me on  janbosch.com/blog, LinkedIn (linkedin.com/in/janbosch) or Twitter (@JanBosch).
And you might like www.software-center.se!