Contextual Scaled Agile
SUBMITTED IN PARTIAL FULFILMENT FOR THE DEGREE OF MASTER
OF SCIENCE
Anouk Cederboom
4132211
Master Information Studies
Information Systems
Faculty of Science
University of Amsterdam
3th of July 2019
1stExaminer
Dhr. Drs. A.W. (Toon) Abcouwer Faculty of Science. Informatics Institute
2ndExaminer Ms E. (Emoke) Takacs Faculty of Science. Informatics Institute
ABSTRACT
To select a new software development model for a large organ-isation, a combined model of the Cynefin framework and the Adaptive cycle of resilience was created. Several scaled agile frameworks, like DAD, SAFe and LeSS were arranged in the different contexts of the combined model, using the character-istics of these contexts. Choosing a scaled agile framework can be done based on the context an organisation resides in, but this paper shows that organisations do not actually do this yet. Interviews with representatives show that the characteristics of the combined model, for example the state of mind and the decision-making approach, are not necessarily aligned. In ad-dition, the findings show that the placement of a scaled agile framework based on literature is different when the placement is done by experts in scaled agile frameworks. The main reason for the different placement is the perspective the expert uses to place the scaled agile. The background of all experts is the same, which is why future research could diversify the background of the expert to see if it leads to different results. Furthermore, future research can be focus on more scaled agile frameworks to develop the combined model.
KEYWORDS
Cynefin framework, Adaptive cycle, Scaled Agile Frameworks, software development processes
1
INTRODUCTION
Organisations are in an ongoing movement in which they move between different organisational contexts [2]. Each organisa-tional context demands a different approach towards the solving of potential issues and for decision-making [2, 35, 42]. It is there-fore important to have a software development process that not only suites an organisation, but also suites the context in which an organisation resides. The software development process of an organisation can be defined as a series of steps needed to develop or maintain the software of an organisation [10]. This definition is similar to the goal of the frameworks, methods and methodologies that are based on the Agile Manifesto [7]. They also represent a series of steps needed to develop or maintain software [10]. It is therefore that in this paper Agile frameworks, methods and methodologies are seen as software development processes.
Adopting an Agile software development process has become more and more popular with organisations due to the successful implementations in organisations, flexibility, increased produc-tivity and the ability to manage changing priorities amongst oth-ers [18, 21, 39]. With the introduction of scaled agile frameworks larger organisation could also adopt one of the Agile software development processes [4]. However, choosing an Agile frame-work that fits with an organisation remained a complex process for an organisation [40].
Choosing a software development process can be complex for an organisation due to the complexity of an organisation. One way in which complexity can be defined is as a system with numerous interactions amongst individual components and between components and the entire system, also known as emer-gent behaviour [11, 17]. By taking a holistic approach and seeing an organisation as a system, in which emergent behaviour occurs, it becomes possible to classify the components of an organisation [12, 29]. One approach to classify an organisation is by using
the decision-making framework, the Cynefin framework. At the same time the Cynefin framework can help an organisation with choosing a software development process [27, 29]. Another ap-proach of choosing a software development process is by looking at the different factors that describe an aspect of an organisation [40]. Factors like organisational dynamics, dynamic capabilities, culture, company size, number of employees and/or industry can be used to choose a software development process as an organisation [10, 29, 40].
In this paper, the approach chosen for selecting a software development process is a combination of the Cynefin framework and the factor organisational dynamics. To address the factor organisational dynamics of an organisation the Adaptive cycle of resilience is used [2]. Research, however, doesn’t show how choosing a software development process can be done with the Cynefin framework nor does it show how organisational dynam-ics and the Cynefin framework can be used to choose a software development process. It is, therefore, that the aim of this research is to explore if the combination of the Cynefin framework with the Adaptive cycle of resilience can lead to an arrangement of different software development processes through a mapping.
To be able to create the mapping a set of research questions has been formulated.
Main Research Question How can large-scale agile devel-opment processes be arranged using decision-making ap-proaches and organisational dynamics?
To help answer the main research question the following sub-research questions have been formulated:
SQ1 What is scaled Agile?
SQ2 How are software development processes connected to a decision-making framework and organisational dynamics?
SQ3 Based on what factors can software development processes be mapped?
This paper is structured as follows. First, related work is in-troduced. Then, the method and validation of this paper are explained. Next, the results are discussed. In addition, the short-comings of this research are displayed in the discussion. Further-more a conclusion based on the results was written. Last, future work is discussed.
2
LITERATURE REVIEW
Understanding the different types of behaviours, that are part of complexity, in a system requires knowledge and an under-standing of the relations amongst the components and the entire system [11, 17]. Models that look at the behaviour amongst components in a system and the entire system, from an organ-isational perspective, are the Adaptive cycle of resilience and the Cynefin framework [2, 24, 35]. Both the Adaptive cycle of resilience and the Cynefin framework have in common that they look at the cause-and-effect relations between different com-ponents which can be traced back to the fundamental work of Thompson [38]. In his work Thompson [38] explains that deci-sion issues always involves the two basic variables of decideci-sion: ’beliefs about cause-and-effect relations’ and ’preferences re-garding possible outcomes’. The two basic variables of decision were combined in a model with each variable forming one of the axes. Both axes were then split up into certain(ty) and un-certain(ty) which resulted in the four different types of decision
issues: computational strategy, judgmentally strategy, compro-mise strategy and inspirational strategy. All four decision issues require a different strategy to make a decision, as the relations be-tween cause-and-effect are different [38]. The relations bebe-tween cause-and-effect are also used both the Cynefin framework and the Adaptive cycle of resilience. It is, therefore, that, in this paper, the Adaptive cycle of resilience and the Cynefin framework are used to address complexity in organisations. In addition, research regarding scaled agile framework and the comparison of scaled agile frameworks are addressed. Finally, the theoretical model of this paper is described.
2.1
Organisational dynamics
As mentioned before, organisations are in an ongoing move-ment. The ongoing movement that organisation endure can be explained by using organisational dynamics. Organisational dy-namics describe two aspects within an organisation [1]. The first aspect describes the ongoing process of strengthening resources and improving the performances of employees. The second as-pect is the manner in which an organisation manages and advo-cates organisational learning, improved business practices and strategic management. The dynamics in an organisation undergo changes, for example, as a result of trying to stay ahead of the competition or aiming to be flexible enough to make on the go changes [19, 36]. During the process of changing dynamics it is possible that an organisation has to deal with risk manage-ment and has to make decisions on how to deal with emerging challenges [28, p. 1672]. The challenges an organisation possibly faces can be well or ill defined. The challenges can be categorised into certainty, risk, and uncertainty. If a challenge falls under the category certainty, all taken actions lead to an assured out-come. When a challenge is categorised as risk all outcomes, and also the likelihood of each outcome, are known. If a challenge is categorised as uncertainty, the outcomes are known but their likelihood is not [28, p. 1672].
Figure 1: The adaptive cycle of resilience showing differ-ent dynamical phases of an organisation [2]
The challenges an organisation faces can change the dynamics of an organisation. Dynamics of an organisation can be described through the adaptive cycle of resilience model [2]. The adaptive cycle of resilience model uses two axeswant and can. The x-axis want describes where an organisations desires to go and the y-axiscan describes the ability to actually facilitate the direction (see Figure 1) [2]. The axes of the adaptive cycle are further di-vided into thecertain and uncertain which describe the certainty
of the context. In the adaptive cycle an organisation goes through the four quadrants Equilibrium, Crisis, New combinations and Entrepreneurship.
It is assumed that an organisation starts in the Equilibrium quadrant where the relationship between cause-and-effect are known, there is a chase for efficiency, preservation and improve-ment on the market, and problems are resolved by approximately the same approach as previously used. In an Equilibrium there is certainty and the state of mind is described as confidence in the present and the past [2].
At some point, an organisation unavoidably ends up in a crisis situation, in the model referred to as the "Crisis" quadrant. A Crisis arrives suddenly and has a huge impact on the organisation leading to changes. In a Crisis the approaches and tools used in the past no longer work to resolve the current problems. In a Crisis an organisation needs to find a solution for the challenges the organisation undergoes by actively looking for innovation. The state of mind in a Crisis is described as insecure about the present and (curious about) the future [2].
At some point the research and innovation done in the Cri-sis context lead to multiple new combinations out of which the organisation can choose. The organisation has found possible solutions to the challenges it faces, but still doesn’t know what it wants, it has moved on to the New combinations quadrant (see Figure 1). When in the New combinations context, an organisa-tion is looking for obtaining experiences and in the end has to make a choice which new combination works best. The choice is made by developing the new combinations through experimen-tation and testing. The state of mind of the New combinations context is described as being hopeful about the future [2].
If an organisation knows what it wants, through its vision and objectives, is fast growing and/or scaling up and has an understanding of the relation between cause-and-effect it finds itself in the Entrepreneurship quadrant (see Figure 1). In the Entrepreneurship context there can still be some uncertainties regarding what the organisation can do. An organisation in the Entrepreneurship context is developing a new business-as-usual situation and finds itself a new equilibrium. The state of mind in the Entrepreneurship context is described as confidence in the present and future. At the point where an organisation stops improving their organisation it is back in the "Equilibrium" quad-rant. An organisation can go through all four quadrants of the adaptive cycle and is always moving from one to another quad-rant. It is, therefore, that the motion through the adaptive cycle is illustrated through a lemniscate. The adaptive cycle of resilience describes the organisational dynamics of an organisation by explaining the different phases organisations experience [2].
2.2
Cynefin Framework
The decision-making framework, the Cynefin framework, can help executives comprehend complex concepts, bring a new view-point, and help to address real-world problems and opportunities [24, 35]. The Cynefin framework uses the three domainsOrdered, Unordered and Disorder to explain the issues leaders face. The three domains have been defined using the relations between cause-and-effect of an issue or problem. The domains Unordered and Ordered can each be further split up in to sub-domains (see Figure 2). The Disorder domain is placed in the middle of the Ordered and Unordered domains. It is hard to say when an organ-isation finds itself in the Disorder domain. What is clear in the Disorder domain is that there are multiple perspectives which all are trying to outdo each other. The approach to get out of the Disorder domain is to break the issues and decision up into
the four sub-domains of the Ordered and Unordered domains. From that point on, depending on the domain, a strategy can be chosen to solve the issue(s) or make the decision(s).
Figure 2: The five domains of the Cynefin framework and how to respond on an issue or decision in each domain [35]
The Ordered domain is split into the sub-domains Simple and Complicated (see Figures 2). The Simple domain can be characterised by the balance and apparent cause-and-effect re-lationships that can be distinguished easily by everyone. Often in the Simple domain there is a right answer that is self-evident and undisputed which is why the Simple domain resides in the "known knowns" context. The leadership style for the Simple domain is described as being straightforward where leaders have to sense, categorise and respond to situations.
Unlike the Simple domain the Complicated domain can con-tain several right answers and while there is an apparent rela-tionship between cause-and-effect this relarela-tionship is not clear for everyone. Due to the fact that the relationship is not clear for everyone the Complicated domain resides in the context of "known unknowns". In the Complicated domain the leadership style is described as having to sense, analyse and respond to situations.
The Unordered domain has the two sub-domains Complex and Chaotic (see Figures 2). In the Complex domain, unlike in the Complicated domain, it is not possible to find out the right answers. As there are many different questions with many differ-ent answers the relations between cause-and-effect are unclear at first. In retrospect it is easier to identify the relation between cause-and-effect. Therefore, the Complex domain resides in the "unknown unknowns" context. Leaders in a Complex domain have to patiently wait until a solution emerges and can best probe first, then sense and then respond [24, 35].
In the Chaotic domain the relationship between cause-and-effect is impossible to figure out due to the regularly changing nature of them. It is therefore that searching for answers in a Chaotic domain is useless and that the Chaotic domain resides in the "unknowables" context. Leaders whose organisation are in the Chaotic domain can best act first, then sense and then respond.
An organisation can move between all the different domains mentioned above. There is no set movement between the dif-ferent domains in the Cynefin framework nor is there a certain duration for an organisation to stay in a specific domain. The Cynefin framework helps organisations to identify the domain
they are in and make decisions according to the domain the organisation finds themselves in. Knowing in which domain an organisation finds themselves helps with recognising pat-terns in the organisation, creating new patpat-terns and developing strategies.
2.2.1 Connections and strengths of Cynefin framework. A dif-ferent way of looking at the Cynefin framework can be done through types of component connections which are common in each domain (see Figure 3). The component connections de-scribe how strong or weak the connections between a central director and underlying teams are and how strong or weak the connections between the underlying teams themselves are [24]. In the ordered side of the Cynefin framework the connections between a central director and underlying teams are described as being strong. The strong connection often comes in the form of structures that have a constrain in the behaviour of underlying teams, for example, through procedures, forms or expectations. On the Unordered side the connections between the central di-rector and underlying teams are deemed weak. In the Unordered side attempts at control are made through structure, but these often fail due to lack of grasp or visibility. The complex and com-plicated domains have strong connections between underlying teams in common. The result of the strong connection amongst underlying teams is that stable group patterns can arise and withstand change through repeated interaction. On the other hand the simple and chaotic domains have in common that the connections amongst underlying teams is weak and that group patterns do not arise on their own (see Figure 3). Depending on the domain, knowing the strengths of the connections can help shape the strategy of an organisation. Shaping the strategy of an organisation in a domain can be done by using the stability of the strong connections, whilst having them remain flexible, and by using the freedom that comes with the weak connections as an advantage [24].
Figure 3: The connections strengths and distribution be-tween teams and central according to the Cynefin frame-work [24]
2.2.2 Boundaries between the Cynefin domains. The different domains in the Cynefin framework are divided by boundaries. The boundaries in the Cynefin framework indicate that there is a difference between the domains and that organisations can move between the different domains [16, 24]. It is important to know what the boundaries are and when an organisation has crossed one. The crossing of a boundary requires a shift in the
interpretation of the domain of an organisation, as well as a different leadership style. The Cynefin framework has has four boundaries: the Simple-Complicated, the Complicated-Complex, the Complex-Chaotic and the Chaotic-Simple boundary. Among the different boundaries in the Cynefin framework ten differ-ent movemdiffer-ents of crossing one or more boundaries have been identified. When an organisation is aware of the boundaries in the Cynefin framework, the organisation can raise awareness of how they want to approach the crossing of a boundary and respond to the change in domain. In addition, an organisation who is aware of the boundaries can manage the perceptions of crossing a boundary and in which manner the organisation crosses the boundary [24]. The benefit of having the knowledge about the different boundaries in the Cynefin framework is that the decision-making process and response to rapid change(s) increases and becomes more effective [16].
2.3
Scaled Agile Frameworks
Scaled agile can be defined as a software development process in an organisation, or the part of the organisation that devel-ops software, with 50 people or more or at least six teams [14]. This means that also organisations whose focus is not primarily on software development, but do have a software development department are also considered. In addition, the people who are contributing to the development of software do not have to be software developers other roles like Product Owners, Scrum masters and others are also included in the sum of 50 or more people.
With the introduction of scaled agile frameworks it became possible for larger organisations to make agile scalable, but the challenge of adopting agile in larger organisations remained [14]. There are several reasons why the implementation of a scaled agile framework can be challenging. Challenges can, for exam-ple, be the culture of the organisation being at odds with the principles of a scaled agile framework, finding it complex to im-plement scaled agile due to the dependencies between teams and projects in an organisation and/or resistance to change within the organisation [14, 39]. Other reasons that made the adoption of Agile in large organisations complex are the organisation not being fully Agile (yet) and the interaction between parts of the organisation that are not (yet) Agile, for example, the human resources department of an organisation. As a result the scaled agile frameworks are adjusted to the needs of an organisation [5, 14, 15].
In the last few year more and more scaled agile frameworks like Disciplined Agile Delivery (DAD), Large Scale Scrum (LeSS), Spotify model, Nexus and Scaled Agile Framework (SAFe) have been developed. Some of these scaled agile frameworks were adopted more than others with the aim of to overcome the is-sues that initially presented themselves for larger organisations who wanted to become Agile and to provide a full end-to-end life-cycle for large organisations [3, 13, 39]. There are differ-ent approaches to comparing the scaled agile frameworks. One approach is to start of with a list of criteria, for example, the "degree of flexibility" and the "underlying Agile method" which are described for each scaled agile framework in the compari-son. Then, where an other comparison approach starts, a more in-depth review of each scaled agile framework is made by look-ing at the roles, practices and meetlook-ings/moments as they are described in the guide of a framework. By looking at the roles, practices and meetings/moments the similarities and differences between the different frameworks are put forward[3, 13]. The differences between the scaled agile frameworks were found in
team size, methods and practices adopted, technical practices, type of organisation, training and certification [3].
2.4
Categorising software development
processes
The Cynefin framework can be used to understand in which domain an organisation resides and through that find a suit-able which software development process for an organisation [25, 29, 31, 33]. Through the combination of the characteristics of the different domains, the relations between cause-and-effect and the (best) practices of the software development processes a categorisation of Agile frameworks was made [31, 33]. It has been found that Agile is most effective in the Complicated and plex domain and in the boundaries between Complicated, Com-plex and Chaotic of the Cynefin framework [9, 16, 41]. The Simple domain has been described as consisting of "known knowns" where problems and issues are resolved by using known solu-tions. It is, therefore, that an Agile approach is not needed in the Simple domain rather a waterfall approach would be more effective [16]. The Chaotic domain, on the other hand, has been described as being open for new possibilities and innovation [24, 37]. Agile can be used to help with innovation in an organi-sation [6, 32] and therefore the Chaotic domain would also be suitable for Agile.
2.5
Theoretical Model
The two models, the Cynefin framework and the Adaptive cycle of resilience, as described above can be combined through the cause-and-effect relations as described in both models to form one model [37]. With the combination of the Cynefin framework and the Adaptive cycle of resilience the organisational dynamics of an organisation are described alongside the decision-making context of an organisation.
Furthermore, as research [27, 29] has shown that the Cynefin framework can be used to select a suitable software development approach. It is, therefore, that the combination of the Cynefin framework and the Adaptive cycle is used to create a mapping scheme for the selected software development approaches. How-ever, the Disorder domain from the Cynefin framework the dis-order domain is not included in this research due to the nature of the Disorder domain. The focus of this research is on the on the Ordered and Unordered domains of the Cynefin framework, in combination with the organisational dynamics as described in the Adaptive cycle of resilience. The contexts and domains are combined as follow: Simple domain and Equilibrium context, Complicated domain and Entrepreneurship context, Complex domain and New combinations context, and Chaotic domain and Crisis context. In addition, the connections and strengths from the Cynefin framework were used to make a mapping of the different software development processes.
The software development processes were chosen randomly, but had to be able to give structure to at least six teams or 50 or more people in an organisation. The chosen software devel-opment processes used for the mapping are Disciplined Agile Delivery (DAD) [26], Large Scale Scrum (LeSS) [8], Large Scale Scrum Huge (LeSS Huge) [8], Spotify model[22, 23], Nexus [34], Scaled Agile Framework (SAFe) [20], and Waterfall [30].
3
METHODS
Most questions asked at the start of this research have been answered by combining researches. The answers led to a map-ping of different scaled agile frameworks using organisational dynamics and the Cynefin framework. To be able to validate
the initial mapping a qualitative research has been performed to answer the questions that stayed unanswered after the literature review. The qualitative research is divided up into thinking aloud sessions and interviews with organisations who work according to a scaled agile framework and who’s software department has at least 50 or more people or six teams. This section is struc-tured by first explaining the mapping of the different scaled agile frameworks. Then, the validation method of this paper is explained.
3.1
Mapping of scaled agile frameworks
based on literature
The basis of the mapping is formed with the combination of the Cynefin framework and the Adaptive cycle of resilience, as de-scribed in section 2.5, as the basis of the model. From now on the combination of the Cynefin framework and the Adaptive cycle of resilience is referred to as the combined model. The selected software development processes DAD, LeSS, LeSS Huge, Spotify model, Nexus, SAFe and Waterfall were placed in the combined model. To be able to place the software development processes in the different areas of the model (see Figure 4) the charac-teristics of the software development processes were used as factors for mapping. The characteristics of the software develop-ment processes that were used are the roles, artefacts, processes, meetings, practices and connections between teams, artefacts and roles. By using the characteristics of the software develop-ment processes the software developdevelop-ment processes could be connected to the characteristics of the different contexts in the combined model. The reasons for the placement of the software development processes are slightly different from one another. Although the Complicated-Entrepreneurship, Chaotic-Crisis and Complex-New combinations contexts are the areas where Agile is placed according to literature, this literature was not followed whilst creating the mapping. The reasons behind the placement of the different software development processes (see Figure 4) are explained per software development process.
Figure 4: The combined model. A mapping of the selected software development processes in the combined Cynefin framework and Adaptive cycle of resilience model.
LeSS and LeSS Huge. A strong central and distributed con-nection has been created through the shared roles, artefacts, meetings and teams working on the same product. Where LeSS is for 2 to 8 teams, LeSS Huge is for 8+ teams. Within LeSS (Huge) there is a shared Product Backlog for the entire organisation out of which the different teams pull their work. It is possible within LeSS (Huge) that different teams also work closely together on the same part of the product. Compared to LeSS there is more than one PO in LeSS Huge to be able to accommodate the work for all teams in an organisation. It is, therefore, that both LeSS and LeSS Huge are placed in the Complicated-Entrepreneurship context
Nexus. is based on Scrum, but then scaled to fit three to nine teams who are all working from the same Product Backlog. There is one Product Owner (PO) who is responsible for the mainte-nance of the Product Backlog. At the same time the PO is also the person who has the final say about the work that is placed in the Product Backlog. For all teams to be able to collectively work with each other the meetings before, during and after an iteration are done with all members of the teams or, in some cases, representatives of the teams. The result of combined meet-ings between representatives or all members of the teams leads to a stronger connection between the different teams. In addi-tion, due to the role of the PO and the connections the PO has with the teams and the stakeholders, the central connections in the organisation become stronger. It is, therefore, that Nexus is placed in the Complicated-Entrepreneurship context.
SAFe. has been made in a way that lots of different types of organisation can adopt it in their organisation, as it comes in four different varieties. The different layers in SAFe, also known as levels, resemble the different layers in an organisation and all have a strong connection. Between the different levels, there are several roles, meetings and (overlapping) artefacts which enforce the central connection within SAFe. All the teams on the lowest layer have the option to choose either a ScrumXP or a Kanban approach as the software development process. On the higher layers the teams have a Kanban process. Besides a different soft-ware development approach, the ScrumXP approach also comes with the roles PO, Scrum master and Development team which is not the case for Kanban where it is just a team. Regardless of the chosen approach, all teams are combined through the Agile Release Train (ART). The ART exists of stakeholders and Agile teams who together develop, implement, deploy and operate one or more solutions in a fixed schedule. Depending on the imple-mentation of SAFe the connections between the different teams in a layer is either strong or weak. The connection between the different layers in SAFe is, however, strong. It is, therefore, that SAFe can be placed in both the Complicated-Entrepreneurship and the Simple-Equilibrium contexts.
DAD. has five different, so-called, lifecycles that a team can follow and a program lifecycle that allows an organisation to use DAD as a scaling method. To map out DAD over the combined model (see Figure 4) the approach has been chosen to separate all five lifecycles from each other and treat them as if an organ-isation would only implement one of the five basic lifecycles throughout the entire organisation alongside the program lifecy-cle. The reason this approach was chosen is due to the differences between the lifecycles which could result in different processes and dynamics between teams and in an organisation [26]. The reasons for placing the lifecycles in a certain context are the following.
• TheContinuous Delivery: Agile and Lean lifecycles Both Continuous Delivery (C.D.) lifecycles were placed on the Ordered side, in the Complicated-Entrepreneurship and Simple-Equilibrium contexts. The Simple-Equilibrium context is chosen as the processes are kept roughly the same each iteration and there is a streamlined process with frequent, continuous results for stakeholders in place. On the other hand, the Continuous Delivery lifecycles also en-ables teams to hand over work fast to stakeholders which allows them to learn from the progress they have made. It is therefore that the Continuous Delivery lifecycles also can be applied in the Complicated-Entrepreneurship con-text.
• TheAgile lifecycle is similar to Scrum. The Agile life-cycle allows teams to enhance existing features or create new features. Through this practice the (sub)teams using the Agile lifecycle can apply the probe-sense-respond ap-proach when faced with issues. This apap-proach is used in the complex context of the Cynefin context and it is there-fore that the Agile lifecycle fits within the Complex-New combinations context.
• Thelean and exploratory lifecycles aim to only work on items when the capacity is available and do not have meetings as described in the Agile lifecycle if it is not necessary. The lean and exploratory lifecycles allow the (sub)teams to take an experimental approach, for example, to see if a new feature works or not. In addition, lean and exploratory lifecycles enable (sub)teams to work on a project without knowing all the specifications up front. It is, therefore, that the lean and exploratory lifecycles can be used in the Complex-New combinations and Chaotic-Crisis contexts.
The Spotify model. has loosely coupled and tightly aligned teams, also named squads, who can operate autonomously. Each squad works on their own part of the product, but it is possible that squads use the work of other squads to improve the product. Besides working on the same product the different squads are also connected through the release train which enables teams to deploy their work. Another aim of the Spotify model is to have a loosely coupled central connection to enable squads to be autonomous in the development of software. In addition, it is encourage to organise, so-called, hack days or hack weeks in which squads experiment and create or improve a feature. It is, therefore, that the Spotify model is placed in the Complex-New combinations and Chaotic-Crisis contexts as it can be both certain and uncertain what an organisation can do but not certain what an organisation wants.
Waterfall. is a software development process in which a project has been designed and given requirements in a way that almost all uncertainties have been removed at the start of the project together with stakeholders. The Waterfall approach is also know for its set planning and known project duration in which software is developed. At the end of the project the stakeholders are consulted to see if the outcome of the project is also the expected result. It is, therefore, that the Waterfall approach has been placed in the Simple-Equilibrium context as it is clear what is wanted and what is possible.
3.2
Validation of mapping
The validation of the mapping was done in two different manners, which took place simultaneously. The first validation method was semi-structured interviews with organisations who were
either working with or transitioning to a scaled agile framework in their organisation. The only other requirement that was set for the interviewed organisations was that the software devel-opment department of the organisation needed to have 50 or more people or at least six teams. The semi-structured interview was structured using the contexts from the Adaptive cycle of resilience as guidelines. The questions in the semi-structured interview were divided into the topics General, Context of the organisation, Old situation, Chosen Framework, Implementation of the framework, and After implementation. The aim of the dif-ferent topics was to find out what the decision-making context of an organisation is, what the organisational dynamics of the organisation look like and how the selecting and implementation process of the selected scaled agile framework was.
The semi-structured interview contained three multiple choice questions. Two of the multiple choice questions described the types of making approaches and characteristics of decision-making approaches as described in the Cynefin framework. The third multiple choice question asked the interviewee what the state of mind, as described in the Adaptive cycle of resilience, of the organisation or IT department was. In all questions, the domain and context names were removed to make sure that the interviewee wasn’t influenced by the names of the domains. Through the three multiple choice questions, an attempt was made to find out in which domain/context the organisation re-sides.
All semi-structures interviews were recorded and transcribed. The different topics of the semi-structured interview were used as labels. Next, as some labels were too general specific labels, for example, "expectations transition", "start implementation", "hybrid model", and others were created. The specific labels were then used to label the answers of the interviewees. All the answers of the interviewees, based on the corresponding label, were then placed in a table.
The goal of the semi-structured interviews is to see if the organisational dynamics and the decision-making process of an organisation can indicate in which context of the combined model an organisation resides. By looking at the scaled agile transition of an organisation, an attempt for finding out the reasons for the change in software development processes and if the transition was successful was made.
The second approach of validating the created mapping was through so-called experts. The experts, in this case, were people who had a certificate in one or more of the selected software development processes or who possessed knowledge about one or more of the selected software development processes. Before each thinking aloud sessions started the expert was given an explanation of the Cynefin framework and the Adaptive cycle of resilience as presented in Figures 1, 2 and 3. To make sure that the Cynefin framework and the Adaptive cycle of resilience were clear two examples of organisations, Eastman Kodak Com-pany and Nokia Corporation, were given to the expert. Then the experts were presented with a list of the selected software de-velopment processes and they were asked to fill in the software development processes which they knew. If the expert indicated that they were unfamiliar with a software development processes or didn’t know that much about the software development pro-cesses it was not included as part of the results. The aim of the thinking aloud sessions was to use the knowledge of the experts on software development processes to gain a new, maybe missed, perspective on the placement of a software development process in the combined model.
Using these two different approaches an attempt was made to validate the combined model (see Figure 4).
4
FINDINGS
In this section, the findings from the thinking aloud sessions with experts and the semi-structured interviews are discussed. First, the findings from the semi-structured interviews are presented and discussed in-depth. Next, the findings from the thinking aloud sessions are presented and discussed in-depth.
4.1
Results semi-structured interviews with
organisations
Eight representatives from different kind of organisations, who met the requirements (see 3.2), were interviewed. The representa-tives of the IT department of the organisation were interviewed, either face-to-face, by phone or over Skype. The telephone in-terview turned out to be incomplete and was therefore excluded from the results. The representatives were Release Train Engi-neers (RTE) or a manager/lead of the IT department. The IT department of the organisations varied from 50 to 60 people to an IT department of 800 to 850 people.
Two out of the seven organisations indicated that their or-ganisation has been divided into autonomous sections and that the IT department was further split into different divisions. Due to their autonomous nature, the organisations transitioned to a scaled agile methodology from an Agile methodology. As a result of the autonomous nature of both organisations, all IT divisions are free to choose their own software development process. It is for this reason that no conclusion was made for the entire organisation or the IT department of the organisation, but only the specific division of the representative. All other representatives were able to indicate how the decision-making processes and transition to a scaled agile framework went for the IT department, but not necessarily for the rest of the organi-sation. It is, therefore, that the following results represent the IT department of the organisation or a division of an IT depart-ment and not the organisation as a whole. Except for the two autonomous organisations all other organisations still have a combination, a hybrid model, between the software development processes Waterfall and the new software development process. Reasons for the hybrid models are IT projects which are more suitable for a Waterfall approach, the implementation of the new scaled agile framework is not finished yet and/or not all parts of the organisation can be structured according to the scaled agile framework due to the nature of the work.
Only in the case of one organisation, the transition towards the scaled agile framework was described as"organically evolved to the new software development process". According to the organ-isation, the transition evolved organically due to the culture of the organisation and the question to change from within the IT department. As for all other organisations, the results show that the transition started because the old software development pro-cess no longer worked for the organisation. The representatives indicated that the IT departments had problems with delivering work fast, delivering high-quality work, that the old software development process led to the segregation of teams in the or-ganisation and/or that the processes were too chaotic due to lack of structure. Based on these problems the organisations started looking for a framework that suited the organisation and the IT department. Some of the IT departments of the organisations chose a version of SAFe to structure their software development process. Other IT departments of organisations created their own scaled agile framework based on an existing framework. The IT departments who created their own scaled agile frameworks did this by looking at the best practices of other frameworks, creating their own terminology, rules, meetings and/or functions.
Before transitioning to the scaled agile framework some of the organisation and/or IT departments set some expectations for when the framework was implemented. The expectations included delivering work faster, have a better structure in the IT department and/or organisation, have higher customer satisfac-tion and/or have a higher quality of work. The representatives whose organisation have been implementing the chosen frame-work for six months or longer indicated that some or all of the expectations that were set were also met. However, not all ex-pectations were met as not all organisation set up a structure to measure the expectations (yet) and compare them to the old situation.
The organisations took similar approaches of starting the im-plementation of the scaled agile framework. Employees were trained in the scaled agile framework and received either inter-nal or exterinter-nal Agile coaching. In some cases, the organisations had to create or reassign new functions and/or roles within the organisation to be able to work according to the chosen scaled agile framework. While implementing the scaled agile frame-work, the organisations ran into different kind of problems. The problems the organisations faced, varied from employees having trouble with the process changes, culture changes as a result of the transition, setbacks from having a hybrid model, issues with alignment to parts of the organisation who follow a different software development process, issues with leadership style, push backs from the top of the organisation and/or keeping up busi-ness as usual whilst implementing the scaled agile framework. As far as the interviewees could tell most of the problems were (partly) resolved.
Based on the results it can be said that decisions are made throughout the organisation. The decisions are either made on a specific organisational layer, strategic, tactic or operational, or they are made as low in the organisation as possible. All representatives indicated that the top of the organisation sets a vision for the IT department, but how the vision is implemented is done by the IT department. The representatives indicated that the IT departments deal with different types of decision-making approaches depending on the context and subject of a decision. In addition, the results showed that the contexts of the state of mind, decision-making approach and decision-making pro-cess of the IT departments don’t nepro-cessarily match. Five out of seven representatives chose, without knowing, the same context for the decision-making approach and decision-making process. However, when choosing a state of mind for the organisation they ended up choosing an opposite state of mind. For exam-ple, two representatives indicated that both the decision-making approach and decision-making process were in the Complicated-Entrepreneurship context. The same two representatives indi-cated that the organisations state of mind was between the Chaotic-Crisis and the Complex-New combinations contexts. This can be explained through the length of the scaled agile tran-sition, the hybrid model the organisation follows or the problems the organisation faced during the implementation.
4.2
Findings of thinking aloud sessions with
experts
The experts in this research were (senior) consultants from the same consultancy firm. Despite the fact that the experts all work for the same consultancy firm, they all have a different back-ground ranging from business to development. A total of seven experts participated in this research. The experts have between three and eleven years of experience in consultancy geared to-wards software development processes. Some of the experts also
Simple-Equilibrium Complicated-Entrepreneurship Complex-New combinations Chaotic-Crisis
Expert 1 LeSS Huge, SAFe LeSS, Spotify LeSS, Nexus, Spotify LeSS, Waterfall
Expert 2 Waterfall Spotify LeSS, SAFe, Spotify LeSS, SAFe
Expert 3 LeSS, SAFe LeSS, SAFe Spotify Waterfall
Expert 4 SAFe Waterfall
Expert 5 SAFe, Waterfall Agile lifecycle, Lean lifecycle, Spotify
Agile lifecycle, Exploratory lifecycle,
Lean lifecycle, Spotify Lean lifecycle
Expert 6 Waterfall SAFe, Waterfall LeSS Spotify,
Exploratory lifecycle Expert 7 Waterfall
Continuous Delivery Agile and Lean lifecycles, Agile lifecycle, Lean lifecycle, SAFe
Agile lifecycle, Exploratory lifecycle, Lean lifecycle, LeSS, Nexus, Spotify
Table 1: The placements of the software development processes in the combined model as done by the experts during the thinking aloud sessions.
had a certificate in one or more of the software development processes that were mapped out in the combined model (see Fig-ure 4). Similarities were found in the reasons for the placement of the software development processes by the experts. In the findings only the software development processes that the Ex-perts were familiar with and indicated to have knowledge about have been included in the analysis of the results. The experts were allowed to place a software development process in more than one context which is why a software development process can appear in several different contexts. The findings from the thinking aloud sessions are presented per software development process.
4.2.1 Reasons behind the placement of DAD. Two out of the seven experts knew DAD partially. Expert 5 knew the Agile, Lean and Exploratory lifecycles and Expert 6 knew the Exploratory lifecycle. Expert 7 knew the main points of all lifecycles in DAD and used that knowledge to place the lifecycles in the different contexts.
TheAgile lifecycle has been placed in the Complicated-Entrepreneurship context as it takes on the sense, analyse and respond approach. Furthermore, to reach its full potential the Ag-ile lifecycle is not suited in the Simple-Equilibrium context which is why it’s placed in the Complicated-Entrepreneurship context. The Agile lifecycle has also been placed in the Complex-New combinations context. The reason for the placement Complex-New combinations context is that an organisation who doesn’t know what they want but do know to a certain point what they can and is exploring is able to use the Agile lifecycle to do this. The probe, sense, respond approach can be applied in the Lean lifecycle according to the experts. Because of this the Lean lifecycle has been placed in the Complex-New combinations context. In the Chaotic-Crisis context organisations are uncertain about what they want or can. In the Chaotic-Crisis context, the Lean lifecycle can help with finding out what the organisation wants or can. Based on this reason Expert 5 placed the Lean lifecycle in the Chaotic-Crisis context. According to Expert 7, on the other hand, the Lean lifecycle reaches its full potential in the Complicated-Entrepreneurship context.
The work in the Continuous Delivery lifecycles is picked up quickly and put in production right away. In addition, the work is measured and done in short cycles which is done in both the Complex-New combinations and Complicated-Entrepreneurship contexts according to Expert 7.
Due to its experimental nature, the strong distribution amongst the teams and the weak central connection theExploratory lifecycle has been placed in the Complex-New combinations context by Experts 5 and 7. Due to the fact that the Exploratory lifecycle can help an organisation with trying something and
learning Expert 6 placed the Exploratory lifecycle in the Chaotic-Crisis context.
4.2.2 Reasons behind the placement of LeSS. LeSS has been placed in all four contexts by the Experts. The way an organ-isation implements LeSS, according to the experts, leads to a different outcome and therefore also a different usages. Based on Expert 3 LeSS has strong central connections between the top and the bottom of an organisation. Depending on the im-plementation of LeSS and the organisation using it, LeSS has either weak connections amongst teams and therefore LeSS is suited in the Simple-Equilibrium context. On the other side, if LeSS has strong connections between the teams LeSS is suited in the Complicated-Entrepreneurship context, according to Expert 3. According to Expert 1 and 2 LeSS is a framework that can be used to give structure to an organisation when they are in a crisis and want to leave a crisis. When the organisation leaves the Chaotic-Crisis context and is figuring out what it wants they can use LeSS in the Complex-New combinations context, accord-ing to Expert 1. In addition, the central connections in LeSS are seen as loosely coupled and the connections amongst the teams are strong which is why Expert 1, 6 and 7 placed LeSS in the Complex-New combinations context. Based on seeing organisa-tions using LeSS in the Complicated-Entrepreneurship context, Expert 1 placed it in that context.
4.2.3 Reasons behind the placement of LeSS Huge. Only Ex-pert 1 knew LeSS Huge ahead of the thinking aloud session. According to Expert 1 LeSS Huge is the implemented in an or-ganisation after the oror-ganisation used LeSS in the Complicated-Entrepreneurship context. LeSS Huge was placed in the Simple-Equilibrium context by Expert 1 as the organisation has grown and needs more structure then LeSS provides.
4.2.4 Reasons behind the placement of Nexus. Expert 1 and 7 both mentioned that Nexus is similar to LeSS, however, with a more formal description according to Expert 1. Both Expert 1 and 7 acknowledged the strong connection amongst the teams and weak, loosely coupled central connection in Nexus. It is, therefore, that Nexus has been placed in the Complex-New com-binations context.
4.2.5 Reasons behind the placement of SAFe. SAFe has been placed in all four contexts due to the different manners in which SAFe can be implemented in an organisation. In the Simple-Equilibrium context SAFe was seen as a structured framework which has a strong central connection, but weak distribution amongst the teams. Additionally in the Simple-Equilibrium con-text SAFe was seen as being used by organisations who have certainty in what they want and can.
Besides a strong central connection SAFe can also have a highly coupled connection amongst the teams, according to Ex-perts 3, 4, 6 and 7. For example, when different teams all work on the same product.
According to Expert 2, SAFe does have elements in it where structure is given to the company top-down, but tasks are per-formed on a decentralised level in the organisation leading to a weak central connection. It is, therefore, that SAFe has been placed in the Complex-New combinations context by Expert 2. The structure that SAFe provides can help an organisation in a crisis situation. It is, therefore, that SAFe has been placed in the Chaotic-Crisis context by Expert 2.
4.2.6 Reasons behind the placement of the Spotify model. All experts who has knowledge about the Spotify model agreed that the Spotify model is ideal for experiments in an organisation. According to Expert 6, a weak distribution amongst the teams and a weak central connection. In addition, the teams are given freeway to experiment which is why the Spotify model was placed in the Chaotic-Crisis context by Expert 6.
The connections in the Spotify model are seen as strongly distributed amongst the teams and weak in the central. It is therefore, that the Spotify model is placed in the Complex-New combinations context by Experts 1, 2, 3, 5, and 7. Although some-times depending on the implementation the central connections can also be strong and therefore the Spotify model is also placed in the Complicated-Entrepreneurship context by Experts 1, 2 and 5.
4.2.7 Reasons behind the placement of Waterfall. Waterfall has been placed in either the Simple-Equilibrium context or the Chaotic-Crisis context. Waterfall was placed in the Simple-Equilibrium context by some of the experts. According to those experts there are no uncertainties, everything about the project is already known and planned, and if a problem arises it is cate-gorised and resolved. However, other experts reasoned that all work in the Waterfall approach is already planned out ahead of time and all tasks are assigned to the different teams leading to weak central connections and weak connections between the teams. It is, therefore that some of the Experts placed Waterfall in the Chaotic-Crisis approach.
5
DISCUSSION
The validation through the thinking aloud session resulted in a variety of opinions from the perspective of people who have been working with different scaled agile frameworks. The different experts all presented their opinions and how they thought a software development process performs compared to another in organisations. During the thinking aloud sessions some of the experts also indicated that they had a preference for one of the frameworks compared to the others that were presented. The preference for a particular framework may have influenced the placement of the frameworks in the different contexts. In addition, the way in which the experts placed the frameworks varied based on knowledge from the field to based on the guides of the frameworks. The difference in the placement type by the expert could have had an influence in the outcome of the placement of the different frameworks. It is, therefore, that the knowledge an expert has should be tested or proven through a certificate ahead of the thinking aloud session. Furthermore it should be stated clearly that the placement of the frameworks is either based on knowledge from the field or knowledge based on the guides.
All experts asked for the thinking aloud sessions were (senior) consultants. As a result of the differences in years of experience and different background the findings that originate from the thinking aloud session ended up differently. However, in a future research it is advised to ask experts who have a different back-ground as this could lead to a different outcome in the findings. In general the semi-structured interviews with representatives went well. However, based on the results of the semi-structured interviews no conclusions can be drawn for the entire organisa-tion. The main reason for this is that the representative couldn’t speak for the entire organisation. Interviewing more employ-ees on different levels about the decision-making process of the organisation could resolve this issue.
6
CONCLUSION
This research explored if a mapping for software development processes could be created by creating a combined model of the Cynefin framework and the Adaptive cycle of resilience. The aim of the created mapping was to answer the main research question of this research"How can large-scale agile development processes be arranged using decision-making approaches and organisational dynamics?". To be able to answer the main research question three sub-research questions were formulated.
The answer to the first sub-research question,SQ1: "What is scaled Agile?", has been found in literature. Based on literature, large in scaled agile can be defined as a software development or-ganisation, or the part of the organisation that develops software, with 50 people or six teams. The literature study also showed that the Cynefin framework and the Adaptive cycle of resilience can be combined based on their cause-and-effect relations. The characteristics of the software development processes, for exam-ple, the roles, artefacts, processes and others can be combined with the characteristics of the combined model. It is, therefore, that the software development processes can be mapped out in the combined model. Which answers the second,SQ2: "How are software development processes connected to a decision-making framework and organisational dynamics?", and third, SQ3: "Based on what factors can software development processes be mapped?", sub-research questions of this research. The answers of the three sub-research question have led to the creation of a mapping of software development processes through the combination of the Cynefin framework and the Adaptive cycle of resilience, also known as the combined model.
Unlike the answers to the sub-research questions, the vali-dation of the mapping of the software models in the combined model couldn’t be addressed with a literature study. It is, there-fore, that an attempt to validate the mapping of the software development processes on the combined model has been done through the thinking aloud sessions and the semi-structured in-terviews. The results from the thinking aloud sessions show that the same software development processes are placed in the same and different contexts when compared to the mapping based on the literature study. Some of the results from the thinking aloud sessions support the placement of the same software de-velopment processes in the combined model. However, based on the results of the thinking aloud sessions it cannot be concluded if the mapping of the software development processes on the combined model is correct or not.
The results from the semi-structured interview showed that the decision-making processes and decision-making approaches don’t always match. In addition, when the decision-making pro-cesses and decision-making approaches do match they don’t
necessarily match with the current state of mind of an organi-sation. Reasons why the state of mind doesn’t match with the decision-making processes and decision-making approaches can be due to the usage of a hybrid model. The hybrid models, in this case, keep the employee(s) in both the old and new software development processes at the same time. This can lead to con-flicting approaches in the software development processes of an organisation. Another reasons for a different state of mind context can be the length of a scaled agile transition. If the tran-sition towards a new software development process just started the employee(s) can still lag behind in terms of mindset. Further-more, the results of the semi-structured interviews showed that the reasons for the change in software development processes vary, but mostly come down to the old software development process no longer working for the IT department. The old soft-ware department brought the IT department of an organisation problems and by transitioning to a new software development process the IT departments aimed to resolve the problems. In addition, all IT departments go through different setbacks during the implementation process of a scaled agile framework.
In conclusion, the answer to the main research question:"How can large-scale agile development processes be arranged using decision-making approaches and organisational dynamics?" is, it is possible to find a software development process by combin-ing the Cynefin framework and the Adaptive cycle of resilience through their cause-and-effect relations resulting in the com-bined model. The characteristics of the different contexts in the combined model can be used to analyse in which context an or-ganisation resides. Based on the results of the analysis a software development process that matches the context the organisation is in can be selected.
7
REFLECTION
In this research process, I learned that during the transition from one to another software development process all organisations encounter problems. In my opinion some of these problems, for example, misalignment between parts of the organisations and conflicting priorities could have been prevented. I also learned that looking at the context an organisation resides in, through organisational dynamics and the decision-making approach and process, provides a good overview of an organisation. However, the overview can become better when other factors describing an organisation, for example, the culture of an organisation, are also included. In addition, I think it is important to take the state of mind of an organisation into consideration when analysing an organisation. As the state of mind of an organisation can be in a different context than the decision-making approach and/or process. The difference in context between the state of mind and the decision-making approach and/or process could influence the leadership style of an organisation. Meaning, for example, that the followed software development process and the mindset of the employees are not aligned, yet.
Through this research, I attempted to contribute to both the research field and the practical field. Despite the fact that the validation of the research was not successful, I do think that I succeeded in proving that, depending on the context of an organisation, you can choose a software development process for an organisation. Which, in my opinion, makes not only the process of selecting a software development process but also the software development process itself contextual. In addition, this research adds that organisations do not only tailor the new software development process to their organisation they also often create a hybrid model by letting the old and new software
development processes co-exists in the organisation. Based on the problem that the organisations encounter due to the hy-brid model, I would recommend organisations not to let the old and new software development processes co-exist. Problems with misalignment between different parts of the organisation, conflicting priorities, conflicting leadership styles, and conflicts regarding the processes in an organisation can all be prevented by not letting the old and new software development co-exist in an organisation. When I look at the findings for the basis of the research, the combined model based on literature, I see it as successful. The foundation of the combined model was found in the literature and therefore has a strong fundamental. The vali-dation of this research, however, wasn’t as successful as initially planned.
8
FUTURE WORK
The findings in this research show that more research towards the topic of contextual scaled agile is needed. Further topics that can be looked into are, for example, the Disorder domain of the Cynefin framework or hybrid software development processes. In this research the Disorder domain of the Cynefin framework was not taken into consideration. It can, however, be interest-ing to do further research on this domain with the aim to find out what a suitable software development approach is for an organisation in the Disorder domain. Furthermore, the research as presented in this paper can be further developed by expend-ing the amount of scaled agile frameworks that are looked at in the research. More and more options for scaled agile frame-work solutions are being developed and the existing frameframe-works are continuously improved. Thus, the details of the scaled agile frameworks quickly change which also changes the way or-ganisations use the scaled agile frameworks. In addition, whilst validating the combined model the examined scaled agile frame-works should all be covered in either the thinking aloud sessions or through the semi-structured interviews.
In future research, different kind of experts, like Agile coaches, could be asked to give their feedback on the created mapping. The differences in the backgrounds of the experts could lead to a new perspective on the mapping. In addition, asking more and a variety of experts could lead to a better validation of the mapping. Furthermore, to end up with a better perspective on an organisation and thus make a better conclusion, more people of the same organisation should be interviewed.
Another interesting topic of research could be the usage of hybrid software development processes in an organisation. The results of the semi-structured interviews show that during the implementation of a new software development process the old software development process is followed alongside it. Future research could look at the potential downside and benefits of following a hybrid model as a software development process.
Last, a topic that can be researched is how and which parts of the leadership changes by transitioning towards a new software development process.
REFERENCES
[1] Human Resources M B A. 2016. What is Organizational Dy-namics? (2016). https://www.humanresourcesmba.net/faq/ what-is-organizational-dynamics/
[2] Toon Abcouwer and Bas Smit. 2015.Business IT alignment: A never-ending story. Technical Report. Working paper UvA. Universiteit van Amsterdam. [3] Mashal Alqudah and Rozilawati Razali. 2016. A Review of Scaling Agile
Methods in Large Software Development.International Journal on Advanced Science, Engineering and Information Technology 6, 6 (2016), 828–837. https: //doi.org/10.18517/ijaseit.6.6.1374
[4] Mashal Kasem Alqudah and Rozilawati Razali. 2017. Key factors for selecting an Agile method: A systematic literature review. International Journal on
Advanced Science, Engineering and Information Technology 7, 2 (2017), 526– 537.
[5] Julian M Bass. 2016. Artefacts and agile method tailoring in large-scale offshore software development programmes.Information and Software Tech-nology 75 (2016), 1–16.
[6] Mitch Beaumont, Ben Thuriaux-Alemán, Prashanth Prasad, and Chandler Hatton. 2017. Using agile approaches for breakthrough product innovation. Strategy & Leadership 45, 6 (2017), 19–25.
[7] Kent Beck, Mike Beedle, Arie Van Bennekum, Alistair Cockburn, Ward Cun-ningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, et al. 2001. Manifesto for agile software development. (2001). [8] The LeSS Company B.V. 2019. LeSS Framework. (2019). https://less.works/
less/framework/index.html
[9] Weng Tat Chan and Fengwei Ying. 2014. A social complexity approach to investigate trust in Agile Methodology.2014 17th IEEE International Conference on Intelligent Transportation Systems, ITSC 2014 117576 (2014), 172–177. https: //doi.org/10.1109/ITSC.2014.6957686
[10] Paul Clarke, Rory V O’Connor, and Brian Leavy. 2016. A complexity theory viewpoint on the software development process and situational context. In Proceedings of the International Conference on Software and Systems Process. ACM, 86–90.
[11] Shahram Mirzaei Daryani and Amir Amini. 2016. Management and Orga-nizational Complexity. Procedia-Social and Behavioral Sciences 230 (2016), 359–366.
[12] H William Dettmer. 2011. Systems thinking and the cynefin framework-A strategic approach to managing complex systems. Port Angeles, WA: Goal Systems International (2011).
[13] Philipp Diebold, Anna Schmitt, and Sven Theobald. 2018. Scaling agile: how to select the most appropriate framework. InProceedings of the 19th International Conference on Agile Software Development: Companion. ACM, 7.
[14] Kim Dikert, Maria Paasivaara, and Casper Lassenius. 2016. Challenges and success factors for large-scale agile transformations: A systematic literature review. The Journal of Systems and Software 119 (2016), 87–108. https: //doi.org/10.1016/j.jss.2016.06.013
[15] Torgeir Dingsøyr, Tore Dybå, Mette Gjertsen, Anette Odgaard Jacobsen, Tor-Erik Mathisen, Jan Ole Nordfjord, Kjetil Røe, and Kjetil Strand. 2019. Key lessons from tailoring agile methods for large-scale software development. IT Professional 21, 1 (2019), 34–41.
[16] Davide Fierro, Stefano Putino, and Lucio Tirone. 2018. The Cynefin Frame-work and Technical Competencies: a New Guideline to Act in the Complexity. InINCOSE International Symposium, Vol. 28. Wiley Online Library, 532–552. [17] DA Gkika, K Ovaliadis, N Vordos, and L Magafas. 2019. Managing complexity:
the case of nanomaterials.Journal of Nanoparticle Research 21, 1 (2019), 17. [18] Emam Hossain, Muhammad Ali Babar, and June Verner. 2009. Towards a
framework for using agile approaches in global software development. In International Conference on Product-Focused Software Process Improvement. Springer, 126–140.
[19] Roumiana Ilieva, Kiril Anguelov, and Mario Nikolov. 2018. A Cynefin Frame-work for Agile Decision Making of AI BOTS. In2018 International Conference on High Technology for Sustainable Development (HiTech). IEEE, 1–4. [20] Scaled Agile Inc. 2019. SAFe for Lean Enterprises. (2019). https://www.
scaledagileframework.com/safe-for-lean-enterprises/
[21] Martin Kalenda, Petr Hyna, and Bruno Rossi. 2018. Scaling agile in large organizations: Practices, challenges, and success factors.Journal of Software: Evolution and Process 30, 10 (2018), e1954.
[22] Henrik Kniberg. 2014. Spotify Engineering Culture (part 1). (2014). https:// blog.crisp.se/2014/03/27/henrikkniberg/spotify-engineering-culture-part-1 [23] Henrik Kniberg. 2014. Spotify Engineering Culture (part 2). (2014). https://
blog.crisp.se/2014/09/24/henrikkniberg/spotify-engineering-culture-part-2 [24] Cynthia F Kurtz and David J Snowden. 2003. The new dynamics of
strat-egy: Sense-making in a complex and complicated world.IBM systems jour-nal 42, 3 (2003), 462–483. http://vdc.edu.au/wp-content/uploads/2018/02/ Sense-making-in-a-complex-and-complicated-world.pdf
[25] Marion Lepmets, Rory V O’Connor, Aileen Cater-Steel, Antoni Lluis Mesquida, and Tom McBride. 2014. A Cynefin based approach to process model tailoring and goal alignment. In2014 9th International Conference on the Quality of Information and Communications Technology. IEEE, 166–169.
[26] Mark Lines and Scott Ambler. 2019. INTRODUCTION TO DISCIPLINED AGILE DELIVERY (DAD). (2019). http://disciplinedagiledelivery.com/ introduction-to-dad/
[27] MF Mikkelsen. 2016. How to Cope with Complexity?-a Review of Project Complexity Literature Using the Cynefin Framework as Theoretical Lens. (2016). http://www.novateam.dk/PDF/IRIS2016
[28] Shabnam Mousavi and Gerd Gigerenzer. 2014. Risk, uncertainty, and heuris-tics.Journal of Business Research 67, 8 (2014), 1671–1678.
[29] Rory V O’Connor and Marion Lepmets. 2015. Exploring the use of the cynefin framework to inform software development approach decisions. In Proceedings of the 2015 International Conference on Software and System Process. ACM, 97–101. https://doi.org/10.1145/2785592.2785608
[30] Kai Petersen, Claes Wohlin, and Dejan Baca. 2009. The waterfall model in large-scale development. InInternational Conference on Product-Focused Software Process Improvement. Springer, 386–400.
[31] Piyush Rahate. 2017. Stacey matrix and the complex domain. (2017). http: //www.piyushrahate.com/stacey-matrix-complex-domain/
[32] Darrell K Rigby, Jeff Sutherland, and Hirotaka Takeuchi. 2016. Embracing agile.Harvard Business Review 94, 5 (2016), 40–50.
[33] Anita Sagar. 2019. Choosing the Best Project Management Approach for Your Team: The Cynefin Framework. (2019).
https://enterprise-knowledge.com/choosing-the-best-project-management-approach-for-your-team-the-cynefin-framework .
[34] Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, and Gunther Verheyen. 2018. Nexus Guide. (2018). https://www.scrum.org/resources/nexus-guide
[35] David J. Snowden and Mary E. Boone. 2007. A leader’s framework for decision making.Proceedings of the 2007 IEEE Symposium on Computational Intelligence in Multicriteria Decision Making, MCDM 2007 85, 11 (2007), 267–271. https: //doi.org/10.1109/MCDM.2007.369449 arXiv:http://ehis.ebscohost.com/ [36] Hassan Soltan and Sherif Mostafa. 2015. Lean and agile performance
frame-work for manufacturing enterprises.Procedia Manufacturing 2 (2015), 476– 484.
[37] E Takács, A W Abcouwer, and O P Banga. 2019. Is there a need for a system approach for management , leadership and teams ? 1 (2019), 1–14. [38] James D. Thompson. 1967. Organizations in action; social science bases of
administrative theory. New York, McGraw-Hill.
[39] CollabNet VersionOne. 2019.The 13th annual state of agile report. Technical Report. 1–16 pages.
[40] Leo R Vijayasarathy and Charles W Butler. 2016. Choice of Software Devel-opment Methodologies: Do Organizational, Project, and Team Characteristics Matter?IEEE Software 5 (2016), 86–94.
[41] Mark Woodman and Aboubakr A. Moteleb. 2015. Grounding and Making Sense of Agile Software Development. Technical Report. 234–240 pages. https: //doi.org/10.5220/0002015502340240
[42] Brenda Zimmerman. 2001. Ralph stacey’s agreement & certainty matrix. Schulich School of Business, York University, Toronto, Canada, available on http://www. plexusinstitute. org/edgeware/archive/think/main_aides3. html (2001).
