ORG TOPOLOGIES 

Mind The Gap Between The Train And The Platform! In the rush to platformization, organizations often create a chasm between the platform and its customer-centric parts. This divide can lead to misaligned priorities, inefficiencies, and stifled innovation. Mind the gap! Caution This topic is highly contradictive as many consultants advice for exactly the opposite — to focus on platform development. That is probably why recent LinkedIn post on avoiding platformization has triggered a lot of attention. In this detail article I’m going beyond this false dichotomy (i.e. to platform or no to platform) and aim to advise for a balanced view on this subject with a preference to focus on the whole product. Problem Statement Imagine an architect who discovers that several stream-aligned teams share a common concern that could be extracted and reused. Thrilled by the opportunity, the architect identifies an important task ahead. The default reflex is to design a platform to address this shared concern. However, each stream-aligned team has its own roadmap and is busy with their tasks. The proposed solution seems simple: create a new team dedicated to this platform. Thus, a platform team is born. The architect collaborates with this platform team, spending weeks meticulously designing and implementing a platform solution, complete with beautifully published APIs. The next step? Mandate that all the stream-aligned teams integrate and utilize this new platform. This seemingly straightforward approach, however, is fraught with challenges and often leads to unforeseen issues. This modus operandi assumes that all variables can be anticipated through extensive analysis and design, a notion that often proves unrealistic in the dynamic environment of software development and organizational operations. The Pitfalls of Platformization in Software Development and Its Effects on Org Design Platformization, particularly in software development and organizational design, often stems from misguided priorities and expectations. While platformization aims to achieve economies of scale by standardizing processes and creating reusable components, it can paradoxically lead to inefficiencies if not approached correctly. The key is to balance the pursuit of economies of scale with the need for flexibility and customer focus. Viewing the "platform" as a separate product or value stream can lead to prioritizing internal efficiencies over delivering tangible customer value. Instead of focusing on what customers truly need, organizations may fall into the trap of building elaborate platforms that do not align with actual market demands. Despite the broad spread of populist ideas that promote platformization and the need for dedicated "platform teams", the long-lasting undesired effects of premature platformization cannot be overstated: Hindering Adaptability and Innovation Leading to Lower-Level Org Topologies Archetypes Overengineering and Waste Creating Internal Silos and Dependencies 1. Hindering Adaptability and Innovation Emphasizing platformization can stifle organizational adaptability and innovation by creating monolithic structures resistant to change. This contrasts sharply with higher-level archetypes within the Org Topologies model, such as B2, B3, and C3, which champion adaptability, cross-functionality, and a shared focus on customer outcomes. 2. Leading to Lower-Level Org Topologies Archetypes For instance, dedicating separate teams to platform development can lead to a "not our job" mentality and hinder value flow. This issue aligns with lower-level archetypes like Y2 ("component development with narrow-specialized teams") and A2 ("hopeful yet entangled teams"), known for their siloed nature and struggles with dependencies. These archetypes often lack the fluidity to adapt quickly to changing market needs, which is critical for innovation. 3. Overengineering and Waste Premature platformization frequently results in overengineered solutions. Without a validated business model or clear customer demand, organizations risk investing heavily in features and functionalities that are not actively sought after. This approach can lead to significant waste of resources and effort. 4. Creating Internal Silos and Dependencies Dedicating separate teams solely to platform development can create unwanted silos within an organization. This isolation often leads to misaligned priorities, communication breakdowns, and a "not our job" mentality, ultimately hindering the overall flow of value creation. Such internal silos can disrupt collaboration and efficiency. Alternative Approaches to Mitigate Platformization Risks To mitigate the risks associated with platformization, several alternative strategies are recommended: Validate Your Business Model : Prioritize building successful, customer-facing products first. Only consider platform development when a genuine need for shared services emerges from these validated products. Promote Shared Ownership : Avoid dedicated platform teams. Instead, encourage a collaborative approach where product teams contribute to platform development as a shared effort. This fosters a sense of collective ownership and ensures the platform evolves in alignment with real-world needs. This resonates with higher-level archetypes like B3 ("interdependent teams collaborating on business value") and C3 ("holistic product development"), which prioritize shared ownership and cross-functional collaboration to deliver customer value. Focus on Emergent Architecture : Allow the platform to emerge organically based on actual usage patterns and requirements. This iterative approach supports adaptability and prevents overengineering by ensuring development remains closely aligned with real-time needs. Consider Shared Code Libraries/Services : Instead of building a full-fledged platform, start with reusable code libraries or services that any team can create, co-own, and co-develop. Whole Product Focus : Avoid creating "value streams" dedicated to internal non-customer-facing concerns, such as platform or infrastructure development. Concentrate on delivering a complete product or its vertical slice that meets customer needs comprehensively. This involves integrating various components and services seamlessly, ensuring that the final product provides a coherent and valuable experience for the end-user. By focusing on the whole product, teams can avoid fragmented efforts and ensure that platform developments align with broader business goals and customer expectations. Key Takeaway Approaching platformization as a primary goal is ill-advised. Instead, a more customer-centric, adaptable, and collaborative approach to organizational design and software development is recommended. By prioritizing validated business models, shared ownership, emergent architecture, reusable code libraries, and a whole product focus, organizations can mitigate the risks associated with platformization and create a more agile and responsive environment for delivering customer value. Additionally, this approach allows for the realization of economies of scale in a lean manner without sacrificing adaptability and innovation. This approach doesn't say imply that platforms are not necessary or wasteful in general. This is just a just caution that premature platformization can harm organizational adaptability, innovation and resilience due to the gap between the platform-creating and customer-focused parts of the organization.

A recent publication by Jürgen De Smet and Viktor Grgic on Cognitive load and the recent Org Topologies course I followed, got me reflecting on my role as a Product Owner/Product Manager. We often focus on the cognitive load of development teams, but it’s crucial to consider our own too. As Product Owners, we handle a lot—from talking to stakeholders and prioritizing backlogs to keeping the team aligned with the product vision. We, too, should be managing our cognitive load better, in order to support our teams more effectively and make the whole product development process smoother. Managing Complexity in Feature Development When new features start crossing boundaries of technical ownership, the complexity of managing this often falls on the Product Owner or Product Manager. This responsibility can become very broad, encompassing tasks such as seeking alignment between teams, splitting the work across them, tracking progress of the different parts, and creating a release plan. This is often too much for any one person to handle, leading to the need for additional resources or the creation of new roles to address specific issues, as Jürgen De Smet discusses in his YouTube video on how organisations go nuts . The creators of Org Topologies, Alexey Krivitsky and Roland Flemm, provide a valuable way to visualize where this kind of complexity impacts us. Their illustrations of the Type 1 (Pre-agile) and Type 2 (First agile wave) ecosystems clearly show how these complexities emerge and affect team dynamics in the form of projects. Embracing Business Agility Working as a Product Owner in a Type 3 ecosystem focused on business agility is a whole different experience. The key idea here is a ‘Team of Teams’ with fluid ownership. It can be shared ownership, but it doesn’t have to be. With a ‘Team of Teams,’ you don’t have to worry about who owns what. Instead of managing how work is divided, you collaborate with the ‘Team of Teams,’ and they take care of that complexity. This means as a Product Owner, you switch contexts less when working with the teams, since it’s now a unified effort. Additionally, you tap into the collective wisdom of the group when addressing a problem, rather than figuring it out on your own. Instead of managing team details, a Product Owner or Product Manager can now focus on strategic planning, engaging with key stakeholders, interacting with customers, fostering innovation, mentoring team members, among other things. Managing Cognitive Load Effectively As a Product Owner or Product Manager, cognitive load can be high at times. You need to know a lot about a lot of things: the product, your market, technical details, your stakeholders, etc. As cognitive load theory indicates, the problem is that it takes time and repetition to learn all these things. Make sure to take your time for this, don’t overreach. And don’t keep this all to yourself. Your team will not be able to catch up fast if you keep them out of the loop for too long. Avoid the mistake of trying to figure out everything by yourself. Involve your team when they have more knowledge, especially when they are actively working on a particular feature. Don’t hesitate to challenge those who are competing for your time and attention. Always align tasks with your strategy and product vision. If something doesn’t fit, let others convince you of its value first. Consider the initial steps to validate an idea rather than fleshing it out completely. Finally, transparency is your best friend. Ensure your backlog and roadmap are open and clear to everyone. Prefer frequent, smaller updates over large, infrequent ones. It’s okay to repeat key messages to ensure they stick. One effective method is to invite stakeholders to your Sprint Review and make it as interactive as possible. Involve the teams and encourage stakeholders to provide direct feedback. Remember, it’s about inspecting and adapting, not just giving a status update. Empowering Teams for Better Outcomes Working in Type 3 ecosystems, where you uplift and empower your teams, is not only more enjoyable but also highly effective. These environments foster collaboration and shared ownership, allowing you to focus on strategic planning, stakeholder engagement, and fostering innovation. Don’t be afraid to trust your teams—they have the knowledge and capability to manage their tasks effectively. This will also have a positive impact on your cognitive load. Additionally, as a Product Owner, considering organizational design is often overlooked but very important. Understanding and influencing how your organization is structured can significantly impact your team’s efficiency and your own cognitive load. By involving your team, maintaining transparency, and aligning tasks with your product vision, you can create a more productive and satisfying work environment for everyone involved. Embrace the ‘Team of Teams’ approach and encourage continuous improvement and adaptation.

Why Cognitive Load Matters * This text is a version of the foreword I wrote for the free e-book Navigating Complexity of Cognitive Load by De Smet and Grgic. Have you ever tried collaborating with an overloaded person? In my experience, it is impossible to tell whether a person is overloaded or lacking professional attitude and skills. In other words, overloading makes us incapable of producing work of the expected quality. The   American Institute of Stress  reports that workers' daily stress (measured in the US and Canada) increases by roughly 5% yearly. 83% of US workers suffer from work-related stress, with 25% saying their job is the number one stressor in their lives. A stressed worker gets, on average, 41% less productive and 33% less engaged. I found no numbers specifically in our high-tech knowledge work field, i.e., digital product development. But we can be sure that the ever-increasing complexity and speed at which companies are forced to push new value onto the market doesn't make us less stressed. Quite the opposite! So, it shouldn't surprise us that reducing cognitive load has been gaining increasing traction in our field over recent years. For five years, it has become one of the most quoted factors managers consider when making organizational design decisions in their R&D organizations. The most common treatment for the cognitive load problem is limiting the scope of ownership of software teams. This argument is easy to agree with (hence its popularity): the less code the team needs to manage, the less would be the cognitive load of the team members.  Problem solved! Yet, such organizational design decisions that seem correct when analyzed without proper scrutiny (fast thinking) have unexpected side effects rippling throughout the entire product development organization. It doesn't take a rocket scientist to see how private code ownership policy (applied to fight high cognitive load) quickly creates problems in other parts of the organizational system. Queues of pull requests, longer lead times of time-to-value, the “us vs. them” culture between different teams owning different parts of what a customer would call a “single product.”  For at least several years, the industry is familiar with these ramifications, which spread almost uncontrollably within the larger product development system, making it slow to deliver, unresponsive to learning, and essentially non-agile.  Are these the trade-offs that your organization is willing to make? This book you are about to read goes several layers deeper than the popular materials on reducing the cognitive load you can find online and on bookshelves. The world is not black and white. There are no one-size-fits-all solutions out there. There is no quick fix to complex dilemmas. Reducing cognitive load is so important that we must keep uncovering better ways to deal with it. But without dualistic ideas of either-or, we need to fight the work-related stress of our workforce and simultaneously learn to tap into the unlimited potential of our organizational intelligence. We must go beyond curing just the symptoms and applying fast, sloppy thinking to complex issues. Reduction of Cognitive Load is Critical! And it is also important to understand that cognitive load has nothing to do with storing of information in our brains: those limits have not been found by the research, so we can assume that our inner hard drives are unlimited. Hence, point #1: cognitive load has nothing to do with knowing different things, we can keep acquiring new information almost forever. But what is limited, in fact, is our immediate temporary memory (i.e., RAM) - we cannot stay productive by being focused on more than a handful of things, and we cannot be engaged simultaneously in several unrelated complex activities. E.g. did you notice when driving a car that when the traffic situation worsens, then for those few moments we stop paying attention to the news on the radio? Hence, point #2: cognitive load is essential for maintaining our productivity.  Now, how to approach this in our workplace? How to design organizations that take that into account? The art and science of org design is not to mix primary and secondary concerns.  What do we mean by that? Organizations are NOT created to reduce cognitive load. In fact, the best way to reduce it would be NOT to start a company and NOT to engage in product development. So, in fact, not delivering value is not an option. Hence, point #3: the primary concern of an organization is to discover and deliver customer value.  Now, now we agree that the customer value is our primary concern, we must find ways how to do that in the most effective and productive manners by maintaining adequate levels of cognitive load. This work becomes our secondary concern in org design. Customer value in most cases is a thing that spans different components, modules, microservices, applications ... it is a cross-cutting thing. Therefore, in order to solve customer problems and provide the best customer experience, we need to keep this wholistic view. Hence, point #4: we need to find ways to stay productive and reduce cognitive load without jeopardizing customer value and customer experience.  So point #5: divide and conquer (i.e., split the product into parts and give away those parts to be owned by individual teams) is not always the best option. In fact, that must be our last resort. There Is More Than One Way To Manage Cognitive Load Hence, this list below is ways to reduce cognitive load by maintaining a systemic view on the customer problems: #1 Simplify, Automate and Standardize (Reduce Switching Costs) #2 Apply Test-Driven Development #3 Share Work and Mob (Avoid Individual Tickets) #4 Use GenAI #5 Minimize the Distance to Customers  #6 Avoid Separating Discovery and Delivery (Continuous Discovery Habits) #7 Embed Business Analysis into the Teams #8 Minimize General Organizational Complexity #9 Use Modeling Techniques to Grasp the Bigger Picture  #10 Minimize WIP #11 Develop Learning Skills by Making Learning a Habit ... and the list goes on and on. Get the free e-book! https://learnhow.simplification.works/p/cognitive-load

Last month, I did something a bit unusual.  Instead of being the instructor, I was a student and attended an  Org Topologies™ Practitioner course .  The things I learned there resonated with me because they helped me answer this question, “Why do so many organizations struggle to #DoBetterScrum?”  When done well, Scrum (and other Agile processes) will create change.  But many Scrum and Agile adoptions are short-lived or superficial.  They do not touch upon the other elements of organizational design - strategy, structure, rewards and people.  IME, if you do not adjust these other elements of the system, the organizational design will reject the new processes because they are inconsistent with how the business truly operates.  For me, the Org Topologies course gave me a light that I can shine onto an organizational design to discover if it is fit for purpose. What is Org Topologies? Org Topologies  is a mental model published by  Alexey Krivitsky  and  Roland Flemm  to help organizations visualize how their teams are organized.  The model is based upon a series of archetypes (Y0, A1, B2, etc.) organized around two axes.  The overall goal is to map the various teams within the organization into the different archetypes so that the business can then draw conclusions about the effectiveness of its organizational design to realize its strategic business objectives.  The x-direction measures the delivery capability of each individual unit in the organization.  It describes the ability of each unit to sustain a fast flow of complete units of value to the customer.  On the left side of the x-axis, zero and one, the work is predominantly functional.  Specialists, or groups of specialists, focus on completing a single part of the whole.  On the right side of the x-axis, two and three, the work is multifunctional.  In this case, cross-functional teams must collaborate to deliver a complete slice of customer value. The y-direction measures the scope of the work of each unit in the organization. It describes the level of knowledge each unit has about the customer and the degree of co-ownership of the business outcomes among the various work units.  At the lower levels, Y and A, the scope is narrow.  Individual tasks or small features that are often disconnected from customers and\or business outcomes.  At the higher levels, B and C, the scope expands to include outcomes that have a broader impact on the business. How is Success Defined with Org Topologies? In their model, Krivitsky and Flemm place the highest performing units in a location they call “C3”.   When a small business is operating as a start-up, it would be considered a C3 unit.  A C3 unit has the following characteristics: It is a cross-functional team that can deliver a complete slice of value to its customers quickly and efficiently, with a minimal amount of waste. The team has direct interaction with customers and is adaptive to a changing business environment. As a result of its direct interaction with both customers and the competitive landscape, the team will learn whatever is needed in order to generate a win for both the customer and the business. As the business scales, the various responsibilities that were contained within the initial C3 unit, the start-up, are now divided across multiple units that map to lower archetypes, such as Y0, Y3, A0 or A1.  Unfortunately, the lower archetype work units lack self-sufficiency, so they need coordinating units from the higher archetypes to deliver end-to-end value to the customer.  By definition, the entire organization must be C3, or it would fail as a business.  How Does Org Topologies Help You #DoBetterScrum? There are a couple of reasons why I think this mental model will be helpful for teams and organizations who want to do better Scrum. Evolutionary:  with its scales of zero to three and Y to C, practitioners and other leaders can chart their growth along multiple horizons based upon the destination they desire. Diagnostic:  it helps practitioners and other leaders identify where they are today, where they can expect to encounter resistance, from whom, and offers some reasons why they might be resisting change. Holistic:  to achieve higher levels of performance, practitioners and business leaders must look beyond the adoption of new (Agile) processes and consider additional elevating practices that impact strategy, structure, rewards and people. What I like about this model is that its creators are (mostly) neutral on what is the final destination.  While both have a preference to help organizations to grow in the direction of C3, one of their main motivations was to publish a model that gave practitioners a clear and specific language when talking about organizational design. For instance, if a business completes an Org Topologies mapping and discovers its current organizational design enables it to achieve its strategic objectives, then nothing needs to be changed.  However, if the mapping reveals the organizational design is not fit for purpose, there are a number of  elevating structures  they could adopt to shift right, or up, in the Org Topologies map.

Multi-team PBR is one of the Elevating Structures  that help to uplift your ecosystem up the levels of the Org Topologies™ mapping: This article focuses on refining the Product Backlog with multiple teams at the same time: multi-team Product Backlog Refinement (aka mt-PBR) . The goal of mt-PBR is to maximize information sharing and collaboration during Product Backlog Refinement. We bring all development teams together in one refinement session instead of having teams conducting separate refinements. Refinement in Scrum The Scrum guide mentions refinement, but does not elaborate much on how to do it: “Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.” (Scrum Guide) When we develop a product with more than one team, the Scrum guide suggests to have one single Product Owner and One single Product Backlog: If Scrum Teams become too large, they should consider reorganizing into multiple cohesive Scrum Teams, each focused on the same product. Therefore, they should share the same Product Goal, Product Backlog, and Product Owner. (Scrum Guide) This suggests a move towards the higher archetypes (B and C levels) as per Org Topologies™. Maybe that is too scary or simply not what you want. However, even without transforming your organisation, you might want to explore and benefit from Scrum events such as Product Backlog Refinement with a team of teams. Why would you want to do a mt-PBR? It makes sense to try out mt-PBR when: You want to create a shared understanding of the work. In other words, you want the teams to focus on the whole product or problem at the same time rather than splitting the work into smaller items per team upfront. You want to reduce the coordination effort that is needed to reduce dependencies between the teams when they work asynchronously from each other in isolation. You want to minimize integration issues that will occur if the teams do not integrate during the Sprint. You have the opportunity of dealing with a challenge that affects multiple teams. This could be a shared problem or a Product that is been developed by multiple teams and you want the teams to collaborate on that challenge to increase the chances of success. You think it is important that team members learn from each other and you want to give everybody the opportunity to contribute to creating the best possible value. Preconditions In order to get the anticipated benefits of mt-PBR, you will need a single product backlog and one Product Owner. It’s okay if you have many POs running around the teams, as long as there is one single person who takes responsibility for the whole product (or the cross-team problem you are addressing). There is a restriction on the number of people involved. I have used this practice with up to 70 development team members, say about eight teams. I know there are colleagues who have run successful mt_PBRs with up to 150 attendees. At every customer where I introduced this practice, the teams were cross-functional (archetypes A2 or A3). Meaning that every team can design, test, and build software. I suspect this practice will not work very well with single-function teams of Y2 level (analysis, test, development in separate teams). You need a cross-team Definition of Done (DoD) so all teams have a shared understanding of what needs to be done to be Done. Preparations Before we can start the mt-PBR sessions, the Product Owner (PO) and Scrum Master (SM) need to prepare the session. The Product owner: Needs to shape the top of the backlog by identifying the Product Backlog Items (PBIs) that need to be refined. Let’s say 10 or 15 (larger) items, enough work that will take one or more Sprints to complete with the whole group. Needs to describe the PBIs as goals, not as outputs. Needs to provide customer-centric acceptance criteria for each PBI. Needs to prepare the product vision and shorter-term Product goal (let’s say for the current quarter or less). Consider impact maps as practice. Sends an invitation to the whole group, relevant stakeholders, and Subject Matter Experts (SMEs). The Scrum Master: Needs to book a space that is large enough for the group to work in and with sufficient wall space to work on. Needs to ensure there are flip-overs, brown papers, stickies, markers, etc. Needs to ensure there are “stations” or desks where groups of people can work. Needs to arrange a beamer and possibly a loudspeaker system. If there is no common understanding of “Done” across the teams, the Scrum Master needs to establish a minimal DOD that applies to all teams. While refining, this will create transparency on the work that needs to be done for each item. Often the work is estimated while refining. The Scrum Master should ensure the unit of estimation (possibly story points or t-shirt sizing) is calibrated across teams. This will prevent wasteful discussions between members of different teams when estimating. mt-PBR session process The mt-PBR consists of two parts: part 1: Overall Refinement part 2: Detailed (multi-team) Refinement The two parts are planned directly after each other. Part 1: Overall Refinement This is a session that prepares for the detailed refinement session (part 2). If you have never worked with large groups in sessions, you will be happy to learn that the overall refinement session is done with a small group of delegates from the teams. It is a meeting that has a size you will be familiar with: no more than around 10 people. The attendees are team delegates (development team members) Subject Matter Experts (SMEs) and possibly Product Managers. The session takes 30 minutes to an hour. The input of the session is the top of the Backlog as prepared by the PO. The output of the session is a set of PBIs for one Sprint that has been discussed briefly, with a rough (t-shirt-sized) estimate, acceptance criteria, and known dependencies. Session details The PO briefly iterates the product vision and mission (the Product goal). This provides context, “the Why” for the work that we are about to pick up. This helps everybody to understand why the PO has chosen to prioritize the Product Backlog the way he or she did. The team delegates form heterogeneous groups of 3 to 5 people to discuss one PBI each. This is important. They do not work on the problem with their teammates. They estimate PBIs and split them if they seem to be bigger than one sprint. They also identify dependencies, which are indicators for possible team collaboration during the Sprint. Note that probably not all of the selected PBIs require multiple teams to work on. A great benefit of the Overall Refinement is that the team delegates will later be able to guide the rest of the group during the upcoming Detailed Refinement. They will share their insights with the rest of the group. To increase the value of the detailed refinement, we close the overall refinement by the attendees doing a teach-back to each other of what they learned and what is decided regarding the selected PBIs. Part 2: Detailed multi-team Refinement Immediately after the Overall Refinement, the detailed multi-team refinement starts. This session requires strong facilitation. Ask your Scrum Master to help out! All development team members must attend. This is not an optional meeting. Anybody who holds relevant knowledge of the PBIs (such as SMEs, architects, domain model experts, etc.) should attend too. This session can take two to four hours. You will need to experiment to learn what works best in your context. The group gets informed about the PBIs by a Subject Matter Expert. Session details The session starts centrally with the PO briefly (re)sharing the product vision, mission and the current Product goal. The SMEs or Team delegates who were present at the Overall Refinement introduced the selected PBIs. They also share which teams are likely to collaborate during the Sprint. There is no need for much technology, the items are on large sticky notes and visible on the wall. the Product Backlog When all PBI’s are introduced there is usually a short Q&A. When that’s done, the PO picks up one PBI at a time and asks the people who will refine that item. Guided by the team delegates, the people will self-organize in heterogeneous groups to further refine the PBI’s. Note that we deliberately break up the existing teams to stimulate learning and knowledge sharing. Sometimes multiple groups refine the same PBI. You can make this a hybrid meeting by creating “numbered Stations” with a room in zoom or teams. A group that picks up an item calls the station number, so the remote attendees know which (virtual) room they will be working in. Members of different teams collaborate in refining. The PO, PMs, SM, and SMEs walk around and support the groups when needed. They contribute to the refinement by asking powerful questions. Each group clarifies the acceptance criteria by creating initial designs, examples, or scenarios that describe how the PBI can be tested. Any question and input that is a prerequisite to taking the PBI into the Sprint needs to be addressed. People verify existing code if needed. The groups use the DOD here to verify if everything we need to do to meet our quality standards is addressed. Iterations When the groups have worked on their item for about 15 to 20 minutes, we rotate the groups across the items to continue refining the PBIs with different people. We iterate and rotate because our goal is to use the full potential of the whole group. By ensuring everybody knows most of all PBIs to some extent we create flexibility: it will make decisions easier, multiple teams can collaborate on an item as all teams will have (some) knowledge about the item, it mitigates integration issues and increases self-organization. There are a number of iteration techniques: Partial roulette: each group works on an item. When the time box expires, one person stays behind at the station, the other people move to the next station to contribute to the refinement of another item. Full roulette: each group works on an item. When the time-box expires, all people move to the next station to continue refinement. Diverge and merge: Our favorite! Each group works on an item. When the time-box expires, one person (SME) stays behind at the station, all other people split and go to a random other station. They get taught about the other PBI for 5 minutes, give feedback and suggestions and then return to their station to discuss learnings. Each group then continues refining their initial PBI. Teach-back: each group works on an item. When the time-box expires, all people gather around one station where the SME explains the findings. All stations are visited sequentially. This is time-consuming with large groups. We iterate the refinement rounds as many times as needed. Mostly two to three times is enough. Also, we stop when the time box expires. Before we end the meeting we record the results by taking pictures or otherwise. The session is concluded centrally by the PO going over the PBIs, asking for open ends, which teams are involved in doing what, etc. During, but mostly after the session, people create items in their work management tool (Jira, TFS, or the likes) as needed. The complete schedule in a nutshell 9:30–10:30 Prepare and set up the room 10:30–11:30 overall PBR – intro 20 min. – refine 20 min – closing 20 min 10:30 -10:45 break 10:45–12:30 detailed PBR (longer if needed) – intro 15 min – Multi-team PBR 60 min (3x 20 min diverge/merge 12:15 -12:30 closing  – done (time for lunch)! Alexey Krivitsky and Roland Flemm

This article has been updated on November 1st, 2022 to reflect our improved understanding of Marty Cagan's model. As a result, the conclusion and mapping have been changed. TL;DR This is a series of articles (among them are analysis of Spotify's Tribes and Squads and Team Topologies ) where we compare and contrast different well-known approaches applicable to product development organizations to help leaders make better org design decisions. For our analysis, we are using a map of seven archetypical org designs , that we call Org Topologies™. Empowered Product Teams is not a new concept and Marty Cagan hasn't coined this term, but he writes about empowered product teams a lot these days. So, we're going to use his quote from this source to set the stage: "...They [the teams] are cross-functional (product, design and engineering); they are focused on and measured by outcomes (rather than output); and they are empowered to figure out the best way to solve the problems they’ve been asked to solve". In other words, empowered product teams are not simply executing on requested features. They are not the “delivery teams” that work on whatever is spoon-fed to them. Instead, they do real product development work with the goal of maximizing the outcome while minimizing the output. What we conclude: Per Marty's vision: an empowered product team has a product manager as a team member. Such a team works off an independent team-level backlog. This will make such a team work in isolation from other teams. Marty sees this as a sign of empowerment (from the team's level), and we see this as a local optimization (from the global company's level). A team, that works from its independent backlog, has its own local priorities. Per Marty's vision, a team's backlog should be set at a level of business/customer problems (not features). We agree that it helps a team to find more creative solutions by owning discovery and delivery as a whole. Though, Marty is not 100% clear if the whole team is involved in discovery, or it is just the product manager's job. At scale with many teams, individual teams will have local interests in solving problems that they own. Such individualism won't create a truly scalable product organization where teams collaborate in a multi-team fashion to share and solve big problems together. Such an org design doesn't lead to higher adaptivity and innovation; it doesn't create a resilient organization. Empowered Product Teams in Marty's Words Below is a short interview with Marty Cagan where he shares his views on this subject, while dropping some terminology that we will debunk in this article: He says a few things that we would like to highlight for further study: “empowered product teams” are contrasted to “feature teams” from the outside they look very similar, they both are “squads” in the Spotify language they both have someone with a title like “product manager” How Marty understands what a “feature team” is and how it works: the “feature teams” are told the solution, often without even explaining the underlying problem, like “go and build this feature that we need” then Marty describes a process when such a “feature team” designs the feature and puts it on its backlog to implement in a sprint (a very diminished view of Scrum) “it is all about output”, he says, “they can't be held accountable for the results” 20-30% success rate of such an approach a product manager on such a team is more like a project manager “herding the cats” In contrast, “empowered product team”: is given a problem to solve: a customer problem, a business, or both and empowered means that they are given the freedom to determine the best solution to that problem they eventually build features too, but they measure the outcome and may try other approaches to succeed they might then try to redesign and even eliminate the features to find whatever works and because they were given a problem, they can be held accountable for the results such teams have a different purpose, they are to serve the customers the way it works for the business instead of just building what the business wants and this has implications for the people on that team as their job is not just to code, but to solve – that is discovery to come up with a solution that is valuable, usable, feasible, and viable; and then build a quality implementation and ship it this is a much broader job for the entire team and the product manager on such a team is responsible for the valuable and viable aspects (the hardest parts) the designers are responsible for usable and the engineers – for feasible the product manager is more like a start-up CEO (the head of product in a startup) These words have a lot of wisdom, the “empowered product team” do definitely provide organizations with high adaptivity and innovation, so they deserve to be placed higher on the Org Topologies™ map. More detailed analysis of this in the article below. Clearing the Terminology Fog But that interview has some disturbing parts too: Marty Cagan seems to undermine and diminish Scrum to be just the implementation cycle. Marty uses the term “feature team” when he tries to describe a team that is merely “coding” away the solution. We both, authors of the Org Topologies™, train and consult organizations with Scrum and Large-Scale Scrum (LeSS) for many years. We are also affiliated with Scrum Alliance and Scrum.org – two key bodies that represent Scrum in the industry. So, we feel obliged to clarify the shadow of confusion that Marty's words are casting upon Scrum and LeSS. Our clarification on Scrum Team and “feature team”: Scrum (per its first early source from 1986 and the modern scrum guides updated in 2020) has never been described in such a way, where the Scrum Team solely implements a solution without any accountability for the results. So, Marty's words distort Scrum which is in fact a meta-framework that helps to find a suitable work process to deliver value through adaptive solutions for complex problems. Maybe, we guess, Marty refers to broken and dysfunctional Scrum implementations that he saw in the industry. But the game of football and the game of basketball are still great games, no matter if someone plays football with hands and basketball with no basket. And Scrum is a game with clear values, principles, and rules. Marty's refers to “feature team” without really defining what those are and clarifying the source. We assume he means teams that are not involved in the discovery and are given pre-decided features to build. OK. But there is a well-established and not overloaded definition of a feature team in LeSS. And according to that source, those teams are cross-functional cross-component long-living customer-facing self-managing teams. That are enough adjectives put together in this definition to help avoid any confusion with “delivery teams” – that just code things away. If not for these two important corrections, Marty's vision of empowered product teams is an interesting concept to study. And now that we clarified some points and references that Marty Cagan has been making, we can proceed with analysis to see what it takes to create and sustain such organizational design. Mapping Ideally Empowered Product Teams In this and the next chapters, we will be looking at what we will call “ ideally empowered product teams”, i.e., without any anchoring to Marty Cagan's idea for now. We will do this to broaden our discussion and analysis. And then in the conclusion, we see if what Marty Cagan's claims match our understanding. Ideally empowered product teams should display a very different organizational culture than delivery teams. Formerly do love the customer's problems and own their solutions. Being organizational consultants, we believe that culture follows structure (in established organizations). That means that to create an environment for empowered product teams, management needs to put in place concrete structural elements. The structure goes first and affects how people see the work, do the work, and think of the work – affecting the culture of work. So, what are those structural elements required in the org design for empowered product teams? We will be looking at ideally empowered product teams from the viewpoint of organizational adaptivity, innovation, and resilience using Org Topologies™ mapping. Our main question is always: how to create and sustain an organizational design to make such teams flourish? The X-axis of the map is “fluency of delivering a given customer value item”. And the Y-axis is “fluency in learning the whole product”. This gives us a matrix where different org archetypes can be mapped and compared with one another. Organizational adaptivity, innovation, and resilience are increasing when moving top right. A detailed description of this mapping is available at orgtopologies.com . Get yourself familiar if you are new to this. And then read on. Scope of Work On the map, the scope of work increases going upward the Y-axes: from tasks to user feature focus, from customers to product & services focus. So logically, we can conclude that because ideally empowered product teams are dealing with high-level concerns, such as customer problems and business objectives, their archetypes should be represented high on the map. Team Skills Ideally empowered product teams should be working on customer problems towards business objectives. That implies they speak both the customers and the business languages. They should be formulating problem statements, designing hypotheses, building prototypes, running experiments and measuring the impacts, and then iterating to improve. Let's now try to understand the empowered aspect. And what structural implications it has. Being empowered has many layers to this meaning. One that stands up for us as a prerequisite is to have technically sufficient teams (end-to-end). Teams need to have a high level of fluency in delivering features (the X-axes of the map) to have a short lead time, and receive and process market feedback fast. So, engineering excellence is the fair minimum for product teams to be empowered. But not just that. Such teams need to possess more than just delivery skills. They ought to master product management, product marketing, human interaction design, quick prototyping, UX, IT operations – to name a few. If we sum up all the skills, we are getting to a few dozen of them. Does it mean that such teams have a few dozen of team members in them? So, large teams? Multilearning Having large teams is an option, but it contradicts what we observe to work best in software product development. Self-management, the feeling of empowerment, and process ownership are easier to cultivate in smallish teams. Ideally with 5-7 members. This leads us to an inevitable realization. Product teams must consist of multidiscipline individuals, people with primary, secondary, tertiary, and so forth skills. We need multiskill team members. This doesn't mean that everyone can do absolutely anything. But this definitely helps to understand and collaborate on the shared work that is in front of a team. That's not new. Full-stack engineers are the kings of the software industry today. Also, the technologies such as Flutter and React Native help to minimize the zoo of programming languages and technologies required. But there's more! Such teams are not just polishing the same feature subset over and over again. Instead, they got constantly challenged by novel customer problems and business challenges. They are product teams, for god’s sake! How do they cope with that anyway? To be able to work on new things, they ought to be constantly learning to acquire new skills. That is inevitable. They are learning teams. We are going to refer here to a somewhat forgotten term of “multi learning teams”. This has been one of the six characteristics defined in the very first article on Scrum in 1986. Surprisingly, empowered product teams stay very close to what Scrum authors were envisioning. And modern definitions of Scrum come even closer to that. So let us repeat this: Ideally empowered product teams are multilearning teams that work on the product end-to-end, mastering and acquiring new technical, product and business skills. Scrum Teams If you agree with our logic above, then we can conclude Scrum teams and ideally empowered product teams are, in fact, the same. Provided for Scrum applied is the context of product development. In Scrum, the Scrum Team has always envisioned doing the real work for customers and business (not just feature delivery). A Scrum Team works end-to-end from business objectives to customer happiness, from concepts to cash. It is the failure of our industry (and us, coaches) that we have allowed Scrum to be redefined and reduced to “executing delivery teams”. We have failed. Not Scrum. But let's move on. Product Learning Let's try to understand the product aspect of the ideally empowered product teams. And what structural implications it has. There is one key structural element of product organizations that can either constrain or facilitate broad product thinking. It is the product backlog(s) . Some naïve coaches and consultants don't pay attention to the number and the level of the backlogs. But let us explain why this is a big deal. Consider these two extremes: Separate team-level feature-centric backlogs (one backlog per team). A common product backlog with shared business objectives for a group of teams (one backlog for all). Backlogs create mental filters and barriers in teams and team members. Note how different the teams will look at their work depending on whether they have individual feature-centric backlogs versus one common objectives-centric backlog. So, what kind of backlogs do the empowered product teams should have? Do they have individual, narrow team-level feature-centric backlogs? If yes, the presence of such narrow separate backlogs will make the teams have a permanent focus on some predefined fixed set of product features. In such an organization, we will expect to find specialized teams. A “product catalog team” working on the product catalog, a “mobile team” working on the mobile app, and so forth. It is not uncommon to see such teams in organizations. But is such an org design (with a narrow separate backlog per team) compatible with the idea of product teams working from concept to cash, from problem to happiness, that are driving high outcomes with low outputs? We don't think so. The thing is that you can't keep working forever on something and expect to make a constantly high impact. An effect of diminishing returns will kick in eventually. And it will eventually stop making any economic and business sense to keep working on the same stuff over and over again. Isn't that what those “product catalog” and “mobile” teams are destined to do? Sadly, yes. That's why those are not product teams! Broader Product Definition To avoid being fixed on a product aspect and face the effect of diminishing returns, a product team needs to have a moving focus. This is not the same as not having a focus. They will have to switch from one solved top-priority customer problem to the next unsolved one. If those problems affect the same product part – fine, they can leverage their present skills. But that might not always be the case. This means such teams need to be constantly learning to work with different product parts, customer problems and business aspects. Over a very long period of time, you can expect that such teams will have worked already on the entire product and acquired a significant set of skills. We claim that; Learning to work broadly on the product (meaning not having a static fixed focus) is an inevitable characteristic of ideally empowered product teams. Our understanding is that the ideally empowered product teams need to share a common objective-oriented product backlog, with its items prioritized by a top-level business representative. And this view might be different from the one that Marty Cagan and his fellow consultants hold. Conclusion: Mapping “Empowered Product Teams” to Org Topologies™ We've looked above at ideally empowered product teams – our understanding of what it takes to create and sustain an organizational design where such teams would flourish. The X-Axes We've proven that such teams must be technically advanced and embrace multi learning. That should be the far right on the X-axis. But in some interviews, Marty Cagan claimed that a product lead is doing evidence value and viability proofs, before handing out this work to the team. And at the same time, Marty was saying that the team does discovery and delivery. We were not sure really what to make from this. Listen to the last 5 minutes of Xagility podcast . Marty Cagan literally says there: “… We can have it [the evidence] with a lot of prototyping and quick testing… And when it's worth building, then it goes on the product backlog, and then the team, Scrum or Kanban, would … be delivering a product. “ Does that imply that someone (a team lead?) does the prototyping and testing? Is that done separately and without the involvement of the team (as implied by the quote from the interview above)? If this is the case, then such a team is not doing the work 100% multidisciplinary, as there is some kind of reliance on a specialist. It is not clear to us what Marty means. But this made us doubt whether a team stretches to the far right on the map. The Y-Axes If we want the teams to work on the highest impact on customer and business problems, as we concluded above, the ideally empowered product teams have to share a single prioritized product backlog. This way, when the teams pull work from the top of the backlog, they engage themselves with the discovery and delivery of something of high value. An example can be: to increase customer retention rate to some desired level. But when this goal is achieved, improving retention is no longer the most important goal (as it has already been achieved). Therefore, the teams will have to work on something different that is now at the top of the product backlog. If we allow the teams to have individual backlogs, a given team might stay for as long as it wishes on a given topic, e.g., on improving retention. But it will also mean that the team isn't contributing to the highest impact because it ignores global priorities. We didn't hear Marty Cagan saying anything to confirm the fact that teams in his model to share a common product backlog. In fact, he insists that a product lead (a product owner) should be on a team, deciding priorities. That contradicts the idea of having cross-cutting priorities and implies local backlogs at the team level. It was also not in Marty's materials and explanations whether he sees multiple teams working with a single product lead (a product owner). And again, embedding a product lead (a product owner) into a team suggests the opposite. On the Org Topologies™ map, such an org design represents an A-row – teams working in isolation. This is not a place of high adaptivity, innovation, and resilience. We conclude our analysis with the following mapping: Comparing to SAFe In his articles, Marty Cagan contrasts “empowered product teams” with “delivery teams”. And we think we understand the distinction he tries to draw: product thinking vs. execution mode. Marty Cagan is used to saying that they have never seen any successful product organization using SAFe. That's a powerful statement! We believe he's got a point. His observations are also aligned with ours – we believe SAFe won't create a proper environment for empowered product teams to flourish. Instead, SAFe creates disempowered delivery teams focusing mainly on the execution with separated team-level feature-oriented backlogs . Below is the mapping of SAFe to Org Topologies™. Compare it with the mapping of empowered product teams: SAFe organizations and empowered product teams live indeed, slightly, in different worlds as per the mapping. One significant difference between these models is that an empowered product team can decide which features to build to satisfy the given objective. Whereas teams in SAFe are simply given features to build. Towards Better Organizations (with Empowered Product Teams) The goal of Org Topologies™ is not to downgrade other models or provide some sort of basis for another maturity assessment model. Not at all. The mission of Org Topologies™ is to help you , a leader of a given organization, to discover a vector of your long-term organizational development. We believe that higher states of adaptivity, innovation, and therefore overall organizational resilience are a great place to grow towards. As we did in our other analytical articles (on the Spotify Model of Tribes and Squads and Team Topologies ), we conclude by sharing some improvement recommendations. Have the most senior product manager be the Product Owner (product's CEO). For a start-up of 50-ish people, this role shall be played just by the CEO. We see this role as similar to what Marty Cagan defines as a Product Leader . This person needs to be: senior enough in the organization to have the necessary mandate in the context of the product work. This way, such a leader can drive the product strategy on a daily basis by making his list of business priorities clear (Product Backlog). That Product Backlog will likely be formulated as business objectives and customer needs . That is precisely what it takes to let the empowered product teams solve real business and customer problems. We suggest avoiding creating a helpers group around the Product Owner that typically consists of product managers and designers. Instead, make them team members of the empowered product teams. Introduce product and discovery specialists right into the existing teams – avoid separate specialist groups. Thus, you will facilitate the expansion and growth of the teams to become real product teams. What if you don't have enough product specialists for each team? It is better to have 5 out of 10 teams properly staffed than all the 10 teams understaffed and suffering. We believe that the fully end-to-end teams will show the difference by shipping faster, better solutions. And eventually acquiring the missing extra UX skills for some teams becomes a tactical decision. Employ the idea of multi-team work . To offload some work from the Product Owner (product lead), try applying prioritization over clarification pattern and practices of multi-team meetings . This would minimize the bottleneck and increase the flow, allowing the single Product Owner to lead many teams and increase the business impact of their work. © 2022-2023, Alexey Krivitsky and Roland Flemm. Org Topologies™.

The Agile Fluency® Model is a fantastic model. We just love it. With this model, you start seeing your journey as a series of paradigm shifts and stages toward higher fluency in Agile: The Agile Fluency model was an inspiration for us when we were designing Org Topologies ™ . So, no surprise, there are some similarities. The axes of Org Topologies™ are two kinds of fluency – in delivering and learning value, along which different organizational archetypes can be mapped in the boxes. Each move from and to any box on the map is a realization of a certain paradigm shift . Org Topologies can be used by leaders to analyze the current state of an organization and find a roadmap for change. It is envisioned to serve as a map to navigate to the perfect state of high organizational adaptivity: Org Topologies™ as a Map for Mastering Agile Fluency Having understood these two models, you shall be able to see how the Org Topologies™ can help to map a journey for Agile Fluency in a series of radical change steps ( Kaikaku in Japanese). It all starts with focusing on value. Without defining value, no agile transformation is possible. This is because the goal of such a transformation is to design an organization that discovers and delivers customer & business value continuously. After focusing, delivering goes – as a shift toward creating customer-facing self-managing teams. In Scrum terms, this is about improving upon the Definition of Done. And in the 21st century for software development teams, this means realizing the paradigm of Continuous Delivery . Once the value is defined and the teams start to learn and deliver, the change isn't done yet. It is never done. As optimizing & strengthening are continuously applied improvement katas that are performed within the organization never stop improving and experimenting. The image below illustrates this idea, mapping Agile Fluency stages onto the Org Topologies™. The next chapters detail these change steps. Focusing Some organizations are winning when they realize the collaboration, transparency, and cost savings that come from Focusing on business results. agilefluency.org We believe this too. On the map of Org Topologies, focusing can be represented as a vertical move – a move towards a higher understanding of value. Of course, every journey will be unique: some organizations will be capable of comprehending value at the feature level, to begin with. Others – at some higher levels, for instance at the level of customer needs and journeys. If so, they are likely to be forming value areas . Focusing on the value must be the first strategic move in the game of transformation. Only once the target understanding of value is clarified, the next steps of restructuring should take place to focus the teams on that value. Structurally speaking, the focus is on creating an organizational understanding of value. It shall result in clear accountabilities (e.g., the role of a product owner) to manage the value at that defined level (e.g., with a product backlog). Plus, the technical capabilities in the form of teams focused on the value as goals and priorities. For instance, if the target understanding of the target org design is to form a wholistic value area (a B-level of Org Topologies), then there should be a leader who can take accountability for maintaining that area backlog. Such backlog will be shaping the area investment decisions and inform the teams about the product strategy -- creating an environment of radical transparency, focus and shared ownership. Thus, any team-level backlogs of any kind would jeopardize that vision. We discussed this issue in detail in our analysis of Spotify's Tribes and Squads model. To recap on that key message: if an organization is serious about optimizing at the level of a value area – that should be seen as an organizational cell built at the higher level, with no local suboptimization within. Delivering Other organizations require the minimal defects and high productivity that allows them to ship on cadence and receive the market boost that comes from consistently Delivering when the market demands. agilefluency.org Once there is a target understanding of the value and corresponding supporting context for it (strategy, leadership, a backlog, teams), now the second part of the journey starts – to improve the delivery capabilities of the teams, individually and collectively. On the map of Org Topologies™, delivering can be represented as a horizontal move towards multidiscipline and multi-learning work with flow. Again, it is up to a given organization, how high it sets the bar and how incrementally it sees that change happening. But Org Topologies™ can be used to set the direction. For instance, an organization might go with some stream-aligned and platform teams. That might be the right move to a better state in terms of fluency in delivering, but some thorough critical thinking is to be applied to make such improvements work continuously. Not to get stuck in mediocrity. We have reviewed those ideas in an article on Team Topologies and highlighted some serious drawbacks of such an organizational design. Nevertheless, it is now the job of the leaders and coaches of such an organization to find the path of improving delivery of the value. Optimizing & Strengthening Yet other organizations need to anticipate the market, dance with change and receive the benefits that come from smoothly Optimizing their value and applying their market expertise in new ways. agilefluency.org We love the Agile Fluency model because it is a description of a journey , not a static picture. There are enough static frameworks out there, that might help organizations improve just slightly or almost superficially. A good example here would be SAFe . So be aware. In order not to get stuck in some kind of agile-limbo state, an organization needs to have a perfection vision that will be pulling it further, no matter what. The mission of Org Topologies™ is to help organizational leaders to discover their long-term organizational development vector towards perfection and embark on a never-ending journey of realizing it. We are carefully picking the words here. We are saying “development” (as a never-ending effort), rather than a “transformation project” (that can be accomplished and marked 'done'). In this view, Agile Fluency is alike, it helps you embark on a journey. And now with Org Topologies, we want to believe, you also have the maps to help you navigate the land of agility. Agile Fluency® is a registered trademark of Diana Larsen and James Shore, used here with their permission. © Alexey Krivitsky and Roland Flemm.

Have you read the introductory article Seven Archetypes (the Alphabet) of Org Topologies™ ? That would help. The big determining factor on the vertical axis is the type of input a given unit receives: Does the unit receive tasks ? ... feature requests ? ... business objectives ? ... product goals & customer challenges ? Tasks provided as inputs to the unit would classify the unit as the Y-level . Constant feature requests (and nothing else) would classify the unit as an A-level archetype. Business objectives, product goals, and customer challenges - B or C (the higher archetypes), depending on how broad the scope of work and ownership is. This very simple logic will help you determine the vertical level of a given work unit (individual, functional group, or team). This is an outside, black-box view from the mere viewpoint of the inputs a work unit receives. The input levels a unit receives are not random in a given context but are a function of: org & power structures work breakdown and work integration processes believes of the management cultural aspects Therefore, the correct determination of the vertical a unit belongs to, says a lot about the organization structure, process maturity and culture. But what if we look inside the box? "There is a whole universe within a universe." Looking inside a team might have a completely different picture of how the work is received, perceived and gets done. In the theory of networking there are six different types of networking topologies possible to perform a (networking, routing) operation: And if we consider an org work unit (i.e. a team) as a graph of connections and relationships between its members, we can assume some of these classical networking topologies have their place. Consider the star topology above - one person (i.e., a team lead) decides who works on what, then divides and distributes the work accordingly. This central hub of a network might receive feature requests (an A-level per Org Topologies™) but then break down the work into tasks to be fed to his teammates (almost like a Y0 level - individualistic task work). That creates a conflict! From the outside, the work unit acts like an A-level (let's say an A2) archetype that doesn't require external micromanagement and can convert a feature request into a working feature. But once we unwrap the black box, we see that most of the team members exhibit the Y-level dynamics: they work on tasks, don't see the bigger picture, don't speak the customer's language, and require a task coordinator. The same logic can be applied to at least one more networking topology - the line topology . At a team level, it will result in sequential work with hand-offs between single-skilled individuals, a mini-waterfall. The mesh topology is probably the best representation of how any team coach would want an agile team to operate. But also with dynamic relationships. There, the people work with whoever they need to work on at any given moment of time without any central hub to be held responsible for the overall coordination. Coaching opportunities "Give me a lever and a place to stand and I will move the earth". If you uncover a mismatch between an external view (e.g. A2) of an archetype and how it operates inside (Y0 with individualistic work or maybe Y1 with a mini-waterfall), this means that a given team doesn't live up to its full potential yet. Hence, you've found your coaching opportunity - a lever! This can be visualized with the sub-levels as illustrated in the picture below: Imagine every box of the Org Topologies™ map has a smaller map inside. As we described above, with the help of the networking topologies, an A2 archetype can be different when studied from the inside. This is what you typically see around when coaching the A2 teams: some A2s will have a team lead and be more like a Y0 inside some A2s will have mini-waterfalls and act inside like a Y1 others, more perfect A2s, will be more like real A2s So, by putting a map inside a box, you can find the internal gap - a coaching opportunity: Summary Applying Org Topologies™ to coach organizations requires observing the system as a whole as well as its parts. Studying the whole system or its parts are two different approaches that are valuable in understanding the whole ecosystem. Working with the whole When we observe the whole, we assess which elements are in the ecosystem and study the interactions between them. We are not zooming in trying to improve the performance of a single part. We design and sustain the org design by working at the level of the organizational building blocks (the archetypes). Once we understand how the parts are interacting and what level of adaptivity this produces for the whole system (i.e. the development organization), we can formulate actions to redesign it to obtain higher adaptivity at the whole level. An example of such a systemic change is moving a collection of teams that work independently from each other with feature ownership towards a team of teams that work as one on a business objective. Coaching the parts We can also deliberately zoom in and study the parts internally. In other words, we consider the organizational element that we examine to be the boundary of our system. Inside that system the mapping of Org Topologies™ can be equally applied to study the interactions of individuals inside an org unit. We will find many coaching opportunities by going to Gemba to coach the teams. We can help them to unleash their true potential by leveraging their inter- and in-team collaboration skills. © 2023 Roland Flemm and Alexey Krivitsky for Org Topologies™.

I was asked by a Product Owner to come and have a look at one of his teams. I served him getting Scrum going about 1,5 years ago and he wanted to know how they were doing now. When I asked him what he wanted me to do exactly, he smiled and said he wanted me to "shake things up a bit". (This article builds upon a basic understanding of Org Topologies ™) . Since I worked with the team, they had grown from five to eight team members. They work in a complex and large corporate environment. The original idea 1,5 years ago was to create an autonomous team working on a feature set (A3), but I observed now they were spending most of their time managing dependencies (A2). After observing some of their events and a session to make an inventory of the main problems they experienced, we scheduled a "ready for the future" session. The goal of this session was two-fold: 1) Explore possibilities for creating more in-team cohesion between the product specialists and the developers and 2) Understand how the team might best cope with the existing (inter-team) dependencies. Introducing the Org Topologies™ Map To kick off the session, I introduced the team to Organizational Topologies™ (OT™). We explored the organizational archetypes on the map and tried to determine where the team is now. We concluded that over the past 1,5 years, the team had grown from their initial Y0 (individualistic task-driven work) via A1 (a team of product specialists without developers) to A2, an incomplete team with a feature focus. It took about thirty minutes to explain the OT™ tool. The team could then identify their journey and current position. While assessing their journey the team was using a common language while talking about organizational design: the language of Organizational Archetypes. Exploring the journey on the horizontal axis We then zoomed in on the horizontal axis of the Org Topology™ map. This axis describes the in-team collaboration and focuses on the capabilities needed to deliver a working product in the hands of the customer. We need to focus on how autonomously the team can create a final product, in other words, we study the team's dependencies. A good question to get clarity on the dependencies is: What skills does the team need to be able to deliver "DONE" autonomously, i.e. from idea to production? Someone on the team replied: "There are so many skills needed that we will end up with a team that is way too large!". I suggested that we should make this concrete by summing up all those skills. They came up with about 15 skills. With the capabilities listed, we need to understand how this impacts the functioning of the team. We marked which of these capabilities were currently not present in the team. Since we do not want to implement solutions to resolve exceptional situations, we only want to focus on the most important missing skills. Important here means: occurring most of the time. For every missing skill, I asked the team to think back and determine if they needed this skill in seven of the last ten sprints, i.e. do we need this skill (capability) 70% of the time? If not, then this is not a very blocking missing skill. (I prefer to pull up the Product Backlog history for this to prevent generalizations, but in this case with the PO present, that was not necessary). We ended up with 5 capabilities that were missing and frequently blocking: Requirements analysis, Test specialism, Branding, "TP-application"-skills, and Legal. To reduce the list, I asked the team if there were skills that would no longer be important in the (near) future. The "TP-application" was to be decommissioned later this year. The team agreed to deal with this dependency for the time being and understood further investment was not a wise thing to do. To tackle the final list of four, I asked the team if they had any proposals to resolve the remaining skills. The developers proposed to find an analyst and a test specialist and add them to the team. The Product Owner mentioned that this was an expensive option. The other team members were arguing that anybody could learn analysis and testing and that actually existing team members doing this work would be a better option because this would keep the team nimble. Then the developers were arguing that T-shaping would reduce their specialism. The Product Specialists on the team observed that they had learned a lot from each other's expertise over the past time and this had turned them into specialists with multiple skills instead of reducing their primary specialism. We also agreed that the company offers guilds and chapters to specialists to keep their knowledge up to par. Often, when Product Specialists create new offerings or change existing product conditions, there might be legal consequences. For example, relaxing loan conditions could turn a loan product potentially into a liability for the bank. Team members agreed it would be interesting but not feasible to do a legal study to cover all legal matters. Instead, the option of having someone in close proximity, ready to join the team in refinements is good enough. Someone argued that in many cases, Legal was asked prematurely and that it would be worthwhile to define from what level legal advice is indispensable. They would make agreements with legal so the team would get the mandate to decide by themselves when they need legal support and when not. In summary, the team came up with the following generic options to solve the missing skills problems: Existing team members learn the skill (acquire knowledge) Agreeing with stakeholders to give the mandate to the team (acquire permissions) Automate and create a self-service solution (no-code/low-code solutions) Having someone close to the team who can help refine and provide feedback Adding someone with the missing skill/knowledge to the team An appropriate solution was found for each of the missing skills. The team was surprised that there were so many other achievable options other than the obvious, adding people to the team. What about the vertical axis? The vertical axis describes how collaboration takes place between teams. The team had grown from tasks to features (Y to A level) over time. When studying the OT™ map, they concluded they had now arrived at the B level, working as a Business value area. This was incorrect, they were still at the A level working as a single team, because there was no team of teams. I wanted to make them understand where they are now and what it takes to work at the B level. (Having clarity on your current position and knowing your destination is important when you are on a journey). We drew the teams in circles on a whiteboard in a larger circle with the department name and around all a circle with the name of the company. We then asked ourselves the following questions: How often do we coordinate work with the other teams within our department? How often do we coordinate work with other teams outside our department? What is the name of the product that each team in our department is responsible for? And: Is the customer willing to pay money for "our product"? Now what does the customer perceive as being the product? The team agreed that this would be the combined output of all teams working in the department: A business loan. For example, if the customer does not want to pay for the registration of their customer data, the customer does not want to pay separately for getting a new loan and for making a change to an existing loan. With that product definition in mind, we explored what would be "the best team" to serve the customer. Or in other words, what product knowledge should our team have so that it can independently deliver all customer value? The answer is: each team should have the product knowledge of all current teams combined. I drew this picture to explain the feature team concept: Just as becoming T-shaped makes team members more adaptive on the horizontal axis (skills), broadening product knowledge makes teams more adaptive across the vertical axis (breadth of product understanding). Making this change creates groups, "teams of teams", in what we in Org Topologies™ call "Business Value Areas". These groups are able to absorb much more variations because they span a greater area of knowledge. This move would require teams to be reorganized and product backlogs to be aggregated to contain true customer value items. Team members wondered what could be possible reasons why you would want this aggregation and reshuffling of teams and they wondered if it would apply in their context. We came up with the following benefits: If we consolidate, we have fewer dependencies There is much more connection between product work and software development work (and there will be less local optimization) Capacity problems in the current teams are solved when we combine teams We can work much more efficiently because we all know what we are going to make, and also because we are working on the same goal at the same time We will deliver more valuable products to customers We discussed some concerns (and found answers to most of them): This is quite a drastic change. Can we do this? Do we need approval? What will the Product Owners think of this? How will this affect the surrounding service teams we work for? How do we divide run and change work? How do we maintain knowledge of our specialisms? How do Sprints work with so many people at once? The objection that was mentioned last "that it could be very difficult to work in Sprints with such a large group (about 60 people)" was something I paid some extra attention to. I explained how this is usually done in LeSS with Multi-team Backlog Refinements, joint Sprint Planning, and Sprint Reviews. You might want to read some more on how to facilitate these large-scale events here: Multi-team Product Backlog Refinement Large-scale Sprint Planning Large-scale Sprint Review Another interesting question was, "If we don't make such a deep change, can we nonetheless benefit from the perks like the higher B and C levels do?" The answer to this is: Yes, you can! The effect will be smaller, but it will help you "get used" to that way of working. For example, by starting with a joint Sprint Review, you will make it easier for stakeholders to join an event where condensed information can be acquired. And at the same time, you will find that retrieving feedback on the result from the combined teams is more rewarding than from each of the teams individually. This provides an incentive to look for ways to work together more intensively. Conclusion This team now has an understanding of the downsides of their current team setup. They have been studying their history and current position from a systemic point of view. They have assessed possible future states and understand what moving up to the B level on the Org Topology™ map could bring them. They also already see what this will require of them and they have some idea of how this B-level with a team of teams might work. In only 1,5 hours the team has taken the first important step toward taking ownership of their organizational design. © 2022 Roland Flemm and Alexey Krivitsky for Org Topologies™.