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)


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, LinkedIn ( or Twitter (@JanBosch).
And you might like!

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.


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

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
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.


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.


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

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 —