Disciplined Delivery and Organizational Design Maturity: A Socio-Technical Evolutionary Journey

Abstract

The increasing digitalization of the world underscores the critical importance of both social and technical aspects in software engineering practice. While prior research links socio-technical congruence (STC) to positive workstream outcomes, the current convergence of digital products, technologies, and social systems introduces novel and often unpredictable results, driven by the complex interplay of leadership, organizational culture, and software engineering practices operating as a complex adaptive system (CAS). This paper proposes a novel model for adopting socio-cultural practices to bridge the social and technical divide through the lens of STC. The innovation of the model lies in its socio-technical evolutionary journey, built upon dual systems: (1) an analytical System-I focused on enhancing robustness via compliance with Lean and Agile socio-cultural practices, and (2) a holistic System-II emphasizing resilience through an acceptance of interdependence of system actors that requires sense-making techniques. A methodology based on this model was piloted across six case studies: three in an Enterprise IT organization and three in two business units undergoing transformations on Lean and Agile plus DevOps adoption. System-I’s robustness was evaluated through surveys and structured STC maturity assessments (self and guided ones). System-II employed sense-making techniques to foster resilience within the system of work (SoW), laying the groundwork for their evolutionary journeys. The findings reveal a significant need for greater alignment between management (as transformation agents) and software engineering practices. However, the study suggests actionable guidelines, grounded in new principles and mental models for operating within a CAS, to cultivate enhanced resilience and robustness in a VUCA world.

1. Introduction

The inherent vulnerability of complex systems to single-agent disruptions poses a significant threat to their reliability. The 2021 blockage of the Suez Canal (Figure 1 Image by Rosenfeld Media—https://www.flickr.com/photos/rosenfeldmedia/52597293760, accessed on 9 May 2025—Attribution-NonCommercial-NoDerivs (CC BY-NC-ND 2.0)—https://creativecommons.org/licenses/by-nc-nd/2.0/, accessed on 9 May 2025) illustrated the fragility of complex systems such as global supply chains, which are susceptible to disruption by a single point of failure and the consequences to global trade. The reliability of the system, defined as the probability of performing as intended, requires both robustness and resilience [1]. A system is robust when it is resistant to being moved from a steady state, while a system is resilient when it is able to recover to a steady state after the disruption without external intervention.

Digitalization is a primary driver of the significant challenges confronting technological organizations operating in today’s volatile, uncertain, complex, and ambiguous (VUCA) world. These challenges include the accelerating pace of technological development, shorter time-to-market pressures, and the increasing prevalence of interconnected “systems of systems” [2]. Organizations, as systems, face a lack of predictability and a greater need for robust risk management [3]. The system environment has become more complex, characterized by an increase in the number of components and the complexity of their interactions, resulting in organizational silos of silos and fragmented stakeholders and specialists [2]. Consequently, this complexity leads to emergence of unpredictable events and processes that influence the decisions of change agents. Addressing these challenges derived from digitalization requires individuals to develop competencies in system thinking and leadership [2]. Recently, Govers et al. emphasized the need for a holistic approach when working on socio-technical systems (STS) in the context of digital transformation. This approach is based on five principles (division of labour, human scale, self-organization, effective and healthy hierarchy, and minimum critical specification) to manage complexity and achieve a sustainable organizational design [4].

In the digital age, organizational success for software organizations hinges on their ability to understand change through the lens of complex adaptive systems (CASs) [5]. CASs are characterized by their adaptiveness, maintaining performance despite significant internal or external changes [6] and their nature as open systems that exhibit emergent behavior [7]. This perspective challenges traditional notions of component separability and emphasizes concepts such as emergence, holism, and downward causation [7]. Consequently, effective software engineering practices are intrinsically linked to the design of the organizational ecosystem, which focuses on team structures, communication, and coordination to enhance performance and adaptability. Research applying Conway’s Law [8] confirms the dependency of software delivery on both communication structure and system design [9], a finding supported by the need to align technical and social systems [10]. Although there are prescriptions for this alignment [9], achieving it requires more than just a good system design [11,12]. Ultimately, software development can be conceptualized as a socio-technical system where the alignment of technical (job to be done) and social (organizational coordination) elements, a concept known as socio-technical congruence (STC) [10], is crucial to achieve the desired outcomes.

Recent advances in STC research increasingly consider human factors and social aspects [13,14], recognizing that organizational interactions are better understood through the lens of complexity theory and the CAS [15]. Key tenets of the CAS, such as self-organization, emergence, non-linearity, adaptation/evolution, feedback (based on history), and operation between order and chaos, make it a recommended model for addressing complexity in social sciences, where system outcome predictability is inherently limited [15].

This article furthers the study of STC by examining software development as an open system operating as a CAS. We propose that the organizational ecosystem design, viewed and understood through the CAS lens, provides a framework for testing hypotheses and generating validated learning, focusing on emergent CAS properties, that build on previous work in STC concerning coordination and alignment. We argue that a deeper understanding of CAS enhances the ability to achieve and adapt business outcomes.

The effectiveness of software engineering practices is inherently linked to how an organization develops its “constructors”, that is, the essential tools and methodologies used not only to build theoretical models and practical solutions but also strategic approaches to drive organizational change. These constructors evolve the organizational system substrate and influence emergent behaviors among agents (investors, suppliers, customers/users, and employees). The long-term sustainability of an organization is directly linked to its ability to attract talent and cultivate a socio-technical balance. This balance, integrating sociological and psychological dynamics with the technical aspects of work (organizational design, processes, and measurement via KPIs and targets), is crucial for maintaining a consistent flow of value [16].

Although adopted software engineering practices contribute to robustness in development and delivery, they do not guarantee the achievement of the right outcomes. Recent studies on DevOps adoption [17,18,19] reveal a tendency to prioritize automation of engineering practices, often overshadowing critical people-related factors for successful change. The Agile Manifesto [20] started a movement against traditional waterfall management for many software practices. Sadly, Agile transformation programs, methods, and tools often fall short in helping organizations create better software products due to a misalignment of Agile principles with existing leadership principles and management principles [16]. Organization culture and lack of leadership support are the leading causes of unsuccessful Agile delivery [21], with resistance to cultural and mindset shifts at leadership levels being a major obstacle [22]. Reviews of large-scale Agile transformations (LSA) [23,24,25] further emphasize socio-cultural factors as primary challenges (e.g., resistance to change, integration with non-agile parts of the organization, lack of knowledge, requirements management) and proposed success factors (e.g., communication and transparency, knowledge management, training and coaching), with fewer considerations for engineering practices (e.g., tools, automation, testing).

Ultimately, enhancing sustainable performance across the organizational structure should be a primary management objective. This requires a holistic and lean approach to foster efficiency, business excellence, and value creation [26]. The enduring success of organizations increasingly depends less on software engineering practices alone and more on their ability to consistently deliver software projects that yield positive business outcomes. Business Agility emerges from understanding and embracing this complexity, prioritizing the human element within the system, and striving for continuous improvement in system outcomes [27] as a central tenet. Expanding on this perspective, Turner et al.’s THE FLOW SYSTEM [28], built upon complexity thinking, distributed leadership, and team science, provides a holistic framework for understanding the interconnectedness of software development and the broader organizational and societal context, addressing crucial interdependencies [16] for long-term organizational viability.

Conceptualizing socio-technical systems as CASs involves observing the interplay between management systems (organizational structures, processes, and measures) and the adoption of Agile methods, tools, and frameworks. These interactions create new connections that change the attributes of the system’s substrate, primarily through the exchange of information and energy between organizational agents and units [29]. Over time, trust-supported connections and interactions foster knowledge-based relationships, ultimately reducing system complexity with stable and trustworthy relations and yielding co-learning and long-term innovation [30].

This paper proposes that the convergence of socio-technical attributes with the complexity science in CAS leads to more effective constructors and new attributes, such as more effective teams and financing models, that drive desired outcomes. CAS sensing enhances the resilience of the organizational system of work (SoW) in achieving these outcomes. Sense-making techniques (methods used to interpret and understand complexity) and the development of appropriate constructors are crucial for building resilience in this complex ecosystem, guiding change agents’ decision making [31].

Conversely, when socio-technical attributes are manifested through more linear transformations and scaled, any existing misalignment amplifies divergent outcomes and significantly reduces organizational resilience. This misalignment also hinders sense-making capabilities and the effective use of scaffolding (structures to facilitate understanding and development of new concepts), increasing the likelihood of unintended outputs and/or wasted resources. A major impediment to cultural and mindset change is the persistence of legacy thinking and a lack of direct leadership engagement in fostering these shifts [22]. Understanding socio-technical complexity (STC) is, therefore, instrumental to software engineering practices, profoundly influencing organizational vitality and sustainability in an era of accelerating change [27].

Given the economic imperative for organizations, this research explores how misaligned motivations across organizational entities affect socio-technical alignment within a CAS. By a deeper understanding of the factor interdependencies and acknowledging the emergent nature of system attributes, this work aims to identify socio-technical factors that enhance an organization’s capacity for timely sensing, analysis, and response, thereby normalizing continuous change. To this end, we formulate four research questions focused on achieving organizational efficiency:

• RQ1: Which Lean and Agile socio-cultural practices help to assess the current and wanted position of the system, with an emphasis on the system robustness?
• RQ2: How do Lean and Agile socio-cultural practices, in conjunction with DevOps engineering practices, help to assess the current and wanted position of the system, with an emphasis on the system robustness?
• RQ3: How do sense-making techniques supported by understanding the current system position from a socio-technical congruence (STC) view point help transformation agents in defining the SoW transformation journey in a CAS?
• RQ4: How does socio-technical congruence (STC) augmented with a CAS allow teams to build robust technical execution and human-focused solutions to have a more resilient and human-centric execution model in a time of VUCA?

These questions are addressed in this paper by developing a theoretical model of STC as a CAS grounded in previous literature. This model proposes a novel STC evolutionary journey based on dual systems. The first, an analytical system (System-I), focuses on robustness through compliance with Lean and Agile socio-cultural practices (addressing RQ1), integrated with DevOps engineering practices (RQ2). The second, a holistic system (System-II) emphasizes resilience through the acceptance of system–actor interdependence and the application of sense-making techniques (RQ3). This leads to enhanced resilience in the SoW and addresses RQ4 via an evolutionary journey defined by change actors. The dual system model was empirically explored through a case study involving six programs undergoing transformation, focusing on Lean & Agile practices for human factors and social aspects, and DevOps practices for software engineering, to answer the research questions.

On summary, the key contributions of this article are the following:

• Theoretical model: A novel theoretical model is proposed to adopt socio-cultural practices bridging the gap between social and technical aspects through the lens of congruence in alignment with the literature.
• Evolutionary journey: An evolutionary journey is presented based on an analytical system to assess robustness and a holistic system complemented by sense-making techniques to achieve greater resilience in the SOW.
• Analytical construct: A set of analytical assessment constructs is defined to assess the robustness of the SOW considering socio-technical aspects.
• Guiding construct: A guiding construct is introduced to promote sense-making techniques, such as narratives for sense giving, to help transformation agents define the evolutionary journey towards greater resilience in the SOW.
• STC methodology: A novel STC methodology (supported on previous constructs) is formulated to guide change in the SOW and empower transformation agents for achieving organizational efficiency.
• Empirical validation: The results from case studies conducted within six programs in an organization provide empirical evidence to evaluate the initial steps of the formulated STC methodology in addressing resilience and robustness in the SOW.
• STC outcomes: The case study results highlight the significant effort required to enable transformation agents and engineering teams to achieve greater resilience and robustness in a VUCA world.

The remainder of this paper is structured as follows. First, Section 1 presents the theoretical foundation that includes the hypothesis statement and the background and theory development, which is derived from the Westrum generative organizational model [32], psychological safety [33,34], complexity thinking [35], and Lean and Agile culture adoption [20] as part of the software model for the emergence of system’s resilience. Next, the relevance of socio-cultural aspects are covered in Section 3, where the novel theoretical contribution is addressed. Section 4 complements a maturity model, based on technical and socio-cultural aspects, with sense-making techniques for guiding transformation, representing our methodological framework. Section 5 formulates a STC methodology with detailed steps to support change agents in planning their STC evolutionary journey. Then, a model evaluation (Section 6) is carried out using responses to a maturity survey and narratives from project contributors to ensure system robustness. Finally, Section 7 discusses the implications of our findings, and Section 8 addresses limitations and future work.

2. Theoretical Foundation: Hypothesis and Background

2.1. Hypothesis Statement

This research hypothesizes that integrating STC principles through the lens of a CAS can enhance software organizational performance and resilience [15], shifting the focus towards human well-being and fostering emergent change in both DevOps and non-DevOps environments [36]. This hypothesis is based on the patterns observed in the industry benchmark for Agile transformations [37,38,39]. Agile transformations are derived from a linear problem-solving view where one or more frameworks are targeted, people are trained, and agile engineering methods are driven through framework and method conformance. According to Malik, previous work theorized that the root cause of organizations routinely struggling with Agile is due to specific gaps in knowledge of the specifics of Agile development [40]. Malik went further to outline the social system being composed of team diversity and communication. But this focus on team and technology seems too granular as digitization scales physical and digital boundaries. Organizations undergoing transformation should consider their business drivers for change, along with environmental aspects of a SoW. The organizational design should be prepared to co-create the transformation journey with change agents while considering the SoW boundaries [4]. In organizations under LSA transformations, non-technical debts include people, social, documentation, and process debts [41]. Meanwhile, according to Leite et. al., major challenges in adopting DevOps involve “effectively empower collaboration among functions”, with organizational design being a major concern [17].

The foundational hypothesis comes from the work on leadership and organizational principles by Bjarte Bogsnes [16], Daniel Pink [42], and MacGregor’s Theory X and Theory Y [27]. In summary, Agile frameworks, tools and methods emerged from Theory Y management models. Putting a set of Theory Y practices into a Theory X SoW creates a cognitive and social divergence for knowledge workers. STC as a CAS uses constructions to shift or nudge change in management agents towards more Theory Y. The hypothesis assumes that alignment of STC, when viewed as a CAS, will deliver better organizational outcomes. This is due to the imperfect relationship between processes and outcomes outlined by Amy Edmondson [33]. In a VUCA world [28,43], good software practices produce bad outcomes. In other words, the robustness of the system achieved by adopted practices is not enough and social techniques are also required that emphasize the resilience of the system to drive the right outcomes.

2.2. Background on Theory Development

Agile transformations are designed to fail when they are seen as a linear A (not-Agile) to B (Agile) path by organizations who miss the underlying emergence from the principles and values [27]. Such transformations frequently begin with the adoption of software practices as a defined delivery model, where transformation agents (e.g., C-Level and organizational leadership) initially promote Agile core values and principles from the Agile Manifesto [20] and establish Agile teams. This scenario adopts Agile practices and events that are not adopted to existing norms. This may be referred to as doing Agile (building robustness) and not being Agile (building resilience). These transformations change tangible parts of the SoW in which software teams reside.

Scaling Agile to multiple teams working on a shared value stream [44,45] necessitates additional practices to ensure alignment and collaboration. Several scaling Agile frameworks, including SAFe [46], LESS [47], and Scrum@Scale [48], address this need by advocating for cross-team practices, a conclusion supported by practitioner literature reviews [23,24,25,41]. Lean principles and the concept of flow are increasingly introduced to tackle these scaling challenges. Failure in scaling Agile has significant consequences, impacting numerous individuals and organizational performance. Some organizations even leverage these frameworks to define new organizational designs based on reverse Conway’s Law, as seen in Team Topologies [49].

The evolution of development workstreams has progressed from Waterfall to Agile, and the current trend in organizational design is shifting towards DevOps (development and operations) and/or Lean product management [50,51]. DevOps, defined as the unification of people, processes, and products for continuous value delivery [52], empowers organizations to respond to digitalization challenges by addressing business drivers. Adopting DevOps or Lean product management requires a broader perspective of the SoW, encompassing not only development but also operational and security workstreams [18,19].

The linear Agile transformation approach often overlooks the crucial aspect of continuous organizational improvement that drives outcomes (DORA research KPIs [36]). Despite aiming for organizational efficiency through team empowerment, true effectiveness can remain elusive, since the adoption of best practices has a limited impact on business due to local optimizations [53]. These local optimizations impede the value flow through social structures and hierarchies. Transformation agents must recognize that transformation is a socio-technical emergent evolution, requiring cultural change within management class alongside the adoption of new software practices. Consequently, both aspects are intertwined, like two sides of the same coin. Management class acting as change agents utilizes “narratives to guide actions, decision making, and problem solving” [54] to facilitate sensegiving in complex environments [31]. One of the most fundamental success factors of LSA and DevOps adoptions is the sponsorship of management class as change agents [17,18,23,24,25].

System evolutions require collective mental model shifts among system agents to perceive their SoW as a CAS. Therefore, innovative frameworks and models like Cynefin framework [5,55] and OODA loops [28] are necessary to guide LSA and DevOps transformations. This mindset unlearns existing techniques to evolve new management models for distributed decision making. The Cynefin framework aids agents in understanding optimal responses based on the system’s current behavioral pattern across five domains, namely: clear, complicated, complex, chaotic, and confused/aporetic (Figure 2a). The complexity domain, as is the case of LSA and DevOps transformations, is associated with CAS [15] and requires the use of resilient constructors to facilitate sense-making activities and give an indication of predictability in uncertainty, in comparison to the complicated and clear domain, as is the case of Agile scrum transformation for a single team. CAS can be viewed as a non-linear system where adaptation is based on learning through iterative feedback loops [55]. The adoption of CAS can imply considering the change as an emergent property of the evolutionary change of the SoW, not as a linearly planned transformation. Today, effective change agents navigate these domains, applying appropriate strategies to simple, complicated, and complex problems. In this sense, system agents who recognize the SoW as a CAS, can use the Cynefin framework to classify practices to adopt from LSA and DevOps, identifying suitable constructors and sense-making techniques for emergence.

Social systems are context-dependent, complicating the application of traditional scientific methods. Key concepts include “emergence, holism, and downward causation” [7]. A SoW as a CAS exhibits complex collective behavior, signaling and information processing, and adaptation.

Adopting CAS for organizational agility requires a domain-appropriate approach to address specific problems (Figure 2b). The change agents shift from following linear transformation plans and methods to navigating with emergent methods. In the realm of unknown unknowns, change agents “need to probe, sense, and then response” [3] the behavior of the SoW as a retrospect outcome [56] of small safe-to-fail experiments [57] helping to make sense [3] of emergent strategies for change. CAS methods enhance resilience by adapting to both intended and unintended impacts on the SoW attribute changes. Change agents are morally responsible for both intended and unintended changes [58]. For example, intellectual stimulation behaviors by team members such as embrace questioning and rethinking on new ways of solving problems can be promoted as emergent strategies to change behavior of the SoW.

SoW changes supported by CAS methods and system thinking emerge from the SOW’s environmental state [29]. System thinking, as one of the five disciplines of the learning organization [59], is a conceptual framework for handling and understanding complex and interdependent systems by observing, from a holistic view, the “interactions between the parts” [30] rather than the individual elements of the SoW. This system-thinking holistic viewpoint can be achieved by small qualitative safe-to-fail experiments, which provide explanations and insights within the complex domain [3]. Using a probe-sense-respond approach for the complex domain constitutes an enabling change action, whereby leadership and management principles are shifted from a focus on robustness to a focus on resilience, as shown in (Figure 2c): for example, building informal communication networks to bridge operational silos, allowing factual decision making and risk taking, helping to change teams interaction to setup a Westrum organizational culture within the SoW, or facilitating inter-team communication and collaboration with appropriate controls and standards [18] to change teams interactions within the SoW. Change agents may employ methods that go beyond complexity thinking [35] to foster a sense of agency within the human elements of the SoW (e.g., individuals, teams, or other subsystems) (Figure 2d). Complexity thinking “explores how independent agents interact with each other in a variety of ways” [15] to gain collective knowledge. This collective knowledge is achieved by a sense-analyze-respond approach. For example setting a cadence of events to share information and cross-pollinate knowledge to setup a learning culture in the SoW, or having security champions in teams to bridge the gap between security and development in DevOps transformations [18] with the aim to growth team and individuals competencies in the SoW.

This human-centric approach is based on natural sciences and sociology, which proposes alternatives to organizational design where people are organized around value streams [28]. Team Topologies [49] create a set of principles using ’socio-’focused principles. The first principle is to design the organization using the reverse Conway’s Law [60]. Secondly, work scope is limited based on the cognitive load limits of the human brain, as determined by natural sciences. The System Mode-2 way in which the human brain thinks is a slower cognitive process [3,61], allowing individuals to be inquisitive, look at opportunities, reflect, and learn [62].

Sense-making enables change agents to comprehend present events in a retrospective way [31]. Sense-making techniques such as the Boyd’s OODA loop are well adapted to all ontological states to emerge from the resilience of a SoW. The aforementioned loop is composed of the elements observe, orient, decide, and act [28] with a focus on understanding whether the hypotheses derived from emergent strategies are facilitating the acquisition of knowledge or providing an advantage. The OODA loop creates the basis for triple-loop learning as a strategic capability. In the context of software practices, the OODA loop has potential to influence the delivered software solution (product domain), the collective organization of the individuals (process and practices domain), and the new skills gained by individuals (product, process, practices, and technology domains). This triple loop learning supports John Boyd’s hierarchy of focus in descending priority order. The first is to focus on the people, the second is to evaluate ideas through thought patterns and mental models, and the third is to focus on things that are composed of physical and nonphysical artifacts, tools, and methods. The OODA loop is an effective lens for studying the resilience of a SoW. In this sense, system agents can use the OODA loop elements to quickly iterate when introducing new practices from LSA or DevOps transformations within the SoW. This allows them to fail fast, change direction, and gain knowledge when transforming the SoW as a CAS.

3. Socio-Technical Evolutionary Journey

3.1. Dual Systems as Constructs to Guide the Evolutionary Journey

In the context of knowledge work in the software domain, system interventions, such as the maturity model, require identifying and defining the hierarchy of mental content, which, in order of increasing value, includes the following elements: data, information, knowledge, understanding, and wisdom [63]. Gathering data from the maturity model is useful for creating information, a common understanding of fundamental concepts [64], and potential knowledge. The aim of maturity models is applying “what is known about success, what works, and what can be improved” by formalizing and institutionalizing knowledge’s, competencies, values, and practices [64] in a roadmap towards a targeted organizational performance goal [65]. The purpose of dueling systems is to ensure that the collection of maturity models within organizations is driven to facilitate and accelerate learning, that is, the acquisition of knowledge. This is conducted by moving between two systems that mimic how the human brain works to develop wisdom from education, experience, and exposure.

As concluded by Buckle, maturity models could facilitate planning, guidance, and control over future systems thinking performance, but they represent “a difficult undertaking” as it involves unique human competencies which require “sharing interpretations about sense-making and problem-solving practices”. Maturity models that include a system thinking perspective must be iterative [64]. In addition, maturity models must be holistic, considering the socio-technical contribution [65]. Short iteration loops promoting safe-to-fail experiments help transformation agents in obtaining emergent knowledge and competency in the adoption of new socio-technical practices towards organizational performance.

A shift must be made from a system construct based on data and information represented by traditional maturity models with a primary focus on practice adoption (promoting system robustness) to one based on knowledge, understanding and wisdom (promoting system resilience). Consequently, sense-making will facilitate adaptation of the transformation journey by transformation agents in accordance with the current achieved position of maturity.

The human brain is capable of operating in two distinct modes. Mode-1 is characterized by a higher level of reactivity and the utilization of pre-existing biases and pattern recognition to save energy and respond rapidly as (“quick intuition-based decision-making” [3]). Mode-2 enables inquisitiveness, the examination of opportunities, reflection, and the acquisition of knowledge, but at a higher energy cost as (“slower controlled cognitive process” [3]). This evolution occurs as a result of the fact that humans make more than 30,000 decisions a day [62].

When the SoW is conceptualized as a living system, the analogy of a single mind can be extended to encompass the collective mindset. Similarly, the Agile mindset operates in a duality of systems. System-I builds robustness and barriers and analytical risk analysis through processes and compliance. System-II builds resilience through the integration of thoughts, enabling exploration through cultural enablers and organizational structures [55].

Analytical System (System-I). This approach emphasizes the importance of robustness through compliance, with governing constraints including mandatory training, the elimination of errors/bugs, the imposition of compliance rules, and root cause analysis that allocates culpability. This approach is appropriate when the agent perceives the world as a closed system composed of ordered domain problems.

Holistic System (System-II). This approach is used to describe a system that is considered to be a whole, rather than a mere collection of parts. This emphasizes resilience, which is achieved through an acceptance of interdependence of actors and systems. This requires a greater ability to sense rather than to measure analytically. This growing human capability employs generative constraints that include principles, human judgment, and personal experience (tacit knowledge) to build an early detection capability to prevent quality from moving downstream in the value chain. System-II is interdependent on the local culture of shared learning and experiences along with measurements.

Embracing Complexity Thinking in the Transformation Journey

In a CAS, a map is merely a starting point, given the multitude of unknowns and missing information that precludes the creation of a detailed plan [29]. The maturity model used in this work enables the ability to detect System-I anomalies and opportunities within the ordered domain [29]. When conducted by a facilitator versed in complexity thinking, the maturity model review will evoke both macro-narratives (e.g., collective ideas, goals and vision shared across all the individuals in the SoW) and micro-narratives (e.g., shared ideas between few individuals during a coffee break) in order to generate sense making for those individuals who are most closely involved in the work. These aforementioned narratives, when performed in a psychologically safe environment, provide improved agency through mastery, autonomy, and empowerment [33,42].

“Conducting assessments provides guidance in terms of current capabilities and identification of performance gaps, helping to identify where improvement is possible, necessary, or desirable” [64,66]. In this sense, the maturity model is used to quantify opportunities and, when used with the narratives, will allow the creation of constructors to change and adapt patterns and modify the system’s attributes of the software model.

By considering socio-cultural aspects within the maturity model and the evolution of the SMF canvas [67], introduced in the next sections, our approach is still considering the traditional method to assess and steer organizational transformation journeys. This may use existing maturity models such as CMMI appraisal [68,69,70] or OWASP SAMM [71,72]. We aim to move beyond this System-I maturity model by adopting a holistic view of an ever-changing organization, which is not merely managed but guided towards its desired state. Maturity models that incorporate sense-making practices enable transformation agents to “conceptualize qualitatively different ways in which system thinkers can function” in contrast to previous maturity models that focus on ranking quantity [64] of adopted practices. It is essential to comprehend how SoW is cohered, which practices contribute to its robustness, and how to sustain its resilience or equilibrium [73,74]. This transformation journey must be a socio-technical-aligned one, with the objective of enhancing the performance of the SoW through the dual system. The robustness through the adoption of System-I practices and the resilience through holistic System-II practices facilitate structuring the unknown, understanding and explaining the SoW, and informing action [57,75].

3.2. Guiding the System of Work by Framing the Desired Future

The Agile Manifesto [20] has served as a source of inspiration for many active discussions about software development in organizations. However, to include aspects of Lean and CAS, Simon Powers [27] defined three core beliefs to understand the Agile mindset that go beyond his Agile onion. These three core beliefs are as follows: the complexity belief, the people belief, and the proactive belief (Figure 3).

For achieving the holistic System-II, these three beliefs must be incorporated by considering the socio-technical change (the complexity belief), the stakeholder positive regard (the people belief), and the confluence of human interactions that is continuously evolving with the understanding of the SoW (the proactive belief) into the guiding model.

3.2.1. Socio-Technical Change

Socio-technical change is the result of the three emerging beliefs. The three beliefs influence the evolution of management to affect the SoW. When management is oriented by the dynamic processes that unfold, it is a signal that working conditions are emerging. The social process of people taking small actions today to make long-term changes tomorrow is the paradox of transformations. Transformations assume a linear process from A to B (i.e., I was not Agile, now I am). The three beliefs implicitly force change to happen now with sense-making constructors that generate a cascade effect in a CAS. In a CAS, changes in one sub-system will eventually change the interactions with other systems that, with appropriate leadership, can start to change the SoW at multiple levels within the organization. In this sense, complexity theory is adopted as a method to explain and theorize [15] through sense-making techniques how to guide the socio-technical change within the SoW. Socio-technical change is a wicked problem that can be better addressed by using complexity theory and complexity thinking methods, rather than solely relying on system theory or systems thinking [15].

3.2.2. Stakeholder Acceptance

Nicole Forsgren et al. define the gold standard for acceptance of changes based on people-based outcomes [36,76]. The first outcome is the relative movement towards the organizational performance (commercial and/or non-commercial) as measured by the performance of the delivered software by its end user and other stakeholders. This outcome is necessary for any organization to continue to thrive, just as oxygen is necessary but insufficient to survive. The second outcome is to flourish. It is based on the people within the SoW who created the output and their own self-perceived well-being. The SoW has tangible consequences, including the tangible human cost of burnout, excessive rework, and the pain to obtain a sense of flow through the SoW. In both cases, this can be quantified and qualified. The aforementioned outcomes are quantified using metrics, analytics, and the synthesis of data collection to gather insights for System-I. Qualified through the sense making of the macro-narratives and micro-narratives from agents for System-II. Agents identify as having greater agency in organizations that use guiding principles for decision making [77]. In other words, an approach to support decision making is needed, which takes into account and analyzes information (System-I) to come up with purposeful tailor-made safe-to-fail solutions (System-II) [3] to increase cognitive load and knowledge to achieve organizational outcomes.

3.2.3. Confluence of Human Interactions Evolves the System of Work

The organizational design requires an appropriate balance between three tensions; control related to the degree of autonomy and integration; change related to structure stability or adaptation to the specific operation environment; and design related to self-organization and a purposeful SoW. In a CAS, the balance point between the three tensions evolves over time, while the lack of balance implies that the SoW is not well performing. “Structure must evolve and adapt as the organization and its environment change” [78]. The SoW as a socio-technical system is a CAS in which stakeholders interact using tools, practices, and knowledge to deliver an outcome in a physical and socio-cultural environment [79].

The evolution of the SoW requires a confluence of energy and information exchange at the intersection of three domains (Figure 4). The intersection between the WHAT, the HOW, and the WHY within a bounded context, the WHERE, creates the socio-cultural environment for evolving the SoW.

WHAT as Explicit Knowledge: This includes methods, frameworks, processes, practices, and enabling tools. This is the most visible aspect of the change, which includes the things that you can see and touch. The WHAT people do is highly visible and can be expressed explicitly by enabling practices (e.g., people: organizational culture and leadership norms; processes: Agile frameworks, change approvals, sprint cadence, and organization trees; technical: coding rules, build pipeline automation, and tool ecosystem) [27,28,80].

The HOW as Tacit Knowledge: This is what agents in the system explain: “This is HOW we do things around here”. It is the collection of unwritten rules, norms, and collective habits that drive decision making and human interactions. The HOW people do it is embedded in tacit knowledge and can be influenced with guiding principles (e.g., cultivating a Lean mindset to focus teams and individuals on reaching a sustainable flow of value delivery, remove waste, continuous improvement, and innovation) and incentives (e.g., individual and collective rewards facilitating breaking silos at organizational level) [28,49,55].

The WHY as Distributed Leadership Habits, Organizational Design, and Policy Definition: Leadership in this context is the lowest-level leader who has the ability and authority to change the way people work [27] through their behaviors and changing structures, policies, and measurements. Leadership must be seen as the ability to influence and motivate people to achieve SoW outcomes [3]. The components of the leadership mindset, organizational design, and measures drive the evolution of culture within the system context. This evolution in the SoW is supported by sense giving as an iterative process for experts to gain legitimacy [81]. This legitimacy is used by leaders as a sense-making narrative that guides decision making in the SoW [31,82]. This domain is the catalyst for changing information flows and growing or regressing the effectiveness of the SoW. It provides the foundation for setting the stage for the WHAT and HOW by outlining the WHY that drives cultural norms (e.g., by cultivating the promotion of the right behaviors from the Agile mindset to pursue an organizational culture based on respect and psychological safety [33], they can be the constructors that emerge a focus on the flow of customer value and perceiving failure as valuable learning) [28].

The WHERE as the System Boundary and Environment: The components of the environment include the internal and external forces that drive the behavior patterns. This will encompass both the system surroundings, in terms of the business setting, market conditions, and system internal aspects such as local culture, organizational norms, and policies. Technology and culture both influence each other and impact the environment [79]. The WHERE gives external energy to pass and store information through the exchange of energy to generate the constructors that enable the change of system attributes [29]. Once we understand the environment, agents can start taking action to “change it to more favorable conditions” [83]. Turner et al., in their multifaceted sense-making theory, propose nine stages of sense making with a focus on reasoning (sensing, meaning making, sense giving, becoming, and agency), action (future-scoping, movement, and evaluation), and transitioning through counterfactuals to gain understanding of the environment with an aim on changing it [83].

Changing organization is based on considering environmental conditions and strategic business choices. In this sense, the organizational design is recommended to be co-designed with the various change agents within the boundaries of the given ecosystem [4]. In LSA transformation initiatives, non-technical debt (NTD) might be incurred as debt in the form of documentation (incomplete or insufficient documentation), social (communication, coordination, and cooperation), people (domain knowledge and experience-related knowledge), and process (inefficient processes or following no longer appropriate processes) [41]. This NTD impacts both on the success of the undergoing transformations and on organizational outcomes. In order to succeed, a transformation shall consider creating a psychological safety environment promoted by leadership as the foundation for the emergence of change to pursue a learning organization design [34].

The components of WHERE are largely social and invisible and are best described with sense-making techniques such as macro-narratives through experience and history. This includes the aggregation of individual experiences into a set of collective sentiments and decisions across sub-system social boundaries.

By putting these three domains in congruence, the desired changes are seen as a whole, where sub-system decomposition prevents understanding the whole SoW. As a CAS, the SoW is like an ecosystem that optimizes survival through adaptation [15] and exaptation [80] to its environments and surroundings. The transfer of information is seen as a survival technique that embraces the paradox of changing culture through sense-making stages [83] supported by micro-actions with whole organization vision. The paradox of moving a culture starts and ends with a SoW perspective rather than a linear and mechanistic transformation plan proposed by certainty merchants that results in local optimizations [84].

4. Socio-Technical Congruence Study

In this section, we cover how the four research questions (RQ1, RQ2, RQ3, and RQ4) can be evaluated.

4.1. Assessment of Socio-Technical Congruence

A tangible model was created to study the evolution of the socio-technical systems with change agents. The result was a maturity model designed to move and evolve with the SoW to meet the lifecycle in the market and organization. The maturity model was designed to be a collaborative process to uncover sense-making techniques such micro-narratives to support using an OODA loop model. The OODA loop was designed to evaluate the organizational capability of three core domains or pillars along with a transversal layer. The three core pillars include people, process and technology capabilities and practices considering the technical aspects. The transversal layer gathers information on the social structures and norms as seen through governance and leadership. A holistic perspective [65] considering socio-technical and managerial impacts on the SoW has been considered. The maturity model collects information on robustness through self-guided surveys and resilience through engagements with an external change agent, such as a coach or mentor.

On one hand, the proposed maturity model considers the SoW’s robustness as a quantifiable attribute that helps to provide awareness to agents on what is the current position (AS-IS) of the SoW with regard to adopted socio-technical practices in the three domains and transversal layer. This awareness is obtained by answering self-guided surveys. On the other hand, the SoW’s resilience needs sense-making techniques to define and align agents [64] on safe-to-fail purposeful experiments to clarify and gain knowledge on the desirable state of maturity (TO-BE).

The maturity model used is an evolution of lessons learned from previous models that were too linear or limited [9,64,65]. These models represent a foundational step to support transformational agents in defining, discussing, communicating, and sponsoring the emergence journey. The maturity model gathers leading indicators with a focus on socio-cultural aspects and technical aspects. Established models such as CMMi [68] and OWASP SAMM [71] provide structured approaches to process improvement and software security, respectively. However, they do not explicitly address socio-cultural aspects. SAFe [85] provides business agility and partially considers socio-cultural aspects. Our STC model fills this gap by integrating socio-cultural practices, which are crucial for achieving holistic STC at the SoW level.

Assessments against the proposed maturity model provide guidance to change agents on the SoW’s current position on gaps related to adopted capabilities and performance [66,86]. In other words, assessments provide insights where improvement is possible, necessary, or desirable [66], with the aim of “creating roadmaps aligned with SoW goals” [65]. But from CAS, system thinking, and complexity thinking viewpoints that consider the holistically socio-technical capabilities of the SoW, it is a difficult undertaking that must be done iteratively and supported by sense-making techniques [64].

Socio-technological aspects plus management aspects have an impact across all levels of SoW, so a holistic perspective is needed when SoW assessment is performed [87,88]. Previous model such as CAFFEA framework [89] offer insights on social debt [90] impacting architectural debt as a symptom of lack of knowledge and inter-communication in LSA transformations, only considering socio-technical dependencies facilitated by the organizational design. NTD in software engineering identifies three type of debts (process, people, and social) grouped on thematic causes as socio-cultural challenges to address in the organizational design [91]. The cultures framework builds on social science and cultural theories offers a structure approach in cultural change to identify its cultural ensembles (motivators, activities and materiality, and cultural vectors) that determine sustainability outcomes within the agency boundary impacted by external influences [92]. Comparing our STC model with these socio-cultural frameworks can highlight how it uniquely integrates socio-cultural aspects into technical practices, providing a more comprehensive approach to STC. Figure 5 depicts the reference framework for socio-technical congruence capabilities proposed in this article as a construct to provide a holistic view of the current level of adoption of socio-technical practices. The framework highlights capabilities in the technical domain grouped by previous mentioned pillars, people, process, and technology, and the transversal governance layer where the culture capability of the SoW resides. The reference framework encourages the integration of transformational guiding principles from Lean, Agile, and software engineering to facilitate the adoption of capabilities and practices. It serves as a tool to achieve desired outcomes at the SoW level.

Assessment conducted with agents such as leadership and SMEs is an enabling construct required to answer RQ-1 and RQ-2.

As concluded by the DORA research program [93], adopted capabilities predict the SoW’s performance, which predicts the SoW’s outcomes. The core model proposed technical capabilities such as deployment automation, trunk-based development, or test automation, intertwined with culture capability to achieve software delivery performance as a prediction of SoW performance and individuals’ and teams’ well-being.

4.1.1. Technical Aspects in the Maturity Model

Technical aspects of software engineering in the proposed reference framework represent a deeper look at the technicalities and managerial practices adopted by agents (both individuals and teams) within the SoW.

The first pillar focuses on people by promoting the adoption of Lean and Agile practices for the enablement of management capability (e.g., adoption of agile ceremonies and rituals, use of flow for measuring system performance) and awareness capability (e.g., sharing knowledge through communities of practices). Promoted guiding principles by this pillar are visualizing flow, effective prioritization, empowered teams, and alignment and enforcement.

The second pillar focuses on the enablement of continuous exploration capability (e.g., feasibility analysis, prioritize the team or team of teams backlog, obtain a balanced backlog that considers continuous improvement actions, or obtain a modular design), which promotes guiding principles such as visualize the flow, agile iteration and cadence, and effective prioritization. Continuous automation capability (e.g., build pipeline as code, delivery pipeline as code, or test as code) promotes software engineering guiding principles such as Everything as Code, the continuous automation of practices, shift-left [94,95], and built-in quality (including security and safety), in conjunction with Lean and Agile guiding principles such as deliver customer value and learn and respond.

Finally, the third pillar is the technology pillar covering enabling capability (e.g., a tool journey adoption plan exits to enable company-wide policies when adopting software development life cycle practices and secure development life cycle practices, the adoption of qualimetry tools enabling the software engineering team to ensure and review a secure implementation of the codebase (static application security testing—SAST) are in place, or the adoption of tools enabling the deployment and provisioning of the IT infrastructure for supporting target environments in the build pipeline as well as developer’s workstations) and assurance capability (e.g., quality metrics are in place in the build pipeline and developer’s workstations, qualimetry measures based on ISO/IEC 25010 [96] are gathered following the quality model, or qualimetry and cybersecurity measures are formalized by tools based rules check compliant with MISRA standard [97]). The promoted guiding principles by this pillar are guaranteeing built-in safety, security, and quality in the case of assurance capability. Meanwhile, in the case of enabling capability, the guiding principle is inner sourcing to promote collaboration across the whole enterprise while enabling a common technological ecosystem.

Examples of specified practices that enable capabilities and transformational guiding principles from the proposed reference framework can be found in Appendix B.1,

Table A2. Technical Capability, Practice Areas and Practices.

Capabilities	Areas	Practices
Management	Lean & Agile Product Management	small incremental improvement tasks are identified and prioritized during retrospectives (Foundation) improvement hypothesis from the retrospective is regularly incorporated into the next iteration (Recommended) backlog items are pulled into the plan based on historical capacity/velocity (Highly Recommended) team has a role defined who ensures that key stakeholders attend and participate in the demo session (Recommended)
Continuous Exploration	Release Planning	Product Owner keeps the backlog/User stories up-to-date in advance of the release/sprint (Highly Recommended) During sprint planning or review or backlog refinement/estimation, the Product Owner is available for any discussion/clarification (Foundation) User stories are being prioritized for the sprint by the Product Owner in order to keep the vision and roadmap of the offer (Foundation) Changes of priority/User Stories rarely occurs during the ongoing planned sprints (Highly Recommended)
Continuous Automation	Configuration Management	a documented standard folder structure is in place for all the source code repositories (Highly Recommended) Engineering team develops code following a common branching strategy (e.g., GitHub Flow, Git Flow, …) enabling parallel development, faster release cycles and automated delivery from code to production (Foundation)
Continuous Automation	Enabling Environment	All environments (development, integration, staging, production) are configured as code (Infrastructure as Code), ensuring same setup and configuration (provisioning), and their enablement on an automated way (Foundation) Infrastructure Package Manager (e.g., Helm) is used to automate the install and resources on targeted IT infrastructure environments (Recommended)
Continuous Automation	Testing	Code is modular and supports unit testing (Simple design) (Foundation) Chaos Engineering Test Cases are executed periodically (Recommended)
Assurance	Continuous Quality	Agile team allocates a bucket of capacity during every sprint to reduce Technical Debt backlog (bugs, defects, vulnerabilities) (Foundation) Unit tests are documented, and in the case of pure software, they are documented as code (Test as Code) (Foundation)
Enabling	Tools	A tool journey adoption plan is in place to enable company-wide policies (Foundation) Qualimetry Tool(s) enabling Software Engineering Team (e.g., Developers, Testers) to ensure and review a secure implementation of the codebase (Static Application Security Testing—SAST) is(are) in place in the build pipeline as well as developer’s workstations (Highly Recommended)

for each of the three pillars, with a focus on the technical aspects of the SoW. These practices will help to evaluate RQ2.

4.1.2. Socio-Cultural Aspects in the Maturity Model

Socio-cultural aspects are a deeper look at the behaviors and social norms that supersede the policies and directives. These are commonly called workarounds or hacks in the face of bureaucracy. These indicators help assess opportunities to create scaffolds from a current position (AS-IS) to a desired domain (TO-BE). They include proactively defining the desired state as a vision, the outline of impediments or counterfactuals that impede that vision, and a set of leading and lagging indicators to use as guideposts on the journey.

These socio-cultural transformation indicators are qualitative, but can be quantified, as performed by Forsgren et al. in the book Accelerate [76]. The authors conclude that measuring indicators with a focus on employee loyalty, or employee identification with her organization, and job satisfaction are leading indicators for predicting the achievement of organizational performance. Thus, indicators measuring the satisfaction of individuals working and collaborating in their value stream is relevant to validate the perceived psychological safety in the SoW [34].

“The extent to which people identified with their organization predicted a generative, performance-oriented culture and also predicted organizational performance, measured in terms of productivity, market share, and profitability”. This is further elaborated in Change [27], “We optimize to the limit of our identity”. Individuals self-optimize to their identity. When they identify as an individual expert, they will optimize individually. On the other hand, if they identify as a team member, they will work to optimize the team.

In addition, indicators measuring the satisfaction of individuals working and collaborating in their value stream are relevant to validate the perceived psychological safety in the SoW. Hence, a need to measure the journey of the cultural competing values would shift from a transformation focus to an evolutionary focus. The culture would use the Westrum model to evaluate if there is an evolution from pathological (hoarding information or withholding it for political reasons) to or from bureaucratic (silo-oriented, protecting departments in their own ways of doing things) to or from a generative organization (performance-oriented with a focus on the effective delivery of value) [32] that is instrumental in the evolution. With Accelerate [76] and DORA [36], the Westrum organizational culture becomes predictive of organizational performance outcomes and individual and team well-being.

The model predicts that when leadership and transformation managers evolve towards a generative culture, this facilitates the flow of value between teams and individuals. The generative environment is more at peace working in the complexity of interdependent value streams. It also provides focus for behaviors to amplify or dampen towards those outcomes. The embracement of complexity helps to adapt the approach to disciplined delivery models based on the SoW attributes and sociological patterns (trust, cooperation, openness, and transparency) in the organization. The adaptation is supported by timely and quality-based informed decisions that emerge between roles when using the Westrum organizational culture model [32] to evaluate the current state of the culture in an always complex and changing environment.

Examples of specified practices enabling capabilities and transformational guiding principles from the proposed reference framework can be found in

Table A3. Agile Socio-Cultural Practice Areas and Practices.

Areas	Practices
Team based collaboration	cadenced ’stand-up’ meetings (Recommended) knowing vision and mission tests (Foundation) avoiding the Five dysfunctions of a team [105] (Recommended) embrace respectful and collaborative behaviors (Recommended) escalation of impediments outside of team responsibility (Highly Recommended) build generalist skills outside own area of specialty (Foundation)
Team members and workspace	promoting caves (area to work with high cognitive load) and commons (open space for collaboration) spaces (Recommended) open workspace (Highly Recommended) multidisciplinary team (developers and testers) (Highly Recommended) team size [106] (Recommended) training in Agile concepts, principles, practices and values (Foundation) team incentivized to behave according to the Agile values (Recommended)
Team collective ownership	team commitment from collective knowledge and historical capacity (Highly Recommended) team is rewarded collectively, and successes are celebrated together (Recommended) empowering individuals to solve issues and protect them when things do not go as expected (Recommended) team has a feeling of self-organization (Foundation) heartbeat retrospectives to make improvement plans (Recommended) feeling of sustainable pace on constant delivery with the same level of quality (Highly Recommended)
Organization culture	Communities of Practices to cross-pollinate on practices and technologies experiences (Foundation) training Lean and Agile to leaders and business owners on “Lean-Thinking manager-teachers” to lead emergent evolutions and have empathy for teams on the engineering streams (Highly Recommended) proactive leadership participation at program/stream events (Foundation) enabling an Inner Source culture and practice to foster reuse and teams’ interaction (Highly Recommended)

in Appendix B.2, and

Table A4. Lean Socio-Cultural Practice Areas and Practices—I.

Areas	Practices
Transformational Leadership	leadership set the middle-term and long-term vision (Foundation) organization-wide promotion of inspirational communication (Highly Recommended) supportive leadership intellectually stimulating behaviors (Recommended) recognition based on collective goals and improvements (Highly Recommended)
Learning Culture	setting an organization climate of self-learning (Highly Recommended) individuals have resources to engage in formal learning and space to explore ideas through on the job exposure and experience (Recommended) people feel safe to take interpersonal risks by speaking up and sharing concerns, questions and ideas (Foundation) cadence of events to share information and cross-pollinate knowledge (Highly Recommended) enabling continued education with a focus on market trends (Recommended)
Westrum organizational culture [32]	the habits and structures for a generative organization that includes the adoption of providing access to the customer needs and timely information flow enables making data driven decisions and actions (Foundation) setting a climate where management decisions can be openly challenged, or negative news can be delivered (Highly Recommended) shared responsibilities at team level (Highly Recommended) build informal communication networks to bridge operation silos, allowing factual decision-making and risk taking in the SoW (Recommended) use post-mortem analysis to inspect the system as a whole or facilitate the capability to do experiments to explore new ideas (Highly Recommended)

and

Table A5. Lean Socio-Cultural Practice Areas and Practices—II.

Areas	Practices
Lean business operations	development and value stream have been mapped using a Value Stream Management mapping process [107] (Foundation) Value Stream Mapping is done iteratively to improve flow with measurements to remove waste in software practices [108] (Highly Recommended) process times and delays are made visible and measured (Foundation) bottlenecks, delays and impediments are addressed quickly (Foundation) Kanban [109] boards are used to visualize flow and proactively limit Work in Process with team swarming [110] (Foundation) backlog queue lengths are measured and manage using Cost of Delay/Economics to prioritize [111] (Recommended) Development teams understand the operational value stream and how their development value stream impacts the operational one (Recommended) development teams apply customer-centric metrics and analytics to measure the hypothesis tests they execute (Recommended)
Strategy Agility	vision, mission and strategy are communicated effectively and are available to all individuals when needed (Foundation) market research and analysis is continuously focused on creating and validating hypothesis tests with data (Recommended) customer feedback is institutionalized, routine and fast (Highly Recommended) executives spend time with the people do the work and building understanding (Gemba walks) to understand the flow of value (Highly Recommended) executives spend significant time directly with customers to gather their needs and build empathy for their problems (Recommended) Minimum Viable Products (MVPs) express hypothesis-driven innovation with pivot/persevere/perish criteria based on analytics (Recommended) leading indicators provide fast feedback on business Epics that are not financial in nature (Recommended) Objective and Key Results (OKRs) [112] are defined (Recommended)

in Appendix B.3, for the Governance layer with a focus on socio-cultural aspects of the SoW. These practices will help to evaluate RQ1.

4.1.3. Sense-Making Techniques for Guiding Transformation

Transformation must use evolutions to move ahead. These evolutions are performed by experimentation of safe-to-fail experiments with the teams and individuals [84] that are part of the SoW. The individuals and teams are given higher agency in changing the SoW that has a higher correlation to change indicators such as the Employee Net Promoter Score (ENPS) or job satisfaction (JS). In this way, the transformation is not being enacted against them, it is being enacted by them. The work in Accelerate shows that ENPS and JS are the result of the direct focus on social aspects driven by the governance domain of the value stream rather than just looking at enabling better software practices [76].

The progress of the transformational journey is proposed to be tracked using an evolution of the canvas tool introduced by the scaling management framework (SMF) [67]. This tool was born with the intent to communicate with organizational thought leaders and organizational hierarchical managers (transformational agents) about the aspects that support the evolution of the SoW. The decision to start a transformation journey in three scaling domains of the software model is mainly driven nowadays by the megatrend of digitization.

In the transformation journey, roadmapping is proposed to use the SFM canvas as a tool to guide change agents, by using it for defining and prioritizing collectively safe-to-fail experiments pursuing resilience in SOW.

The SMF considers three scaling domains: the process domain, the product (or technology) domain, and the organization (or people) domain. This model embeds the socio-cultural aspects as part of the organization domain that can also support the need to scale to several value streams to achieve higher organizational alignment. The SMF is a help guide to evaluate when and where scaffolding, such as frameworks, teamwork, tooling, or management policies, can be adapted to experiment within the SoW. The proposed canvas to communicate the software model adoption journey is structured in four building blocks by extending it with a governance layer where socio-cultural aspects reside and a prioritization journey for experiments adoption (Figure 6b).

The SMF canvas (Figure 6b) is used as a sense-making tool to “depict sense-making moments representing the intersection of all parts of the Situation-Gap-Outcome” triangle [98] (Figure 6a). Change agents using the proposed extended SMF canvas realize the gaps in the SoW and bridge them by “experiencing questions and muddles that lead them to construct bridges”. The situation is shown by the change agents in their current position (AS-IS) in socio-technical practices as the outcome of the assessment against the reference maturity model. The gaps and current inabilities of the SoW are shown in terms of SoW’s performance metrics. Those metrics represent the wanted abilities in the future scenario; in other words, they represent the target outcome or SoW’s performance. Bridges are represented by the experiments and their prioritization journey that agents collectively define to achieve the desired outcomes. Collective sense making enabled by the SMF canvas “produces a shared map of what is going on and enables coordinated action” [99] for change agents.

First, the transformation within the organization begins by identifying the core business drivers pursued to achieve specific objectives (e.g., shorter lead time to deliver value, increased productivity of teams, and boost innovation on product). These drivers may originate from internal or external sources within the SoW and represent the underlying reason to change.

Second, the current capabilities (the AS-IS position) depicting the situation in terms of practices in use (e.g., lack of backlog awareness by the team or Infrastructure as Code is not in place, preventing common IT environments) in the three domains covering the whole software model with the governance layer (e.g., unknown customer persona by team members).

Third, the desired capabilities (the TO-BE position) depict the bridge in terms of practices to be adopted (e.g., align vision and focus on balanced prioritized backlog items or common IT environments (staging, integration, production) enabled by Infrastructure as Code) in the three domains plus the governance layer of the software model with the governance layer (e.g., define customer persona and share at SoW scale).

Fourth, the current inabilities, growing pains, or inefficiencies are observed gaps in the SoW (the AS-IS position) (e.g., from lead time and cycle time not being measured) based on the current situation of capabilities and practices in the scaling domains, as opposed to the future or desired abilities, pain points removal, or efficiencies being pursued as outcomes after transformation actions are taken, in the organization by adopting or evolving capabilities and practices in the software domains (the TO-BE position) (e.g., towards lead time and cycle time measured automatically and shared in an open dashboard).

These experiments alter how individuals and teams perceive their experiences and can influence the mindset of management by developing collective interpretations of truth from the constructors. The SMF is built on an assumption that management and thought leadership are progressing toward establishing genuine team structures that align with new leadership compartments. The cultural evolution is targeted in the socio-cultural aspects.

With those incremental safe-to-fail experiments, agents interact with the system by probing [5] and sensing its response. Continuous improvement is achieved through an ongoing adaptive cycle in which each response initiates the next probe [57], while agents are growing their competencies in socio-technical practices.

This article proposes (Figure 6b), that the governance domain (culture and organizational design) be considered a domain of practices in addition to the process, people, and technology as an extension of the SMF model. By identifying the socio-cultural practices and the position of technical practices (AS-IS), we propose a transformation journey towards the desired socio-cultural position and technical (TO-BE) plus measure socio cultural indicators (ENPS and JS), technical indicators deployment lead time (deployment LT), deployment frequency (DF), change failure rate (CFR), and mean time to recovery (MTTR) proposed by DORA [36], jointly with the SMF canvas to discuss emergent micro- and macro-narratives among change agents to evaluate RQ3.

5. Methodology

A digital transformation journey as the one proposed in this section for the software model must consider the awareness, readiness, planning, and execution phases [65]. The awareness phase is the organization’s decision to initiate the transformation journey, leadership support, understanding the drivers of change, and self-perception of current inabilities in terms of SoW performance and socio-technical practices.

The readiness phase involves studying the current position of SoW with guided assessment on the reference maturity model on socio-technical practices.

The planning phase involves prioritizing and roadmapping safe-to-fail experiments in a collectively aligned transformation plan.

The execution phase involves guiding the SoW to a desired position when probing experiments to improve SoW performance and/or gain competencies adopted by agents in the SoW. The outcome of each iteration in the execution phase is a new current position, representing the readiness phase for a systematic implementation and maintenance in a SoW’s continuous improvement journey for organizational performance.

5.1. Socio-Technical Congruent Methodology

The proposed methodology (Figure 7) relies on an evolutionary journey, supported by gathering insights from dual systems. The methodology considers sense-making techniques supported by six steps with the aim to provide answers to RQ1, RQ2, RQ3, and RQ4.

Step 1—Engage: to obtain buy-in from the transformation agent. This agent obtains the organizational power to promote, sponsor, and engage a value stream and individuals on the transformation journey. Transformation helps to align the strategy by influencing teams and individuals [3], enabling sense giving to guide actions and decisions [31] and supporting the impact of the transformation journey while cultivating and promoting the culture [65].

Step 2—Awareness: to gain foundational awareness of the SoW situation by gathering input from the coordinator agent and SMEs. The coordinator agent, via the Gathering insights constructs

Table A1. Gathering insights questionnaire.

Question	Potential Answers
Question-6: What are the Business Drivers of your Program to start the transformation	Increase team productivity Ensure quality & security of deliveries Shorten lead time to deliver value Improve individuals’ job satisfaction Improve organizational efficiency Booster innovation on offers Simplify portfolio management Increase progress awareness by visualizing flow of value Others
Question-7: What are the areas of perceived in-efficiencies in your organization	On quality of delivered value On value delivered to end customer/user On productivity of value delivered On predictability of value delivered On adoption of practices (Lean/Agile, engineering, …) On socio-cultural aspects
Question-8: Which of the following aspects associated to your Program you consider might be improved	How work items are being prioritized and planned (Process pillar) How automation and shift-left practices are introduced in each activity (Process pillar) How workstream organize, which engineering practices must be followed and how workstream collaborate (Organization pillar) How workstream track, measure progress and efficiency in the end to end process (Organization pillar) How application and technology support the SDLC of the offers and ease collaboration (Technology pillar) How to ensure built-in quality, security and safety for delivered software (Technology pillar)

in Appendix A, aggregates the SoW’s details to trigger the start of the journey, and SMEs self-assess their current position for foundational practice items with the support of assessment model constructs in Appendix B with a focus on socio-technical capabilities. As an outcome of this phase, business drivers and self-assessment on socio-technical practices are gathered as analytical System-I constructs.

Step 3—Assessment: Guided interviews are facilitated by change agents to cover the Deep Dive Assessment (the entire set of practice items in the assessment model constructs in Appendix B), as input to depict the current robustness level of the SoW. Facilitator change agents might be internal or external individual with the right level of agency to coach or mentor members in the SOW. The guided assessment uses the questionnaire as an analytical System-I construct, while System-II micro-narratives on each question provide an understanding of the underlying aspects of the socio-technical practices to SMEs and situational background context of the SoW to the change agent.

Step 4—Transformation Plan: The insights collected from the awareness and assessment steps help to build a first version of the SMF canvas. This first version of the canvas collects business drivers for change from the awareness phase, the current position on the adoption of socio-technical practices, and the KPIs in use for SoW performance from the assessment phase. The shared situation with change agents is a System-I constructor. The canvas tool supports the emergence of System-II narratives and discussion among all agents. As an outcome, improvement actions (in the form of safe-to-fail experiments for socio-technical practices adoption) are prioritized in a plan to pursue the increase of robustness in the SoW. This plan represents the evolutionary journey towards continuous improvement.

Step 5—Practice Adoption: SMEs create context-appropriate incremental improvement actions within the team’s practice area by iterations. Each iteration includes an inspect and adapt session to create a level 1 and/or level 2 OODA loop. SMEs and change agents collect System-II narratives from the team. Through the lessons learned, SMEs apply micro-actions that are guided by System-II narratives to foster new behaviors and shift team orientation towards desired outcomes.

These build a collective set of learned lessons where SMEs gather emerging narratives to apply alternate micro-actions as tactics for constructors of new behaviors and competences to shift the team orientation towards the desired outcome. By guiding with holistic System-II narratives, the approach embeds the adaptive nature of the emergent system rather than following practices of adoption blindly.

Step 6—Conclusion and the Next Desired Position: The SMF canvas is updated to include an evaluation of practices, KPI tracking, and narratives aimed at reaching the intended TO-BE state at the SoW level, thereby constituting the new AS-IS.

An introduction of the journey is continuously shared with change agents as an iterative process between steps 4 to 6 for continuous improvement of the SoW to pursue the increase in the resilience of the SoW.

5.2. Specification of the Gathering Insights Construct

Understanding WHY an organization’s embarks on a transformation journey through a disciplined delivery model is crucial for both sowing the seeds of change and gaining insights into the organization’s context (the SoW).

With the dual purpose of gathering insights, as well as feeding the SMF canvas with early insights on business drivers for the future emergence of System-II narratives, a questionnaire was built and organized into four sections.

Entity Details and Key Contacts: aims to collect essential contacts for the workstream, including the program’s sponsor and subject-matter experts (SMEs).

Adoption journey focus: to understand which capability areas allow deeper interest in the transformation (e.g., culture capability); what the business drivers are, or the WHYs as reasons to move into the journey (e.g., boost innovation or shorten lead time); and what the areas of perceived waste are within the SoW, or which aspects are considered as objects that can be used as constructions for improvement (e.g., which software engineering practices must be followed and how workstreams share information or energy).

Program awareness: collecting insights on the value stream’s focus, program socio-details in terms of the number of teams and headcount, the type of software being delivered, and the disciplined delivery model in place.

Best time to start the awareness and assessments steps of the methodology (Figure 7) to understand the analytical System-I insights (AS-IS robustness), and other contextual comments.

This construct has been defined to be answered by a transformation coordinator agent nominated by transformation agents (leadership). Table A1 in Appendix A includes examples of the questions collected by this questionnaire.

5.3. Specification for the Assessment Model Construct

The assessment model construct is based on socio-technological practice items grouped in practice areas within pursued capabilities. This assessment model is used as analytical System-I construct to measure the SoW’s robustness. Practices consider enabling guiding principles from Lean and Agile (e.g., visualize flow, effective prioritization, or deliver customer value) and software engineering (Everything as Code, continuous automation, shift-left, built-in quality, and inner sourcing).

Each practice item has been classified with its relative potential impact within the SoW called practice journey. The practice journey starts with foundation practice items that shall be used as early constructs. Then, it continues with highly recommended items that shall be built upon and used as constructors once foundation practice items have been adopted within the practice area. To conclude, recommended practices items shall be adopted for continuous improvement in the practice area. This aids in choosing practices to be incorporated into the SMF canvas tool’s current position, facilitating the development of narratives among change agents to initiate discourse on defining the adoption journey plan.

5.3.1. Technological Practices in Disciplined Delivery

In this section, technical practices are grouped into enabling capabilities and practice areas. The practices enable continuous automation capability by promoting the Everything as Code paradigm as part of the enabling environment practice area with a practice item such as with the implementation of all environments as code (concept of Infrastructure as Code) to ensure the same setup and configuration when provisioning the different environments (development, integration, staging, or production). Alternatively, through practices like an Agile team dedicates a portion of capacity in each sprint to diminish the technical debt backlog, the continuous quality practice within the assurance capability adheres to the built-in quality principle. More examples within the assessment model construct can be found in (Table A2 in Appendix B, Appendix B.1).

The adoption of these practices represents the analytical system viewpoint, aiming to ensure SoW robustness (Figure 8). Assessing these practices provides awareness of the current position (AS-IS level of maturity) from a technological domain. These practices will help to evaluate RQ2.

5.3.2. Socio-Cultural Practices in Disciplined Delivery

In this section, two sets of socio-cultural practices are grouped into practice areas. The first set of practices is focused on Agile teams to promote Agile organizational cultural evolutions with a focus on the system team scale (Table A3 in Appendix B, Appendix B.2). In contrast, the second set of practices is focused on multiple Agile teams, scaling Agile or DevOps disciplined delivery or Lean delivery model [51] for product management to promote Lean organizational cultural evolution on the whole system scale (Table A4 and Table A5 in Appendix B, Appendix B.3). The adoption of these practices represents the analytical system viewpoint, aiming to ensure SoW robustness (Figure 9). Assessing them brings awareness of the current position (AS-IS level of maturity) within a socio-cultural domain. These practices assist in evaluating RQ1. (These behaviors would be supported by an organizational evolution of structures, processes, and measures. The structures will include how teams are allocated and hierarchy is defined to move from functions to purpose driven. Processes will move from centrally defined and enforced processes to more local decisions based on principles and transparency. And finally, the measures would move away from short-sighted SMART goals to long-term goals, forecasts, and adaptive resource allocation [16]).

Within culture capability, the practices have been grouped into practice areas (Table A3, Table A4 and Table A5), such as team-based collaboration. These practices are classified by applicability scope within the value stream boundary (Agile team or organization scale), the type of software delivered (e.g., firmware, thick client, desktop, cloud, or mobile), and the in-place SoW disciplined delivery model (Waterfall, Agile, DevOps, or Lean product management).

Appendix B aggregates the detailed socio-technical congruencies for Agile (Appendix B.2) and Lean (Appendix B.3), software engineering and management (Appendix B.1) areas along with their respective practices to create hypotheses for scaffolds that focus on addressing cultural evolutions both at the single team (sub-system level of the SoW) and the organizational or SoW scale, respectively.

To obtain the System-I analytical awareness of the SoW current position (AS-IS), seven constructs as surveys have been implemented. Usually, SMEs were central to filling in questions in the surveys to aggregate the practices’ evaluation. Each survey engages the SME to achieve an awareness step and an assessment step (Figure 7). The awareness survey is carried out first as a self-assessment that covers foundational items. The assessment survey is a guided interview that covers all the practice items to evaluate the AS-IS of the SoW. The assessment is driven by the change agents, who aggregate the narratives and KPIs. SoW level narratives emerge through an open discussion.

5.3.3. Assessing Maturity Adoption on Capabilities and Practices

When assessing the role of maturity on capabilities’ adoption in a holistic view for the SoW, different roles as SME on the capability and practice area must be considered. As an example, when considering the cultural dimension within the SoW, it has been recommended that for the Agile team scope, the scrum master role obtains the better viewpoint to aggregate the answers to gain insights, while at the program or system scope, the release train engineer role (when applying SAFe [100]) or the scrum of scrum masters role (when applying LeSS [47]) is suggested to aggregate the answers. Similarly, when considering continuous automation capability dimension practice items, the SMEs to consider are the software offer build manager and the product owner, the architect, and the test leader when considering continuous testing practices in an end-to-end viewpoint.

Four responses are predefined for each practice item in terms of perceived adoption. Deployed is when a practice item is mastered and adopted in the SoW. In Progress, a practice item is under adoption in the SoW with some continuous improvement energy allocation. Not deployed is when a practice item is not yet adopted in the SoW. I am not aware of is when the SME is not aware of the status or terminology of the practice item.

6. Case Studies and Results

The previously outlined STC methodology is being tested in its initial phase in three flagship programs within an enterprise IT organization and three flagship programs in two business units within a corporation, each beginning their LSA and DevOps transformations journeys. As of this writing, the first four steps of the process have been completed for these programs. This article will present the first findings obtained by implementing the dual system approach within the STC methodology.

6.1. Step 1—Engage: Getting Sponsor’s Buy-In

For confidentiality, programs are referred to as A, B, C, D, E, and F. The rationale for selecting programs was because their management class (C-Level) as sponsors agree to start their LSA and DevOps transformations as part of a broader corporate initiative. Sponsors appointed coordinator agents for each program.

Programs under transformations are representatives ones within the businesses and are a good representation of the diversity of programs within the corporation. No other criteria were suggested to sponsors rather than willingness to participate in the case study. Details of the programs can be seen in

Table 1. Flagship programs’ context.

Program	A	B	C	D	E	F
Individuals	108	40	80	40	10	200
Scrum Teams	9	5	6	5	2	15
Type of Software	CA	CA	CA	TC	DA & CA	FW, TC & CA
Delivery Model	I	A	S	A	LP	S
# of SMs	1	3	2	1	0	3
# of RTEs	2	1	1	0	0	1
# of BMs	1	1	1	1	1	2
# of TLs	1	1	1	1	1	1
# of QLs	1	1	1	1	1	1

Type of software: cloud application (CA), desktop application (DA), firmware (FW), and thick client (TC). Delivery model: Agile (A), iterative (I), Lean product (LP), and SAFe (S).

. To highlight, their SoW varies in size between large-scale and very large-scale accordingly to Dingsøyr et al. [101]. The type of software they develop and discipline delivery models before applying the methodology are also representative of the corporation.

6.2. Step 2—Awareness: Studying the SoW Current Position

The participating SMEs were scrum masters (SM), release train engineers (RTE) (or equivalent), build managers (BM), test leaders (TL), and quality leaders (QL). They were directly engaged by coordinator agents within their respective programs. Data collection from SMEs was facilitated through questionnaires implemented in Microsoft Forms. The gathering-insights questionnaire (Table A1 in Appendix A) was completed by a release train engineer. Additionally, SMEs self-assess their programs based on their area of expertise using questionnaires such as the one introduced in Appendix B, providing insights into the current position of socio-technical capabilities.

To ensure SMEs’ psychological safety and obtain their honest responses when completing the self-assessments and deep dive assessments, we included the following sentences in all questionnaires:

“Please notice that this assessment:

• is not used to judge the team as being ‘good or bad’ or used to compare teams with a score
• results is used to define the adoption of practices to achieve a certain level on this assessment

The aim of this questionnaire is to get your self-awareness of your program with regards to <name of capability> supporting your development lifecycle practices”.

6.2.1. Insights and Business Drivers for Change

By answering the gathering-insights questionnaire Table A1 in Appendix A, we obtain awareness on the contextual insights for each program (Table 1), plus insights on their business drivers to change (Question 6) (

Table 2. Flagship programs’ business drivers for transformation from gathering-insights questionnaire (Question 6).

Business Driver/Program	A	B	C	D	E	F
Increase team productivity			Yes			Yes
Ensure quality and security of deliveries	Yes	Yes		Yes	Yes
Shorten lead time to deliver value	Yes	Yes	Yes	Yes	Yes	Yes
Improve individuals’ job satisfaction	Yes	Yes		Yes	Yes	Yes
Improve organizational efficiency			Yes
Booster innovation on offers
Simplify portfolio management
Increase progress awareness by visualizing flow of value

Programs should highlight their business drivers for up to 3 main topics.

), on the perceived inefficiencies (Question 7) (

Table 3. Flagship programs’ perceived inefficiencies from gathering-insights questionnaire (Question 7).

Inefficiencies/Program	A	B	C	D	E	F
On quality of delivered value			Yes	Yes	Yes
On value delivered to end customer/user				Yes	Yes
On productivity of teams		Yes	Yes		Yes
On predictability of value delivered	Yes	Yes	Yes	Yes	Yes	Yes
On adoption of practices (Lean, Agile, engineering, …)	Yes	Yes
On socio-cultural aspects

Programs can check any topic to highlight their perceived in-efficiencies.

) and on desired improvement aspects within the three pillars of the technical domain (Question 8) (

Table 4. Flagship programs’ aspects to improve from gathering-insights questionnaire (Question 8).

Improvement Aspects/Program	A	B	C	D	E	F
How work items are being prioritized and planned (process pillar)	Yes	Yes	Yes	Yes	Yes	Yes
How automation and shift-left practices are introduced in each activity (process pillar)	Yes				Yes	Yes
How workstream organizes, which engineering practices must be followed, and how workstream collaborates (people pillar)	Yes		Yes	Yes
How workstream tracks and measures progress and efficiency in the end-to-end process (people pillar)		Yes	Yes	Yes
How applications and technology support the SDLC of the offers and ease collaboration (technology pillar)		Yes
How to ensure built-in quality, security, and safety for delivered software (technology pillar)					Yes	Yes

Programs should highly their aspects to improve in at least three topics in.

). Those represent the drivers (the WHYs) for starting the transformation journey for each program. The names of programs in Table 1 have been anonymized.

Table 1 summarizes contextual insights for six flagship programs, together with details of the roles involved in the awareness and assessment steps. Three flagship programs (A, B, and C) are delivering internal cloud-based applications enabling enterprise processes, while end customers products are delivered by program (D) as a thick-client product, program (E) as a desktop and cloud solution, and lastly, program (F) as a solution including firmware, thick client, and cloud. In terms of individuals collaborating and contributing in the SoW, it varies from 10 in Program E to 200 in Program F. In relation to the disciplined delivery model, Program A follows an iterative process and has started to adopt Agile practices, Program B and D adhere to Agile scrum, Program C and F use SAFe, and Program E has recently started adopting Lean product development practices.

Table 2 summarizes the business drivers for each program to start the transformation journey (Question 6 in the gathering-insights questionnaire) The reasons for starting the transformation for Programs A, B, D, and E were to ensure built-in quality and security, shorten lead time, and improve job satisfaction. In the case of Program C, the reasons were to increase team productivity, shorten value delivery lead time, and improve organizational efficiency. Finally, in the case of Program F, the motivations were to increase team productivity, shorten lead time, and improve job satisfaction. It is noteworthy that all the programs were customer oriented and that the business drivers emphasized shortening the lead time to deliver value in the SoW. In addition, socio-cultural business drivers in SoW, such as improving individual job satisfaction and improving organizational efficiency, were also expressed by all the offers.

Table 3 summarizes, for each program, the areas of perceived inefficiencies in SoW to optimize for efficiency (Question 7 in the questionnaire). For those programs, their perceived inefficiencies were the quality of delivered value (Programs D and E), the value delivered to end customer or user (Programs D and E), the productivity of the teams (Programs B and E), the predictability of the value delivered (Programs A, B, D, E, and F), and the adoption of practices (Programs A and B). In the case of Program C, the expressed perceived inefficiencies were teams’ productivity, teh quality of delivered value, and the predictability of delivered value. All of them highlighted inefficiencies in the predictability of value delivered in alignment with what they expressed in Question 6. However, no program expressed socio-cultural aspects, which contrasts with business drivers expressed in Question 6. We can infer that the programs are still considering focusing on the adoption of technical practices for improving efficiency in the SoW.

Finally, Table 4 summarizes, for each program, the desired improvement aspects (Question 8 in the questionnaire) within the three pillars of the technical domain: people, process, and technology. The prioritization and planning of work items is common to all the programs. Then, Programs A, E, and F expressed the role of automation and shift-left on practices, Programs A, C, and D expressed workstream organization and collaboration aspects, B, C, and D expressed tracking and measuring progress and efficiency in the SoW, Program B expressed how applications and technology support collaboration, and to conclude, Programs E and F expressed ensuring built-in quality, security, and safety in deliveries of the SoW.

These contextual insights on business drivers and perceived inefficiencies are inputs to the SMF canvas (Figures 13 and 14 facilitate the definition of the transformational plan supported by the emergence of narratives between agents as illustrated in Section 6.4).

6.2.2. Socio-Technical Assessments

Self-assessments on socio-technical practices (in Appendix B) are completed individually by each SME. When more than a SME is providing inputs in the self-assessment, an average of their responses is used as highlighted in Figure 10.

6.3. Step 3—Assessment: Studying the SoW Current Position

Step 3 involves a deep dive assessment guided in an interview format by a change actor, with the participation of a coordinator agent and SMEs. These assessments expands on the questions from Step 2, covering additional practices within each capability. Responses are collected in Microsoft Forms, and the change actor takes side notes for background purposes. The aim of these guided assessments is to facilitates a common understanding among SMEs of the interpretation of socio-technical concepts related to various practices.

6.3.1. Awareness of Socio-Cultural Practices

Figure 10 provides Program B’s insights on the adoption of practices within the culture dimension. Those figures show the answers of the SMEs in the awareness and assessment steps. As expected, we observed differences in the responses of the individuals on the program. This System-I view supports the change agents in obtaining an early snapshot of sub-systems robustness within the SoW. For example, not deployed practices (not implemented ones) are indirect symptoms of the current position in terms of the adoption of practices.

On the other hand, Figure 11 shows the current position, AS-IS maturity, on socio-cultural practices for Program B and C as a result of the completion of the assessment step. It provides change agents with a detailed view of SoW’s socio-cultural robustness. For example, both programs present a weakness in adoption in Lean-related socio-cultural practice areas. In addition, it can be observed that Program B is more mature than Program C in Agile related socio-cultural practices. Indeed, Program B has been practicing Agile for few years, and is currently evolving into SoW scale transformation with support of an Agile Coach support. Meanwhile, Program C is just beginning its journey at the sub-system (team) level. Hence, it can be inferred that the methodology helps to answer RQ1.

Other System-I symptoms of applying the methodology were identified in Program B. In this case, the assessment step showed an improved position over the awareness step. More than a quarter spans between the completion of both steps. The program incorporated an Agile coach after completing the awareness step. In this period, SMEs were educated and practiced several of the HOW and WHAT aspects of the transformation, including leadership behaviors, when completing the assessment step. However, most foundational practices were just starting or about to start. In addition, SMEs’ inputs in both steps as unknown practices, with narratives introduced by the change agent, helped SMEs understand the purpose of some practices. Non-optimized practices (with an impact on the SoW’s robustness) steered by an Agile coach for adoption were also identified.

In addition, for the five programs, none of them were measuring the ENPS and JS socio-cultural indicators. Those metrics are dependent on the global functions of human resources. While ENPS is assessed as a regular practice, there are no aggregated details with a SoW scope (e.g., Program B value stream as a SoW). On the other hand, JS is not being considered in current surveys of the SoW. This implies a need to engage human resources functions to provide ENPS details with a program scope, plus incorporate, in their survey questions, measurement of JS.

The awareness of System-I socio-cultural practices is input to the current position on the governance layer in the SMF canvas (Figure 13 helping the emergence of narratives (sense making) between agents to facilitate the definition of the transformational plan supported as illustrated in Section 6.4.1).

6.3.2. Awareness of Technical Practices

Figure 12 shows the current position, AS-IS maturity, on continuous automation practices as part of the process pillar for Program D and E as a result of completing the assessment step. It provides to change agents a detailed view of the SoW’s technical robustness. Both programs, for instance, show weaknesses in the areas of adoption concerning build and testing, continuous integration, and continuous deployment, as well as monitoring, control, and logging technical practices. Program D is a new R & D program in its early steps that can be appreciated by its maturity records in each practice area. However, program B is restricted by limited computational resources that hinder advancements in building, testing, as well as continuous integration and continuous deployment practice areas. Thus, in both programs, we gain a precise understanding of technical robustness. It can, therefore, be concluded that the methodology aids in addressing RQ2.

In addition, for the five programs, none of them were measuring deployment LT, DF, CFR, and MTTR as technical indicators. The observability at the system level as shown in the monitoring, control, and reporting practice area in Figure 12 is a lack of all programs, preventing them from supporting their transformation journey and decision-making process based on leading indicators for SoW efficiency.

The awareness of System-I technical practices is input to current position on the three pillars (people, process, and technology) in the SMF canvas (Figure 14 helping the emergence of narratives (sense making) between agents to facilitate the definition of the transformational plan as illustrated in Section 6.4.2).

6.4. Step 4—Transformation Plan: Guiding the SoW Desired Position with SMF Canvas

Future steps will focus on shifting to a holistic view with additional SoW stakeholders to incorporate System-II micro-actions. The canvas presents the business drivers, perceived inefficiencies, current position, wanted position, and target efficiencies on socio-technical practices as part of the governance layer and people, process, and technology pillars to use for the emergence of narratives between agents when defining the evolutionary path.

6.4.1. Canvas and Socio-Cultural Practices

Figure 13 shows a partial view of the SMF canvas, highlighting socio-cultural practices (governance layer) to define the evolutionary path for Program B. The SMF canvas is built with inputs from Steps 1—engage, 2—lite assessment, and 3—deep dive assessment to fill business drivers, inabilities, and the current governance layer position for Program B. Step 4—transformation plan starts by sharing these outcomes with change agents to facilitate the emergence of narratives to collectively align and define the desired position both in the governance layer and abilities as System-II micro-actions for Program B.

6.4.2. Canvas and Technical Practices

Figure 14 shows a partial view of the SMF canvas, highlighting technical practices (process pillar) to define the evolutionary path for Program E. The SMF canvas is built with inputs from Steps 1—engage, 2—lite assessment, and 3—deep dive assessment to fill business drivers, inabilities, and the current process pillar position for Program E. Step 4—transformation plan starts by sharing these outcomes with change agents to facilitate the emergence of narratives to collectively align and define the desired position both in the process pillar and abilities as System-II micro-actions for Program E.

Hence, from the SMF canvas in socio-cultural practices and technical practices, it can be inferred that the methodology helps to answer RQ3.

6.5. Next Steps on Case Studies

The SMF canvas and maturity results are to be shared with programs’ key roles, with the aim to align stakeholders on their evolutionary path. These case studies constructed the SoW map for each program’s targeted outcomes. Following offers on their adoption of practices for continuous improvement will help to introduce refinements on the dual system methodology with early feedback cycles to mature the STC methodology and related constructs. The impact on the SoW’s KPIs will help validate whether the methodology provides results by enabling effectiveness in the SoW. These KPIs will require to be measured for a long period of time to prove the validity of the STC methodology. In other words, this will help to answer RQ4.

7. Discussion

7.1. Assessing Maturity: A Dual System Balance in CAS

Assessing the maturity of software practices in an organization is usually oriented towards robustness through the adoption of practices as a checklist of explicit practices. This provides an understanding of the current state of maturity in the WHAT domain (Figure 4) of the organization. Evaluations are limited to a partial understandings of the SoW because they use the analytical System-I perspective on sub-systems. These analytical maturity assessment models ignore the emergent properties inherent in the CAS. The CAS attributes are the aggregation of software practices together with the interactions between agents (human and technical) that result in organizational performance. This emergence of knowledge is supported in the methodology by these interactions as a System-II perspective of the SoW in addition to the System-I perspective.

As an example, one of the main reference frameworks adopted for LSA transformations by corporations is SAFe [46]. SAFe focuses on guidelines to achieve organizational agility and create a continuous learning culture [102]. SAFe proposes a measurement approach considering three domains called competency, flow, and outcomes [103]. This approach is largely at the software practices sub-system level of the SoW. Outcomes and flow are both aspects of the WHY domain. Finally, the competency domain is structured around SAFe’s seven core competencies that are further subdivided into dimensions and sub-dimensions [85]. Each core competency can be self-assessed to evaluate the HOW and the WHAT domains. For instance, team and technical agility covers the HOW and the WHAT for execution, while Lean portfolio management covers HOW and WHAT for investment decisions.

SAFe’s baseline practices and methods are implemented through licensed toolkits. These toolkits are oriented around the SMF’s people and process domain, primarily for System-I. The technical domain in the SMF is used to introduce the end-to-end perspective of the SoW. Consequently, the SMF helps to facilitate the emergence of narratives required necessary for achieving holistic System-I and System-II viewpoints of the SoW.

Recent studies have highlighted similar challenges in LSA [24,25,41] and DevOps [18,19] transformations, such as the need for a shared understanding of the problem, fostering collaboration across functions, and commitment to change. These findings align with the challenges identified in our programs. The engagement step of our STC methodology was instrumental in initiating their journey and aligning roles. Furthermore, the necessity of a dual system approach to address both explicit practices and emergent factors in the SoW as a CAS was key to build a sharing understanding and aligning role’s commitment to change.

7.2. Leadership as a Catalyst in CAS Organizational Design

The three domains within the socio-technical scope, as depicted in Figure 4, facilitate an evolutionary journey of the software model, enhanced by dual systems as opposed to a System-I methodology. The WHY, by engaging with the sponsor (the leadership), provides the vision and purpose with associated KPI’s and targets (Figure 6b). The sponsor is accountable for embodying the three core beliefs as a model agent who is responsible for changing the SoW for organization design changes, actively influencing the organizational policies when they are counter to the three core beliefs. This means that the role of the sponsor goes beyond cheerleader and financier. The sponsor actively leads by example, demonstrating the aspects of distributed leadership habits that drive the evolution of the culture at SoW scale. By doing so, the foundation stage is set for the emergence of both the WHAT and the HOW, like planting a seed in fertile soil.

Regarding the HOW, the SMEs promote the adoption of guiding principles in the SoW (Figure 4) by working with change agents, by influencing the way that tacit knowledge is achieved by everyone in the SoW. This is like growing a plant from seed and fertile soil (Figure 6b).

Regarding the WHERE, with the involvement of all stakeholders (sponsor, coordinator agent, SMEs, and change agent), the context of the SoW is understood holistically and the confluence for change is aligned to influence the whole SoW (Figure 7). The change is based in the system’s environment and culturally appropriate for the setting, rather than blindly adopting a maturity checklist better suited for another garden.

Previous studies in LSA and DevOps transformations have highlighted the role of leadership as the most fundamental factor [24,104], directly influencing the social debt of the SoW [41]. Acquiring knowledge, communication, transparency [19,24,25], collaboration, and coordination [41] are additional success factors in organizational design for LSA and DevOps transformations. Catalyst leaders play a crucial role in this process by generating new initiatives, energizing teams, and fostering a culture of psychological safety and sense-making [33,34]. The STC methodology, with its awareness, assessment, and transformation plan steps, helped change agents understand the dual system. Meanwhile, the SMF canvas constructor promotes sense-making techniques, creating an environment where change agents can openly communicate, exchange ideas, and make sense of the necessary actions for change in the SoW as a CAS.

7.3. Cultivating Change in CAS Through Collective Behaviors

Figure 15 depicts the different steps of the emergence of change toward efficiency in SoW. Collective experiences support the foundation of collective beliefs, helping to establish the soil for the emergence of the right behaviors both individually and collectively. Behaviors facilitates the emergence of change actions, but these behaviors must be shared and practiced by individuals collectively. The absence of right behaviors compromises the emergence of change actions, impeding the achievement of outcomes both at team and organizational levels. Enhancing communication and employee engagement by promoting purpose, goals and change efforts supported by sense-making techniques for narrating change can be useful for increasing agents participation and developing a culture of ongoing learning and adaptation [104].

The case studies demonstrated that both individual and collective behaviors have a significant impact on the change agent’s alignment during the adoption plan phase of the methodology. During this phase, the methodology copes with individuals and team behaviors with the discussion among change agents around the SMF canvas tool. The lack of collective psychological safety to openly discuss the SoW pain points, focusing the discussion on the SoW problems rather than on improvement actions (e.g., safe-to-fail experiments) for removing the problems, is a symptom observed during the experiments with the different programs. The collective guidance of the team on their own proposal of actions supported by the emergence of right behaviors with a mindset of continuous improvement represents the challenging outcome observed in the transformation journeys of the different programs. This continuous improvement journey is just starting for the different programs highlighted in the case studies section. However, previous observed behaviors impede organizational learning [34]. Building resilience is essential for the long-term survival of the organization [104] in a VUCA world.

7.4. Practical Implementation: The STC Paradox in My Garden

When adopting STC methodology within your organization, you must consider that LSA and DevOps transformations require a custom approach [41]. While Lean and Agile socio-cultural practices to assess System-I robustness proposed in Table A3–Table A5 are suited for other organizations, the proposed journey path highlighted in brackets can be customized to define your journey path. Similarly, the path for technical practices to assess System-II robustness proposed in Table A2 might be customized for the needs of your organization.

The transformation agent when applying the STC methodology should act as a guide for change stakeholders (sponsors, change agents, and SMEs) on how to use the System-I analytical constructors of the SoW (questionnaires and assessments from Step 2 and Step 3) as inputs to build a holistic view of the transformation. The SMF canvas must be used as a collective knowledge constructor of the current position of the SoW to discuss how to address the pain points that impact on organizational efficiency (Step 4). We consider that building collective agency for change is instrumental to achieving resilience in the SoW. The management class as sponsor should act to facilitate this collective agency for change and support the proposed change actions, so learning is prioritized [34].

8. Conclusions

The work of this study demonstrates that STC with a CAS lacks a clear cause and effect, which requires sense-making techniques such as narratives to be collected and constructors to be used with the system agents to emerge more changes that are desired outcomes to create higher STC.

The STC theory is an aggregation of thought and behavior patterns that can be extended with the use of a CAS to lead to change adoption. The study of STC as a CAS theory is largely about the system exchange of information and energy through constructing and using constructors to shift the system dynamics from a low-agency hierarchy to a higher-agency network of decision makers. The transition is concomitant with a shift from a System-I reliance on robust analytical problem-solving to shifting to a System-II resilience. System-II implies the changing of self-identification by producing a collective mutual mental model and building collective narratives supported by emergent SoW properties such as psychological safety, trust, diversity of opinion, and inclusion of thought [27]. The interdependence of System-I and System-II changes outcomes in organizational robustness and resilience.

Increasing the capability to sense-make a problem’s Cynefin ontological state in a CAS and adapt the appropriate responses can strengthen the agency of individuals, teams, and entire cross-sections of an organization. When information is shared with low energy costs between agents in a system, the economic transaction costs decrease. When these transaction costs decrease, the OODA loop becomes shorter in duration. An organization with a shorter OODA loop can penetrate another organization’s OODA loop and disturb its ability to respond [28].

The proposed STC methodology, validated through case studies involving six programs, provides empirical evidence supporting the dual operating system for the SoW as a CAS. The baseline status on socio-cultural practices and technical practices that represents the AS-IS robustness of the SoW has been identified. We propose a novel theoretical model that bridges socio-cultural and technical aspects through congruence, defining an evolutionary journey that emphasizes the robustness and resilience of the SoW. Analytical constructs, as questionnaires for assessing System-I maturity on SoW robustness, has been introduced. The outcomes of these assessments are used in the proposed evolution of the SMF canvas as a guiding constructor to promote sense-making techniques, build agency for change, and define and prioritize change actions to achieve efficiency in the SoW. Empirical validation through case studies highlights the need for significant effort to achieve resilience and robustness in a VUCA world. The System-II view is part of future research activities. High STC creates a more robust OODA loop that makes an organization quickly detect the ontological state of transformations to surpass other organizations that focus only on the technical side of the equation.

Socio-technical organizations should foster the exchange of information between system agents to bring desired outcomes in the target environment. The exchange of support includes social and technically appropriate changes based on the ontological state. This may include the creation of communities where organizational agents act more as citizens than employees.

8.1. Research Limitations

Analytical System-I aims to understand the current maturity of the SoW. However, it relies on inputs from SMEs, which may be influenced by their personal understanding of the questions, their interpretation of practices, and their knowledge level. Aditionally, their psychological safety affects the values they select in the questionnaires. This issue is related to both socio-technical questionnaires and Steps 2 and 3 of the STC methodology, where we assess the robustness of the SoW. Step 4 narratives can be influenced by the change agent. If the change agent acts as an influencer rather than a facilitator, it can hinder collective ownership and agency among change actors. Therefore, change agents must be well-trained in conducting sense-making techniques. Finally, we acknowledge that we are in the early stages of the STC methodology with a limited scope of programs. Scaling the number of programs at the corporate level will help us to identify good patterns for System-II to understand the resilience of the SoW.

8.2. Future Work

This study suggests a positive link between STC using CAS theory to achieve the desired outcomes of organizational performance in the environment and the well-being of people within the SoW. More studies are needed to gather observations and measurements and cluster the results to build a more detailed analysis. The difficulties of future studies mainly surround the SoW definition and changing the definition or roles of agents within a system, when dealing and studying many different subgroups within an organization for which everyone, including the team and the organization, has different motivations plays a more prominent role.

Future work will need to explore how the challenges faced by organizations in adapting STC influence the development of a “WE” experience in an organization. This would include how to build a feeling of agency or influence over decisions about system outcomes and internal governance. While we included some quantitative variables to create some foundational control variable, future work would need to find an effective way to collect and analyze qualitative data from micro-narrative and macro-narrative against the desired outcomes to embrace emergence. The application of the cultures framework as a research guide can be used to explore and identify the relevant motivators as belief to build agency for change in the SoW, exploring constructors based on the use of business intelligent tools to provide a consolidated view of program’s maturity and trends as guiding activities to change direction. Additionally, exploring the use of visual management tools as scaffolds for the collective exchange of experience could facilitate the emergence of collective belief, helping to understand how individuals embrace emergence and change in the SoW. Constructors as qualitative surveys would help answering this open question, jointly with which sense-making techniques are the suitable ones for agency.

As the STC methodology scales from 10 to hundreds of programs within the corporation, data correlation will be instrumental to assess the impact of the STC methodology along different environmental factors of the SoW. Factors such as size of the transformation, disciplined delivery, and the type of software being delivered will be crucial in accelerating and facilitating the transformation journey for future programs. Additionally, designing constructors as qualitative surveys to collect feedback from roles (sponsors, change agents and SMEs) will provide valuable insights into the STC methodology impact on organizational design and its efficiency.

Finally, the previously discussed constructors, sense-making techniques, and scaffolds derived from the dual system can be integrated into the governance practices of the organization’s management class. This integration will impact their understanding of software delivery as a CAS and promote the foundation of actions for change as a continuous and sustained improvement journey towards organizational efficiency. Additionally, validating the proposed KPIs will help measure organizational efficiency through outcomes and business impact, ensuring that change actions are increasing both the robustness and resilience of the SoW as a CAS.