Review: Team Topologies

515ymmKuFqL._SX332_BO1,204,203,200_Many organizations are struggling with their business agility transformation. One of the reasons is the way they have organized their teams. The focus was probably on efficiency and if these teams start to use agile ways of working, this doesn’t make the organization agile. The book Team Topologies – Organizing business and technology teams for fast flow, by Matthew Skelton and Manuel Pais, will help you to design a team organization structure that helps you to become more agile. Using their ideas will help to overcome some obstacles for fast flow. E.g. pushing against Conway’s law, software that is to big for teams, confusing organization design options, teams that are pulled in many directions, painful re-organizations every few years, blocked flow, too many surprises and disengaged teams.

The book is divided into three parts. Part I focusses on teams as the means of delivery. Part II explains team topologies that work for flow and part III elaborates on evolving team interactions for innovation and rapid delivery.

QRC (Team topologies, 200525) v1.0To download: QRC (Team Topologies, 200525) v1.0

The book explains the seven core ideas behind team topologies:

  1. Conway’s law. “Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.” Conway’s law tells us that an organization’s structure and the actual communication paths between teams persevere in the resulting architecture of the system built
  2. Team first. Start with the team for effective software delivery. There are multiple aspects to consider and nurture: team size, team lifespan, team relationships, and team cognition. Organizational groupings should follow Dunbar’s number, beginning with around 5-8 people, then increasing to around 15 people, then 50, then 150, then 500, and so on. Organizational groupings should follow Dunbar’s number, beginning with around 5-8 people, then increasing to around 15 people, then 50, then 150, then 500, and so on. Cognitive load: “The total amount of mental effort being used in the working memory.” Restrict team responsibilities to match the maximum team cognitive load. The following three different kinds of cognitive load are explained:
    • Intrinsic cognitive load – relates to aspects of the task fundamental to the problem space
    • Extraneous cognitive load – relates to the environment in which the task is being done
    • Germane cognitive load – relates to aspects of the task that need special attention for learning or high performance.
  1. Four fundamental topologies. The four fundamental team topologies are explained including expected behavior and capabilities:
    • Stream-Aligned Team: a team aligned to the main flow of business change, with cross-functional skills mix and the ability to deliver significant increments without waiting on another team (some would call these teams “product or feature teams” but talking about streams makes more sense)
    • Platform team: a team that works on the underlying platform supporting stream-aligned teams in delivery. The platform simplifies otherwise complex technology and reduces cognitive load for teams that use it (a good platform is “just big enough”)
    • Enabling team: a team that assists other teams in adopting and modifying software as part of a transition or learning period
    • Complicated-Subsystem Team: a team with a special remit for a subsystem that is too complicated to be dealt with by a normal stream-aligned team or platform team. Optional and only used when really necessary.
  1. Team interaction modes. The primary interaction modes for the 4 fundamental team topologies are:
    • Collaboration: working closely together with another team
    • X-as-a Service: consuming or providing something with minimal collaboration
    • Facilitating: helping (or being helped by) another team to clear impediments
  1. Organizational sensing. Expect to adapt and evolve your organization structure.
  2. Topology evolution. An organization should expect to see different kinds of interactions between different kinds of teams at any given time as the organization responds to new challenges
  3. Team API. A description of the entire interactions with the team: code, versioning, wiki and documentation, practices and principles, communication, work information and other.

Combine a team-first approach with Conway’s lay, the four fundamental topologies, team interaction modes, topology evolution, and organization sensing. Get started: begin with the team, identify streams, identify the thinnest viable platform, identify capability gaps, and practice team interactions.

Conclusion. I would say a great book for those who are designing their agile transition. This book will help to understand where you have to think about when creating your team topology. You get lots of case studies and industry examples.

To order (Maangementboek.nl): Team Topologies

To order (bol.com): Team Topologies

To order (Amazon.com): Team Topologies

The Digital Fluency Model

My quest continues and continues. The Digital Fluency model is the next one to add to my Bird’s eye view on the agile forest article (thanks to Zaher Alhaj).

Digital Fluency is about achieving what is required for your specific needs and goals and recognizing the importance of continually investing and evolving with your business and customers. The Digital Fluency Model will help you map out your aspired level of fluency for each building block (frictionless operating model, platform strategy, experience design & product capability, intelligence-driven decision making and engineering culture, delivery mindset) capability and identify the sensible default set of investments required to achieve your business goals. Fluency (awareness, focusing, executing, optimizing and strengthening) will be different for each capability, for each organization and even across different parts of the same organization.

Digital Fluency ModelThe Digital Fluency Model can be used to assess your digital (agile) transformation. According to this model, there are 5 digital capabilities:

  • Frictionless OperatingModel:  a smooth flow from business strategy to execution.
  • Platform Strategy: exposing core business capabilities easily as consumable services, providing self-service access to data, evolutionary #architecture patterns and advanced delivery infrastructure.
  • Experience Design & Product Capability:  building modern digital products and experiences iteratively through experimentation
  • Intelligence-Driven #DecisionMaking:  leveraging all data assets
  • Engineering Culture, Delivery Mindset: patterns and best practices of lean, iterative, and continuous delivery of software.

These capabilities are planned and monitored over 5-levels of fluency:

  1. Awareness (something needs to change in order to be successful)
  2. Focusing (Agree, plan and set up your change)
  3. Executing (Mastery of practices)
  4. Optimizing (Remove constraints)
  5. Strengthening (Reinforce across the business)

See for detailed information the corresponding website Digital Fluency Model

The digital Fluency Model makes use of the Agile Fluence Model. I position this model in the Culture-targeted box of my Bird’s eye view on the agile forest. See the corresponding article.Grasp session (Scaling Agile bron, 200414) v1.1

Recensie Agile Design

9789492618375-480x600Een van de principes van het Agile Manifesto luidt: “The best architectures, requirements, and designs emerge from self-organizing teams”. Het bestaansrecht van een design wordt echter door veel organisaties in twijfel getrokken. Op het moment dat meerdere teams aan één product werken wordt het hebben van een globaal ontwerp al duidelijker maar ook indien in de ideale situatie slechts één autonoom team verantwoordelijk is voor een product of service is er nog steeds behoefte aan een design. Een design is essentieel voor het borgen van kennisoverdracht, ondersteuning van beheer en het nakomen van wet- en regelgeving. En dit is precies waar het in het boek Agile Design Best Practices – Een set van best practices voor een evolutionair design van informatiesystemen geschreven door Bart de Best over gaat.

In het boek staan twee aspecten centraal. Het veranderparadigma en de design pyramid.

Het veranderparadigma laat zien dat bij een verandering van werkwijze ook het delen van gemeenschappelijke uitgangspunten vereis is. Het is belangrijk dat er eerst een synchronisatie van denkbeelden plaatsvindt. Dit betreft zowel de denkbeelden van de business case (beeld), het eigenaarschap (macht), de werkwijze (organisatie) als de benodigde mensen en middelen (resources). De auteur projecteert dit op zowel een agile aanpak, een waterval aanpak alsmede op een uitgewerkte casus.

QRC (Agile Design, 200504) v1.0

Downloaden: QRC (Agile Design, 200504) v1.0

De design pyramid geeft een classificatie van onderdelen waaruit een design moet bestaan. De non agile design pyramid komt kort aan bod en de ideal design pyramid bestrijkt de hoofdmoot van het boek.

Een non agile design pyramid beschrijft de architectural, functional, technical, requirements, test en code view van een traditionele aanpak. Hierbij wordt in het voortraject de meeste tijd gestopt en naarmate je verder in de tijd bent wordt er steeds minder tijd gestopt in de volgende views en lopen de views vanuit de business (wat) naar de techniek (hoe). Deze pyramide wordt gevisualiseerd door een omgekeerde pyramide.

Het boek beschrijft in detail alle lagen van een ideal design pyramid waarbij de lagen wederom vanuit de business (wat) naar de techniek (hoe) lopen maar waarbij de inspanning omgekeerd is. Aan het begin minder inspanning en naarmate men verder in het project is steeds meer. De lagen en bijbehorende op te leveren producten, die ieder in een hoofdstuk aan bod komen, zijn:

  • Business view: system context diagram en value stream canvas
  • Solution view: use case diagram, system building blocks (Informatie, applicatie en technologie) en value stream mapping
  • Design view: use cases bestaande uit use case narrative en use case scenario
  • Requirements view: Behavior Driven Development (BDD) feature files (Given-When-Then format)
  • Test view: Test Driven Development (TDD) met testframework, testcases en testdatasets
  • Code view: code as documenten of documentation as code of continuous documentation.

In de bijlagen onder andere aan tabel van agile tools inclusief verwijzingen naar websites.

Conclusie. Het boek geeft veel praktische handvatten hoe een agile design vormgegeven kan worden. Als rode draad loopt het ontwerp van een koffiemachine door het boek. Bij iedere laag van de ideal design pyramid krijgen we de bijbehorende  ingevulde op te leveren producten. Verder per laag verschillende tips en trucks (trucs of tricks?).

Bestellen: Agile Design

Recensie Vakblad Projectmanagement en agilemanagement (nummer 10)

Schermafdruk 2020-05-01 20.23.52Alweer het 10e nummer en daarmee is het tweede lustrum een feit. Het blad waarin deze keer het thema duurzaamheid centraal staat, wordt binnenkort in de brievenbus afgeleverd. Het is niet meer weg te denken en volgens mij, jammer genoeg, het laatste papieren vakblad voor projectmanagers in Nederland. Om dit lustrum te vieren kan iedereen een gratis digitale editie van het nummer downloaden op www.kwdrm.nl.

Luuk Ketel gaat in het hoofdartikel Samenhangende duurzaamheid in op het thema duurzaamheid, de relatie met de huidige Corona crisis en de zeventien door de Verenigde Naties gestelde sustainable development goals en welke persoonlijke invulling daarbij nodig is.

Leo Klaver interviewt Abt Henry Vesseur van de Benedictijnse abdij Willebrord te Doetinchem om vast te stellen of een abdij met roots uit de 5de eeuw ook in de 21ste eeuw hetzelfde bestaansrecht heeft als toen en wat religie ons kan leren over duurzaamheid. Vele projectmanagers kennen het Agile Manifesto maar wie kent de meer dan 1500 jaar oude ‘Regel voor monniken’, een handleiding waarin het geestelijke, sociale en materiële leven van de monniken wordt geregeld en de ‘Regel van Benedictus’. Ook projectmanagers hebben een verantwoordelijkheid voor hetgeen ze in bruikleen is gegeven zoals het team, de resources en de middelen om een duurzaam resultaat neer te zetten. Welke business case ligt er ten grondslag aan het werken in de abdij?

Het artikel Streven naar duurzame ontwikkeling, wat betekent dat? van Ben Berndt en Peter Storm laat zien dat bij iedere persoonlijke handeling en bij elke zakelijke investering een zodanige keuze wordt gemaakt dat zowel de belangen van de huidige generatie als die van toekomstige generaties worden meegenomen. Kijkend naar IT projecten laten de auteurs zien dat er meerdere wegen om te kiezen voor duurzaam projectmanagement zijn zoals een opportunistische, een pragmatische of een idealistische weg.

Martijn van Nierop benoemt in zijn artikel Het glazen plafond in agile transities een aantal dilemma’s zoals besturing, planning, financiering en HR waarover genuanceerde beslissingen moeten worden genomen om te voorkomen dat de bottom-up ingestoken agile transitie stil komt te staan. Beslissingen die top-down genomen moeten worden.

In het artikel Wanneer ben je niet op je best? En wat kun je eraan doen gaat auteur Peter Storm in op psychologische veiligheid en wat je daar zelf aan kunt doen aan de hand van een voorbeeld van zijn taalbuddy Obada – een vluchteling uit Syrië – die een Engelse taaltest moest doen.

Ben Berndt en Irene Schrotenboer houden in hun artikel Integratieve projectmanagement-rapportage een pleidooi voor een rapportage waarin met meerdere invalshoeken wordt rekening gehouden of te wel een rapportage die is afgestemd op alle stakeholders. Irene laat zien dat zij in haar rol als projectmanager van het Interreg-2-Seas project de verplichte rapportage heeft aangevuld met een integratieve rapportage die gebaseerd op de zes ‘capitals’ uit het Six Capital model namelijk financial, manufactured, natural, human, intelectual en social and relational capital waardoor duidelijk wordt dat de beoogde deadlines op een duurzame manier worden bereikt.

In het artikel Competenties en karaktereigenschappen van projectmanagers beschrijft Liesbeth Rijsdijk de competenties en gedragseigenschappen die noodzakelijk zijn in de VUCA-wereld. Hierbij spelen de door Howard Gardner genoemde mindsets disciplined, synthesizing, creating, respectful en de ethical mind een belangrijke rol. Ook de door het World Economic Forum genoemde cruciale karakterkwaliteiten nieuwsgierigheid, initiatief nemen, vasthoudendheid, aanpassingsvermogen, leiderschap en sociaal en cultureel bewustzijn paseren de revue alsmede de karakterkwaliteiten van de 21st Century Learner. Vervolgens worden al deze kwaliteiten vergeleken met de IPMA ICB4 om vast te stellen waar uitbreiding gewenst is.

Saskia Giebels duikt in haar artikel De kracht van intuïtie … en de valkuilen in de wereld van het adaptieve onbewuste aan de hand van Henry Mintzberg, Malcolm Gladwell, nobelprijswinnaar Daniel Kahneman en ervaringen van projectmanagers als ze op basis van intuïtie beslissingen hebben genomen. Stel jezelf de vraag of aan je intuïtieve oordeel echte expertise ten grondslag ligt of is de situatie eigenlijk te onvoorspelbaar om hierover intuïtief te kunnen oordelen. Zijn er vooroordelen of biases zoals optimistic bias, planning fallacy, halo- en horn-effect, anchoring effect en aversie tegen verlies en framing die een rol spelen in mijn oordeel als projectmanager?

Uiteraard komen de drie projectfilosofen ook weer aan het woord. ‘Waarzegger’ John Hermarij stelt in zijn column Duurzame interventies dat er geen juiste aanpak voor veranderen bestaat maar dat luisteren naar je eigen mensen in je organisatie de basis is voor de juiste verandering. ‘Herkauwer’ Ben Berndt kauwt in zijn column Lectio divina in duurzame transparantie op de woorden duurzaam, duurzaamheid en transparantie. ‘Waakhond’ Peter Storm vraagt zich in zijn column De ‘wetteloosheid’ van projectmanagement af wanneer we nu eindelijk eens internationaal geaccepteerde projectrapportage richtlijnen en een gezamenlijke projectstandaard krijgen en gebruiken om vergelijking van projecten mogelijk te maken en daarvan te leren.

Van mijn hand deze keer een recensie van het boek Duurzaam projectmanagement, de nieuwe realiteit van projectmanagement geschreven door Ron Schipper en Gilbert Silvius. Met in de inleiding een voorbeeld hoe een Zweeds ingenieurs en consultancy bedrijf het belang van duurzaamheid in hun (PRINCE2) projectaanpak onder de aandacht brengt.

Conclusie. Wederom een lezenswaardig blad waarin voor iedere projectmanager wel weer een aantal interessante artikelen te vinden zijn! Goed om te zien dat het kernthema duurzaamheid een platform heeft gekregen. In maart was ik nog op de valreep voor de Corona crisis in Litouwen om daar in een driedaagse workshop het IPMA Project Excellence Model te doorgronden. Sustainability staat in het hart van het model.

Geen abonnee maar wel belangstelling voor het blad, en ik kan het van harte aanbevelen, dan is het een kwestie van abonneren. Zie: KWD Resultaatmanagement.

Review Rethinking agile

51nTAg-en9LRethinking agile – Why agile teams have nothing to do with business agility written by Klaus Leopold is great book to cope with agile transformations and what you have to do to increase the chance of success. It definitely busted the myth that having agile teams makes you agile.

The book is divided into four parts: the problem, the causes, the first solution, and the result.

The book starts with a case study of an organization that wants to optimize their time-to-market. They want to reorganize their teams. All teams should be cross-functional and organized according to the premise: One team, one product. Teams could choose the agile method they wanted to use, and the following requirements needed to be fulfilled: work should be visually managed, hold daily stand-ups, retrospectives, throughput and cycle time must be measured. All 600 IT employees followed a one-day agile mindset basis training. Management realigned the teams according the product structure and the reorganization took place through self-organization (marketplace). External support in the form of 16 coaches helped the teams to run system design workshops and create Kanban systems to visualize and manage their workflows. As a result, all teams were fully transformed and fulfilled the stipulated agile framework conditions. But the ability of the teams to deliver had not changed much! Projects are not being completed more quickly!

The author describes four causes why their projects were not completed more quickly.

Cause #1: The pitfall of simplistic inference in the change process

    • Implementing agile is a means – not a purpose – for achieving business agility
    • The change process as a project (pull versus push principle)
    • Change is a new organigram – mixing up cause and effect.

Cause#2: Dealing with dependencies between teams and products. They forget to consider:

    • One product, many teams
    • Dependencies between products
    • Peculiarities in knowledge work.

Cause #3: An incomplete value stream

    • What is happening downstream? Integration? testing? release? …?
    • What is happening upstream? Idea pool? Triage? Business case, decision making. …?
    • End-to-end management of the value stream was missing.

Cause#4: WIP limits at the wrong place

    • Reducing WIP: Park the work in front of the system (option pool)
    • Limit the initiatives, the number of projects in the system (strategic portfolio management).

As a solution the author discusses the added value of the flight level model as a communication instrument to identify the effect of specific improvements at operational level (team), coordination (value stream) and at strategic portfolio management (company) and to discover where within the organization it makes sense and/or is possible to leverage improvements (visualizing the work, setting WIP limits, establishing feedbackand determining and implementing improvements). On top of that he sees three areas of improvement: make dependencies visible (product boards), integrating the upstream (be aware of traps: too much, too exact, too unnecessary) and strategic portfolio management (strategy board).

The book ends with a summary to make your business agile:

  • Start at the top (the first agile team)
  • Agility begins with the change process
  • Focus on the goal not on the method
  • Agility is not a team affair
  • Identify the flight levels (operational level, coordination and at strategic portfolio management)
  • Manage and eliminate dependencies
  • Incorporate the drivers for lean business agility at every flight level (visualize, manage WIP, feedback loops, improve).

Conclusion. Great book and nice illustrations (by Matthias Seifert). A must read for those who are starting or in the middle of a business agility transformation to learn what others did wrong and what you can do to increase your chance of success. A next print could benefit when a contents paragraph and chapter and paragraph numbers are added.

To order (Amazon): Rethinking agile

To order (bol.com): Rethinking agile

Review: DevOps for the modern enterprise

devopsDevOps for the modern enterprise – winning practices to transform legacy IT organizations is a practical book based on the experience of the author Mirco Hering.

The book is divided into three parts. The first part explains how to create the right ecosystem for success. The second part puts the people and organizational dimension in the spotlights and the last part emphasizes on technology and architecture aspects. Every part contains four chapters and at the end of each chapter you get some steps to exercise to make it more practical.

The first part – creating the right ecosystem – starts with the usage of value stream maps to visualize your IT delivery process and a jump-start of the transformation with an initial roadmap and governance approach. As a next step you have to analyze your application portfolio (criticality of application, level of investment in application, preferred frequency of change, technology stack). Based on this analysis you should focus on a minimum valuable cluster (MVC) to speed up the complete cluster by uplifting the MVC. The following chapter discusses the added value of guidelines for selecting new applications and the strengthening of your architecture by creating and empowering ecosystem. The following aspects can be used to start the assessment of architecture maturity: auto scaling, self-healing, monitoring and capability for change. When looking at your packages, in case you can’t or don’t want to replace, the following approaches are explained: leverage your system integrator, leverage user groups, strangle the application and/or incentivize the vendor to improve their product. In line with the types of applications (differentiator applications, workhorses and true legacy) you have to find the right partner that fits your ambition and culture.

As stated, the second part put the people central. How can you provide your people with the right context for their decisions, what team structure you should choose to enable autonomy and purpose, how to shift from legacy thinking that has caused many test automations projects to fail, and how to manage your people better? Based on the “burger organizational chart” the author discusses delivery governance (with an agile governance function, DevOps governance function and quality assurance),  the test automation center of excellence, agile teams (maybe clustered in an agile release train, team by location, team by function and team by technology) and the platform team (test automation, automated app release and environment provisioning). A separate chapter is dedicated to testers and the importance of quality. The last part gives more generic people-oriented techniques and ways of working like one-on-ones, feedback, delegation, creating a blameless culture and measuring your organizational culture.

The last part looks at the right way to choose DevOps tooling, what makes a good DevOps architecture, how to evolve your application architecture, how to leverage the relationship between DevOps and cloud computing, what each delivery model looks like, and how these models impact your organization.

The delivery models are:

  • Continuous delivery model deploys applications automatically into persistent environments (either cloud or on premises)
  • Cloud-enabled delivery model deploys applications automatically after provisioning a new environment from the cloud or data center. Main difference compared to continuous delivery model is the maturing of the infrastructure practices – infrastructure as a code.
  • Container-enabled delivery model deploys applications as a set of containers into one or more hosts that are dynamically created. Main difference compared to cloud-enabled delivery model is the maturity of the container practices and the more modular application architecture.
  • Serverless delivery model (potential future model) where you don’t run services as such but rather write a function to perform some business logic. When the function is called, an instance is created just for the duration of the function call (e.g. Amazon Lambda).

To evolve your architecture over time you can use the strategies decoupling (two speed delivery model), going on a diet (paying down the technical debt and making the core more agile), let’s try it on the side (green field setting) and erode the core with microservices (a service that serves one purpose; it is self-contained and independent; it has a clearly defined interface and isolated persistence). The book ends with different aspects of levering cloud-based services. Benefits of the cloud are cost benefits, ease of setting up redundancy for resilience, the scalability of resources, and the strong ecosystem of related services that you would otherwise have to build yourself. on the risk side we see the dependency on a third-party provider, the challenges with data sovereignty, and the risk of being attacked because you are on a popular platform.

Conclusion. Reading this book and execute one or more of the exercises gives you one of the reasons why so many agile transitions fail. It’s not only about creating, sometimes only renaming teams into agile teams but you have to look at the complete ecosystem, your application landscape, the application architecture and your delivery models. A must read for those who are transforming their IT organization towards a more agile organization.

To order: DevOps for the modern enterprise

 

Business Agility model

eyeMy quest continues. The Business Agility model is the next one to add to my Bird’s eye view on the agile forest.

The Business Agility Model (developed by the Business Agility Institute) consisting of twelve interacting domains across four dimensions to take into account when transforming your organization. These are the essential building blocks for an agile organization.

At the center of the model we see the customer domain. The first ring, surrounding the customer domain is the relationship dimension with the domain’s partners, board and workforce. In the outer ring we find the three dimensions Leadership (how to shape an agile organization with domains people management, one team and strategic agility), individuals (how an agile organization delivers value with domains growth mindset, ownership & accountability and craft excellence) and operations (how an agile organization works with domains enterprise agility, process agility and structural agility). All domains are complementary and mutually necessary to business agility.

Schermafdruk 2020-04-14 16.23.33The 12 domains explained:

  • Customer: The heart of business agility is no less than the very reason we exist: Our customer.
  • Board: Business agility requires an open, 2-way, relationship between an organization’s leaders and the board of directors; built upon customer-focus and long-term success, which enables the company leaders to go after long-term bets, as opposed to short term wins.
  • Workforce: Business Agility requires a mission-aligned, passionate, empowered workforce built of individuals with a strong culture fit and potential over fit for a specific position.
  • Partners: Business Agility requires partnerships crafted with flexibility and driven by customer value so both an organization and its partners are able to adapt in a coordinated and complementary manner, rather than a series of contractual transactions.
  • People management: Business Agility requires leaders to recruit, hire, nurture, and develop people with a strong fit for future potential and mission alignment, over fit to position.
  • One team: Business Agility requires a One Team mindset of co-creative efforts to achieve shared goals that span functions, teams, and divisions within the organization.
  • Strategic Agility: Business Agility requires leaders who set, and clearly communicate, an adaptive strategy that empowers teams to identify opportunities to execute that strategy in potentially innovative and previously unforeseen ways.
  • Growth mindset: Business Agility requires that individuals are open to learning by doing, continuous learning and personal development as well as being comfortable operating and making decisions in a dynamic and ambiguous environment, free from the fear of failure.
  • Craft excellence: Business Agility requires craft excellence that continually improves over time, is the most impactful to creating value, and enables individuals to take advantage of emergent opportunities for customers.
  • Ownership & Accountability: Business Agility requires deep ownership and accountability, so individuals close to the work and customers drive timely decision making and adaptations.
  • Structural agility: Business Agility requires the ability for an organization to create coalitions or change structure as needed to embrace new opportunities with ease and without disruption.
  • Process agility: Business Agility requires operations to adapt and continuously evolve as needed in service of creating value for customers.
  • Enterprise agility: Enterprise Agility is a response to competitive pressure, to adapt fast to changes in market demands and seize opportunities while reducing costs. At the core of the Agile Enterprise are the People, knowledgeable, skilled and innovative.

See https://businessagility.institute/learn/domains-of-business-agility/ for more detailed information.

The business Agility model is not a framework in itself but it gives you a head start with the agile mindset and culture. Your teams can make use of Scrum, LeSS, SAFe or one of the others. In my bird’s eye view I positioned the Business Agility model in the culture-targeted box.Grasp session (Scaling Agile bron, 200414) v1.1Bird’s eye view on the agile forest article.