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.