ORG TOPOLOGIES™ 

Management Summary  Leaders set business objectives and define strategies to achieve them, yet often lack the tools to sustainably drive organizational performance. The good news is that this can be learned and thoughtfully applied today at organizations. Org Topologies (OT) will help you get the desired change going. How do you define and successfully lead the change that’s right for your organization? Here’s a key point: Different goals—rapid delivery, global adaptability, resource optimization, or amplified innovation—require different and tailored org designs. As a leader, you can define that goal and use the approach offered here to evolve your organization in the chosen direction.  Why does change fail so often? First, existing solutions may seem suitable when analyzed superficially, but, in fact, don’t fit your unique context. Second—an underappreciated factor behind failed change—people, when not owning the change ideas, won’t fully accept them and won’t go the extra mile to make them work. As a result, the promised benefits of change often remain unfulfilled despite all the wasted resources and opportunities. This case study explains how applying Org Topologies ensured that a company was implementing a correct organization design and how OT helped to introduce the change in the product development group. Strategic Org Design What is Org Topologies? Org Topologies (OT), being a strategic org design system, helps you align all the moving pieces so that your (1) business strategy, (2) organizational capabilities, and (3) change process work together cohesively to drive the desired organizational performance. Why Use Org Topologies? When organizations undergo transformations, choosing a framework like SAFe, Spotify, or LeSS alone may not be sufficient. OT helps identify if your new organizational design will genuinely solve the underlying issues or if it will fall short due to overlooked systemic challenges. OT helps companies align their internal structures with business goals, resulting in a performance boost, measurable by faster innovation and efficient delivery of customer value. Customer Case: Elevating XG Customer profile: XG (anonymised for confidentiality purposes), is a scale-up in the EV market. They provide an EV information platform and empower the most ambitious players to meet EV power demands. The challenge at XG  The business was growing fast, but the R&D department could not keep up with the growing demand for features. Although XG was the number one innovator in their market, they noticed that they were losing their pole position. Competitors were catching up in releasing new customer delighters. Growing the number of R&D employees did not solve the problem. The time to market for customer requests increased from weeks to multiple months.  XG management studied the possible causes for the declining delivery speed. Their R&D department consisted of 7 teams, each team responsible for one component of the complete XG solution. Their org design had grown organically over time, with its main driver being clearly defined component ownership by deep specialists. While growing from 8 to 50 people, the R&D group had turned into a collection of isolated silos.  The managing directors agreed on the need to improve the organizational performance. They would need to restructure the processes of the teams at R&D. Middle management (Head of Engineering and Head of Product) were tasked to implement a change to solve the problems.  The solution designed by XG To solve the performance problem, middle management informed themselves on existing frameworks. Before any external consultant was approached, they crafted a custom org structure for the R&D department by themselves. They anticipated implementing key characteristics of the LeSS Framework: removing Product Managers at the team level in favor of three product areas, with each one having a single Product Owner and multiple teams. They designed the product areas by customer type. Each area should work as a team of cross-functional teams. They had designed a new Target Operating Model and were looking for external consultants to implement the TOM and support them in improving their scaled Scrum processes.  Org Topologies It seems XG had found/created a solution that needed no further discussion. However, a closer look at the TOM revealed that implementing it would not result in a sustainable change.  Three observations led to this conclusion:  The TOM design did not completely resolve the root cause of the long time to market. The change was not systemic, meaning it focused only on restructuring R&D and did not yet consider other elements of the organizational design that influence organizational performance. Top management was very supportive, but not involved.  To address these challenges, we used the Org Topologie MADE method (Map Assess, Design, and Elevate) as a guide in our consulting and coaching activities. Map   We used Org Topologies to map the existing design and assess the future TOM. OT Mapping entails determining the prevalent archetype of each org design unit (teams, managers, etc) involved in the value creation chain and plotting them on the OT map.  Org Topologies mapping at XG, existing design The current design shows a Head of Product (H) working at the whole business level. He works with eight Product Managers (items with a P on the map) who work at the capabilities level, each responsible for one team (items with a T on the map, one color representing one capability).  Each team is locked to one component (capability) of the whole solution. And each team depended on (most of) the other teams to deliver customer value (depicted by the lines connecting the teams). Assess Assessing with the OT MADE Method consists of verifying if a design is fit for purpose. In this case, we asked ourselves if the new TOM XG was fit for purpose. Was the new org design the correct solution to achieve the business goals in their market? How well was the design understood, and how well did (upper) management know the change implications? Each org design provides certain organizational capabilities. Org Topologies proposes three recognizable topologies: The Resource Topology, the Delivery Topology, and the Adaptive Topology. The business ambitions and market conditions determine which organizational capabilities most likely support achieving our goals. In the XG case, the market was uncharted, finding new innovative solutions to win customers and being fast in delivering known solutions were required. The Adaptive topology can provide this.  Mapping the existing org design confirmed the root cause for slow value delivery: the dependencies between the teams caused hand-offs and coordination work.  We mapped the TOM proposed by XG. In the new design, the Head of Product works with three Product Owners, each for a specific customer type. Each PO has a group of teams working at the feature capabilities level.  Reducing the number of product managers and elevating them to manage three partial business areas was a great idea. However, having three product areas would not completely solve the inter-team dependency problem since product backlog items might span multiple areas. The middle managers acknowledged this problem, but this sub-optimal design was deemed to be a great improvement considering the component landscape they were coming from. Creating a single Backlog for the whole company was too big of a stretch for upper management at that moment in time. Design The Design phase explores options to consider which topology could best be implemented in which part of the business.  Mapping and assessing the XG target design demonstrated that the proposed TOM was the Adaptive Topology. They designed three product areas containing cross-component and cross-functional teams that worked as a team of teams per business area. Each team had the capabilities of delivering end-to-end functionality at the business area level. Note that the colors of the three teams in the new design are similar, since their only level of specialization is the focus on their business area.    Final design at XG Understanding how the new TOM would or would not improve the performance before the change is implemented is a great win. Discussions showed there was insufficient understanding at XG of how the adaptive org design would work in practice and that it was unclear what was needed to elevate the existing org design to the new TOM.  The Org Topologies mappings of the existing and proposed designs were extremely helpful in the sessions where we communicated the change with the development group. They had heard about the change initiative, but did not have a concrete idea of what the change would be like. Especially, the formation of new cross-functional teams was unknown to them. And yet, this was the most impactful change that would hit the teams. The mappings transparently explained that the existing component team ownership would be broken and replaced by end-to-end capable teams. Explaining the existing component team dynamics with the map, visualizing the inter-team dependencies, was a feast of recognition for the development group. Talking about expanding the mandate on skills and scope of work created the understanding of how to move forward to end their dependency hell. Explaining the current and future situation using the map has become an ongoing activity. Learning simply takes time and repetition. Elevate   The last step in the MADE method is Elvate. The Elevating Katas answer the question “But how are we going to do it?”. It is a rich set of practices that bring the ongoing transformation effort into business as usual.  We prepared the existing teams to be ready to work in the new business area team of teams. We flipped the organization in two days. We ensured everybody had time to work on the change preparations while the business as usual was going on before the flip. Time and effort were spent learning and preparing at the cost of a productivity loss. This is a necessary investment: slow down now to accelerate later.  We applied the following Elevating Katas to enable the flip to the new design:  Single product backlog at the partial business level Elevate three team PMs to partial business POs Promote remaining team PMs to become product developers Self-design team workshop to create new teams per area Elevate the Definition of Done to the whole business level Practice multi-team product backlog refinement sessions After the flip, the change work needed to continue using the Elevating Katas to execute smaller experiments to further improve the development system: Pair programming Mob programming Opening all repositories Communities of practice Code mentorship Integration test automation Architecture and knowledge sessions The results When the teams started working in the new setup, the performance increased dramatically.  Happiness has gone up for almost all employees. However, some devs have difficulty accepting shared code ownership and broadening the mandate on the business domain. Some single-skill specialists struggled to find their new purpose outside of their comfort zone. Initially, upper management was thinking lightly of the impact of the anticipated (process) changes in R&D. During the change process, they started seeing the impact of the transformation and the need for employee buy-in to embark on a never-ending journey of continuous improvement. They enjoyed the energy of the people crafting their journey within the boundaries set by management. The Support department was onboarded and included in the change, not only to manage their expectations, but also to involve them during refinements and Sprint Reviews. The Map, Assess, Design, and Elevate steps brought the client from supporting the change initiative by funding it, to being involved by understanding the change. The MADE method revealed omissions in the target design and demonstrated the complexity of the change..  We used the OT mapping in various workshops to explain to the employees the current design and the new org design. The visualizations are a powerful means of communication to bring understanding of the why and what of the change. We emphasized that elevating a development group impacts how the company sells its product, hires new people, provides support, and manages its human capital. Org Topologies elevated managers and employees to become systems thinkers.

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

Introduction Any organization can be analyzed using the Org Topologies™ map. On this map, the Holy Grail is at the top right, representing an organization capable of adapting ultra-rapidly to face any opportunity thrown its way. An organization also capable of delivering value to its customers quickly and efficiently. Figure 1 : Org Topologies Map Startups generally fall into this category, and if they don't, they don't last very long in this highly competitive world, where it's crucial to perform at a very high level. A level where the consumption of the few resources available enables you to quickly find the product that the first customers will love and that will keep the adventure going. As a small organization grows, the general tendency is to segment responsibilities. Departments specializing in different areas are created (marketing, sales, after-sales, etc.), with a consequent reduction in adaptability and in the ability to deliver value quickly and cost-effectively. The growth of an organization tends to take it towards the lower left-hand zone of the map, where the teams and individuals making it up no longer have a holistic vision of what is best to do for current customers and to continue to prosper by reaching new markets, for example. In this article, we'll follow the story of Paul, a consultant specializing in digital application testing at the start of his career. On an assignment, Paul joins an organization with multiple departments, scattered teams and individuals, that require a lot of coordination to ultimately serve the company's customers. In this story, you'll see how this organization, and more specifically the business unit Paul joins, embarks on a path to regain the holy grail, notably by relying on the Kanban strategy. Chapter 1 : The beginning The business unit Paul joins, delivering digital services to its customers, is a collective of around 50 people. These 50 people cover all the skills needed to deliver a digital product to some of the company's customers (Business, IT, Marketing, Sales, Hotline, etc.). This business unit is located within a larger company serving other products and services, for a wider panel of customers. Using the 4 vertical strata of Org Topologies mapping (C, B, A ,Y), this would give this form of representation: Figure 2: The company as a whole in the vertical hierarchy of org topologies The story that will be told throughout these chapters focuses on the business unit X that Paul joins. The organizational situation of this business unit when Paul joins the company is represented on the following Org Topologies™ map: Figure 3: Representation of the business unit Paul joins, with mapping of Org Topologies™ Links between individuals or teams (pseudo-teams) are represented by connectors. This organization is highly siloed, with no member of the sales group (C1), who is closest to the customer, ever communicating with the product development group (A1). To act as an interface between the salespeople busy in the field selling the various products and services the company offers, and the people developing the product, the organization has chosen to place several business contacts (B0), each with their own area of responsibility (marketing project manager for X-type customers, another for Y-type customers, etc.). There isn't one coherent unit sharing knowledge, but X number of distinct interlocutors with their own dedicated business knowledge. These people find themselves without a global, customer-oriented vision, but with a partial vision centered on their business domain, their customer domain. The hotline (B1) has a broader, more shared knowledge base, with its members dealing with all types of customers and all kinds of problems, but it responds and unblocks situations on a case-by-case basis, without having the decision-making power and capacity for action to bring about lasting changes that benefit customers. In this situation, a lot of coordination is required between these different actors, and inevitably a lot of useful information is lost so that the right decisions can be made for the business and the best possible service can be provided to customers. These people don't have the skills to maintain and develop the product. They will rely on an IT department, generally divided into two parts, Business Analyst and Coder. In this case, a group of people with skills linking business and IT will analyze the problems and needs raised by the Hotline or by business contacts. It's also not uncommon for this group to consist of people who are highly specialized in specific business fields, but who can't all address the issues of different customer groups. The organization presented here is such a case, with its Business Analysts (B0) specialized in specific fields. Paul is assigned to join a group specialized in testing, the QA unit (A0). This group acts as a reinforcement, freeing up the BAs' bandwidth so that they can focus on understanding needs and issues, and manage "big" projects as IT project managers. A group of testers with missions often specific to non-regression test batteries. A frenetic pace of testing that leaves no room for knowledge sharing, leading people to specialize in parts of the application. Paul has a hard time getting to grips with his mission, as his colleagues are not available to help him understand how the application works and all its subtleties. Fortunately, there's a lot of documentation available, and after a few weeks he's able to find his way.  In view of future developments, an IT project manager (B0) asked him to focus on one part of the application. Obviously, the organization has equipped itself with IT developers (the digital product isn't going to be built by magic!), these developers form a unit often siloed into specific areas of competence (A1). This is the case in the organization Paul joins, where knowledge sharing is rare and peer-programming non-existent. A unit where each developer, according to his or her specialization on the application, takes bits and pieces of the specifications written by the BAs in order to code the evolution or the correction. The organization has chosen to call on an external technical skills center (Y1) to manage fluctuating IT development skills requirements. The company's strategy is to control the increase in its payroll for technical skills, fearing a drop in activity around these skills in the future. They do not want to have dozens of employees to whom no activities can be entrusted. Between poorly drawn-up contracts and IT security constraints, this technical skills center finds itself carrying out corrective rather than evolutionary tasks, and submitting deliverables that must then be integrated by the internal development team. Finally, to deliver the application in production, carry out technical monitoring and ensure infrastructure maintenance and evolution, the organization has specialists in a dedicated unit (Y1). Paul regrets not being in touch with the business contacts or the hotline. Instead, it's the BAs and IT project managers (B0) who receive the problems and, when necessary, pass them on to Paul's unit. He sincerely believes that he could better understand the bugs found and more easily reproduce them to help developers correct them. He's already mentioned the subject several times, but nothing has changed. An organization that sets up numerous committees to coordinate the various teams and individuals, requires many hours of reporting preparation and spends many hours in these meetings. Paul has to keep track of the bug counters, the percentage of remaining test cases, and an assessment of the time remaining to complete the tests he has been asked to perform. A complicated task for him since, if he detects a bug, he is often unable to continue because the bug needs to be fixed first. Since he has no idea how long the fix will take, he commits himself to other test work. As a result, it can take a long time to get back to what was interrupted a few days later. At least, he says to himself, " I'm becoming more and more proficient across the entire application. " He wonders on what basis the IT project managers communicate landing dates for the various projects. It seems to him that this is done on a gut feeling rather than on factual elements. Of course, there are Gantt charts and schedules, but there are always unforeseen events, such as bugs or setbacks, which he detects and which upset the plans. A type of organization that you may have known, or in which you are currently involved in some way. An inefficient, ineffective, and unpredictable organization. For this organization, schedule slippages are constant. Announcements of corrections and new features are communicated to customers but are hardly ever kept. Customer dissatisfaction is on the rise, to a level that is becoming critical to the business, and this is not something that management can afford to ignore. It is absolutely vital for this organization to increase its ability to respond faster and more predictably. We'll continue Paul's adventures in this organization in the next chapter... Chapter 2 : Redesign project and initial organizatio nal changes What's more, the organization, which was far from efficient, had dragged the digital application into a major technical debt. Customers were suffering the consequences, with critical incidents becoming increasingly frequent. Paul was also paying the price, with more and more non-regression tests being pushed to the tester unit, hoping to avoid bringing major problems into the hands of users. With this in mind, and with increasing feedback that the organization was not efficient, management decided to launch a major overhaul project.  They took the opportunity to make a few organizational changes to bring together the people whose objective was to carry out this project. The BAs/IT Project Managers (B0) merged with QA (A0), to form a functional unit (B1) (For the time being, this unit will be referred to as the BA unit). Paul, who had acquired a great deal of knowledge in the area, was offered the chance to join the team and terminate with consultancy. The idea appealed to him all the more as, at the business contact level, management had taken steps to federate a customer knowledge unit around one person, a business project manager (C0).  Figure 4: Representation of the business unit after the first modification Through her work with sales, marketing, hotline staff and, of course, customers, this person would quickly acquire a broad knowledge of customer expectations and issues. She would also work closely with Paul's team to bring meaning to the work carried out and prioritize the most relevant developments in relation to what was expected by customers. Paul had never had the opportunity to talk to someone who made him so aware of customer expectations, and his motivation, and that of his colleagues quickly became much greater. In his previous experience, Paul had seen teams using physical visual management to manage their projects. He suggested that the rest of his BA unit implement visual management. Paul's idea and the collaboration with the rest of the unit led them to set up a simple "To do", "In progress", "Pending", "Finished" workflow. The development unit had also heard about this approach, and Paul remembers that they had implemented much the same thing. Paul discovered a little later that they had initiated the implementation of a Kanban strategy (see here for the official Kanban guide : https://kanbanguides.org/english/ ), however : " We were clearly not in a Kanban strategy, simply because at that time nobody knew what had been set up at Corbis* and the emergence of Kanban for the product management field. If that had been the case, we certainly wouldn't have had this column ("Pending"). Moreover, we didn't have any very explicit rules for pulling elements to the next states, so there was a lot of implicit in this workflow. Finally, we lacked all the other elements of a true Kanban strategy. How to control work-in-process? Explicit pull policies, a service level expectation, etc. At that time, we could and should have merged our workflows to have a global view of what was going on, because in the end, when we (BA) finished something, it was a specification, an explanation of a bug that we gave to the dev team, and which for them would then appear in their "To Do" list.  When they finished, it would come back to us (BA) for testing. We would then enter a test ticket that would go through our workflow (hence the pending column we used when a bug was found and we were waiting for a fix to be delivered to resume testing). " *If you want to know more about the birth of Kanban for product management that happened at Corbis (a Bill Gates company), the story is very well told in the Kanban pocket guide ( https://prokanban.org/kpg/ ). If these two units had juxtaposed their workflow, they would have obtained something like : Figure 5: The initial workflow and the evolution of the elements after a few weeks This juxtaposition made it difficult to get an end-to-end view of how long it took the team to complete a project that customers were waiting for, or that was useful as part of the application redesign.  Paul explains: " We sometimes had as many as 4 or 5 round trips with corrections to be made and new tests to be run, as many post-it notes circulating on our visual management. We had added creation dates to our tickets, but if we wanted to know how long it had taken to develop, test and correct the Dev A, we had trouble getting this information. The simple implementation of this had a significant gain in terms of visibility in each unit of what needed to be done, of what was in progress. Collaboration within our units had become better, and people were increasingly able to intervene globally on the existing application, but also on the new one we were building ". On the other hand, Paul reports that the business project manager was regularly annoyed because it was impossible for him to get clear information on when a subject was going to be completed. He could see that a lot of work had been done, and that progress was being made, but if he wanted to communicate to management or customers when the F functionality was going to be released, he still couldn't get accurate answers. This meant that he had to revisit his communication on a regular basis. The time actually taken to complete a feature was often well in excess of the initial estimate... and unfortunately not in the right direction, often taking several weeks. Management, for its part, was beginning to doubt the team's ability to successfully complete the redesign project, with numerous schedule slippages occurring again and again. Paul: "The increasingly frequent irritation of the business project manager and the doubts of management (which came down to us in the form of pressure) made us feel strongly that we had a major area for improvement to implement quickly. In discussions with colleagues from the BA unit and the development unit, we saw the need to break down our silos and become a single, multi-skilled unit, aligned around a single short-term objective, in order to reassure ourselves of our ability to complete the project successfully. We also hoped that this would give us an overview that would enable us to be more reliable in our answers to the “When?” questions we were often asked... " Chapter 3: The birth of a Scrum Team This willingness of two separate units to work together to improve the overall performance of digital product creation was somewhat accepted by management. Not without a considerable effort, particularly on Paul's part, to convince everyone that the experiment was worth trying. This new unit was obviously expected to deliver on the expected results of this experiment, particularly in terms of improving Time to Market (T2M).  This T2M was clearly the cycle time, but the team used this name, better understood by management, to sell the experience they wanted to achieve. Figure 6: Representation of the business unit after the second modification Paul relates that this organizational evolution brought about two things: "The "business" project manager more or less integrated the team into a Product Owner accountability. I say more or less because we were in the early days of Scrum. If today, in many places, Scrum is still not properly implemented, particularly around the PO role, I'll leave you to imagine what differences this PO role had at the time (and we're talking about the years ~2010) with that of a project manager (spoiler alert: nothing or almost nothing).  Together with the in-house developers, we (BA) formed the Scrum development team (yes, that's what it was called back then, so I'm allowed to say it!). We had a great ticketing tool. Great is ironic, because it's certainly responsible for a lot of the mistakes we made when defining our unified team workflow: Figure 7: Unified workflow following organizational change We finally had a more global, unified view of what we were doing to create value."   You may have noticed that the "pending" column was still present with this unification of workflows by merging the two entities.  Paul explains why: "Well, for us at least, it was very clear because we weren't yet a team, but just a group of people with almost all the necessary skills, but still talking about Business Analyst People, Technical People and passing the hot potato back and forth. So yes, we always had this pending column mainly meaning that we were waiting for the technical people to correct a detected problem."   A bad practice, at least if you hope to achieve a high-performance flow! (But so common in an organization with silos). In fact, each silo can be seen as a dependency, through which each element of potential value has to pass before finally reaching the hands of the end-user. Each dependency is a point where the flow breaks down, with elements potentially (and frequently) piling up and aging. As a result, these silos lead to an increase in the number of items in progress, as, for example, the "Business Analyst People" start additional work while awaiting either developments or corrections. Contextual changes are numerous, which also leads to a loss of efficiency, due to the not-inconsiderable cost in terms of time spent going back over elements. A serious study on the subject of context switching showed that by switching contexts between 2 subjects, around 20% of time was lost, and 40% of time was lost by pursuing 3 subjects at the same time (see: https://www.scrum.org/resources/blog/financial-cost-task-switching ).   Even so, after a few weeks of experimentation, this fusions began to show positive signs. Both in terms of T2M, as measured by the Product Owner-to-be, a downward trend was visible, but also on the quality of what was being produced. Indeed, this fusion had sometimes (unfortunately not yet regularly) led to collaborative workshops between the different skills to understand the expectations, the problems to be solved and to find the best solution together. Technical skills were thus able to better grasp what was expected, enabling them to make proposals (and no longer code without trying to understand why), which collectively enabled more qualitative increments to be implemented. However, there was still one notable point of inefficiency in this organization, and that was around an external development unit devloping software for the service center. Paul makes the point very well: "In fact, in this workflow, if you zoomed in on "Development" you could see that things were no longer within our unified team, but on the side of this service center. The work they were doing had to be integrated. We added an integration stage before the acceptance stage to make this transparent. The data collected clearly showed a point of inefficiency, which helped us to support management's need to address the issue. "   When the opportunity arose to change the service center, Paul and his colleagues managed to convince management to make a few changes to the contract and internal process. Not without difficulty, they succeeded in getting this additional coding force to join their Scrum team and to work on the product in the same way as anyone else.This reduced dependency aligned these people with a common objective and increased the collective intelligence to come up with the best possible solutions. In the end, both the service provider and the people involved were more committed, because they were faced with problems to solve that made sense to end-users (instead of "peeing" code without understanding why).   A change that clearly paid off, as you'll discover in the next chapter. Ch apter 4: Ramping up the Kanban strategy With a little patience, a little effort, and a lot of dialogue, Paul and his team sealed a collective spirit of unity.  They were making progress in their understanding of Scrum, but also of the Kanban strategy. They began measuring cycle times and experimenting with WIP limitations in an effort to optimize their workflows. In creating the team's DoD, they unfortunately still were not allowed to go into production. This last step was always carried out by the infra-Prod people (Y1) outside their team. Paul says: " We no longer saw work items as something we passed on to each other, but as something we had to finish as quickly as possible together. We helped each other, both functionally and technically, with whatever skills we individually had. For example, the functional people had learned how to carry out automated tests, and not just through the GUIs, we went as far as automating tests at API level. People with technical skills were invited to participate earlier in the design of the solution and contribute their ideas. Some of them carried out tests, when this was preferable given the state of our workflow. We were now in the same room, collaboration was very strong, pair programming had become a regular custom and pairs often functional & technical." Figure 8: Representation of the business unit after the third evolution The Scrum team's workflow* had thus evolved and was now :  Figure 9: Workflow evolution following this third upgrade * For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing). By checking with Paul, the team had established WIP limits on the refinement, dev and acceptance stages. The WIP limits were intended to help improve the team's focus by avoiding starting too many jobs in parallel, but also to avoid a "shortage" somewhere in the workflow. The team therefore established optimum WIP limits, i.e. both an upper limit not to be exceeded, and a lower limit to be maintained. Ultimately, the aim was to experimentally find the best limits to improve performance.  Paul: "The mistake we made at the beginning was not to also limit the stages of waiting for dev, waiting for test (or by grouping stages with the previous stage of active work)". This is a classic mistake, which often results in a pile of pending work, and ultimately more work in progress than the optimum level for the team. Paul reports that this problem was quickly detected and corrected, adding: " All this led to a clear improvement in our speed of processing. We didn't measure it very well before, but with the data that the project manager, hmm sorry our Product Owner, was communicating and the various reschedules, we were roughly between 30 days and 90 days to complete a feature. The data we're now collecting showed us a halving of the maximum cycle time and reduced variability (~25-45 days). " These now frequent measurements of cycle times, and the quest to improve their performance, led them to look at an even more interesting metric than cycle time: the age of the current elements in their flow. Why even more interesting? Because it informed them much earlier than the cycle time (calculated only once the item had reached the end of the workflow), enabling them to have the necessary conversations more quickly to best manage the performance of their workflow. Paul tells us how it came about: "We discovered this metric through the blog post: https://caroli.org/en/latency-and-banana/ . The idea seemed brilliant, but we preferred to count the number of days without hanging banana peels on our post-its... A little later, we learned how to visualize the cycle time of our various components on a scatter plot and, by adding percentiles, we discovered the distribution of the cycle time of our components... 70% under 24 days, 85% under 33 days. This will lead us to define a Service Level Expectation (SLE) based on our historical data and challenge us to do better: 20 days or less 85% of the time was the one we chose. We coupled that with tracking the age of our current elements and it was a game changer." The limits of WIP that the team had experimented with had brought a fairly minimal improvement in performance. The experiments carried out had sometimes brought improvements, but also sometimes regressions, except that it took little time to assess. Age control and the Service Level Expectation (SLE) the team had chosen, on the other hand, brought a substantial improvement. Better WIP limits even emerged quite naturally through the practice of age control and the focus on trying not to exceed the SLE. After a few months, the team had more than met its challenge and could even challenge itself to further improve its SLE. However, it also undertook another improvement, that of increasing the usability quality of its product, by training part of the team in UX Design. However, Paul tells us about one of his misadventures with UX skills: " We had succeeded in selling the contribution this skill could make to our customers' happiness, and therefore to our business. Management and our business representative (Product Owner) were so anxious to see the contribution this type of skill could make to the product, that they wouldn't let us apply our newly-acquired skills on our own. They called in a specialist consulting firm, and unfortunately this added a separate unit to our team, and therefore a unthoughtful dependency ". Chapter 5: A good idea that turned into a dependency for a while (thus a flow killer) This addition led to dependency and, unfortunately, an overall slowdown of the system. This team had its own workflow, disconnected from that of the Scrum Team. The Product Owner worked upstream with this external UX team to understand more precisely the customer's expectations and issues. They would produce prototypes, and carry out user tests with these prototypes. Unfortunately, this took up a lot of time. Figure 10: Mapping org topologies after the fourth evolution Paul remembers this period well, frustrated at not being able to put his newly acquired skills to good use:  "They were quite high-level in the macro-design of the solution, and we always needed when we got their work back to do some fine-tuning, chopping up the big features into smaller pieces to move forward iteratively and incrementally as we'd become accustomed to doing. What's more, it wasn't unusual for the prototypes they had tested with users to be a problem for us in terms of functional or technical feasibility. We were in a discovery/delivery silo." This can be seen in the Org Topologies™ Map on the vertical axis : Figure 11: Another view of the Org Topologies™ map This desire to better understand customer expectations was commendable, because it's true that it's a shame to develop things that aren't expected by the customer, that aren't going to be used, that are going to create usability problems, but all this had a cost, and in the end T2M, the cycle time for delivering product evolutions, was much shorter before. Paul and the team had managed to find out how long it took before a subject reached them:  "You have to see that roughly with the addition of this external UX/UI team it was ~ 2 months of cycle time spent before we got the hot potato back (if not almost cold, considering the delay already passed). The real knowledge of what we were bringing in terms of value was thus delayed by ~ 2 months, but we potentially had something with a higher level of usability and a few low-value hypotheses discarded. The main problem, in my opinion, was the disconnect between discovery and delivery, accentuated by the fact that it was all upstream work and this UX Team never drew on the concrete in production and in the hands of users to close the learning loop leading to new UX reflections to improve the product." In this ultimately business-oriented positioning, in the sense that the service provider responded to the Product Owner's initial "discovery" order, but without closing the learning loop with the real product and real-life user behavior, the organization was far from reaping the benefits of UX design. Paul and the other team members who had been trained were well aware that the UX service provider could or should have offered more.  They had lost a battle with the arrival of this external UX team, but decided not to stop there. They installed a product analytics tool and began to discreetly analyze user journeys, feature usage and dropout points, and set up heatmaps to take a closer look at the pages where users were circulating in and where they were clicking... Paul tells us: "All this information was extremely valuable, as it enabled us to learn how users actually used our product. I still don't understand why the UX expert company didn't offer this and settled for this initial "discovery", but in the end it made us happy. Indeed, one day, we decided with a few other team members that we had enough marbles via product analytics to open discussions on unused functionalities, paths to be improved, and so on. Where we identified areas for improvement, we produced a few low-fidelity (and inexpensive) mock-ups to suggest improvements and provide a basis for discussion. These elements paid off, as they were much appreciated by the stakeholders and management, and enabled us to establish our expertise in this field too". The UX service provider's mission came to an end a few weeks later, and management and the Product Owner decided to rely on the expertise that the team had proven to have acquired, at least at a level where they weren’t seeing the benefit of paying for an external service. This led to an evolution of the team's workflow in two aspects. Firstly, the team (including the Product Owner) decided that the endpoint was no longer when the product went into production and was in the hands of the customer. The endpoint would now be beyond that and would be when the collection of feedback from the use of the functionality was deemed sufficient. Either to decide to finish, or to decide to finish but with a new input to the workflow linked to the feedback and learning gained from using the product. Second workflow evolution on "discovery" aspects. Paul had recently taken the Professional Scrum With UX (PSU) course and clearly understood the concept of agile dual track. In a nutshell, this concept is the delicate, ongoing mix between what needs to be learned upstream to avoid developing things that won't be used (or almost not used) and fast development, based on this learning, of small increments. Providing fast learning loop and enabling the refillment of idea and evolution based on this new knowledge. It's not, as many may have understood (and perhaps still do), two parallel processes, carried out by different people and feeding into each other in a discontinuous, sequential fashion (the discovery work of the last 2 weeks, feeding into the delivery of the following 2 weeks), with no ongoing consideration of the learning achieved through each "prism". With this newly acquired knowledge, Paul proposed an experiment to the team to visualize this discovery work at workflow level. " In agile product management, it's crucial to know as quickly as possible if you're wrong, so it was beyond me to bring in the idea of having discovery items circulating alongside delivery items that needed to be done before we could progress on delivery. Most of the time, this work had to be linked to the same element of value, so that it was seen as one unit of value, where the whole team remained responsible for flowing the element as quickly as possible towards the end of our workflow.  But on the other hand, sometimes it was necessary to carry out more in-depth and longer studies to ensure that the value hypothesis was viable. So I brought the following experiment to try:  The creation of a new type of value item that would circulate in our workflow, which I called "Study (discovery)" and which would correspond to this longer discovery work. For the rest, I suggested to the team that they consider the contribution of UX practices in the various stages of our workflow: Refining, for example by quickly interviewing a few users, or quickly prototyping something on paper and testing it with a few users. This enabled us to start the IT development with a few improvements or adjustments to the solution we had in mind. During development, and when it made sense (especially when questions about usability emerged), we would continue to explore whether the solution was appropriate, for example on the basis of a higher-fidelity prototype. When we got to the acceptance stage, we would approach end-users to have them handle the new functionality, and in particular check points where we had doubts about usability." These proposals were deemed interesting, and the team embarked on the experiment. For the new "Study Discovery" element type, the team challenged themselves with an associated Service Level Expectation (SLE). They didn't want to bring back the bad experience they'd had with the external UX consultancy themselves, and decided that this should be carried out the majority of the time (80%) within a timeframe of no more than 15 days. The workflow* could be represented as follows:  Figure 12: Workflow definition after the fifth evolution * For the sake of readability, not all the elements of a workflow definition for a professional Kanban strategy are shown here (refer to the Kanban guide to understand what's missing). The experience was highly conclusive, and further strengthened the team's links and pluridisciplinarity. The expertise wasn't at the same level, but this meant that UX work that didn't require a great deal of expertise (collecting impressions and feedback on mock-ups and prototypes, for example) could be carried out by virtually anyone in the team. All these developments brought the team closer to the end-users, management's confidence in the team was excellent, its efficiency had increased drastically and so had its predictability. The Product Owner (and a good part of the team) had been trained to use their (factual) throughput data to make probabilistic predictions via Monte Carlo simulation, which gave much more accurate and relevant results. Confidence between marketing and sales was also greatly improved, and any tensions that may have existed in the past had completely disappeared.  The Product Owner was also increasingly integrated into the team, and on the strength of this experience and the results obtained, he was offered a very interesting opportunity in another company, which he seized.  Management knew they could count on Paul to step in and offer him this opportunity, which he was quick to accept. At that time, the organization could be described as follows:  Figure 13: Mapping org topologies after the fifth evolution Paul, supported by the rest of the team, has been working ever since to resolve a difficulty that is still largely hampering the team's ability to deliver value: the existence of this production and technical infrastructure management unit. Indeed, the Scrum team is always dependent on this unit to be able to see completed developments available in production, which means they lose a few days before the new features are available and they can learn from them. Once they have the power, the permissions and authorizations to deliver their products themselves, they will truly have become an autonomous Scrum team, able to deliver a continuous and rapid flow of new valuable elements. Hopefully, they will succeed, and when they do, the organization in this business unit can be mapped as follows:  Figure 14: Mapping org topologies after the sixth, possibly upcoming, evolution THE END... or not, depending on how you readers react ;-) A big thank you to Alexey Krivitsky and Roland Flemm for creating Org Topologies™ and their incredible OTP class that I was lucky enough to follow on Paris in March 2024, as well as to their various feedbacks, clarifications and clarifications to bring to this story before I publish it.  Elevating Katas (addition of December 2024 by Alexey Krivitsky): This article by José 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 Experience Report on Business Agility with Org Topologies and Kanban: Forming Cross-Functional, Customer-Oriented Teams Transitioning from separate specialist units (BAs, QA, Dev) to more integrated teams capable of handling end-to-end work. Repeatedly merging previously siloed roles encourages shared understanding, reduces handoffs, and aligns everyone around a common goal—improving flow and predictability. Unified and Evolving Workflows (Kanban Strategy) Introducing a visual workflow and continuously refining it with techniques like WIP limits, tracking work item age, and establishing Service Level Expectations (SLEs). Each iterative adjustment of the Kanban system and the workflow—removing “pending” columns, merging steps, and controlling WIP—forms a kata of ongoing operational improvement. Integrating Discovery and Delivery Practices Moving from upstream “big batch” UX/design activities and long, disconnected cycles to a “dual-track” model. By repeatedly incorporating small-scale discovery tasks directly into the same workflow as delivery, the team runs continuous experiments. Over time, this kata improves their ability to learn quickly from real usage and adapt solutions faster, reducing waste and cycle times. Data-Driven Continuous Improvement Routinely measuring cycle time, variability, and throughput to guide improvements. Using product analytics, user feedback, and metrics-based decision-making becomes a kata—repeated cycles of gathering data, reflecting, and refining the approach. This ensures that changes aren’t based on guesswork but on evidence and measurable outcomes. Gradual Removal of Dependencies and External Silos Systematically integrating external providers (e.g., external development service centers, UX consultancies) into the core team or phasing them out. Repeated attempts to reduce external dependencies—such as enabling the team to deploy directly to production—constitute a kata that steadily elevates the organization toward greater autonomy, responsiveness, and continuous delivery capability. More on Elevating Katas here .

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 .

I recently co-authored a case study about our journey at Strobbo over the past few years: ‘Strobbo Adopts Professional Scrum to Accelerate Go-to-Market’ . Alongside my colleague Bert Neels , our agile coach Steven Deneir , and the fantastic team at Scrum.org , we delve into the challenges we faced and how we overcame them over 12 to 18 months. And believe me, it wasn’t always smooth sailing! Even after contributing to the document and recording a podcast about it, I still feel like there is more to share about our story. In this document, I aim to explore our journey through the lens of organizational design using Org Topologies. This approach provides a structured map to navigating the complexities of teamwork and organizational structure. How did we reconfigure our team  dynamics? What organizational structures helped us thrive? It’s like assembling a detailed jigsaw puzzle where every piece is crucial.  Background on Strobbo Strobbo is an HR platform that automates the administration of flexible workers. It offers an all-in-one solution for managing availability, staff scheduling, time tracking, Dimonas (social security declarations in Belgium), contracts, and monthly payments across various sectors, including hospitality, retail, and the funeral industry. Strobbo integrates with existing tools like cash register systems, enabling quick analysis of turnover and staff costs through its reporting module. The platform also connects with reservation systems and weather forecasts to optimize staff scheduling and links with payroll systems for seamless payroll processing. Founded as "Onlinewerkrooster" in 2016 in Lommel, Belgium, by Nick and Bert, who identified a need for flexible staff scheduling in the hospitality sector, Strobbo addressed issues related to the white cash register system aimed at preventing tax evasion. By 2018, it had a team of 9, serving 500 businesses, and was acquired by Protime, a European workforce management specialist, to accelerate international growth. Rebranded as Strobbo in 2020, the company expanded internationally, supported by a growing team. Today, over 2,000 businesses in Belgium and beyond rely on Strobbo for automating personnel administration. Introduction to Org Topologies Since we will be using Org Topologies to analyze our organizational design, I will first introduce some of the basics. What follows below is just the bare minimum to understand the rest of this chapter. For a more detailed introduction, I can recommend reading the Org Topologies Primer . The map contains sixteen archetypes each with their own characteristics, and they are named with a letter (Y, A, B, C) and a number (0, 1, 2, 3). The horizontal axis of the Org Topologies map represents the scope of capabilities of a unit in your organization. The more an organizational unit moves to the right, the faster it will be able to deliver value. We distinguish 4 different types:  0: single-skill individual(s)  1: functional unit(s), i.e., a group of individuals with similar skills who typically perform the same function. This is often not yet a team as everyone is working on their own tasks.  2: multi-skill unit(s) or cross-functional team(s) that can tackle more complex work. There are still dependencies on other organizational units to complete their work.  3: fast-flow unit(s) that can deliver end-to-end value without being held back by asynchronous dependencies. The vertical axis indicates the scope of work in which the organizational units collaborate and share work. The higher you move up the axis, the closer the unit is to the customer and they will actually start working on customer problems and not solutions:   Y: task focus, i.e. the unit receives tasks to work on.  A: feature focus, i.e. the unit receives work as features that need to be built.  B: business area focus, e.g. the units might work for goals stated by a given business department.  C: whole business focus, e.g. the units can work on business problems throughout the entire customer domain and are not tied to any business area or a sub-product. It would take me too far to go into detail of each archetype now, but I will explain those in context of the teams later. However, C3 is worth mentioning here as it has units that are both complete in capabilities and in scope of work. As an example, the authors of Org Topologies refer to startups being in C3 as in this case, the founders are typically very close to the customer and either have the necessary skills or are forced to learn them (mostly because there is no money to hire someone to do the job). As a business grows, you will get lower archetypes, and it requires more and more effort to get back to that C3 state (if it is even possible).  Scaling Issues and Mechanical Scrum Our story starts somewhere roughly two years ago. As Strobbo's team had expanded over time we had already restructured into multiple smaller teams to maintain agility and efficiency. This restructuring involved creating three development teams (A2 archetype) and a second-line support team (Y2). The second-line support team would handle more complex support issues and maintenance for our older technology stack, thus allowing the new development teams to concentrate on the newer technology stack and developing new features.  Despite these efforts, we faced significant challenges, including frequent bugs, performance issues, and a lack of maturity within the team. We brought in external experts (Y0 archetype) to help improve code structure, implement solutions for better quality and performance, and provide training for the existing teams. However, several key issues persisted: Mechanical Scrum: Teams were going through the motions without fully understanding Scrum principles. Overplanning and Lack of Autonomy: Heavy reliance on the Product Owner led to disengagement. Lack of Trust and Fear of Speaking Up: Trust issues and fear of speaking up resulted in low motivation and commitment. Poor Communication: Meetings were passive and disengaged, leading to individualistic work. Tactical vs. Goal-Oriented: High pressure from management and pessimism undermined efforts. Lack of Transparency: Poor transparency and communication led to a lack of shared understanding. The issues faced by Strobbo indicated that while the teams were structured as A2 archetypes, they were still struggling to embody the characteristics of effective A2 teams. Lacking a visual depiction of Org Topologies, we missed the crucial insight that Strobbo's teams were in a transitional stage, aiming to become A2 archetypes but facing significant hurdles that kept them closer to Y1/Y2 behaviors. Some specific examples of behaviors inside the teams that kept us back were: A large focus on ‘resource’ efficiency, with team members being very focused on keeping busy individually.  Breaking down work to fit the skills of one team member, resulting in frequent hand-offs between single-skilled individuals. As you can see, internally the teams were falling back to Y1 behavior and were not  working as a team but also overly focused on tasks. Some team members compensated by keeping the overall picture and breaking down the work. On the other hand there were also still several dependencies between the teams and the product owner and the teams and the external experts that were holding them back: Relying on testing and acceptance by the Product Owner, which caused frequent delays. Contract thinking at task level when feedback was given. e.g. there were frequent discussions about something being in the acceptance criteria (or not) and no focus on the overall goal. Teams did not trust their own skills to make architectural changes and relied heavily on external experts to do the work, causing more hand-offs and delays. Dependency on the second-line support team to release features dependent on our legacy software. While some of these dependencies were to be expected (e.g., dependencies on the legacy software) for the foreseeable future, reliance on both the Product Owner and the external experts was something we actually wanted to avoid. The teams were, however, lacking in certain skills to be able to avoid this. These challenges, combined with legacy issues in both the old and new tech stacks, further complicated their transition to more mature and effective A2 teams. A visual Org Topologies map would have highlighted these discrepancies, allowing us to address them more effectively and guide the teams toward the desired archetype. Implementing Lean Improvement Kata Recognizing these challenges, we initiated a coaching track with Steven Deneir , utilizing a Lean Improvement Kata  on a weekly basis to enhance our work processes. This approach aimed to systematically address our issues and guide us towards more effective team dynamics. We set forth these goals for ourselves: Make the team independent - stop them from looking to Bert (co-owner of the company) and Michael (Product Owner) for the smallest decisions, clarifications, etc. Make sure the team understands that everything can be discussed and changed Make sure the team is proud of their work and boost morale Make Strobbo a showcase within our parent company Protime as a good example of what it means to be a team and what they delivered Prepare the team for further growth (uplift the technical skill level) No longer practice Scrum mechanically and half-heartedly Looking at these goals through the lens of Org Topologies, we aimed to enhance the team's technical skills, moving their position to the right on the map. Simultaneously, making the teams less dependent on the product owner required them to move up on the map. Speaking in terms of archetypes we knew that we wanted to move to B2 with our teams and focus on achieving business agility. Achieving full adoption of the A2 Archetype But as we saw in the previous section our teams were still struggling to fully adopt the A2 archetype. Our Lean Improvement Kata resulted in a bunch of positive improvements which really helped elevate the teams to an A2 and further. With the coaching we received, step by step we were able to make progress. Many of these are also proposed as Elevating Structures within Org Topologies.  Sprint Goals and Transparency : Sprint Goals : Introduced clear Sprint Goals to guide the team's efforts, ensuring alignment and focus on delivering value. Stakeholder Involvement : Invited stakeholders to Sprint Reviews, transforming them into collaborative sessions that provided valuable feedback and boosted team morale. On-Site Reviews : Moved from online to on-site Sprint Reviews, which significantly improved interactions and engagement with stakeholders, including senior management. Product Backlog Refinement : Involved team members in refinement sessions using Impact Mapping, Event Storming, and User Story Mapping. Team Cross-Functionality, Self-Management, and Definition of Done (DoD) : Encouraged collaboration between front-end and back-end developers. Implemented Mob development and pair programming for knowledge sharing and tackling complex issues. Focused on End-to-End Testing, balancing technical and functional responsibilities. Ran a defect matrix workshop to aid in self-management and decision-making. Conducted workshops to define and clarify the DoD. Made UnDone work transparent, creating a clear path to getting items into production. These structures and practices collectively enhanced team autonomy, transparency, and alignment, driving significant improvements in Strobbo’s agile adoption. Transitioning from A2 to B2 Archetype But as we said our vision was to enhance our team's capabilities and autonomy. Initially operating within the A2 archetype, we sought to transition to the B2 archetype within the Org Topologies framework. Our vision went further than simply improving processes; it entailed a fundamental shift towards greater business agility and independence. After fully realizing the A2 archetype, the teams were working effectively, but there was still a significant amount of coordination required from the Product Owner. Additionally, we wanted to close the gap with the customer to ensure better alignment and responsiveness to their needs. This is also the point that we learned about Org Topologies and understood that we needed to spend more time with the team to help them better understand the direction that Bert and I were moving the teams toward. In a team exercise, we started with showing the video  ‘How Misconceptions About the Product Owner Role Harm Your Organization and What To Do About It’  to not only better explain the role of the product owner but also to make the point that they can take ownership themselves. We then let the team put themselves on the map , and had a group discussion about what we are currently lacking. To further elevate the teams at this point, we invested heavily in the following Elevating Structures, building on our previous efforts: Product Roadmap and Ownership : Goal-Oriented Backlog : Transitioned from a feature backlog to a goal-oriented backlog, focusing on metrics such as the number of pilot customers live, feature usage, or deals sold. The emphasis shifted from merely completing features to ensuring their adoption and impact on the company. Roadmap Workshops : Organized workshops with internal stakeholders and developers to align on the product vision and co-create the roadmap. Enhanced Collaboration : Fostered collaboration to reduce reliance on the Product Owner for day-to-day operations. Product Backlog Refinement : User Story Mapping : Utilized techniques like User Story Mapping to create valuable increments towards achieving goals, ensuring value delivery each sprint. Flexible Scope : Instead of detailed estimates, we set goals and placed bets on achieving them within a certain number of sprints. This approach acknowledges uncertainty and allows flexibility in adjusting the scope based on the situation, focusing on the impact rather than features. Sprint Planning : Limited WIP : Leveraged our goal-oriented backlog by limiting work in progress (WIP) and, in some cases, having teams focus on a single goal at a time. Sprint Goals : Centered sprint goals around the next best step for the current goals. A significant consequence of these changes was the evolution of the Product Owner role to be more outward-facing, focusing on stakeholder and customer engagement. This shift also created greater transparency on the roadmap and backlog for both development and business. In the B2 archetype you can also notice a big difference in the interaction between the teams. Y2 and A2 teams require external coordination at the team level as we saw with Protime. In the B2 archetype we see the dynamics change to a ‘Team of Teams’ where teams will organize themselves. Instead of coordinating at the team level you now coordinate the ‘Team of Teams’. This also changes a lot of the dynamics regarding ownership as in A2 teams will be more likely to focus hard on their own parts and use it as ‘cover’, whereas a B2 ‘Team of teams’ will start self-organizing based on the work they receive. There can still be ownership, but it is no longer a problem of the external managers (“C0/C1/B0/B1” archetypes) to figure this out for the teams. Part of moving to the B2 archetype involved less reliance on external expertise, which is why the ‘external experts’ are gone from the map. Collaborating with Protime Strobbo (formerly Onlinewerkrooster) was acquired by Protime in 2018. The timeline discussed previously occurs after this acquisition. While Strobbo remains a distinct brand and product within Protime, alongside their other workforce management solutions, we operate mostly autonomously as a product group. This autonomy allows us to make decisions regarding our product and technology independently. However, we don't operate in isolation. Over time, we've made significant progress in integrating the Protime and Strobbo product groups, fostering closer collaboration. This integration highlights the importance of addressing how we fit within the larger company and how it influences our position on the organizational map. Portfolio management Until now, I have limited the scope to our product development part of Protime. However, the recent creation of a Portfolio Manager role has shifted the position of the Product Owner. From this larger perspective, it becomes clear that the product owner now lacks a ‘whole business focus’ and is concentrating only on a specific part. This change adds an extra layer of coordination and alignment that was previously not there. The impact on the teams is limited, but as the Product Owner might not have the whole picture anymore (depending on how transparent the Portfolio Manager is), we risk them making wrong decisions or losing time on additional alignment. We should realize that when work moves from portfolio to product and then to development, it is not a sequential flow. As we learn more, work might move back from development to portfolio. If this requires a lot of coordination, it can slow us down in terms of delivery and innovation. Planning Domain Following the acquisition, the Strobbo team gradually became responsible for the entire planning domain within Protime. Strobbo continues to exist as a standalone product, but two additional teams have been added to integrate Strobbo and another recent acquisition ( Sheepblue ) into myProtime, Protime's main product. This integration effort aims to streamline functionalities and enhance the overall user experience within the Protime ecosystem.  This integration necessitates adapting our organizational map to fit the larger context. In Protime, the Product Owner (PO) role is different, responsible for assisting multiple teams with feature development but not acting as a true Product Owner. Instead, product ownership is handled by the Product Manager. This shift demonstrates the clear benefit of using an Org Topology map over a framework-based organizational design. Even though the titles change, the position on the map remains consistent. The newly added teams comprise developers from both the Strobbo and Protime development teams. The Planning domain fully encompasses Strobbo as a product, with all its features, and includes Planning as a feature of myProtime. For the teams working on myProtime planning, the scope of work is therefore narrower than for those working on Strobbo. This narrower scope limits the ability of the myProtime planning teams to cross the chasm as the Strobbo teams did. Work beyond their scope must be picked up by other teams, requiring coordination at the 'product' level between the B0 archetypes. Conclusion Reflecting on Strobbo's journey, it is evident that our path to agile excellence was marked by both significant challenges and transformative successes. Initially, moving from a single-team scrum setup to multiple, more specialized teams did not immediately resolve our deep-seated issues related to agility, autonomy, and cross-functionality. However, over time, through persistent effort and continuous improvement, we were able to achieve these outcomes. Key to this transformation was the introduction of clear Sprint Goals, stakeholder involvement, and regular on-site reviews, all of which enhanced transparency and team morale. Although we did not initially use Org Topologies, in hindsight, it would have provided a critical framework for understanding and addressing the complexities of our organizational structure. This approach could have highlighted the foundational issues sooner, guiding us more effectively through our transitions. Our integration into Protime further underscored the importance of aligning our product and technology strategies with broader organizational goals. By adopting a goal-oriented backlog, fostering collaboration, and maintaining a flexible scope, we ensured that our teams remained focused on delivering impactful solutions. As we continue to evolve, the lessons learned from our agile practices will guide us toward sustained growth and innovation within the larger Protime ecosystem. 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 Michael 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 the Strobbo's Case Study: Unifying Product Ownership Across Teams Moving from individual team-based product owners to a more unified product ownership structure. This elevates product strategy and ensures that the product vision is collectively understood, prioritized, and managed. Instead of each team interpreting the product direction in isolation, a unified product ownership model helps maintain strategic coherence and alignment across the entire product landscape. Shared Product Backlog for Multiple Teams Instead of multiple, disconnected backlogs, the organization merges them into a single, shared backlog. This structure forces transparency, reduces competing priorities, and keeps all teams focused on the same highest-value opportunities. Similar to the “Merge Product Backlogs” kata, this elevates the entire organization’s workflow by ensuring that work items are consistently prioritized at a product (rather than team) level. Consistent, Cross-Team Refinement Sessions Establishing regular, multi-team product backlog refinement events. During these sessions, all involved teams align their understanding of upcoming work, dependencies, and priorities. This structure ensures that each increment of work is clearly understood and synchronized, preventing silos and misalignments before development starts. Dedicated Strategic Alignment Spaces (Obeya-like Practices) While not explicitly called “Obeya,” the case study implies the use of dedicated forums or physical/virtual spaces where stakeholders (including product owners, coaches, and team representatives) gather to review strategic metrics, progress indicators, and customer feedback. This structure leads to better-informed decisions and quicker action. Over time, these regular strategic gatherings elevate governance and leadership practices. Capability-Focused Role Evolution Encouraging roles to evolve beyond traditional job titles or hierarchical tracks into more fluid, capability-driven pathways. Instead of fixed roles defined by narrow functions, individuals grow in breadth and depth of skill areas aligned with organizational goals. This aligns with the concept of “Tailwind Career Paths,” providing a structure that consistently nudges people towards multi-skilled growth and adaptability. 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.