itSMF Switzerland - Blog #change culture

The undocumented flow: why organizations fail to formalize value streams and how to fix it

Wed, 15 Oct 2025 07:00:00 +0200

Reading time: ~ 6 min.

Introduction

The concept of the value stream — the sequence of all activities, from initial customer request to delivery of value — is fundamental to modern business efficiency and lean thinking. It's the circulatory system of an organization, determining how quickly and effectively customer needs are met.

Yet, in countless organizations, particularly those with complex legacy systems or rapid growth, these critical flows remain undocumented, informally managed, or exist only in the institutional knowledge of a few long-term employees.

This absence of formalization, spanning both business value streams (the end-to-end steps to deliver customer value) and IT value streams (the development, deployment, and operation of the supporting technology), is a silent drain on productivity, agility, and employee morale.

This article explores the primary reasons why organizations neglect to document their value streams and provides actionable strategies to overcome these hurdles and establish a culture of flow formalization.

Why value streams remain undocumented (the obstacles)

The reasons for a lack of formal value stream documentation are rarely malicious; they are typically rooted in a combination of cultural inertia, strategic misfires, and resource contraints.

The myth of «tribal knowledge» and informality

Many teams operate on the premise that they «just know» how the work flows. This tribal knoledge is a significant barrier.

Reliance on key individuals: over time, processes become embedded in the minds of long-standing employees. Asking them to document it feels like a waste of time, as they can execute it faster than they can write it down.
«We're too busy» syndrome: The immediate pressure of day-to-day work (firefighting, meeting deadlines) consistently overrides the non-urgent task of documentation. Formalization is often seen as a low-priority "nice-to-have" rather than a core strategic enabler.

Organizational silos and blame-centric culture

Value streams, by definition, cross organizational and departmental boundaries. The inherent structure of many companies actively works against documenting them.

Siloed metrics and goals: when departments (e.g., Sales, Operations, IT Development, IT Operations) have conflicting or highly localized Key Performance Indicators (KPIs), they are incentivized to optimize their local step rather than the end-to-end flow. Documenting the full value stream exposes these handoffs and potential failure points, which can be perceived as threatening.
Fear of exposure: formal documentation brings transparency. It highlights bottlenecks, unnecessary rework loops, and non-value-add steps (waste). In a blame-centric culture, documenting these issues can lead to fear of accountability, creating an incentive to keep processes vague.

Lack of strategic clarity and sponsorship

Value stream formalization is often treated as an optional IT or process improvement project, rather than a strategic business imperative.

Missing Executive mandate: without clear, sustained sponsorship from executive leadership (e.g., the COO, CTO, or CEO), documentation efforts lack the necessary authority to demand time and resources from all required departments.
Focus on local optimizations: companies often invest heavily in local process improvements (e.g., better testing tools, faster code deployments) without understanding their impact on the overall value stream. If the bottleneck is a legal review step before deployment, optimizing the deployment pipeline won't reduce end-to-end lead time.

Methodological and tooling overload and the ITSM integration gap

For organizations that do attempt documentation, the effort can quickly become overwhelming due to methodological paralysis. Crucially, existing operational models often fail to provide the connective tissue for documentation.

The ITSM integration gap: frameworks like ITIL 4 provide excellent guidance on practices (e.g., Incident Management, Change Enablement, Deployment Management). However, the stated objective for each practice is often local (e.g., restoring normal service operation as quickly as possible) and does not explicitly articulate how or why that practice must integrate with a larger, cross-functional value stream to deliver a product or service. This means practitioners optimize the practice itself, rather than optimizing the flow that uses the practice as a step. As a result, the value stream remains undocumented because there is no widely adopted model for mapping these practices as connected steps in a single business flow.
Complexity and scope creep: Value streams can be incredibly complex. Teams often attempt to document every minute detail, leading to massive, unreadable "shelfware" diagrams that are immediately outdated.
Lack of a common language/Tool: Different departments use different tools (Visio, BPMN/VDML tools, simple whiteboards) and terminologies. A lack of a standardized, company-wide visualization and measurement language for value streams makes cross-functional documentation difficult to reconcile.

Strategies for formalizing and sustaining Value Stream documentation (the fix)

Moving from undocumented chaos to a formalized, continuously improving flow requires a multi-faceted approach that addresses culture, strategy, and execution.

Start with the "North Star" – The Customer

The most effective way to gain executive and organizational buy-in is to link documentation directly to customer value and business outcomes.

Identify the core business Value Streams: focus on the 5-7 streams that generate the most revenue or are most critical to the customer experience (e.g., "Onboarding a New Customer," "Fulfilling an Order," "Resolving a Major Incident").
Value Stream Mapping (VSM) workshops: conduct focused, time-boxed VSM workshops that bring together all key stakeholders, from the customer-facing teams to the final delivery/support teams. The focus should be on measuring the flow:

Lead Time: The total time from start to finish.
Process Time: The time actually spent working on the request.
Percent Complete and Accurate (%C&A): The rate at which work is correctly passed from one step to the next.
Wait Time (Waste): The time the request sits idle between steps.

Shift the culture from blame to flow

Formalization will only succeed in an environment where transparency is viewed as an opportunity, not a liability.

Measure the work, not the people: Executive sponsors must clearly communicate that the goal is to find waste in the process, not fault in the people. The metrics (Lead Time, Wait Time) provide an objective basis for continuous improvement.
Cross-functional ownership: Assign a Value Stream Owner (VSO) who has executive authority and is responsible for the performance of the end-to-end flow, not just one silo. This individual drives a holistic perspective.

Implement a light, incremental documentation approach

Avoid the trap of over-documenting. Documentation should be a living, agile artifact.

Just-Enough Documentation: Use three levels of documentation:

Level 1 (Strategic): A high-level, single-page "Big Picture" map showing the 5-7 major steps and their key metrics. This is for executives and cross-functional teams.
Level 2 (Operational): The detailed VSM showing process, wait times, and rework loops. This is the primary artifact for improvement teams.
Level 3 (Tactical): Detailed Standard Operating Procedures (SOPs) for individual, complex steps within a single department.

Establish a Single Source of Truth: Use a dedicated value stream management tool or a central repository (e.g., a shared wiki, specialized software) to ensure everyone is viewing the same, current version of the value stream map.

Bridge the Business and IT Divide (DevOps and IT Formalization)

For modern enterprises, the IT Value Stream (how software is planned, built, tested, and deployed) is inseparable from the business flow. This requires reframing ITSM practices as components of the flow.

Map the Product Development Flow: Apply Value Stream Mapping principles to the DevOps pipeline, measuring the time from "idea committed to version control" to "code running in production." This helps find waste in handoffs, slow testing cycles, and manual approval gates.
Reframing ITSM Practices: Instead of viewing Change Enablement, Incident Management, or Service Desk as standalone goals, they must be documented as steps or controls within the end-to-end product value stream. For example, the Change Enablement process is a critical control gate in the "Deploy" step of the IT value stream, which ultimately impacts the "Deliver Product" step of the business value stream. Documenting the connection forces teams to measure the latency and efficiency of that control gate on the overall flow, not just its internal compliance rate.
Integrate Tools for Flow Visibility: Use tools that can connect the dots between planning (Jira, Rally), code (GitHub, GitLab), and operations (monitoring tools). This provides automated, near-real-time metrics for the IT value stream, preventing the documentation from becoming stale.

Conclusion

The failure to document and formalize value streams is ultimately a failure of leadership to prioritize flow over function. Undocumented value streams are a symptom of organizational drift, leading to excessive wait times, increased costs, and frustrated customers. By strategically deploying customer-centric mapping, fostering a culture of cross-functional transparency, establishing clear executive ownership, and embracing an incremental documentation philosophy, organizations can transform their complex operational reality into a predictable, measurable, and continuously improving engine for value delivery. The journey to formalization is not a one-time project, but a continuous pursuit of excellence in the way work flows.

If you want to keep you up-to-date with the most recent news on this topic, don't forget to subscribe to our newsletter: you will get a monthly update with the most relevant and valuable content from our experts!

SUBSCRIBE TO OUR NEWSLETTER

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe to itSMF Newsletter

DISCOVER OUR EVENT CALENDAR

Get the benefits of Membership Program

Our sponsors

A special thanks to our Advanced Sponsors:

The organizational change management according to the ISO 10020 standard

Wed, 20 Dec 2023 07:00:01 +0100

Reading time: ~ 2 min.

Managing the organizational change management with the help of ISO 10020 standard

Organizations that know exactly how valuable is the change management culture don't struggle with the implementation of organizational change management, despite their sizes or their business models.

When organizations need to identify a support for implementing this culture according to the principle that «a change is a chance», they can focus on the ISO/TS 10020:2022 standard on «Quality Management Systems – Organizational Change Management – Processes».

This standard offers a description of the processes that organizations can use to implement organizational change management (OCM) despite its particular form, taking a risk management approach to address the change-related risks.

ISO 10020: an adaptable standard for organizational change management

When we talk about «organizations», we should keep in mind that the ISO 10020:2022 is also suitable to projects as well as smaller activities that need to identify the processes that can use to govern, manage and implement organizational change management.

This document provides not only process descriptions but also diagrams that support better the «big picture» of the Organizational Change Management.

If we should identity a «context or background» for the relevance or applicability of the ISO 10020:2022, we could consider situations as:

the rearrangement of agents
the reorganisation of sponsors
the reorganisation of teams (new team members,...)
the turnover of project managers

The ISO/IEC 10020 standard table of contents

In this updated version of the document (ISO 10020:2022), we find the following chapters:

✅ 4. Organizational change management processes

✅ 5. Governance process

✅ 6. Management process

✅ 7. Implementation process

✅ 8. Measuring affected interested third party intervention progress on the change matrix

✅ Annex A – Process documentation items

✅ Annex B – Generic section definition

✅ Annex C – Comparison between this document and ISO 9001

To better figure out the «big picture» about what we just described in these last lines, we can bring as usual our infographic.

We should finally consider that we can easily find a several correlations between the ISO/IEC 10020:2022 standard and the ISO management systems standards, in particular with the ISO 9001 on Quality Management Systems.

If you want to keep you up-to-date with the most recent news on this topic, don't forget to follow us on our blog, social media channels and newsletter. Don't miss out our next updates on the brand new YouTube Channel!

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe to itSMF Newsletter

DISCOVER OUR EVENT CALENDAR

Get the benefits of Membership Program

Comment les flux de valeur revisitent la gestion des services

Wed, 23 Aug 2023 19:00:00 +0200

Temps de lecture: ~ 4 min.

Introduction

La gestion des services est l'un des éléments clés de l'exécution de la stratégie d'une organisation. En effet, la gestion des services est une capacité à traduire les exigences stratégiques en un portefeuille de produits et de services alignés.

Au fur et à mesure que les organisations évoluent, la gestion des services évolue également. Voici quelques exemples de ces évolutions :

Gestion des services d'entreprise : l'objectif de ce domaine est d'appliquer les connaissances et l'expérience de la gestion des services informatiques à la gestion de tous les services d'une organisation.
Gestion agile des services : l'objectif de ce domaine est d'appliquer les cadres agiles à la gestion des services.
Gestion des flux de valeur : l'objectif de ce domaine est d'appliquer la gestion des flux de valeur de fabrication au cycle de vie des logiciels.

La gestion des flux de valeur peut être étendue à la gestion des services. Cet article décrit comment les flux de valeur peuvent être une approche utile pour la gestion des services

Les domaines de la gestion des services et les principaux défis

La gestion des services est basée sur 4 domaines (décrits comme des dimensions dans ITIL4):

Le domaine des personnes: incluant la culture, la structure de l'organisation, l'éthique...
Le domaine de l'outillage: y compris les données, l'information, les outils et l'automatisation pour fournir et gérer les services.
Le domaine des processus: y compris les processus, les rôles, les facteurs critiques de succès, les indicateurs clés de performance pour fournir et soutenir les services.
Le domaine des fournisseurs: y compris l'écosystème des fournisseurs et des partenaires qui fournissent et gèrent les services.

Ces quatre domaines doivent être traités de manière cohérente afin que la gestion des services ne soit pas seulement une capacité, mais qu'elle garantisse les ressources nécessaires à la gestion et à la fourniture des services.

Les flux de valeur en tant que modèles

Dans toute organisation, les flux de valeur existent déjà sous forme de modèles.

Ces schémas décrivent l'ensemble des actions à entreprendre pour traiter toute sollicitation d'un client de service qui aboutit à une valeur. Ces modèles peuvent être identifiés tout au long du parcours du client :

Dans la phase d'exploration : le schéma qui peut être décrit comme un flux de valeur est axé sur la qualification des opportunités de nouveaux services.
Dans la phase d'engagement : le schéma qui peut être décrit comme un flux de valeur est axé sur la compréhension et la hiérarchisation des besoins de l'entreprise en matière de nouveaux services.
Dans la phase d'offre : le modèle qui peut être décrit comme un flux de valeur est axé sur la couverture des besoins de l'entreprise par des services sur mesure ou normalisés.
Dans la phase d'accord : le modèle qui peut être décrit comme un flux de valeur se concentre sur l'expérience et les accords de niveau de service.
Dans la phase d'embarquement/débarquement : le modèle qui peut être décrit comme un flux de valeur est axé sur la gestion des accès des utilisateurs/clients aux services.
Dans la phase de co-création : le modèle qui peut être décrit comme un flux de valeur est axé sur la gestion des demandes des utilisateurs concernant les services actuels.
Dans la phase de réalisation : le modèle qui peut être décrit comme une chaîne de valeur est axé sur la gestion de l'expérience de service.

Comment les flux de valeur revisitent la gestion des services

Les flux de valeur peuvent revisiter la gestion des services de différentes manières:

Comme les processus ITSM font partie des flux de valeur, les facteurs critiques de succès de ces processus peuvent être gérés au niveau du flux de valeur.
Les indicateurs clés de performance liés aux facteurs critiques de succès sont alignés au sein de la chaîne de valeur et ne sont pas uniquement basés sur l'approche de la cascade d'objectifs.
La pensée en flux de valeur met l'accent sur les processus de bout en bout, l'amélioration continue, la collaboration et la communication, et surtout sur le client.

L'impact de la pensée en flux de valeur sur la gestion des services peut être décrit comme suit:

Les processus ITSM sont combinés dans le cadre de flux de valeur et ne sont pas seulement intégrés en fonction des capacités des outils ITSM, par exemple.
Les rapports ITSM fournissent une vue d'ensemble transparente de bout en bout des flux de valeur.
Les indicateurs clés de performance des processus ITSM sont définis et alignés au sein d'un flux de valeur afin de garantir une approche basée sur les résultats pour mesurer la performance des services.

Vous voulez vous tenir au courant des news de itSMF Switzerland? Inscrivez-vous à notre newsletter ou connectez-vous à notre canal YouTube.

SUIVEZ-NOUS SUR NOTRE CANAL YOUTUBE

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe to itSMF Newsletter

DISCOVER OUR EVENT CALENDAR

Get the benefits of Membership Program

La gestion objective de la subjectivité des services

Wed, 14 Jun 2023 07:00:01 +0200

Temps de lecture: ~ 3 min.

Introduction

Les services informatiques sont basés sur des produits qui mettent des livrables à la disposition des utilisateurs. Ces livrables sont utilisés par les utilisateurs pour créer les résultats attendus par les clients et les résultats conduisent aux bénéfices attendus par le commanditaire du service.

En fait, la cascade de valeur (livrables -> résultats -> valeur) dépend d'une série d'éléments subjectifs qui doivent être gérés.

Examinons ces éléments subjectifs et la manière de les gérer pour soutenir la cascade de valeur.

Les composantes subjectives de la gestion des services

You can edit text on your website by double clicking on a text box on your website. Alternatively, when you select a text box a settings menu will appear. your website by double clicking on a text box on your website. Alternatively, when you select a text box

Les risques. Les probabilités des risques sont principalement subjectives.
La qualité. La qualité des résultats est principalement subjective.
La criticité. La criticité d'un service est subjective.
L'expérience. L'expérience de l'utilisateur et du client est subjective.
La valeur. Par essence, la valeur est subjective.

La gestion objective de ces composantes subjectives

Dans la gestion des services, ces composantes subjectives doivent être gérées objectivement pour maximiser la valeur:

La probabilité d'un risque est calculée à l'aide de statistiques ou d'autres modèles basés sur des données historiques. Avec l'impact du risque, la probabilité du risque aide à prendre des décisions pour accepter ou atténuer les risques.
Les critères de qualité des résultats doivent être spécifiques, mesurables, réalisables, pertinents et limités dans le temps (SMART). Il s'agit d'une mesure objective de la qualité.
La criticité d'un service dépend de l'impact commercial de son indisponibilité. L'indisponibilité est calculée à l'aide de mesures objectives et de pratiques de gestion des incidents et de la disponibilité.
L'expérience des utilisateurs d'un service et des clients d'un fournisseur de services est mesurée par les niveaux de satisfaction. Ces niveaux de satisfaction sont des mesures qualitatives de l'expérience des utilisateurs et des clients.
La valeur est mesurée par le niveau d'alignement avec la demande liée à un produit ou à un service. Elle peut être mesurée dans le cadre de la performance des flux de valeur.

Les bénéfices de la gestion objective de la subjectivité des services

La subjectivité des services est l'ensemble des composantes subjectives de la gestion des services. Le chapitre précédent montre comment ces composantes sont gérées objectivement.

La raison pour laquelle ils doivent être gérés objectivement est leur amélioration continue. Les mesures objectives garantissent que les bases de référence et la vision de l'amélioration sont partagées avec les parties prenantes du service.

Même si certaines composantes de la gestion des services sont subjectives, il est nécessaire de les gérer aussi objectivement que possible pour garantir l'amélioration continue des services.

Vous voulez vous tenir au courant des news de itSMF Switzerland? Inscrivez-vous à notre newsletter ou connectez-vous à notre page d'entreprise sur LinkedIn.

SUIVEZ-NOUS SUR NOTRE PAGE LINKEDIN

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe to itSMF Newsletter

DISCOVER OUR EVENT CALENDAR

Get the benefits of Membership Program

Une perspective agile de l'habilitation des changements

Wed, 17 May 2023 07:00:00 +0200

Temps de lecture: ~ 4 min.

Introduction

La pratique d’habilitation des changements est souvent limitée au comité consultatif du changement qui autorise les changements normaux. Cette restriction est la principale raison pour laquelle cette pratique est considérée comme bureaucratique. En fait, l’habilitation des changements est une pratique agile par définition et cet article explique pourquoi.

L'habilitation des changements requiert des comportements agiles

Les comportements agiles nécessaires à une habilitation des changements efficace et efficient sont les suivants :

Être collaboratif : l'habilitation des changements nécessite une collaboration entre toutes les parties prenantes impliquées dans la gestion d'une demande de changement afin d'atteindre un objectif commun : déployer avec succès le changement demandé.
Être auto-organisé : l'habilitation des changements exige que l'équipe de réalisation soit auto-organisée afin de respecter les délais définis dans la demande de changement.
Être responsabilisé : l'habilitation des changements nécessite une attribution claire des tâches afin de protéger le niveau de qualité du changement demandé.
Culture de confiance et non de blâme : si le changement n'aboutit pas, les raisons doivent être évaluées, mais pas de manière blâmante.

L'habilitation des changements utilise des concepts agiles

Les comportements agiles nécessaires à une habilitation des changements efficace et efficient sont les suivants :

Donner la priorité à ce qui est livré : lorsqu'une demande de changement est analysée, l'autorité chargée du changement peut définir les priorités pour les caractéristiques du changement à mettre en œuvre afin de respecter le délai et les contraintes budgétaires.
Travailler de manière itérative et incrémentale : un changement majeur peut être livré de manière itérative avec des incréments contenant un sous-ensemble de fonctionnalités.
Ne pas tout livrer : l'autorité responsable du changement peut convenir avec le demandeur du changement que certaines des caractéristiques du changement ne seront pas mises en œuvre.
Se concentrer sur le temps : le respect du délai est un élément très important dans la gestion d'une demande de changement.
Inspecter et adapter : l'examen postérieur à la mise en œuvre permet d'analyser le changement déployé et de prendre des mesures correctives si nécessaire. Il s'agit d'un exemple typique du concept «inspection et adaptation».
Limiter le travail en cours : lors de l'élaboration du changement, le travail en cours doit être limité afin de respecter le délai défini dans la demande de changement.

Les méthodes agiles favorisent la mise en œuvre du changement

En règle générale, l’agilité permet d'accepter les changements. Voyons comment les principales méthodes agiles, telles que SCRUM ou Kanban, soutiennent l’habilitation des changemeńts.

Comment SCRUM soutient l‘habilitation des changements

Dans SCRUM, à la fin de chaque sprint, une revue de sprint est effectuée pour inspecter l'incrément du sprint. Cette revue de sprint peut être l'autorité de changement qui approuve la demande de changement (dans ce cas, l'incrément).

Comment Kanban soutient l’habilitation des changements

La visualisation des tâches en cours liées au développement du changement demandé peut être très utile pour identifier toute source de gaspillage et tout obstacle empêchant de livrer le changement dans les délais, dans son intégralité et dans le respect du budget.

Les techniques agiles améliorent l’habilitation des changements

Les techniques agiles suivantes peuvent améliorer lhabilitation des changements:

Diagrammes d'évolution : les diagrammes d'évolution (vers le haut et vers le bas) peuvent aider à vérifier la progression de l'équipe de développement dans la mise en œuvre du changement.
User stories : les user stories peuvent être utilisées pour spécifier les exigences relatives aux caractéristiques du changement. Cela permet d'améliorer la mise en œuvre du changement, car les avantages de chaque fonctionnalité sont pris en compte afin d'établir des priorités.
Rétrospectives : l'examen postérieur à la mise en œuvre peut inclure une rétrospective afin d'améliorer continuellement la mise en œuvre du changement.
Timeboxes : les différentes étapes de la gestion et de la mise en œuvre des changements demandés peuvent être échelonnées dans le temps afin de garantir le respect des délais.
Mesure du flux : le flux de travail lié à lhabilitation des changements demandé peut être géré selon une approche «pull» plutôt que «push».

Vous voulez vous tenir au courant des news de itSMF Switzerland? Inscrivez-vous à notre newsletter ou connectez-vous à notre page d'entreprise sur LinkedIn.

SUIVEZ-NOUS SUR NOTRE PAGE LINKEDIN

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe to itSMF Newsletter

DISCOVER OUR EVENT CALENDAR

Get the benefits of Membership Program

The organizations journey becoming♾️agile

Mon, 07 Feb 2022 14:11:59 +0100

Reading time: ~ 7 min.

The organizations journey becoming agile

Decide timely, commit late, fail smart and learn fast, deliver bettersolutions and experience to customers, challenge each other to improve.

These are some aspects of agility that attract more and more organizations that want to become agile.

Companies recognize the benefits they can harness from implementing agile ways of working. But they often have practices at odds with and lack a culture that can sustain agility.

So how can we help on this agile journey? How do we nurture an agile mindset and culture in organizations?

Mindset and modernity of agile manifesto

The Agile Manifesto celebrated its 20th Anniversary this year, so is it still relevant to the agile mindset and business agility?

Some details have aged, such as the reference to 2 weeks delivery cycle in the third principle when elite performers now deploy multiple times a day.

The reference to projects in the fifth principle is also at odds with the Lean-inspired focus on Product/Solution, Value Stream, and Flow which now permeates agile thinking.

Many things have changed in the last 20 years. However, the manifesto still feels incredibly modern, often giving a sense of premonition exactly because it focuses on the agile mindset.

«Imposing agile methods introduces a conflict with the values and principles that underlie agile methods.»
Martin Fowler, Agile Manifesto co-author

We actually need more reading, discussing and understanding of the Agile Manifesto. Because a critical problem the agile movement faces is the commercialization of " doing Agile", while ignoring the mindset and culture needed (and don't try to impose a mindset either... ).

The manifesto is not there to guide the scaling of agility to the corporate world. Not even is here to guide leadership practices in the 21st century.

So how can we help share the manifesto with the whole company and drive our agile culture?

👉 The Agile Manifesto for Business Solutions

«True business value lies in solutions. A solution is the assimilation of everything: change, software, processes, hardware, marketing, etc.
I call this full delivery.»
Arie van Bennekum, Agile Manifesto co-author

Following Arie van Bennekum's lead, replacing Software with Solutions in the manifesto makes it easier to discuss with the whole organization.

It highlights that agility is best suited to unique and emergent types of work: evolving products, solutions and services.

Agile development includes the entire cycle: Ideation, Pretotype (testing the business case), MVP, Minimum Business Increments of a solution until completion ( no longer used or changed significantly).

It also creates a strong bridge between what happens 'in IT' and what the company needs to un-learn to evolve an agile mindset. It makes it clear that business agility is a team sport that plays across the organization.

👉Agile organizations: the invitation to a journey

So reading and discussing the Agile Manifesto is an excellent first step to get the basics of an agile mindset discussed across an organization.

Maybe try and display the Agile Solutions Manifesto poster and invite people to discuss and sign it!

«We are unconvering better ways of developing software by doing it and helping others do it.»
Agile Manifesto

It is also an invitation to share our respective agile experiences, reflect and share what we have learned so far and continue the journey.

Beyond the Agile Manifesto

Before diving in, consider checking this animation from Barry L Smith, a great refresher on the origins of Lean and Agile.

👉Agile movement influences

In the Simplified History of the Agile movement influences shown above, the influence of TPS (Toyota Production System), Lean and Kanban on Lean Software and DevOps, enables a shift from teams and projects to organizations and products.

This evolution has brought flow and continuous everything (delivery, monitoring, control, experiment, etc) centre stage, underpinned by continuous learning and improvement.

👉Growth Mindset

«Ever tried. Ever failed. No matter. Try again. Fail again. Fail better.»
Samuel Beckett (1906-1989)

Agility is about adaptability and response to change, at the personal, team, and organization levels. The agile mindset is foremost a growth mindset that supports experimenting and improving.

As Linda Rising explains, our brain changes when we learn new things, so we need to support a mindset that welcomes and grows with change.By encouraging effort and learning, including failing better, you prime that growth mindset. But let's look at the theory of mindset building.

👉Mindset building theory

«Mindset theory is about responses to challenges or setbacks.»
David Yeager & Carol Dweck

It is not enough to expect that «the brain is like a muscle—it gets stronger (and smarter) when you exercise it », or explain that «You exercise your brain by working on material that makes you think hard. »

Recent research by Dweck shows that building a growth mindset is a complex problem.
Intervention on growth mindset needs to be customized to the group and only makes sense in context using an experimental approach, it needs agility!

👉Be Intentional

As a leader, it is then possible to start building a culture aligned to your goals (including leadership here from team level to CEO!).

The relevant groups need to come together to work out values, principles, patterns, practices that will help them achieve their target outcomes.

This approach is called Intentional Mindset (Gil Broza). Leadership needs to be intentional about the culture they want to create and be role models.

It is an invitation from the top and commitment at top and bottom to become agile and do agile in an environment fostering transparency, respect, safety and trust: Servant-Leadership supporting active engagement.

👉Apply agility to agility

Building this intentional mindset requires an experimental and incremental approach which, as described in Sooner Safer Happier, needs to « apply agility to agility» , where you need to be agile at becoming agile.

Beware of planned agile adoptions or transformations. A big-bang planned approach to Becoming agile is, at best, creating awareness on conditions for agility.

But change needs engagement and commitment that only come from a journey of experimenting, learning and improving.

«The bridge from principles to practices is patterns. A pattern can be satisfied with any number of practices, resulting in freedom of choice in terms of practices selected.»

Daniel Mezick

Patterns play a critical role in this journey as they allow substantial freedom when applying principles.

They let you customize your practices for your context while being less divisive. Beware of context-free copying, practices need to be tailored to your organization based on proven patterns where possible.

Agile and organizations: the conclusion

Building an agile mindset to sustain Business Agility is a journey that never ends and takes many influences. It is a critical foundation for organizations hoping to become agile.

It starts with understanding the Agile Manifesto in the context of products and solutions delivered by the larger organization. Finally it continues by sharing the agile mindset through metaphors and stories.

This agile mindset is a growth mindset to improve through experiments, which is based first on learning how to fail better.

On the journey, you will need to learn by doing and hone your technical skills to sustain your agility. You will teach by coaching and apply agility to agility ( be agile at becoming agile).

Ultimately each company, department, team, you & I need to find their own values, principles and patterns, intentionally and in context, to enable Business Agility across the organization and optimize the whole.

Building your agile mindset to support autonomous stream aligned teams that focus on outcomes is where Business Agility starts.

Becoming agile organizations: where to start

We can all strive to develop our teams and ourselves in agile ways of working, but how can we help the whole organization on the journey to business agility?

Becoming agile takes many forms, particularly in large organizations; one size does not fit all. The need to nurture the agile mindset cuts across all initiatives and joining a Community of Practice is an excellent way to address that need across the organization.

Many directions are open such as building an online community, publishing articles or discussing Trust and Servant-Leadership, or sharing the experience of successful teams and leaders, or offering expert advice (coaching on Value Steam Mapping or Theory of Constraints..).

Organizing events will help along the way. Popular formats include debates, book clubs, and inviting external speakers (or even setting up an internal conference!).

Extending the community beyond the organization is critical for learning. You could join external groups or associations and support employees speaking on business agility at conferences.

By joining the conversation, you will help nudge the organization towards business agility and give critical support to early adopters. And don't forget posters and stickers.

You'll soon be making videos and be well on your way to experiment with new approaches to Becoming agile! Indeed a CoP is a unique way to gather energy and engagement, identify and support your agility champions and innovators.

This can help the organizations become agile, providing a space for learning and experimenting at the grassroots. It is all part of Becoming agile!

Post extracted and translated by itSMF.
Author: Brice Beard, 2021.03.24
Quote and copyright: Linkedin.

Need to know more about it?

Click on one of the options below to enter in the itSMF Enviroment and for being updated the way which is best for you.

Subscribe the itSMF Newsletter

DISCOVER THE EVENT CALENDAR

Enter the itSMF Membership Program

itSMF Switzerland - Blog #change culture

The undocumented flow: why organizations fail to formalize value streams and how to fix it

Introduction

Why value streams remain undocumented (the obstacles)

The myth of «tribal knowledge» and informality

Organizational silos and blame-centric culture

Lack of strategic clarity and sponsorship

Methodological and tooling overload and the ITSM integration gap@font-face {}@font-face {}p.MsoNormal, li.MsoNormal, div.MsoNormal { margin: 0cm; font-size: 12pt; font-family: "Aptos", sans-serif }.MsoChpDefault { font-family: "Aptos", sans-serif }

Strategies for formalizing and sustaining Value Stream documentation (the fix)

Start with the "North Star" – The Customer

Shift the culture from blame to flow

Implement a light, incremental documentation approach

Bridge the Business and IT Divide (DevOps and IT Formalization)

Conclusion

Need to know more about it?

Need to know more about it?

Our sponsors

The organizational change management according to the ISO 10020 standard

Managing the organizational change management with the help of ISO 10020 standard

ISO 10020: an adaptable standard for organizational change management

The ISO/IEC 10020 standard table of contents

Need to know more about it?

Need to know more about it?

Comment les flux de valeur revisitent la gestion des services

Introduction

Les domaines de la gestion des services et les principaux défis

Les flux de valeur en tant que modèles

Comment les flux de valeur revisitent la gestion des services

Need to know more about it?

Need to know more about it?

La gestion objective de la subjectivité des services

Introduction

Les composantes subjectives de la gestion des services

La gestion objective de ces composantes subjectives

Les bénéfices de la gestion objective de la subjectivité des services

Need to know more about it?

Need to know more about it?

Une perspective agile de l'habilitation des changements

Introduction

L'habilitation des changements requiert des comportements agiles

L'habilitation des changements utilise des concepts agiles

L'habilitation des changements utilise des concepts agiles

Les méthodes agiles favorisent la mise en œuvre du changement

Les méthodes agiles favorisent la mise en œuvre du changement

Comment SCRUM soutient l‘habilitation des changements

Comment Kanban soutient l’habilitation des changements

Les techniques agiles améliorent l’habilitation des changements

Les techniques agiles améliorent l’habilitation des changements

Need to know more about it?

Need to know more about it?

The organizations journey becoming♾️agile

The organizations journey becoming agile

Mindset and modernity of agile manifesto

👉 The Agile Manifesto for Business Solutions

👉Agile organizations: the invitation to a journey

👉Agile organizations: the invitation to a journey

Beyond the Agile Manifesto

👉Agile movement influences

👉Agile movement influences

👉Growth Mindset

👉Growth Mindset

👉Mindset building theory

👉Mindset building theory

👉Be Intentional

👉Be Intentional

👉Apply agility to agility

👉Apply agility to agility

Agile and organizations: the conclusion

Becoming agile organizations: where to start

Need to know more about it?

Need to know more about it?

Methodological and tooling overload and the ITSM integration gap