ORG TOPOLOGIES 

Contexte du cas d'usage J'ai eu la chance de participer début mars 2024 à la toute première formation  OrgTopologies  en France avec les deux co-créateurs  Alexey Krivitsky 🌈  et  Roland Flemm   Carte OrgTopologies Comme souvent, les idées s'évaporent après les formations. Or j'ai eu l'opportunité d'utiliser ce bel outil seulement trois semaines plus tard, à l'occasion d'un atelier avec un groupe de personnes travaillant sur le système d'information d'un domaine bancaire. Le périmètre de ce domaine étant celui de la tenue de compte et de la gestion des différents moyens de paiement (SEPA ; IP ; Virement Gros Montants...). Les personnes du domaine regroupent différentes expertises assez classiques telles que Business Analyse ; programmation dans différents langages ; Ops. Les expertises sont parfois dans la même équipe, parfois dans des équipes distinctes. Mise en scène Avant l'atelier, la demande des commanditaires portait sur l'identification de piste pour "être plus agile". J'ai partagé avec eux que de gagner en fluidité et gagner en capacité à changer de priorité était une manière de qualifier et quantifier le fait "d'être plus agile". J'ai débuté l'atelier en racontant l'histoire d'une startup que je connais dans l'archétype C3, qui a été lancé en 2013 par ses deux fondateurs, lesquels faisaient absolument tout pour leurs premiers clients. En grossissant, la startup a changé de structure et s'est retrouvée avec plusieurs équipes spécialisées, perdant la vision globale du produit et la fluidité initiale. Pour illustrer l'archétype Y0, j'ai évoqué la caricature de l'expert en sécurité qui interdit tout à tout le monde. Ensuite, j'ai proposé aux participants de cartographier leurs équipes actuelles dans un premier temps, en travaillant par groupe afin de partager leur point de vue sur la place des différentes équipes. Pour ce faire, j'ai expliquer assez brièvement un premier niveau de lecture avec une carte 2x2 (no-team / team et livrables / bénéfices) et ensuite je suis allé dans un niveau de détail plus fin avec la carte des 16 archétypes dans une matrice 4x4. Map OrgTopologies d'exemple vierge Les personnes présentes étant les managers seuls. Les Développeurs n'étaient pas présents. Aussi, nous avons clarifier l'objectif qui était de faire émerger des idées d'amélioration. Beaucoup de personnes étant absentes, je ne souhaitais pas que les participants s'engagent sur des plans d'action impliquant les absents. Cartographie en sous-groupe Les sous-groupes ont apporté des questions subtiles sur la finesse du grain des "Produits". D'un côté, parler de "Produits" trop petits (Transfert SEPA ; Transfert IP ; Transfert Gros Montants...) conduit à de l'optimisation très locale ; fait perdre de vue la vision globale ; amène à l'accumulation de listes de travaux, de files d'attente, de besoin de couche de coordination et d'arbitrage de priorités... Et de l'autre, parler de "Produits" trop gros (la Banque) devient trop abstrait et fait perdre pied avec la réalité des collaborateurs. J'ai choisi de les laisser régler eux-mêmes leur curseur de lecture de la cartographie afin de favoriser leur engagement dans l'atelier, plutôt que de rentrer dans une posture de "formateur", ce qui n'était pas à l'ordre du jour. De ce fait, plusieurs tickets ont été placé au niveau B (équipe d'équipes ou méta-équipe, multi-fonctionnelles et multi-technologies) alors qu'il aurait probablement été plus judicieux de les placé au niveau A (groupe d'équipes plus ou moins focalisées sur des fonctionnalités et des domaines fonctionnels distincts). D'autres débats ont émergé autour des frontières entre les colonnes 1 et 2 voire 3. Je les ai orienté vers les archétypes "bas" afin de garder les options d'amélioration plus visibles. Cartographie actuelle Les groupes ont placé leurs tickets sur le tableau partagé, et discuté pour s'aligner sur leurs points de vue. J'ai lancé quelques débats autour de certaines équipes identifiées A1 ou A2 ; B2 ou C2, mais j'ai décidé de ne pas gaspiller notre temps sur des détails peu importants pour ce tout premier atelier. Les participants ont apprécié cette représentation graphique même s'ils n'ont pas fait de grandes découvertes car la carte était déjà partiellement dans leurs têtes. Ensuite, nous avons dessiné des lignes afin de clarifier les interactions entre les différentes équipes, ce qui sera précieux pour l'émergence d'idée qui suivra. Liens entre les équipes A partir de ces tickets et des liens, les participants ont ensuite échangé sur leurs options d'amélioration et de restructuration des équipes afin de progresser vers les archétypes de plus hauts niveaux, vers la droite et le haut de la cartographie. On peut observer ici le regroupement de trois équipes ensembles (Business Analysts + Programmeurs + Ops), trois fois, ainsi que l'éclatement d'une équipe Ops pour partager rapidement son expertise. A terme, cela devrait donner lieu à la création d'équipe d'équipes pluri-fonctionnelles et pluri-technologies ayant des périmètres de responsabilités et d'autonomie plus vastes qu'initialement. Carte finale OrgTopologies Je n'ai révélé mon tour de magicien qu'à la fin de l'atelier, en ne mentionnant qu'à ce moment là que j'avais utilisé la cartographie  OrgTopologies . Pour terminer l'atelier, j'ai proposé quelques questions de réflexion, avec un tour de table pour que chacun puisse confortablement s'exprimer : qu'est-ce que l'atelier m'a révélé ? qu'ai-je appris ? Sachant que de nombreuses personnes sont absentes, quel peut être MA prochaine action (leur parler de la carte ; refaire un atelier similaire dans quelques mois) ? Comment je me sens maintenant (plutôt confiant ; curieux...) ? Conclusion Avec ce matériel produit,  Roland Flemm  m'a aidé par la suite à clarifier plusieurs points en lien avec la carte qui a émergé de l'atelier, ce qui m'a permis de mieux comprendre la carte pour des ateliers futurs. Nous avons amorcé un mouvement avec un atelier assez simple grâce à la cartographie. Il nous reste à entretenir cet élan et à accompagner les équipes à monter vers ces archétypes de plus hauts niveaux. Et vous, dans quel contexte pourriez vous utiliser cette cartographie ?

Une organisation choisie ou subie ? Toute entreprise a une organisation (structure) qui a tendance à guider les interactions entre ses membres. Ces mêmes interactions font circuler de l’information et orientent le travail effectué. La définition, la mise en place et le maintien de l'organisation dans le temps peut être contrôlé par sa tête mais également évoluer de manière organique et décentralisée avec les années au sein de grosses structures. Quelle que soit la manière dont cette organisation évolue, elle aura toujours un effet sur la circulation de l'information et des travaux. Cet effet sur la capacité organisationnelle est alors non négligeable. Si cette organisation est importante, il convient alors de ne pas la subir et d'effectuer des choix pour mettre la structure dans de bonnes dispositions pour parvenir à ses fins. Tout comme les formations des légions romaines, les tactiques des équipes de sports collectifs ou les formations aériennes de l'armée de l'air, agencer différemment les mêmes unités permet de faire face à des situations différentes. Photographie d'une formation aérienne, schéma d'une formation d'équipe de football et extrait d'une reproduction d'une formation de légionnaires romains Dès lors, il vient la question suivante : mais quelle organisation adopter ? Pas de bon choix sans objectif #StartWithWhy Afin de trouver une organisation pertinente, il est nécessaire de connaître le but qui souhaite être atteint par le système que l'on souhaite réorganiser. Plus de rapidité à livrer ? Plus d'apprentissage ? Une plus grande richesse d'opinions ? Une réduction des coûts ? Quelle que soit la motivation ou l'objectif à l'origine d'un changement d'organisation, il est primordial de le formaliser puisque c'est cet élément qui permet de guider les choix d'organisation par la suite. Dans notre exemple, nous choisissons  une réduction du Time-to-market. Mais comment Org Topologies™ peut contribuer à cela ? Org Topologies™ offre un outillage léger pour cartographier et évaluer son organisation afin d'envisager la direction souhaitée des modifications organisationnelles. C'est tout simplement un outil de réflexion pour faire un pas dans le design organisationnel.  L'outil clé d'Org Topologies™ est une carte bi-dimensionnelle avec une dimension représentant l' étendue des capacités  et une seconde représentant le  périmètre d'activité. Les deux dimensions de la carte Org Topologies™  En simplifiant la matrice 4x4 en matrice 2x2, on facilite l'entrée en matière  Visualisation de la simplification Etat des lieux : où en sommes nous aujourd'hui ? Avant de déterminer un chemin d'amélioration, il est nécessaire de dresser une représentation fidèle de l'organisation telle qu'elle est au démarrage des réflexions. Pour cela, nous pouvons utiliser la carte d'Org Topologies™.  Vous retrouvez dans l'image ci-dessous l'exemple de l'organisation autour d'un produit. Cet exemple est un cas hypothétique basé sur des cas que j'observe sur le terrain. Exemple de cartographie avec la carte d'Org Topologies™ Selon la matrice simplifiée (2x2), nos équipes se répartissent comme suit : FLOW-BÉNÉFICES  : --- RESSOURCES-BÉNÉFICES  : Architecte, groupe métier RESSOURCES-LIVRABLES  : Groupe d'analystes, production FLOW-LIVRABLES  : "Équipe Scrum" incomplète Notons ici que pour des raisons de simplicité, il n'y a qu'une seule "équipe Scrum". Cela peut correspondre au développement d'un petit produit. Dans le cas où il y aurait plusieurs "équipes Scrum", il serait possible qu'elles ne soit pas toutes placcées au même endroit de la carte.  (J'utilise des guillemets autour d'équipe Scrum car ces équipes ne sont pas réellement pluridisciplinaires) Envisager des adaptations d'organisation Une fois l'état des lieux réalisé, il est possible d'envisager des modifications. Dans notre cas, nous voulons réduire notre  Time-to-market . Actuellement, il y a de l'attente entre le groupe d'analyses, "l'équipe Scrum" et la production. Nous faisons l'hypothèse que rassembler ces personnes en une seule et même équipe permettra d'accélérer la chaîne et donc le  Time-to-market . Après cette modification, nous avons une équipe Scrum qui dispose de toutes les compétences pour aller de l'analyse jusqu'à la mise en production. Cette équipe passe donc en A3 : Unité à débit rapide avec un focus fonctionnalités. On peut se demander pourquoi cette équipe Scrum ne passe pas au niveau  B3 . La raison est que le Product Owner de cette équipe n'est pas investi au niveau du domaine d'activité pour le moment. Le groupe métier qui est en  B1 , réalise un travail préparatoire qui fait que dans ce cas, le Product Owner n'a pas la responsabilité.  Exemple de modification possible visant à améliorer le Time-to-market. Mesurer l’efficacité de sa formation vis-à-vis de l’objectif Comme tout changement dans un environnement humain présente un haut niveau d’incertitude, il est judicieux d’évaluer a postériori l’effet des modifications effectuées dans l’organisation. Premièrement, il est incontournable de mesurer l'indicateur que l'on vise à améliorer avec nos changements organisationnels pour voir à quel point les modifications ont été pertinentes. Si ce premier indicateur à mesurer peut paraître évident, j'aimerais également souligner l'importance de mesurer d'autres indicateurs pour évaluer des effets imprévus à l'origine. Dans notre exemple, nous voulions réduire le  Time-to-market . En le mesurant avant modification puis un mois après la modification d'organisation, nous nous apercevons que nous l'avons réduit de 20%, génial ! Par contre, qu'en est-il de la qualité des livrables, de la valeur apportée, de la satisfaction des collaborateurs ? Notre organisation est un système complexe, (présentant beaucoup d'incertitude) ce qui signifie qu'il est difficile (impossible, en réalité) de prévoir les conséquences d'une action, aussi bonne soit l'intention de départ. Pour trouver l'équilibre entre les différents indicateurs, utiliser le cadre Evidence-Based Management (EBM) de  Scrum.org , peut être judicieux pour s'astreindre à une rigueur d'expérimentation ainsi qu'à une balance entre indicateurs de valeur et indicateurs de capacité organisationnelle.  En se référant à EBM, on divisera donc nos indicateurs en deux grandes catégories, elles-mêmes découpées en deux sous-catégories, appellées domaines de valeur clés (KVA) : Valeur marchande :  Valeur actuelle  (CV),  Valeur non-réalisée  (UV) Capacité organisationnelle :  Capacité à innover  (A2I),  Time-to-market  (T2M) Donc, dans notre cas, Le  Time-to market  est sous les projecteurs. On peut par exemple suivre le Lead Time ou le Mean time to Restore (tiré des métriques DORA). Pour assurer l'équilibre, il nous faut alors des mesures dans les autres domaines de valeur clés comme par exemple : la satisfaction utilisateur pour la  Valeur actuelle les parts de marché potentielles pour la  Valeur non-réalisée la tendance des bugs pour la  Capacité à innover L'utilisation d'Org Topologies™ couplée à EBM fera sûrement l'objet d'un prochain article. Il est important de noter qu'en fonction des modifications effectuées, les effets peuvent mettre plus ou moins de temps et être plus ou moins difficiles à observer. Conclusion Il est judicieux d'adapter l'organisation de son entreprise, de sa business unit, d'un ensemble d'équipes développant un produit pour atteindre au mieux ses objectifs. Pour faire cela, Org Topologies™ offre un outil intéressant pour faire l'état des lieux et esquisser les changements envisager pour atteindre son objectif. C'est alors l'expérimentation et la mesure régulière de la performance de l'organisation qui permet de naviguer dans l'incertitude, avec la carte d'Org Topologies™ pour dessiner ses expériences et des indicateurs pour assurer la tenue du cap. Toutes les étapes présentées plus tôt peuvent se réaliser avec différentes populations. Il y a un monde entre faire cet exercice seul en chambre ou le faire en présence de l'ensemble des personnes présentes dans le dispositif étudié. Aucun de ces deux extrêmes ne me semble pertinent. Pour sélectionner les personnes, je vous invite à avoir à la fois des personnes dans les archétypes les plus bas (Y & A) ainsi que dans les archétypes les plus haut (B & C) afin de croiser les perspectives qui peuvent être bien différentes.

A chosen or imposed organization? Every company has an organization (structure) that tends to guide the interactions between its members. These same interactions circulate information and guide the work performed. The definition, implementation and maintenance of the organization over time can be controlled by its head, but can also evolve organically and decentralized over the years within large structures. Whichever way this organization evolves, it will always have an effect on the flow of information and work. This effect on organizational capacity is therefore not negligible. If this organization is important, then it's important not to suffer from it, and to make choices that put the structure in a good position to achieve its goals. Just like the formations of the Roman legions, the tactics of team sports teams or the air formations of the French air force, arranging the same units differently enables us to deal with different situations. Photograph of an aerial formation, diagram of a soccer team formation and extract from a reproduction of a Roman legionary formation. The question then arises: what kind of organization should we adopt? No good choice without a goal #StartWithWhy To find the right organization, you need to know what you want to achieve with the system you want to reorganize. Faster delivery? More learning? A greater wealth of opinions? Lower costs? Whatever the motivation or objective behind an organizational change, it's vital to formalize it, since it's this element that will guide subsequent organizational choices. In our example, we have chosen to reduce time-to-market . But how can Org Topologies™ contribute to this? Org Topologies™ offers a lightweight tool for mapping and evaluating one's organization in order to envision the desired direction of organizational change. Quite simply, it's a thinking tool for taking a step into organizational design. The key tool in Org Topologies™ is a two-dimensional map with one dimension representing the scope of capabilities and a second representing the scope of work . The two dimensions of the Org Topologies™ map Simplifying the 4x4 matrix into a 2x2 matrix makes it easier to get started: Simplified visualization Where do we stand today? Before determining an improvement path, it is necessary to draw up a faithful representation of the organization as it is at the start of the reflections. For this, we can use the Org Topologies™ map. In the image below, you can see an example of our organization for which we want to accelerate time-to-market. This example is a hypothetical case based on multiple cases I've observed in the field. Mapping example with Org's Topologies™ map Note that for simplicity's sake, there is only one "Scrum team". This may correspond to the development of a small product. If there are several "Scrum teams", they may not all be placed in the same place on the map. (I use quotation marks around Scrum team because these teams are not really fully multidisciplinary). Consider organizational adaptations Once we've assessed the situation, it's time to make some changes. In our case, we want to reduce our time-to-market. At present, there is a backlog between the analysis group, the "Scrum team" and production. We hypothesize that bringing these people together into a single team will speed up the chain, and therefore time-to-market. After this modification, we have a Scrum team with all the skills needed to go from analysis to production. This team has therefore been upgraded to A3 : Rapid throughput unit with a focus on functionalities. One might ask why this Scrum team isn't moving up to B3 . The reason is that the Product Owner of this team is not invested in the business area at the moment. The business group, which is in B1 , is carrying out preparatory work, which means that in this case, the Product Owner does not have responsibility for the business area. Example of a possible modification to improve time-to-market. Measure the effectiveness of your change in relation to the objective Since any change in a human environment involves a high degree of uncertainty, it makes sense to evaluate the effect of changes made in the organization a posteriori. Firstly, it's essential to measure the indicator we're aiming to improve with our organizational changes to see how relevant the modifications have been. While this first indicator to be measured may seem obvious, I'd also like to stress the importance of measuring other indicators to assess effects that were originally unforeseen. In our example, we wanted to reduce time-to-market. By measuring it before and one month after the organizational change, we found that we had reduced it by 20% - brilliant! But what about the quality of deliverables, the value provided, employee satisfaction? Our organization is a complex system (with a lot of uncertainty), which means that it's difficult (impossible, in fact) to predict the consequences of any action, no matter how well-intentioned. To strike a balance between the various indicators, using Scrum.org's Evidence-Based Management (EBM) framework can be a good way to ensure rigorous experimentation and a balance between value indicators and organizational capacity indicators. Referring to EBM, we will divide our indicators into two main categories, themselves divided into two sub-categories, called key value areas (KVA): Market value: Current value (CV), Unrealized value (UV) Organizational capacity: Ability to innovate (A2I), Time-to-market (T2M) So, in our case, Time-to-market is in the spotlight. We can, for example, track Lead Time or Mean time to Restore (taken from DORA metrics). To ensure balance, we then need measures in other key value areas such as : user satisfaction for Present Value potential market share for Unrealized Value bug trends for Capacity for Innovation The use of Org Topologies™ coupled with EBM will surely be the subject of a future article. It's important to note that, depending on the modifications made, the effects may take longer or be more or less difficult to observe. Conclusion It's a good idea to adapt the organization of your company, your business unit, a group of teams developing a product, to best achieve your objectives. Org Topologies™ offers an interesting tool for assessing the situation and outlining the changes needed to achieve your objectives. It's then experimentation and regular measurement of organizational performance that makes it possible to navigate uncertainty, with the Org Topologies™ map to draw one's experiences. All the steps presented earlier can be carried out with different populations. There's a world of difference between doing this exercise alone in a room, or doing it in the presence of all the people present in the device under study. Neither extreme seems relevant to me. To select the people, I suggest you have both people in the lowest archetypes (Y & A) as well as in the highest archetypes (B & C), in order to cross the perspectives, which can be quite different. This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.

This video features Mauro Sacchi discussing a significant change initiative within his company. The focus is on transitioning product development to be more aligned with business objectives and customer value. The Org Topologies mapping method is used as a tool to visualize and guide this organizational transformation. Company and Product Context: The company is a large, 190-year-old multinational corporation operating in the maritime and energy sectors, transforming energy into power [ 03:09 , 03:47 ]. It heavily invests in R&D, viewing itself as an innovator [ 08:00 ]. Their digital products are integrated into their lifecycle business, primarily related to engine technology [ 07:20 ]. The product architecture spans industrial equipment with automation, edge solutions, and cloud-based solutions [ 10:00 ]. Different user needs (on-site vs. office-based) shape solution design and deployment [ 13:12 ]. The Transformation Journey: Initial State:  The organization began with a resource topology, characterized by "doers" and "directing" archetypes [ 16:42 ]. Challenges included software engineering being treated as a service provider, fragmented requests, and isolated teams [ 21:11 ]. Desired State:  The goal was to move towards an adaptive topology by integrating "doing" and "driving" archetypes [ 16:17 ]. This involved a shift to a single product owner, broader product thinking, and product managers focusing on product management over project management [ 36:16 ]. The vision included more self-managing teams working directly with customers and owning the entire product [ 39:45 ]. Investments were made in scrum masters, agile coaches, and people management to support this [ 42:35 ]. Current Reality:  The transition has created "positive friction" in prioritization and mandate, leading to better dialogue and decision-making [ 51:41 ]. Teams are progressing towards effective delivery, with varying levels of maturity [ 52:54 ]. The current focus is on transparency, problem-solving, and continuous improvement [ 55:48 ]. Key Learnings and Insights: Software engineering should be viewed as a core discipline, not just a service function [ 33:38 ]. A product management mindset is crucial for sustainable product development, rather than a project management approach [ 29:06 ]. The Org Topologies is valuable for visualizing and managing organizational change [ 15:06 ]. Organizational change is an ongoing process requiring continuous adaptation and learning [ 01:02:04 ]. Leadership plays a critical role in fostering an environment where teams can succeed [ 01:05:08 ]. Integrating diverse engineering domains (software, hardware, mechanical) presents challenges [ 01:16:46 ]. Balancing agility with safety is essential in regulated environments [ 01:11:27 ]. Organic learning time and the impact of product expansion on team capabilities are important considerations [ 01:27:07 ].

This video presents Roland's account of a Large-Scale Scrum (LeSS) transformation at Stacker, a Dutch company operating in the electric vehicle charging market. Stacker's 50-person R&D department faced challenges with increasing time to market and a decline in innovation, despite workforce growth. There is also a written case study by Roland on this. Key Aspects of the Transformation: The Challenge:  As Stacker transitioned from a startup to a scale-up, adding more personnel did not resolve issues such as delivery delays, lengthening time to market, and a decreasing rate of innovation [ 03:14 ]. The Approach:  The engineering and product heads, influenced by employees familiar with LeSS, opted to implement the LeSS framework to tackle these problems [ 04:45 ]. Core Lessons Learned: The significance of management's comprehension and backing of LeSS [ 06:55 ]. The value of shared ownership of problems and solutions, aided by Org Topologies [ 07:38 ]. The necessity of monitoring a "critical mass of believers" for a smooth transition [ 08:21 ]. The importance of volunteering, adhering to a strict target date, focused coaching, and the ability to improvise [ 10:11 ]. Transformation Timeline:  The entire process, from initial discussions to the "flip" (the go-live date), spanned approximately two months [ 13:43 ]. Change Team & Focus:  A dedicated change team of 15 individuals from diverse roles was assembled to prepare for the LeSS implementation [ 16:13 ]. The transformation concentrated on three main areas: the product backlog, ways of working, and technology [ 18:17 ]. New Team Structure:  The reorganized structure comprised three areas, each targeting a specific customer segment. Teams were assigned based on feature requirements [ 28:53 ]. Training and Implementation:  Comprehensive training sessions were held to educate teams on Scrum, LeSS, and associated concepts [ 44:54 ]. The "flip" day involved defining the "definition of done," clarifying product backlogs, enabling self-designing teams, and establishing team agreements [ 48:28 ]. Post-Transformation:  The initial sprint following the flip prioritized learning, understanding customer needs, and addressing existing technical debt [ 01:05:16 ]. A rotating support duty was established to manage bugs and foster continuous improvement [ 56:16 ]. Coaching efforts centered on multi-learning, reducing complexity, and ensuring universal contribution [ 01:02:08 ]. Observed Outcomes:  The transformation resulted in enhanced learning, a better grasp of customer needs, and the identification of technical debt [ 01:05:16 ]. Role of Org Topologies:  Roland emphasized the utility of Org Topologies in comprehending and tackling organizational design challenges [ 01:11:55 ].

Make Org Design Sexy Again!  Yes, you read that right. We're here to spice up the way you think about frameworks and practices, with a case study that showcases how understanding and adapting to your organizational context isn't just necessary—it's exhilarating. Introduction This case study is presented anonymously by two Kevin Romijn and Marloes Naber working on a critical technology program for a major player in the aviation industry. This program is pivotal in developing systems crucial for aviation safety and functionality, divided strategically into two segments: the business section dealing with overarching responsibilities like safety and education, and the technology section focused on developing end-user functionalities.    Organizational Context Our focus is the technical side of the program, where the organizational structure positions management at the helm, branching out into several projects each led independently. We are particularly concentrating on the teams highlighted in blue. Here’s a quick rundown of the roles involved:   Architect : Oversees the entire systems architecture. Spec Team : Manages requirements specification. CPO (Chief Product Officer) : Heads backlog management. Development Teams (A, B, C) : Handle different aspects of development. Test Team : Responsible for verification and validation testing. D Team : Focuses on special function testing aligned with the architect to speed up system development. SIM Team : Develops training simulators, operating independently with some dependencies on testing.   Mapping the Current Situation The Org Topologies map uses two primary axes to assess organizational capabilities and focus, which are essential in adapting to rapidly changing market conditions and optimizing internal processes. We have mapped the current organization during an OT workshop with a representation of the teams and roles as earlier described.   We incorporated the concepts of switching costs, adaptivity, transaction costs, and speed into our workshop explanation, laying the groundwork for the following detailed map explanation:   Horizontal Axis (Completeness of Capabilities) : Ranges from single-skill individuals with limited scope to fast-flow units capable of end-to-end delivery with high autonomy. Advancing rightward on this axis correlates with reduced transactional costs, enhancing delivery speed and operational efficiency. Vertical Axis (Scope of Work) : Extends from a narrow task focus to a broad whole business focus. Ascending this axis means lower switching costs, allowing teams to shift focus and adapt more easily and cost-effectively to new priorities or changes in the business environment.     Insights on the Current Situation During the mapping process, valuable discussions took place. Below is a summary of some insightful comments.   Separate Technical and Business Programs : Technical teams operate in isolation from teams in the business program. This likely leads to misalignment between business objectives and technical execution. Lack of a Unified Roadmap : The organization lacks a comprehensive roadmap, focusing instead on immediate needs and easily prioritized tasks. This could result in short-term thinking and inefficiencies in resource allocation. Role of CPO and SPEC :   The Chief Product Officer (CPO) dictates specifications, which are then executed by SPEC in a project setup. SPEC handles feature-level requirements with good environmental knowledge but is not driven by project management or agile methodologies like Scrum. Team Structure (Teams A, B, C) : Teams are multi-skilled and use Scrum, yet roles such as the Scrum Master are not integrated with development roles. There’s no dedicated Product Owner within teams, contributing to a lack of clarity regarding the larger goals. Testing and specification processes are not included within these teams. Separate Testing Team : There is a distinct testing team responsible for validation, which interacts with Scrum teams A, B, and C primarily for testing and automated testing. Communication between these teams is poor, impacting effectiveness. D Team : The D team specializes in creating test scenarios and works closely with the architect to accelerate system development. This team has a specific function that directly supports system enhancements. SIM Team : Operates independently, developing training environments. This team has dependencies on testing outputs but functions separately from the development teams    Objective of the Program – Ambition of Change           The main objective of mapping the current ecosystem was to increase the speed within the program, improve the quality of delivery, and enhance the teams' knowledge level to enable more cross-functional work.   What’s next – an Incremental Approach to Adaptability The current insights inspire us to realize that improvements are possible to achieve quicker and more targeted outcomes. The green blocks on the map represent the new variants and movement on the OT map.   Step 1: Transitioning Development Teams to A2   Roadmap Based on Customer Journey Flow : Create a roadmap that guides development based on the aircraft's lifecycle.  This encourages teams to align their development efforts with the user’s end-to-end experience, which is  one step closer to customer-centricity. Feature Prioritization : Implement a priority matrix to regularly review and adjust feature priorities based on user feedback and business needs. This directly addresses the need for agility in response to the business needs, preventing over-commitment on less impactful features. Clear Definition of Done (DoD) : Develop a standardized DoD checklist that includes all necessary steps, from development and testing to documentation and stakeholder approval. It standardizes completion criteria across teams, which is crucial for maintaining quality and uniformity in multi-team environments. Knowledge Sharing on Features : Implement a peer mentoring program where experienced developers share their knowledge on specific features and systems. This intervention promotes an internal culture of learning and collaboration, essential for sustaining innovation and continuous improvement. Visual Management (Obeya Room) :Use large boards and digital displays to show project timelines, key metrics, and current impediments in a central location accessible to all team members. The Obeya enhances transparency and accountability. Step 2: Moving Teams to A3 Integrate Spec Team, Test team, Sim Team, and Architect : Reorganize teams to include members from the Spec, Test, Sim, and Architect teams to create cross-functional units. Moving towards a more integrated cross-functional unit setup is key in reducing dependencies and handoffs between specialized groups. It enhances the flow of information and work, reducing cycle times and improving response to feedback. Pilot Project with User Integration (B1) : Select one team to include an end-user (e.g., a pilot or maintenance member) to provide real-time feedback and insights. This encourages the continuous learning and experimentation but also increases customer-centricity. Focus roles within the teams : Establishing clear roles with dedicated Scrum masters and Product Owners sharpens accountability and minimizes role ambiguity, streamlining team operations.   Step  3: Transitioning the CPO to C0 Integrate Business and Technology Programs : Establish a joint leadership team that includes key stakeholders from both business and technology sections to drive the integration. This emphasizes the blending of business and technology strategy to ensure cohesive decision-making and alignment on objectives. CPO as the Driving Force : Create a governance framework that supports the CPO's role in decision-making and ensures alignment across all teams. Position the CPO as a pivotal leader in org strategic direction and, ensuring that product vision is closely tied to business goals again. Recommendation: Gradual Organizational Transition Given the program's placement within a traditional, project-based organizational structure, a phased approach to implementing changes is advisable: Manageability and Stability: Large-scale changes can disrupt well-established management and operational systems. Incremental changes allow the organization to adapt without undermining existing management's control over budgets and personnel. Sustained Delivery and Control:  Gradual improvements ensure the organization continues to meet project timelines effectively while gradually introducing new tools and processes. This method respects existing governance structures, ensuring that management maintains oversight and accountability. This step-by-step approach helps embed new practices within the existing framework, enhancing flexibility and efficiency without compromising the organization's operational commitments. Therefore, the teams will initially transition within Level A on the Org Topologies map, focusing on solidifying A-level capabilities before considering a move to Level B. This measured progression ensures that the foundational aspects are robust enough to support the next level's demand   Conclusion By following this structured approach, the company can gradually transition towards a more agile and adaptive organization. This plan aims to improve the speed and quality of feature delivery, ensuring that the company meets the demands of the business and end-users. The integration of systems thinking and Org Topologies principles will help identify and address systemic issues, leading to sustainable and impactful improvements. Through targeted skill development, improved cross-functional collaboration, and effective leadership, this program will enhance its overall agility, delivering higher quality features faster and more efficiently.   Workshop participants’ reaction   "It's great to be involved. It's clear right away. Even though we thought we were already agile, we see once again how important it is to keep going and how nice the communication with each other is."   Kevin and Marloes in action.   This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing.   Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by Kevin and Marloes provides great examples of what we now call Elevating Katas . Elevating Katas are introduced as repeatable, structured patterns or routines introduced into an organization’s ways of working that help teams and leaders build new capabilities, improve system-level performance, and “elevate” their overall approach to value delivery. Elevating Katas Identified in this Case Study: Roadmap Based on Customer Journeys Routinely aligning development efforts with end-to-end customer experiences. By iteratively refining a customer-centric roadmap, teams continuously close gaps between business goals and technical execution. Peer Mentoring for Skill and Feature Knowledge Establishing ongoing, internal mentorship routines that break down silos and elevate shared understanding. Over time, this fosters broader skill sets, enabling multi-skilled teams that more effectively deliver complex features. Unified Definition of Done (DoD) Regularly revisiting and refining a standardized DoD ensures consistency and quality. By embedding this kata, all teams continuously align on clear completion criteria, speeding delivery and improving handoffs. Integrating Cross-Functional Expertise Into Teams Incrementally merging roles (e.g., spec, test, architect) into development teams. Repeated application of this practice eliminates external dependencies, improves flow, and enhances adaptability to changing requirements. Pilot End-User Integration Regularly involving actual users or domain experts directly within teams. Over time, this deepens customer empathy, guides product decisions, and ensures solutions better match real-world needs. Visual Management (Obeya Room) Consistently maintaining a visual, transparent workspace where teams track progress and highlight impediments. This continuous improvement routine builds shared understanding, faster decision-making, and quicker response to issues. More on Elevating Katas here .

Introduction: The Fusion of Theory and Practice In the world of agile transformations and organizational design, the integration of innovative frameworks like  Org Topologies™  with practical learning experiences marks a new era in organizational development. This article delves into a unique experiment with  Org Topologies™ . I. The Org Topologies™ Experiment: A Community's Exploration A Unique Community Event Last Thursday evening, a private community event brought together a group of forward-thinkers to explore the  Org Topologies™  map. This session wasn't just another routine workshop; it was an enlightening journey through the intricate pathways of organizational design. The Experiment's Design and Purpose The session, crafted by yours truly (Jurgen De Smet), aimed to explore two critical questions: Can participants effectively utilize  Org Topologies™  without prior in-depth explanation? What new applications of  Org Topologies™  could emerge beyond the conventional understanding? The approach was minimalistic, with little to no introduction to  Org Topologies™ , encouraging participants to dive into the map with fresh eyes and interpret it based on their instincts and assumptions. And this in a very short timeframe of 1,5 hours! Reflections and Insights Participants engaged in a reflective exercise, exploring the map's various dimensions - vertical, horizontal, and even diagonal axes. This process validated the first objective: people can indeed navigate the  Org Topologies™  map without extensive theoretical grounding. The deviations observed were not just minimal but offered new, potentially valuable perspectives. Some of the reflections build by attendees: II. The Agile Journey: From Understanding to Application Exploring Coaching and Change The second phase of the experiment shifted focus towards practical applications, such as coaching stances and change strategies to traverse the map. Having familiarized themselves with the map, participants brainstormed on these aspects collectively. What shifts does one need to make to go from left-to-right? What shifts does one need to make to go bottom-up? Navigating the Org Topologies™ Map An interesting revelation emerged here: contrary to the expectation that participants would find the left-to-right movement (transformational journey) more intuitive, they expressed greater ease with the bottom-to-top approach (upwards movement in organizational maturity). This finding challenges some traditional assumptions in agile adoption strategies generally focussed on the left-to-right approach, building loosely coupled cross-functional teams. Beyond Conventional Applications The discussion transcended traditional uses of the map, touching upon its role in management, team dynamics, and even personal growth and coaching. These insights illustrate the map's versatility in addressing various facets of an organization's journey towards agility and effectiveness. III. Org Topologies™ in Action: Practical Implications and Insights Effortless Integration in Organizational Work This experiment underscores a vital point: introducing and utilizing  Org Topologies™  in an organizational context is surprisingly straightforward. It does not demand extensive groundwork or explanation, making it an ideal tool for practitioners who favour action over extended theoretical discussions. Value scoring of attendees using Org Topologies map without explanation: Acknowledging the Contributors A heartfelt appreciation goes out to the workshop participants -  Zdenek Soukup  ,  Aernout van den Burg  ,  Tamás Hajdu  ,  Martin Retka  ,  Tom Jans  ,  Vincent Hennebert  - whose engagement and insights were instrumental in the success of this experiment. Additionally I must acknowledge the work of  Alexey Krivitsky  and  Roland Flemm  to put the map together. Great job 👏  IV. Beyond the workshop experiment: Connecting Org Topologies™ with Designing Agile Organizations (DAO) As a licensed  Designing Agile Organizations trainer  I can't help myself becoming the DJ mixing things up. Integrating  Org Topologies™  with  DAO  principles and guides offers a comprehensive approach to crafting agile organizations.  DAO  provides the theoretical backbone and organizational design principles beyond the product development groups,  Org Topologies™  offers a practical, hands-on map to navigate your path. Having a map combined with  DAO  principles, design guidelines and workshop suggestions will make the journey left-to-right, bottom-to-top a lot easier, practical and… allows you to plug-in your product development groups into the larger picture of an organization and its strategic focus. The blend of  DAO's  structured learning and broad view on an organization with the dynamic, experimental nature of  Org Topologies™  creates a powerful synergy. This combination equips leaders and practitioners with the knowledge and tools to effectively navigate the complexities of agile organizational design.  V. The Impact on Agile Adoption and Transformation Redefining Agile Journeys The insights from the  Org Topologies™  experiment redefine how organizations approach agile transformations. It emphasizes a more intuitive, less prescriptive path, aligning with the agile principle of valuing individuals and interactions over processes and tools. Strategic Movements in Organizational Design The experiment's findings highlight the importance of considering both horizontal and vertical movements in organizational agility. This holistic view is crucial for a truly transformative agile journey. Generally know as a systemic approach to transformation, in the heart of both  Org Topologies™  as well as  DAO . Implications for Leaders and Agile Coaches For leaders and agile coaches, these insights provide a fresh perspective on guiding organizations through agile transformations. It underscores the need for adaptability, open-mindedness, and a willingness to explore beyond traditional frameworks. VI. Personal Growth and Coaching: A New Dimension The application of  Org Topologies™  extends beyond organizational boundaries, offering valuable insights for personal growth and coaching. It serves as a reflective tool for individuals to assess their journey and growth paths within the agile landscape. For coaches,  Org Topologies™  becomes a versatile tool in their arsenal, aiding in the development of tailored coaching strategies that resonate with individual needs and organizational contexts. VII. Final Thoughts and Future Directions The experiment with  Org Topologies™  and its integration with  DAO  (and  LeSS ) signifies a pivotal moment in the evolving landscape of agile organizational design. It highlights the continuous need for innovation, experimentation, and an open-minded approach to developing agile frameworks. As we move forward, embracing these principles and tools will be key in navigating the ever-changing dynamics of organizational structures and cultures in the agile world. The journey doesn't end here. Continuous learning, adaptation, and the willingness to experiment are essential for anyone involved in agile transformations and organizational design. PS: I do mix an  Org Topologies™  introduction into my versions of the  Designing Agile Organizations  and  LeSS  courses in a way attendees grasp the potential of this powerful mix of principles, guides and experiments. Reach out if you want to attend one someday or you want to have an in-company event organized.

My name is Yana Bort. I work in a Ukrainian branch of Raiffeisen bank. I joined the bank in mid-2021 to drive the Retail Banking (non-IT) transformation. After achieving results in the non-IT area, I was invited to join the IT team to lead Agile transformation . I currently work as a Head of IT Strategy and Agile Transformation. I became interested in Org Topologies about half a year ago, as the organization prepares for the next wave of organizational change. Earlier this year, I attended an Org Topologies  Practitioner class. As part of the certification process, I am writing this report to share the organization's change journey since 2020, which was assessed with the mapping method of O rg Topologies . Phase 1 (2020-2022) — Domain-Based Org Design with Technological Focus When joined IT in 2022, I encountered this state that had been introduced earlier in 2020. The IT organization was structured according to the Domain-Driven Design (DDD) approach, based on a mix of business rules, architectural concerns, and system logic. Several units were part of that organization: Payment, Loans, Customers, Channels, etc. We called them “Domains.” They can be considered containers of business rules and application knowledge. That structure was supported by a dozen internal agile coaches . For me, it was a starting point in IT, but for the Bank, it was the middle of the transformation with many changes. The war dramatically increased the challenge. A huge number of people were displaced to temporary locations. Therefore, our priorities suddenly shifted from the development and launch of new products to preserving customers' funds and making them available and accessible for payments, withdrawals, and transfers at any time, from any location, under any circumstances and during the war .  The change in priorities affected the change, as the organization required new capabilities. For example, being adaptive and agile became more than just buzzwords; these capabilities became essential for survival. DDD initially helped the organization focus on and invest in technology development. However, under new circumstances, it became an obstacle to creating and delivering customer value end-to-end. During the phase that I call “Domain-Based Org Design,” there were many blocking dependencies between the teams and domains as most teams focused on component development (Y1-Y2, as per Org Topologies): Account Statement functionality, Credit History functionality, etc. In addition to those teams, there were also integration teams that combined the components developed by other teams into customer-facing features. Furthermore, other non-critical disadvantages that the organization had before became crucial when the priorities rapidly changed. The product owners within the domains managed feature development that fit into their domain’s scope of work but not the whole customer journey. That is why managing and reaching business objectives was a challenge. Phase 2 (2022-2023) — More Adaptivity with End-to-End Teams This organizational change introduced end-to-end teams (A2, as per Org Topologies). We called them “Speed boats.” These multi-component teams could do 80% of end-to-end work within customer-facing features. An example of such a team is “Card-to-Card Transaction” which developed functionality end-to-end, including external and internal needs across almost all IT systems.  The change in that phase was limited only to the team structure, so the domain structure remained intact. The “speedboat” teams were formed within the existing domains.  Eleven speedboat teams were formed in total within different domains, which was a breakthrough as these teams proved their value and created the momentum for the next, more systemic organizational change. Phase 3 (2024) — Business-Oriented Tribes with System Co-Ownership Now, we are ready to drive the next wave of change. We are creating new organizational structures around business areas. These clear customer-centric units will have clear ownership and true end-to-end responsibility. We call them “Tribes.” Some of them are corporate Loans, Retail Loans, Corporate Cash Management, and Daily Banking for Private Individuals. To ensure the quality of the change, the Tribes are being implemented one by one. The SpeedBoat model (fast-flow end-to-end teams) is a building block at the heart of the Tribes. The teams will receive work from business-oriented Tribes and can be assessed as B2 teams growing into B3 as per organizational topologies. Due to our complexity, not all systems can be easily shared, so for the moment, there will be systems that are still single-owned by teams, and these teams are outside the Tribes. In addition to the business-oriented Tribes, we are introducing the notion of Platform-as-a-Service with the hope that this approach will reduce many blocking dependencies and enable our teams to work independently to the needs of the Tribes. Our long-term vision is slowly moving all teams to the Tribe and co-ownership model. Summary Analyzing the waves of the organizational journey with the Org Topologies method helps to compare and contrast different org design options that we explored. The mapping I did for this report helped me see the overall direction of our organizational change. Sharing this with my colleagues will enable more alignment and clarity of our change efforts. (C) 2024, Yana Bort for Org Topologies. This experience report presents a personal view on the change story by the credited writer. Should you have alternative views or additional details about this particular company's change story, please do not hesitate to contact Org Topologies and submit your version for publishing. Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by Yana provides great examples of what we now call Elevating Katas . Katas are introduced as systematic changes that help align strategy, improve collaboration, and foster continuous improvement. Elevating Katas Identified in the Experience Report Introducing “SpeedBoat” End-to-End Teams Instead of building teams around technical domains or components, the organization starts to form “SpeedBoat” teams capable of delivering customer-facing features end-to-end. This repeated approach of creating and refining multi-component, customer-focused teams works as a kata: each newly formed SpeedBoat team reinforces the pattern of aligning delivery structures with value streams, reduces dependencies, and cultivates adaptability. Transitioning to Business-Oriented Tribes Moving from domain-based units towards Tribes organized around clear business areas, each with end-to-end responsibility, represents another kata. As the organization repeatedly applies this structural shift, each Tribe formation and refinement cycle solidifies a focus on customer outcomes. Over time, this recurring pattern continuously elevates the organizational design toward greater clarity, accountability, and responsiveness to changing priorities. Embedding Platform-as-a-Service Structures Introducing and iterating on a Platform-as-a-Service (PaaS) approach to reduce dependencies and streamline workflows is a kata that evolves the organizational infrastructure. By continuously improving platform capabilities—offloading complexity from individual teams and enabling independent, frictionless feature delivery—the organization repeatedly practices a pattern that elevates overall system flow and resilience. Regular Org Topologies Mapping and Review Consistently using the Org Topologies mapping method to assess the current state, guide change, and compare different organizational design options acts as a kata. Each cycle of reviewing the topology, identifying gaps, and planning next steps based on the map encourages a habit of evidence-based decision-making. Repeatedly applying this approach ensures that every structural adjustment is informed by a clear, systemic understanding of the organization’s evolution. More on Elevating Katas here .

Une série d'articles sur Org Topologies et la Stratégie Kanban aidant progressivement une unité business d'une organisation à devenir de plus en plus performante et à augmenter son agilité business. Un grand remerciement à Alexey Krivitsky et Roland Flemm pour avoir créé Org Topologies et leur incroyable classe que j’ai eu la chance de suivre sur Paris en Mars 2024, ainsi qu’à leurs différents feedbacks, précisions et éclaircissements à apporter à cette histoire avant que je ne la publie.    Pour ceux et celles qui voudraient lire l'histoire complète en un seul coup, vous la trouverez ici au format pdf . Introduction Toute organisation peut être analysée via la cartographie proposée par Org Topologies. Sur cette cartographie le saint Graal se trouve en haut à droite, représentant une organisation capable de s'adapter ultra rapidement pour faire face à tous les périls semés sur son chemin. Une organisation par ailleurs en capacité de délivrer rapidement et avec une grande efficience de la valeur à ses clients. Les startups se situent généralement dans cette zone et si ce n'est pas le cas, elles ne subsistent pas très longtemps dans ce monde de fortes compétitions, où il est crucial d’être à un très haut niveau de performance. Un niveau où la consommation du peu de moyens disponibles permet de rapidement trouver le produit que des premiers clients adoreront et qui permettra de continuer l’aventure.   Lorsque la petite organisation s'agrandit, la tendance générale est à la segmentation des responsabilités. Des départements spécialisés dans différents domaines sont créés (marketing, commercial, après-vente, etc.), entraînant une baisse de capacité d'adaptation et une baisse de capacité à délivrer rapidement et à moindre coût de la valeur. L'accroissement d'une organisation tend à l'amener vers la zone basse à gauche, où les équipes et les individus la composant n'ont plus une vision holistique de ce qui est le mieux à faire pour la clientèle actuelle et pour continuer à prospérer en atteignant de nouveaux marchés par exemple.   Dans cet article, nous allons suivre l'histoire de Paul, un consultant spécialisé dans les tests d'application numérique au début de sa carrière. Paul rejoint lors d'une mission une organisation avec de multiples départements, des équipes et individus dispersés, mais qui doivent se coordonner pour in fine servir la clientèle de l’entreprise. Dans cette histoire vous verrez comment cette organisation, et plus précisément la business unit que rejoint Paul, entreprend un chemin pour retrouver le saint-Graal, notamment en s'appuyant sur la stratégie Kanban. Chapitre 1 : Le commencement L'unité business que Paul rejoint, délivrant des services numériques à ses clients est un collectif d'environ 50 personnes. Ces 50 personnes couvrent l'ensemble des compétences permettant de délivrer à une partie des clients de l’entreprise un produit numérique (Business, IT, Marketing, Commercial, Hotline etc.).    Cette unité business se situe à l’intérieur d’une entreprise plus large servant d’autres produits et services, pour un panel plus large de clients.   En utilisant les 4 strates verticales de la cartographie Org Topologies (C, B, A ,Y),  cela donnerait cette forme de représentation : L’histoire qui va être racontée tout au long de ces différents chapitres, fait le focus sur l’unité business X que Paul rejoint.   La situation organisationnelle de cette unité business au moment où Paul rejoint cette entreprise est représentée sur la cartographie org topologies suivante : Les liens entre les individus ou équipes (pseudo équipe) sont représentés par les connecteurs. Le silotage au sein de cette organisation est très présent, jamais un membre du groupe de commerciaux  (C1) pourtant au plus proche des clients n'échange avec le groupe développant le produit (A1).   Pour faire l'interface entre les commerciaux occupés sur le terrain à vendre les différents produits et services que l’entreprise propose, et les personnes développant le produit, l'organisation a choisi de placer des interlocuteurs métier (B0), plusieurs, chacun avec son périmètre (chef de projet marketing pour les clients de type X, un autre pour les clients de type Y, etc.). Il n'y a pas une unité cohérente, partageant la connaissance, mais X interlocuteurs distincts avec sa connaissance business dédiée. Ces personnes se retrouvent sans une vision globale orientée client, mais une vision partielle centrée sur leur domaine business, leur domaine de clientèle. La hotline (B1) a une connaissance plus large, plus partagée, entre ses membres qui font face à tout type de clients et divers problèmes remontés, mais elle répond et débloque des situations au cas par cas sans avoir le pouvoir de décision et la capacité d'action pour apporter des changements pérennes bénéfiques aux clients.   Dans cette situation, beaucoup de coordination nécessaire entre ces différents acteurs et inévitablement de la déperdition d'informations utiles pour prendre les bonnes décisions pour le business et rendre au mieux service aux clients.    Ces personnes n'ont pas les compétences pour maintenir et faire évoluer le produit. Ils vont se reposer sur une filière informatique, généralement découpée en deux parties MOA et MOE, Business Analyst et Codeur.  C'est le cas ici, un groupe de personnes avec des compétences liant le business à l'IT vont analyser les problématiques et les besoins remontés par la Hotline ou par les interlocuteurs métiers. Il n'est pas rare non plus que ce groupe consiste en des personnes très spécialisées sur des domaines business, mais que tout le monde ne puisse adresser les sujets des différentes clientèles. L'organisation présentée ici est dans ce cas avec ses Business Analyst (B0) spécialisés avec des domaines de prédilection.   Paul est missionné et rejoint un groupe spécialisé dans les tests (A0). Ce groupe est ici en renfort pour libérer de la bande passant aux BA afin qu'ils se consacrent à la compréhension des besoins, des problématiques et gèrent les "gros" projets en tant que chef de projet SI. Un groupe de testeurs avec des missions souvent spécifiques autour de batteries de tests de non régression.  Un rythme effréné de tests laissant aucune place au partage de connaissances, amenant les personnes à se spécialiser sur des parties de l'application.    Paul a bien du mal à entrer dans sa mission, ses collègues étant très peu disponibles pour l'aider à comprendre le fonctionnement de l'application et toutes les subtilités. Heureusement, beaucoup de documentation existe et il arrive au bout de quelques semaines à prendre ses marques.  Au regard des évolutions à venir, un chef de projet SI lui demande de se focaliser sur une partie de l'application. Évidemment l'organisation s'est dotée de développeurs informatiques (le produit numérique ne pas se construire par magie !), ces développeurs forment une unité souvent eux-mêmes silotés en domaine de compétence spécifique (A1). C'est le cas dans cette organisation que rejoint Paul avec rarement du partage de connaissance, du pair-programming inexistant. Une unité où chacun selon sa spécialisation sur l'application prend des morceaux de spécifications écrites par les BA afin de coder l'évolution, la correction.   L'organisation a choisi de faire appel à un centre de compétence technique externe (Y1) afin de gérer la fluctuation des besoins de compétences en développement informatique. Cette entreprise est dans une stratégie de contrôle de l’accroissement de la masse salariale sur ces compétences techniques, craignant une baisse d’activité autour de ces compétences dans le futur et ne voulant pas avoir des dizaines de collaborateurs auxquels elle n’aurait plus d’activités à confier. Entre contrat mal ficelé et contraintes autour de la sécurité des SI, ce centre de compétence se retrouve à réaliser des tâches plutôt correctives, qu'évolutives et à déposer des livrables qui doivent être ensuite intégrés par l'équipe de développement interne. Enfin pour livrer l'application en production, réaliser le monitoring technique et assurer la maintenance et l'évolution de l'infrastructure, l'organisation s'est dotée de spécialistes et les a regroupés dans une unité dédiée (Y1).   Paul regrette de ne pas être en lien avec les interlocuteurs métiers ou la hotline. Ce sont les BA, les chefs de projet SI qui le sont et reçoivent les problématiques pour finalement lorsqu'ils ont besoin les faire redescendre à l'unité dans laquelle se trouve Paul. Il pense sincèrement qu'il pourrait mieux comprendre les anomalies constatées et plus facilement les reproduire pour aider les développeurs à les corriger. Il a déjà évoqué plusieurs fois le sujet, mais rien ne change.   Une organisation qui réalise de nombreux comités pour coordonner les différentes équipes et personnes, nécessitant de nombreuses heures de préparation de reporting et de nombreuses heures passées dans ces réunions. Paul doit remonter fréquemment, les compteurs d'anomalies, le pourcentage de cas de tests restants, une appréciation du temps nécessaire restant pour boucler les tests qu'on lui a poussés, chose pour lui compliqué car s'il détecte une anomalie, il est assez souvent coincé pour continuer. N'ayant aucune idée de combien de temps prendra le correctif, il s'engage sur d'autres périmètres de tests à réaliser. Cela l'amène à prendre pas mal de temps à se replonger quelques jours plus tard sur ce qui avait été interrompu. Au moins, se dit-il : " Je monte en compétence de plus en plus sur tout le périmètre applicatif. "   Il se demande sur quelle base les chefs de projet SI communiquent des dates d'atterrissage sur les différents chantiers. Cela lui semble être vraiment fait au feeling plus qu'avec des éléments très factuels. Certes il y a des Gantt, des plannings, mais il y a toujours des imprévus, notamment des bugs ou des régressions, qu’il détecte et qui viennent chambouler les plans.   Un type d'organisation que vous avez peut-être connu, ou dans laquelle vous êtes actuellement à certains détails près. Une organisation peu efficiente, peu efficace et aucunement prédictible.   Pour cette organisation, les décalages dans les plannings sont constants. Des annonces de corrections et de nouveautés sont communiquées aux clients et ne sont quasi jamais tenues. Le mécontentement client est de plus en plus présent, à un niveau qui devient critique pour le business, ce qui ne laisse pas de marbre la direction. Il est absolument vital pour cette organisation d'accroître la capacité à répondre plus rapidement et de manière plus prédictible. Chapitre 2 : Projet de refonte et première modification d’organisation L'organisation, qui était loin d'être performante, avait de plus entraîné l'application numérique dans une dette technique importante. Les clients en subissaient très fortement les conséquences, avec des incidents critiques qui étaient de plus en plus fréquents. Paul lui aussi en faisait les frais, de plus en plus de tests de non-régression étaient poussés à l'unité de testeurs, espérant ainsi éviter d'amener des problématiques importantes sur l'application jusque dans les mains des utilisateurs. La direction, au regard de cela et ayant de plus en plus d'écho que l'organisation n'était pas efficiente, décida de lancer un vaste projet de refonte. Elle en profita pour faire quelques modifications d'organisation afin de rapprocher des personnes qui avaient pour objectif de mener à bien ce projet. Les BA/Chef de projet SI fusionnèrent avec les personnes en expertise de test, pour former une unité fonctionnelle (B1) (Pour la suite, cette unité sera appelée l'unité de BA). Paul, qui avait acquis beaucoup de connaissance sur le périmètre, se vit offrir une possibilité de rejoindre l'équipe et en finir avec sa vie de consultant. L'idée lui plaisait d'autant plus qu'au niveau interlocuteur métier, la direction avait entrepris des actions pour qu'une unité de connaissance client se fédère autour d'une personne, un chef de projet métier (C0). Cette personne par son travail avec les commerciaux, les personnes du marketing, de la hotline et bien évidemment des clients devait rapidement acquérir une connaissance élargie des attentes et problématiques des clients. Elle allait travailler par ailleurs étroitement avec l'équipe dont Paul faisait partie pour amener du sens au travail réalisé et prioriser les développements les plus pertinents par rapport à ce qui était attendu par les clients. Paul n'avait jamais eu l'occasion d'avoir un interlocuteur lui faisant aussi bien prendre conscience des attentes des clients, sa motivation ainsi que celle de ses collègues devint rapidement bien plus importante. Paul avait vu dans ses précédentes expériences des équipes qui utilisaient un management visuel physique pour gérer leur projet. Il proposa au reste de son unité de BA de mettre ce management visuel en place. L'idée de Paul et la collaboration avec le reste de l'unité les amena à mettre en place un simple workflow "A faire", "En cours", "En attente", "Terminé". Côté unité de développement, ils avaient eu, eux aussi, écho de cette approche et Paul se souvient qu'ils avaient à peu près mis la même chose en place. Paul découvrit un peu plus tard qu'ils avaient initié la mise en place d'une stratégie Kanban, cependant  " Nous n'étions clairement pas dans une stratégie Kanban, tout simplement parce qu'à cette époque personne ne connaissait ce qui s'était mis en place chez Corbis* et l'émergence de Kanban pour le domaine du product management. Si cela avait été le cas, nous n'aurions certainement pas eu cette colonne ("En attente"). Nous n'avions par ailleurs pas de règles de passage très explicites entre nos états, il y avait beaucoup d'implicites autour de ce workflow. Enfin, il nous manquait tous les autres éléments d'une véritable stratégie Kanban. Comment limiter l'encours? Des règles de tirage explicites, un niveau de service sur lequel l'unité se challenge etc. Nous aurions pu et dû à cette époque fusionner nos workflows afin d'avoir une vision globale de ce qui se passait, car au final quand nous (BA) terminions quelque chose, c'était une spécification, une explication d'une anomalie que nous donnions à l'équipe de dev et qui donc pour eux aller apparaître dans leur "A faire".  Quand ils terminaient, cela revenait chez nous (BA) pour que nous testions. Nous faisions alors entrer un ticket de recette qui traversait notre workflow (d'où la colonne en attente que nous utilisions lorsqu'un bug était trouvé et que nous attendions la livraison d'un correctif pour reprendre les tests). " *Si vous voulez en savoir plus sur la naissance de Kanban pour le domaine du product management qui s’est passé chez Corbis (une compagnie de Bill Gates), l’histoire est très bien raconté dans le guide de poche Kanban ( https://prokanban.org/kpg/ ) Si ces deux unités avaient juxtaposé leur workflow, ils auraient obtenu quelque chose comme : Difficile par cette juxtaposition d'avoir une vision de bout en bout pour savoir combien de temps ce collectif mettait pour terminer un sujet qu'attendait des clients où qui était utile dans le cadre de la refonte de l'application. Paul raconte : " On avait parfois jusqu'à 4 ou 5 allers et retours avec des corrections à réaliser et des nouveaux tests à faire, autant de post-its qui circulaient sur notre management visuel. On avait ajouté des dates de création de sur nos tickets, mais si on voulait savoir combien de temps avait pris le développement, le test et la correction du Dev A, on était en difficulté pour avoir cette information. La simple mise en place de cela avait tout de même un gain non négligeable par rapport à la visibilité dans chaque unité de ce qu'il y avait à faire, de ce qui était en cours. La collaboration au sein de nos unités était devenue meilleure, les personnes étaient de plus en plus capables d'intervenir globalement sur l'application existante, mais aussi sur la nouvelle que nous construisions " Paul relate par contre, que le chef de projet métier s'agaçait régulièrement, car il était impossible pour lui d'avoir une information claire de quand un sujet allait être bouclé. Il voyait qu'il y avait beaucoup de travail réalisé, qu'il y avait des avancements, mais s'il voulait communiquer à la direction ou aux clients quand la fonctionnalité F allait sortir, il ne pouvait toujours pas avoir de réponses fiables. Ce qui l'amenait à devoir revenir sur sa communication régulièrement. Le temps réellement pris pour terminer une fonctionnalité était bien souvent largement en écart à l’estimation initiale qui avait été faite… et malheureusement pas dans le bon sens, plusieurs semaines assez fréquemment. La direction de son côté commençait à douter de la capacité à mener à bien le projet de refonte, de nombreux décalages de planning survenaient encore et toujours. Paul : " L'agacement de plus en plus fréquent du chef de projet métier et le doute de la direction (qui nous redescendait sous forme de pression) nous fit ressentir fortement que nous avions un axe d'amélioration important à mettre en place rapidement. En discutant avec les collègues de l'unité de BA et ceux de l'unité de développement, nous faisions surgir le besoin de casser nos silos et de devenir une seule et même unité multi-compétente, qui allait s'aligner sur un même objectif à court terme afin de rassurer sur notre capacité à mener à bien ce projet. Nous espérions aussi que cela allait nous permettre d'avoir une vue d'ensemble nous permettant d'être plus fiable dans nos réponses à la question du quand, qui nous était souvent posée? " Chapitre 3 : La naissance d’une Scrum Team Cette volonté des deux unités distinctes de se rapprocher pour améliorer globalement la performance de la création du produit numérique fut quelque chose acceptée par la direction. Non sans un effort tout de même conséquent, notamment de Paul, pour arriver à convaincre que cette expérience valait le coup d’être tentée. Cette nouvelle unité rassemblée était bien évidemment attendue sur les résultats escomptés de cette expérience, notamment autour du fait que ce rassemblement devait améliorer; le Time to Market (T2M).  Ce T2M était clairement le temps de cycle, mais l’équipe utilisa cette appellation mieux comprise de la direction pour vendre l’expérience qu’elle souhaitait réaliser. Paul relate que cette évolution d'organisation amena deux choses : "Le chef de projet "métier" intégra plus ou moins l'équipe dans une redevabilité de Product Owner. Je dis plus ou moins, car on était au tout début de Scrum chez nous. Si aujourd'hui a encore pas mal d'endroits, Scrum n'est pas correctement mis en place, notamment autour de ce rôle de PO, je vous laisse imaginer ce qu'à l'époque (et on parle des années ~2010) ce rôle de PO avait de différents avec celui d'un chef de projet (spoiler alert : rien ou presque).  Nous (BA) formions avec les développeurs internes, l'équipe de développement Scrum (oui c'est comme ça que ça s'appelait à l'époque, donc j'ai le droit de le dire !) Nous nous dotions d'un super outil de ticketing. Super est ironique, car il est certainement responsable de pas mal de travers que nous avons pris lorsque nous définîmes notre workflow d'équipe unifiée : Nous avions enfin une vue plus globale, unifiée de ce que nous faisions pour créer de la valeur.”   Vous avez peut-être remarqué que cette colonne "en attente" était toujours présente avec cette unification des workflows par la fusion des deux entités.  Paul explique pourquoi : “Eh bien pour nous en tout cas, c'était très clairement parce que nous n'étions pas encore une équipe, mais seulement un groupe de personnes avec quasi toutes les compétences nécessaires, mais toujours à parler de MOA, MOE et à se repasser la patate chaude. Donc oui, on avait toujours cette colonne en attente signifiant principalement qu'on attendait des personnes de la MOE de corriger un problème détecté.”   Une bien mauvaise pratique, en tout cas pour espérer atteindre un flux performant ! (Mais tellement courante dans une organisation avec des silos). En effet, chaque silo peut être considéré comme une dépendance, par laquelle chaque élément de  valeur potentielle va devoir passer pour pouvoir atterrir enfin dans les mains de l’utilisateur final. Chaque dépendance est un point où le flux se rompt avec potentiellement (et fréquemment) des éléments qui s’empilent. En conséquence, ces silos entraînent un accroissement du nombre d'éléments en cours, car par exemple la “MOA” démarre des travaux supplémentaires en attendant soit des développements, soit des corrections. Les changements de contexte sont nombreux ce qui entraîne également une perte d’efficience, liée aux coûts non négligeables en termes de temps à se replonger dans des éléments. Une étude sérieuse sur le sujet des changements de contexte a montré qu’en changeant de contexte entre 2 sujets, il y avait une perte d’environ 20 % du temps, 40 % de temps perdu en poursuivant 3 sujets en même temps. (voir :  https://www.scrum.org/resources/blog/financial-cost-task-switching )   Malgré tout, ce rapprochement après quelques semaines d’expérimentation commença à montrer des signes positifs. A la fois sur le T2M, des mesures que tenait le Product Owner en devenir, une tendance baissière était visible. Mais également sur la qualité de ce qui était produit. En effet, ce rapprochement avait entraîné parfois (malheureusement pas encore régulièrement) des ateliers de travail collaboratifs entre les différentes compétences pour comprendre l’attente, la problématique à résoudre et trouver ensemble la meilleure solution. Les compétences techniques pouvaient donc mieux saisir ce qui était attendu, ce qui leur permettaient de faire des propositions (et non plus coder sans chercher à comprendre le pourquoi), ce qui collectivement permettait de mettre en œuvre des incréments plus qualitatifs. Cependant, il y avait un point d'inefficience notable encore dans cette organisation, il se situait autour de cette unité de développement externe provenant d’un centre de service. Paul le souligne d’ailleurs très bien : “En fait dans ce workflow, si un zoom était fait dans "Développement" on voyait que des choses n'étaient plus au sein de notre équipe unifiée, mais du côté de ce centre de services. Les travaux qu'ils faisaient, devaient être intégrés. Nous avions ajouté une étape d'intégration avant l'étape de recette pour rendre cela transparent. Les données collectées montraient clairement un point d'inefficience, cela nous aida à appuyer auprès de la direction le besoin de traiter la problématique. ”   Au détour de l'opportunité d'un changement de centre de service, Paul et ses collègues réussirent à convaincre la direction de faire quelques modifications au contrat et au processus interne. Non sans mal, ils réussirent à faire en sorte que cette force de coding supplémentaire rejoigne leur équipe Scrum et puisse intervenir au même titre que n’importe qui sur le produit.Une dépendance en moins, un alignement aussi de ces personnes sur un objectif commun, des nouvelles cellules grises pour réfléchir ensemble aux meilleures solutions possibles. In fine, un prestataire et des intervenants plus engagés, car face à des problèmes à résoudre qui avaient du sens pour des utilisateurs finaux (au lieu de “pisser” du code sans en comprendre la raison). Chapitre 4 : La montée en puissance sur la stratégie Kanban Avec un peu de patience, d'effort de dialogue, Paul et son équipe scellèrent un esprit collectif et d'unité.  Ils avançaient sur leur compréhension de Scrum, mais aussi de la stratégie Kanban. Ils commencèrent à mesurer des temps de cycle, à faire des expériences de limitation de WIP dans une recherche d’optimiser leurs flux. En créant la DoD de l’équipe, ils devaient malheureusement encore s’arrêter avant la mise en production. Cette dernière étape était toujours réalisée par d'autres personnes en dehors de leur équipe.   Paul raconte : “Nous ne considérions plus les éléments de travail comme quelque chose que nous nous transmettions les uns aux autres, mais comme quelque chose que nous devions terminer aussi vite que possible ensemble. Nous nous aidions mutuellement, que ce soit sur le plan fonctionnel ou technique, avec toutes les compétences dont nous disposions individuellement. Par exemple, les personnes fonctionnelles avaient appris à réaliser des tests automatisés, et pas seulement au travers des IHM, nous allions jusqu’à l’automatisation de tests au niveau des API. Les personnes aux compétences techniques étaient invitées à participer plus tôt à la conception de la solution et à apporter leurs idées. Certains réalisaient des tests, lorsque cela était préférable au regard de l’état de notre flux de travail. Nous étions maintenant dans la même pièce, la collaboration était très forte, la programmation en binôme était devenue une coutume régulière et des binômes souvent fonctionnels & techniques.” Le workflow* de l’équipe Scrum avait donc évolué et était maintenant : En prenant des précisions auprès de Paul, l’équipe avait instauré des limites de WIP sur les étapes d'affinage, de dev et de recette. Les limites de WIP devaient aider à améliorer la focalisation de l’équipe en évitant de démarrer un trop grand nombre de travaux en parallèle, mais aussi à éviter que quelque part dans le workflow une “pénurie”. L’équipe avait donc instauré des limites de WIP optimum, c'est-à-dire à la fois une limite haute à ne pas dépasser, mais également une limite basse à laquelle se maintenir. Le but in fine était de rechercher par expérimentation les meilleures limites qui feraient gagner en performance.    Paul précise : “L'erreur que nous fîmes au début, fut de ne pas limiter aussi les étapes d'attente de dev, d'attente de recette (ou par regroupement d'étapes avec l’étape précédente de travail actif)” Une erreur assez classique, qui génère bien souvent un empilement de travaux en attente, et in fine plus de travaux globalement en cours que le niveau optimum pour l’équipe.   Paul relate que ce problème fut assez rapidement détecté et corrigé, il ajoute : “Tout cela nous amena à une progression nette de notre rapidité à traiter les sujets. On ne le mesurait pas très bien avant, mais avec les données que le chef de projet, hmm pardon notre Product Owner communiquait et les différentes replanifications, nous étions grosso modo entre 30 jours et 90 jours pour boucler une fonctionnalité. Les données que nous collections maintenant nous indiquaient une division par deux du temps de cycle maximum et une variabilité plus réduite (~25-45 jours).”   Une équipe qui avait une volonté d’amélioration continue qui s’ancrait de plus en plus en elle. Ces mesures maintenant fréquentes des temps de cycle et la recherche de l’amélioration de leur performance, les amena à s’intéresser à une métrique encore plus intéressante que le temps de cycle, à savoir l’âge des éléments en cours dans leur flux. Pourquoi encore plus intéressante ? Parce qu’elle les informait bien plus tôt que le temps de cycle (calculé seulement une fois l’élément ayant atteint la fin du workflow), ce qui leur permettait d’avoir les conversations nécessaires plus rapidement pour gérer au mieux la performance de leur flux. Paul nous raconte comment cela est venu : “Nous avions découvert cette métrique au travers du billet de blog : https://caroli.org/en/latency-and-banana/ . L’idée nous avait paru géniale, mais on préféra tout de même compter le nombre de jours sans accrocher de peaux de bananes sur nos post-it… Un peu plus tard, nous apprenions à visualiser le temps de cycle de nos différents éléments sur un graphique en nuages de points et, en y ajoutant des percentiles, nous découvrions la répartition du temps de cycle de nos éléments… 70 % en dessous de 24 jours, 85 % en dessous de 33 jours. Ceci nous conduira à définir un niveau de service attendu (SLE) basé sur nos données historiques et en nous challengeant à faire mieux : 20 jours ou moins à 85 % du temps. Nous couplions cela avec le suivi de l’âge de nos éléments en cours et ce fut un game changer.”   Les limites de WIP que l’équipe avait expérimentées, avaient apporté une amélioration de performance assez minime. Les expériences menées leur avaient apporté parfois des améliorations, mais aussi parfois des régressions, sauf que cela prenait un peu de temps à se voir. Le contrôle de l’âge et le challenge autour du SLE qu’avait choisi l’équipe par contre apporta une amélioration conséquente. De meilleures limites de WIP se dessinèrent même assez naturellement au travers de cette pratique du contrôle de l’âge et du focus à essayer de ne pas dépasser le SLE. Après quelques mois, l’équipe avait largement rempli son challenge et pouvait même se challenger à améliorer encore son SLE.   Elle entreprit cependant une autre amélioration, celle de l’augmentation de la qualité d’utilisabilité de son produit, avec la montée en compétence d’une partie de l’équipe sur l’UX Design. Paul nous raconte cependant une mésaventure sur cette montée en compétence UX : “Nous avions réussi à bien vendre l’apport que cette compétence pouvait avoir pour in fine le bonheur de nos clients et donc le business. La direction et notre représentant métier (Product Owner) avaient du coup très hâte de voir l’apport de ce type de compétences pour le produit, à tel point qu’ils ne nous laissèrent pas appliquer de nous même la compétence que nous avions fraîchement acquise. Ils firent appel à un cabinet de consulting spécialisé et malheureusement cela ajouta une unité distincte de notre équipe et donc une dépendance”. Chapitre 5 : Une bonne idée qui se transforma en dépendance pendant quelques temps Cet ajout amena une dépendance et malheureusement un ralentissement global du système. En effet, cette équipe avait, elle aussi, son propre workflow déconnecté de celui de la Scrum Team. Le Product Owner travaillait en amont avec cette équipe UX externe pour comprendre plus précisément les attentes et les problématiques des clients. Ils réalisaient des prototypes, faisaient des tests utilisateurs avec ces prototypes. Cela malheureusement, prenait pas mal de temps. Paul se souvient bien de cette période, frustré de ne pas mettre à profit ses nouvelles compétences acquises :  “Ils étaient assez haut niveau dans la macroconception de la solution et nous avions toujours besoin lorsque nous récupérions leurs travaux de faire de l'affinage, de découper les grosses features en plus petits morceaux pour avancer itérativement et incrémentalement comme nous avions pris l’habitude de faire. De plus, il n'était pas rare que les prototypes qu’ils avaient testés avec les utilisateurs, nous posaient problème en termes de faisabilité pour les mettre en œuvre. Nous étions dans un silo discovery/delivery.”   Cette volonté de mieux cerner les attentes des clients était louable, car il est vrai qu’il est dommage de développer des choses qui ne sont pas attendues, qui ne vont pas être utilisées, qui vont poser des problèmes d’utilisabilité, mais tout cela avait un coût, et finalement le T2M, le temps de cycle pour livrer des évolutions sur le produit était beaucoup plus court avant.   Paul et l’équipe avaient réussi à savoir combien de temps il s’était écoulé avant qu’un sujet ne leur parvienne :  “Il faut voir que grosso modo avec l'ajout de cette équipe UX/UI externe c'était ~ 2 mois de temps de cycle passé avant que nous récupérions la patate chaude (enfin tiède, voire presque froide, au vu du délai déjà passé). La véritable connaissance de ce que nous apportions comme valeur était du coup retardée de ~ 2 mois, mais nous avions potentiellement quelque chose avec un plus haut niveau d'utilisabilité et quelques hypothèses à valeur faible écartées. La principale problématique à mon sens était la déconnexion du discovery et du delivery, accentuée par le fait que ce n'était que des travaux amont et jamais cet UX Team ne s'appuyait sur le concret en production et dans les mains des utilisateurs pour fermer la boucle d'apprentissage amenant à de nouvelles réflexions UX pour faire évoluer le produit.”   Dans ce positionnement finalement uniquement orienté “business”, dans le sens où ce prestataire répondait à la commande de “discovery” initiale du Product Owner mais sans refermer la boucle d'apprentissage avec le véritable produit et le comportement des utilisateurs en situation réelle, l’organisation était loin de tirer bénéfice de l’UX design.   Paul et les autres personnes de l’équipe qui avaient été formés, avaient bien conscience que le prestataire aurait pu ou aurait dû proposer plus.  Ils avaient perdu une bataille avec l’arrivée de cette équipe UX externe, mais décidèrent de ne pas en rester là. Ils installèrent un outil leur permettant de réaliser de l’analytique produit et ils commencèrent discrètement à analyser les parcours, l’utilisation des fonctionnalités, les points de décrochage, ils mirent des heatmap en place pour voir plus finement dans les pages où circulaient les utilisateurs… Paul nous raconte : “Toutes ces informations étaient extrêmement précieuses, car source d’apprentissage de l’utilisation réelle de notre produit. Je ne comprends toujours pas pourquoi la société d’expert UX n’a pas proposé cela et s’est contentée de ce “discovery” initial, mais bon cela finit finalement par faire notre bonheur. En effet, un jour, nous décidâmes avec quelques autres membres de l’équipe que nous avions suffisamment de billes via les analytiques produits pour ouvrir des discussions sur des fonctionnalités inutilisées, des parcours à améliorer, etc. Pour les parcours que nous avions détectés à améliorer, nous avions fait quelques maquettes de faible fidélité (peu coûteuses) pour proposer des améliorations et avoir un support de discussion. Des éléments qui paieront, car très appréciés des parties prenantes, de la direction et qui permirent d’asseoir notre expertise également en la matière”.   La mission du prestataire UX se termina quelques semaines après et la direction, le Product Owner décidèrent de s’en remettre à l’expertise que l’équipe avait prouvée avoir acquise, en tout cas suffisamment pour ne plus voir le gain à payer une prestation.   Ceci amena une évolution du workflow de l’équipe sur 2 aspects. Premièrement, l’équipe (y compris le Product Owner) décida que le point de fin n’était plus le passage en production pour que le client ait le produit dans les mains. Le point de fin serait maintenant au-delà de cela et se situerait lorsque la collecte du feedback de l’utilisation de la fonctionnalité serait jugée suffisante. Soit pour décider de terminer, soit pour décider de terminer, mais en apportant un nouvel élément en entrée du workflow lié au feedback et à l’apprentissage obtenu de l’utilisation du produit.   Deuxième évolution du workflow sur les aspects de “discovery”. Paul avait suivi récemment la formation Professional Scrum With UX (PSU) et avait compris clairement le concept de dual track agile. En résumé ce concept est le mélange délicat et en continu entre ce qui est nécessaire d’apprendre en amont pour éviter de développer des choses qui ne seraient pas utilisées (ou trop peu) et le développement rapide, se basant sur cet apprentissage, de petits incréments, dans un but également d’apprentissage et de réalimentation de la boucle à l’aide de ces nouvelles connaissances. Ce n’est pas comme beaucoup ont pu le comprendre (et le comprennent peut-être encore), deux processus parallèles, menés par des personnes différentes et qui s’alimentent en discontinuité, en séquentiel (les travaux de discovery des 2 dernières semaines, alimentant le delivery des 2 semaines suivantes), sans tenir compte en continue des apprentissages réalisés au travers de chaque “prisme”.   Avec ces connaissances nouvellement acquises, Paul amena la proposition d’une expérimentation à l’équipe pour visualiser au niveau du workflow ce travail de discovery. “En product management agile, il est crucial de savoir le plus rapidement possible si on a tort, il était donc hors de question pour moi d’amener l’idée d’avoir des éléments de discovery qui circuleraient à côté des éléments de delivery et à faire avant de pouvoir progresser sur le delivery. La majorité du temps, il fallait que ces travaux soient liés au même élément de valeur, pour que cela soit vu comme un tout, où toute l’équipe restait responsable de faire progresser l’élément le plus rapidement possible vers la fin de notre workflow.  Mais d’un autre côté, parfois il pouvait s’avérer nécessaire de faire des études plus poussées et plus longues pour s’assurer que l’hypothèse de valeur était à priori “viable”. J’amenais donc l’expérience suivante à tenter :  La création d’un nouveau type d’élément de valeur qui circulerait dans notre workflow que j’appelais “Etude (discovery)” et qui allait correspondre à ces travaux de discovery plus longs à mener. Pour le reste, je proposais au reste de l’équipe de considérer l’apport des pratiques UX dans les différentes étapes de notre workflow : En affinage, par exemple en ayant rapidement fait une interview de quelques utilisateurs, ou en ayant prototypé rapidement sur le papier quelque chose pour le confronter également à quelques utilisateurs. Ceci nous permettait de démarrer le développement informatique avec quelques améliorations ou ajustements de la solution qu’on envisageait. Pendant le développement et quand cela faisait sens (notamment quand émergeait des interrogations sur l’utilisabilité), on allait continuer à explorer si la solution était adéquate, par exemple sur la base d’un prototype de plus haute fidélité. Lorsque nous arrivions à l’étape de recette, on allait approcher des utilisateurs finaux pour les faire manipuler la nouvelle fonctionnalité et vérifier notamment des points où nous avions des doutes sur l’utilisabilité.”   Ces propositions furent jugées intéressantes et l’équipe s’embarqua dans cette expérimentation. Pour le nouveau type d’élément “Etude discovery”, l’équipe se challengea avec un SLE associé. Ils ne voulaient pas eux même ramener la mauvaise expérience vécue avec le cabinet d’expertise UX externe et décidèrent que cela devait être réalisé la majorité du temps (80%) dans un laps de temps ne dépassant pas les 15 jours. Le workflow* pouvait se représenter de cette façon : L’expérience fut très concluante et renforça encore les liens et la pluridisciplinarité de l’équipe. En effet, des membres qui ne s’étaient pas formés à l’UX Design découvrirent et montèrent en compétence en travaillant de concert avec leurs collègues, l’expertise n’était pas au même niveau, mais cela permettait de réaliser des travaux d’UX ne demandant pas une très grande expertise (récolter des impressions, des feedback sur les maquettes, les proto, par exemple) par quasiment n’importe qui de l’équipe. Toutes ces évolutions, rapprocha l’équipe de plus en plus des utilisateurs finaux, la confiance de la direction dans l’équipe était excellente, son efficacité s’était accrue drastiquement et sa prédictibilité également. Le Product Owner (et une bonne partie de l’équipe) avait été formé sur l’utilisation de leurs données de débit (factuel) pour réaliser des prédictions probabilistes via une simulation de Monte Carlo, qui donnait des résultats beaucoup plus justes et pertinents. La confiance du marketing et des commerciaux s’en trouvait également largement améliorée et les tensions qui pouvaient exister dans le passé, avaient disparu totalement.  Le Product Owner était de plus en plus intégré également à l’équipe, fort de cette expérience et des résultats obtenus, il se vit offrir une opportunité très intéressante dans une autre entreprise qu’il saisissa.  La direction savait qu’elle pouvait compter sur Paul pour le remplacer et lui offrir cette opportunité, qu’il ne se fit pas prier pour accepter. A ce moment là, l’organisation pouvait se décrire de cette manière :  Paul, depuis ce jour, soutenu par le reste de l’équipe tente de résoudre une difficulté freinant encore assez amplement l’efficience de l’équipe à délivrer de la valeur : l'existence de cette unité de gestion de la production et de l’infrastructure technique.   En effet, l’équipe Scrum est toujours dépendante de cette unité pour pouvoir voir les développements réalisés disponibles en production, ce qui leur fait perdre quelques jours avant que les nouveautés ne soient disponibles et qu’ils puissent en tirer des apprentissages. Lorsqu’ils auront réussi à avoir le pouvoir, les droits, les habilitations pour eux même livrer leurs produits, ils seront réellement devenus une Scrum team autonome et pouvant délivrer en flux continu et rapide des nouveautés et améliorations sur leurs produits. Il est à espérer pour eux qu’ils y arriveront et lorsque cela sera le cas l’organisation dans cette business unit pourra se cartographier de la façon suivante :    THE END… ou pas, ça dépendra de votre réaction à vous les lecteurs ;-)   Un grand remerciement à Alexey Krivitsky et Roland Flemm pour avoir créé Org Topologies et leur incroyable classe que j’ai eu la chance de suivre sur Paris en Mars 2024, ainsi qu’à leurs différents feedbacks, précisions et éclaircissements à apporter à cette histoire avant que je ne la publie.  N’hésitez pas à vous intéresser à leur travail ici : https://www.orgtopologies.com/ et à aller en apprendre plus sur Org Topologies avec eux dans l’une de leur formation.   L'histoire complète en un seul bloc est disponible ici au format pdf .

This video details PandaDoc's experience evolving its organizational design using the Large-Scale Scrum (LeSS) framework. Denis Salnikov, Head of Agile Practices at PandaDoc, discusses the company's growth, the challenges faced, and the adaptations made along the way. Key Takeaways: Adapting, Not Just Implementing:  PandaDoc focused on tailoring the organizational design to its specific needs rather than strictly implementing a framework [ 01:08 ]. Company Growth:  Founded in 2011 to automate sales quotes [ 03:38 ], PandaDoc achieved unicorn status with a $1 billion valuation by 2021 [ 04:05 ]. As of the talk, the company has over 800 employees globally, with 350 in product and engineering across 48 teams [ 04:16 ]. Evolution of Organizational Design: Early 2021 (Early Growth):  Implemented LeSS Huge, introducing requirement areas focused on customer profiles. Teams were considered the core organizational unit, emphasizing long-lived, stable teams [ 07:15 ]. The structure included four key requirement areas and a platform requirement area [ 08:29 ]. Late 2022 (Hypergrowth):  With 45 teams, managing the product backlog became challenging for the CTO [ 10:19 ]. The product owner's role shifted to defining investments in requirement areas [ 10:42 ]. An incubation area for new product ideas was introduced [ 11:07 ]. The company also prioritized employee safety by relocating staff from Belarus and Ukraine and shifted to a remote-first work model [ 12:06 , 13:19 ]. Maturation Stage:  The company hypothesized that different requirement areas might have different optimization goals [ 16:51 ]. They aimed to separate structures from people for easier team movement and reduced the number of requirement areas to three [ 17:13 , 17:28 ]. A key focus became addressing accumulated system fatigue within the application and organization [ 17:44 ]. Currently, there are three requirement areas, each with distinct optimization goals [ 20:10 ]. Future Endeavors:  PandaDoc is experimenting to measure and understand the optimal level of adaptivity [ 20:58 ] and is developing a multi-app experience for its customers [ 21:19 ]. Q&A Highlights:  The discussion touched upon measuring adaptivity, separating structures from people, and managing numerous teams with a single product owner [ 21:37 ]. In essence, the video offers an in-depth look at PandaDoc's journey with LeSS, emphasizing the adaptation required during growth and the continuous efforts to optimize their organizational system.

While studying organizational design, we created a visual representation of our findings using the Org Topologies™ Map . When explaining our concepts at various conferences and meetups , some people ask questions about the relationship between the Feature Team Adoption Map (FTAM, as known from LeSS) and Org Topologies™. The purpose of this short write-up is to clarify the similarities and differences between the two. The conclusion is: At first sight, there are some similarities, however, the two graphs serve a different purpose and are used differently. We should not compare them as they are too different. The Feature Team Adoption Map Just to align our thoughts on the Feature Team Adoption Map (FTAM), let's start with a short explanation of what it is and how it is used. I was not able to find a formal definition in the LeSS literature, but I think we are pretty close by saying: “ The feature team adoption map is a graph that displays a product group's capabilities, expressed as the potential technology work scope and the degree of cross-functionality in the teams of that group ”. Although the name Feature Team Adoption Map suggests that this is a tool to map teams, it is not. It is a map that displays organizational capabilities. The FTAM suggests Feature Teams as a building block for adopting an organizational design. Feature teams are defined in LeSS : A feature team is a long-lived, cross-functional, cross-component team that completes many end-to-end customer features—one by one. The FTAM concept looks like this: The FTAM is used in LeSS Huge adoptions to: help in defining the scope of teams when forming feature teams, define the size of an adoption, and set future improvement goals. The FTAM is used at the organizational level and focuses on organizational capability. In LeSS Huge, the change is gradual and may take many years to achieve full capability. The purpose of the FTAM is to map out different stages with timelines for when each change can happen and what that change might look like. At the beginning of a change, the FTAM can be used to set the stage for this process and have a vision and strategy for how to get to perfection. Such mapping can look like the picture below. The current activities or capabilities (horizontal axis) of a product group are mapped in relation to the product technology breakdown (vertical axis). Such mapping could tell us for example that most of the teams in the group code their component and then hand it off to testing teams. The FTAM should be created at the organizational level to analyze the current state of a product group. To get insight into the level of cross-functionality of the product group, the degree of cross-functionality in the teams is studied. Since the cross-functionality happens within each team, "the team" is mentioned on the axes. We have found that understanding FTAM is not easy for a couple of reasons: The FTAM appears to be more than just a map. When applying the FTAM, additional dimensions need to be considered that are not mentioned on the map (e.g. Private-code policies, capability,..) The naming on the FTAM axes is confusing (explicitly referring to single teams while the map is not about single teams but product groups) Explanations on the LeSS website and in the LeSS books are limited. The Org Topologies™ Map Org Topologies™ is a framework-agnostic visual approach to assess, focus, and track organizational development that is built on seven organizational archetypes . We have grouped these archetypes in relation to each other and in relation to an archetype with the highest level of adaptivity possible. The horizontal axis of the Org Topologies™ map describes which capabilities are available in an organizational unit. The scale range is from individual work (no team at all) to perfect teamwork, meaning that a team can deliver a Done product autonomously. The vertical axis shows how the teams are organized among each other. It shows how they collaborate on a larger value domain. In the lowest Y-level, people work on a narrow product scope: the task level. The highest C-level is where everybody in the organization understands and works on any part of the product. The Org Topologies™ map is a thinking tool that aims to help people understand where their group, team, department, or organization is located on their journey toward higher adaptability. The Org Topologies™ map will clarify what real change needs to happen to grow adaptivity in a certain direction. When studying an organizational unit, we map organizational elements (i.e. teams, departments, etc) to one of the sixteen archetypes. For simplicity reasons, we only show the seven most prevalent archetypes here. This mapping allows us to have a conversation about where their unit is located now, what their current challenges are for delivering value, where they want to move to solve these problems, and how impactful this change will be on the development organization. The picture below of the journey of a department at a Dutch bank shows that in their starting position, the bank did not work with stable teams. They had individuals and groups working on tasks (Y0 and Y1), and component teams trying to work on features (A2). Their anticipated goal was to resolve dependencies by moving to the B2 archetype, meaning they planned to create value areas where multi-disciplinary teams deliver customer features. This would require teams to be reshuffled to improve the capabilities of the feature teams (horizontal growth) and would require new practices to work on a product part with groups of teams (vertical growth). There are similarities, When we started exploring the problem space of adaptivity, we had LeSS in the back of our minds. We are LeSS-friendly people because LeSS is a very adaptive approach for product development. The idea that the Org Topologies™ map would be similar to FTAM was an observation we never were aware of until someone asked us about it. We were surprised, as the two tools are very different, although we need to admit that at a first glance, novices might be confused by some obvious similarities. Both graphs: are two-dimensional graphs and have an x-axis and a y-axis talk about teams in the context of product development visualize shifting from component/technology to customer/product-centric specialization have an x-axis that tells something about team capabilities have a y-axis that tells something about collaborating on the product can be used to monitor growth toward a better state of adaptivity plot items against a perfection vision of high adaptivity help to leverage bi-directional team growth to reach a sweet spot both are graphs that are more than just a picture But they are not the same. There are essential differences between the two maps: The FTAM is only used in LeSS Huge adoptions. The Org Topologies™ map is framework agnostic. The FTAM gives insight into the adaptivity of a product group and its anticipated future state. The Org Topologies™ map gives insight into the current and future adaptivity of various types of organizational units (individuals, teams, areas, departments, or organizations. The FTAM shows four areas (component teams, feature teams, extended component teams, and functional overspecialized teams). The Org Topologies™ map describes sixteen archetypes . In the FTAM, the X-axis describes the cross-functionality of a team. and the cross-component-ness of the team is on the Y-axis. The X-axis on the Org Topologies™ map describes both cross-functionality and cross-component-ness. The FTAM template needs to be instantiated in each context where it is used. To explain what instantiating means, find an example of such instantiated FTAM below. Notice that the naming on the axes have been contextualized. The Org Topologies™ map can be used as-is to compare, recognize, and locate your org design in relation to an anticipated perfection goal. Additionaly, this allows us in theory to compare Org Topologies™ maps from different groups, departments and organizations. This is not possible with an FTAM. Example of an instantiated FTAM for the Nakashima product catalog. Notice how the naming on the axes has been changed to reflect the organizational context. Example of two ways to represent an organizational mapping with Org Topologies™. Note how the axes remain unchanged. The red dots in the picture on the right represent teams or people of that archetype that are playing a part in the ecosystem. (More elaborate versions can be created where each red dot is named specifically: team Avengers, Lead Architect, etc). Conclusion The tools are both focussing on the domain of organizational design and in their own way, they try to clarify organizational change. However, we conclude that these tools are very different from each other, and comparing the FTAM with the Org Topologies™ map is like comparing apples with pears. (C) 2023, Alexey Krivitsky and Roland Flemm. Org Topologies™.

This case study by Karl Thomas and Nico Liedl from Deloitte explores a large-scale transformation initiative within a public authority’s SAP department. The department, initially structured in a traditional and hierarchical manner with over 500 employees working in waterfall mode and six annual releases, embarked on a dual transformation journey. On one side was a C-level driven organizational transformation, and on the other, a SAFe-based agile transformation with multiple Agile Release Trains with a Team Topologies design inside. Download the full case study in PDF format here: Outcomes The outcomes of the Org Topologies transformation case with Karl and Liedl were a mix of progress and persistent challenges, highlighting both the power and the limitations of typical agile transformations when not systemically aligned. On the positive side, the SAFe implementation was completed across four waves, resulting in 25 agile teams organized into three Agile Release Trains (ARTs). These teams achieved a CAPS-2 level (formerly A2) in the Org Topologies map. This shift led to tangible benefits such as increased delivery speed, greater team flexibility, and the successful implementation of an agile pilot across an entire business area. Teams began working in shared Program Increments (PIs) and adopted modern methods like Scrum and Kanban. However, deeper organizational alignment was not achieved. Major systemic misfits persisted, such as a misalignment between the organization’s structure and its actual work processes, siloed budget control, a lack of clear ownership, and a significant product gap. While teams had improved locally, the overall ecosystem remained fragmented. The dual transformation approach—one top-down (C-level led) and one bottom-up (SAFe implementation)—was not integrated, leading to confusion and disconnected efforts. In summary, the outcome was that the teams improved operationally (speed and flexibility), but the organization did not yet achieve higher-level adaptability or business agility. The transformation stalled at the CAPS-2 level, and to unlock further gains, a shift toward PART or WHOLE-level archetypes is necessary. This will require a more integrated, systemic change effort guided by Org Topologies’ full MADE method.