Balancing between stability and change in Agile teams

Abstract

Purpose

This study aims to create a better understanding of how practitioners implement and work Agile while balancing the tensions arising between stability and change.

Design/methodology/approach

A grounded theory approach was used to explore what happens in practice when software development teams implement and work Agile. The empirical data consists of twenty semi-structured interviews with practitioners working in fourteen different organizations and in six different Agile roles.

Findings

As a result, a substantive theory was presented of continuously balancing between stability and change in Agile teams. In addition, the study also proposes three guidelines that can help organizations about to change their way of working to Agile.

Research limitations/implications

The inherent limitation of a grounded theory study is that a substantial theory can only explain the specific contexts explored in that study. Thus, this study's contribution is a substantial theory that needs to be further developed and improved.

Practical implications

The proposed guidelines can help organizations about to change their way of working to Agile. They can also assist organizations in switching from “doing Agile” to “being Agile”, thus becoming more successful.

Originality/value

The new perspective that this study contributes is the fact that our discovered categories show that several inherent processes are ongoing at the same time in order to balance the need to have both stability and change.

Citation

Lindskog, C. and Netz, J. (2021), "Balancing between stability and change in Agile teams", International Journal of Managing Projects in Business, Vol. 14 No. 7, pp. 1529-1554. https://doi.org/10.1108/IJMPB-12-2020-0366

Introduction

The interest in organizational agility (Holbeche, 2018) and utilizing Agile methods (Devedzic, 2010) to quickly respond to market changes, in order to remain competitive, has increased (Cooper and Sommer, 2016; Ganguly et al., 2009). By working in shorter sprints (Schwaber and Beedle, 2002), Agile makes it possible to rapidly introduce changes, e.g. to an innovation project. Although Agile originates from software development characterized by complex tasks and requirements and exhibits a high degree of changeability (Boehm and Turner, 2004; Leau et al., 2012), there is a growing interest in implementing it in “non-software development” settings (Papadakis and Tsironis, 2018). As a result, Agile is being implemented in growing numbers of “traditional” organizations (Kettunen et al., 2019), e.g. banking (Johnston and Gill, 2017), manufacturing (Eliasson and Burden, 2013) and the public sector (Wisitpongphan and Khampachua, 2016).

However, implementing Agile is not a straightforward process (Dingsøyr et al., 2012; Moe et al., 2012). Agile is described as being people-oriented (Cockburn and Highsmith, 2001) rather than process-oriented (Syed-Abdullah et al., 2006), which can lead to tensions. As with most social phenomena, tensions are hard to define because they cannot be observed directly. Thus, they are likely to be difficult to recognize empirically (Michaud, 2017). Yet, tensions exist in most everyday business practices (Papachroni et al., 2015). Raisch and Birkinshaw (2008) argue that all systems contain persistent tensions between exploiting and exploring, even though the members of an organization may only experience these tensions when being exposed to, for example, change or stress (Fairhurst et al., 2016). Exploitation draws on mechanistic structures, tight coupling, routinization, bureaucracy and stabilization (Lyytinen and Rose, 2006). Exploration, on the other hand, draws on organic structures, loose coupling, improvisation, chaos and emergence (Lyytinen and Rose, 2006). When there are tensions between exploiting and exploring, a winning strategy is being ambidextrous, i.e. having the ability to both exploit and to explore (Hughes, 2018).

Interest in the phenomenon of paradoxical tensions, as well as the strategy (ambidexterity) of dealing with these tensions, is increasing (Hughes, 2018) as more and more organizations are struggling to address rapidly changing environments (Cooper and Sommer, 2016; Farjoun, 2016; Pellegrinelli et al., 2015). This interest is also increasing within the context of Agile. Aghina et al. (2015) argue that Agile organizations, paradoxically, learn to be stable and dynamic. To master this paradoxical tension, organizations must have “a fixed backbone”, i.e. design structures and processes with a relatively fixed set of fundamental components, while also generating looser and more dynamic components that can be adapted rapidly to new challenges and opportunities (Aghina et al., 2015). Implementing and working Agile requires managing the tension between planning future work, based on a business need for stability and predictability, while simultaneously being flexible and changeable. Denning (2015), in turn, describes successful Agile organizations as “Being Agile” and not just “Doing Agile”. “Being Agile” is about embracing Agile values, principles and ways of thinking. Therefore, a successful transition to the Agile way of working requires a deeper understanding of the important Agile values and principles, with the special mindset that characterizes “Being Agile” also being needed (Denning, 2015).

In this paper, we investigate how Agile practitioners experience and balance tensions existing between stability and change, instead of treating the paradox perspective as a problem or a tool. Throughout this paper, the term tensions is thus used to denote paradoxical tensions defined as; “conflicting but still interrelated elements that exist simultaneously and persist over time” (Smith and Lewis, 2011, p. 386). Requirements for both stability and change, as well as this attitude to balancing tensions using the “both/and” perspective, leave several questions open: What are the concrete tensions that Agile team members are experiencing? In what ways are these tensions being experienced? Between which stakeholders do these tensions arise? To answer these questions, we need a holistic understanding of what it takes to become Agile and to work on an Agile team – an understanding that is based on both theory and empirical evidence.

This paper reports on a study of how practitioners implement and work with Agile methods while balancing the tensions arising between stability (exploitation) and change (exploration). Most of the empirical work done on ambidexterity has been at the organization level (Turner et al., 2013, 2016a). Hence, there are only a few studies that address the management measures applied to the day-to-day activities enabling ambidexterity, i.e. the balance between exploitation and exploration (Turner et al., 2016b). In the paper, a grounded theory approach is used which is based on interviews with twenty participants from fourteen different organizations (consultancies, government agencies, product development companies and banks).

The remainder of this paper is organized as follows: Initially, a frame of reference regarding previous research that includes previous, grounded studies in the field of Agile software development is provided. Following that, the research methods used are described, followed by the study's findings. Next, these findings are discussed in relation to related grounded theory studies, the limitations of the study and future work. The paper ends with a presentation of the conclusion drawn from the study.

The Agile way of working

The Agile way of working originates from a set of values and associated principles (also referred to as goals (Agerfalk, 2006; Karlsson and Ågerfalk, 2009) outlined in a declaration known as the Agile Manifesto (Beck et al., 2001). The Agile Manifesto was signed in 2001 by a group of consultants, researchers and practitioners. It contained four values and, in more detail, twelve principles aimed at providing better ways of developing software. The four central values formulated in the Agile Manifesto are listed in Table 1. Agile is, in other words, primarily a mindset; according to Denning (2015), this mindset is more important than any particular methodology, process, system, platform or organizational structure. He found that, where Agile methods were implemented without the essential Agile mindset, few benefits, if any, were observed (Denning, 2015).

When investigating the four values from the Agile Manifesto in Table 1, contradictions or tensions can be found, especially in value numbers 1 and 4: i.e. people vs. processes and in responding to change vs. following a plan (Wang et al., 2008). Wang et al. (2008) state that the existing Agile literature mainly adopts an “either/or” perspective on these paradoxes because Beck et al. (2001, p. 2) state: “While there is value in the items on the right, we value the items on the left more”. Instead of this perspective, Smith (2014) and van Bommel and Spicer (2017) argue that we need to shift the paradox perspective away from an “either/or” toward a “both/and” logic.

Agile practices aim to understand software development as an empirical process (Highsmith, 2002), and these practices are short iterations, continuous testing, self-organizing teams, constant collaboration (e.g. daily integration meetings and pair programming) and frequent re-planning based on current realities (Highsmith, 2002). O'hEocha et al. (2010) argue, further, that Agile practices cannot be “cherry-picked” without duly considering how they interrelate. For example, having stand-up meetings does not, in itself, imply that the team is Agile (O'hEocha et al., 2010). Instead, Agile should be implemented completely and should permeate the entire project organization (Moe et al., 2012; Schwaber and Sutherland, 2017), by involving people, roles and organizational structures, as well as working toward an understanding of the dependencies that exist between practices and how these works together (O'hEocha et al., 2010). In a similar vein, Denning (2015) argues that a deeper understanding of the important Agile values and principles is needed, as well as the particular mindset that characterizes “being Agile”. The Agile mindset, for many individuals and organizations, is a whole new way of thinking. Hence, it can be challenging to unlearn old, traditional practices and to move toward new ones (Thangasamy, 2012).

The annual “State of Agile” survey for 2020 (VersionOne, 2020) shows that Scrum is the most widely practiced Agile method or framework, with at least 75% of respondents working with either Scrum or a hybrid that includes it. The participants in this study are included in this category of Scrum users; thus, some important terms, concepts and specific roles, as described in The Scrum Guide (Schwaber and Sutherland, 2017), will be described in this section. The essence of Scrum is that work is conducted by a small team of people who are extremely flexible and adaptable (Schwaber and Sutherland, 2017). This team consists of three key roles: (1) product owner, (2) development team and (3) Scrum Master (Schwaber and Sutherland, 2017). The role of a product owner is being responsible for strategic decisions because he/she is the one who has a business perspective. In other words, product owners decide and prioritize “what” to do. But “how” the work is to be done is decided, in turn, by the development team. Members of the development team need to have a common understanding of both teamwork and the task and they are all equally responsible for the end product (Levesque et al., 2001). Leadership is shared, with members of Agile teams having substantially more control, in turn entailing that the “old” project manager's role has changed radically ((McHugh et al., 2011; Nerur et al., 2005). Self-management is, therefore, a key factor of Scrum, with the team being given both authority and responsibility as regards, for example, planning, the assignment of tasks to team members and decisions (Moe et al., 2010, 2012). Finally, the role of the Scrum Master is being responsible for promoting and supporting Scrum by helping everyone to understand Scrum and its practices, rules and values (Schwaber and Sutherland, 2017). A Scrum Master must also serve the team and prevent it from being disrupted (Noll et al., 2017; Schwaber and Sutherland, 2017). Because Agile teams are jointly responsible for the end product, it is important that team members are competent in a wide range of skills, as opposed to being an expert in only one area (Lee et al., 2006).

The Agile way of working is a social process; thus, it is crucial to develop organizational as well as individual trust, both within the teams and between these and the customers Chau et al., 2003). McHugh et al. (2011, p. 71) explain that: “Trust requires team members to believe that their colleagues possess the knowledge, competence, and integrity to complete their assigned tasks.” Additionally, McHugh et al. (2011) also emphasize that the product owner must trust the development team to do what it says it will do and that the development team must trust the product owner not to overburden the development team with work. Trust in Agile teams is particularly important for the sharing of tacit knowledge (Buvik and Tvedt, 2017). In the thesis by Buvik (2019), the concept of “swift trust” is discussed, i.e. a unique form of trust where individuals rely on defined roles rather than specific people. This is, furthermore, a form of trust that develops between groups or individuals brought together to accomplish specific tasks (Buvik, 2019). This means that trust requires team members to believe that their team partners possess the knowledge and integrity to complete their assigned tasks (Buvik and Tvedt, 2017).

Previous grounded theory studies in the field of Agile software development

To date, a growing number of studies focusing on Agile software development using grounded theory methods have been conducted. In Table 2 below, the nineteen studies that were found have been categorized on the basis of three closely-related themes, as mentioned in previous sections, i.e. transition, practice and roles. These themes refer to the transition from plan-driven methods to Agile methods, where Agile practices and Agile roles, as mentioned, are very different from plan-driven methods.

While the listed studies provide important insights into different dimensions of Agile transition, practices and roles, Jovanović et al. (2017) argue for the need of additional studies in the field in particular to fully uncover the emergent tensions accompanying the Agile transition. Among the listed articles, it is only those by Hoda et al. (2012) and Gandomani and Nafchi (2016) that address challenges and balancing acts in Agile transition. Thus, research discussing tensions experienced at the team (practitioners) level while both implementing and working Agile, is lacking. To the best of our knowledge, no grounded theory study has been found that focuses on Agile teams balancing between stability and change. In the discussion section, we will discuss our results and compare them with the grounded theory studies that are closest to our study. With the grounded theory studies in mind, our attention now turns to the research design used in this study.

Research methodology

Since the focus of this study is to understand processes, examine strategies and explore underlying behaviors, grounded theory was particularly suitable (Masood et al., 2020a). In addition, the grounded theory method is also applicable to explaining how and why phenomena occur (Hoda, 2021). Hence, in this study, the grounded theory approach (Glaser and Strauss, 1967) was used as a qualitative research method. From the results presented, a substantive theory was generated in order to explain how Agile teams can balance the tensions that arise when the Agile method is implemented and used. Instead of not being limited to a specific case or project, i.e. case study strategy (Cassell and Symon, 2004; Yin, 2017), the participants were recruited from fourteen different organizations. The intention here was to explain how to balance the tensions arising between stability (exploitation) and change (exploration) from the empirical data, rather than validating any existing theories or hypotheses. By means of incorporating respondents from different organizations, the collected data generates a more holistic view of what behaviors can be seen in conjunction with the Agile transition.

Grounded theory approach

Grounded theory is useful for doing research in areas that have not been extensively studied, or where a new perspective might be valuable (Adolph et al., 2011; Hoda, 2011). Furthermore, grounded theory is also suitable when answering questions like: “What is going on in an area?” (Adolph et al., 2011; Jovanović et al., 2017). The flexibility of grounded theory makes it especially suitable for application in the socio-technical setting of the information system (Birks et al., 2013). Therefore, grounded theory fits well with what this study is all about, namely creating a better understanding of how practitioners implement and work with Agile methods.

Researchers must be aware of which version of a grounded theory they are using (Urquhart et al., 2010). For this study, Corbin and Strauss's (2015) approach was applied due to these scholars' willingness to give a voice to the participants as individuals and due to their views on the participants' reality. The main reason for this choice is their systematic and rigorous coding structure used to create a theory that closely corresponds to the data (Kenny and Fourie, 2015). Thus, constructing a grounded theory could be resembled as building a pyramid (see Figure 1), whereby each level is built on top of the others. Based on Corbin and Strauss's (2015) suggestion of identifying a phenomenon, or issue, for a grounded theory study, the phenomenon Agile was approached with no predefined research questions, rather a broad interest in the topic.

The purpose of coding is to break down data into manageable pieces, lower-level concepts, or codes, with these concepts being analyzed by means of constant comparison (Corbin and Strauss, 2015). These concepts are then grouped together to form categories. Each category is then developed in terms of its properties and dimensions. The intention was to let the codes, lower-level concepts and categories emerge from the data (Corbin and Strauss, 2015). For this a broadly defined problem, consisting of several open questions, that deal with practitioners' experiences of implementing and working with Agile methods was used.

At the top of “the pyramid”, the different categories are included in an abstractive core category (see Figure 1) (Corbin and Strauss, 2015).

Procedure and steps

Within the software engineering research community, Stol et al. (2016) emphasize the need for transparency in grounded theory procedures. The current study was initiated using a two-phase literature review (Adolph et al., 2011). During the first phase, a minor literature review was conducted to identify the terminology used in Agile (Hoda, 2011), presented in the section The Agile way of working. During the second phase, when the first draft of the substantive theory had been written, a more traditional literature review phase was carried out. This literature review was performed to compare and contrast our substantive theory with the existing knowledge base (Adolph et al., 2011), presented in the sections “Previously grounded theory studies in the field of Agile software development” and “Comparison with related works”.

Throughout the study, the writing of theoretical memos has been a key activity for keeping track of the relationships between the concepts (Adolph et al., 2011), in line with the recommendations of Corbin and Strauss (2015). Memo writing started as early on as during the interview(s), then following the rest of the grounded theory process and becoming more and more abstract and complex with time (Corbin and Strauss, 2015). In the subsequent section, labeled “The emergence of the core category”, an example of the memo writing done during this study is provided.

Data collection – interviewing and transcribing

This study was carried out by interviewing twenty Agile development practitioners from fourteen different organizations, who voluntarily participated. The participants were recruited from different organizations, namely consultancies, government agencies, product development companies and banks. In order to collect data from a variety of perspectives, different roles were also included for attention in the study. Nine of the participants were women and eleven men —all but one of them works in Sweden, with one working in Austria. Two-thirds of the participants have more than ten years' experience of working Agile. All the participants are identified by numbers given to them, e.g. from P1 to P20, in order to avoid being identified personally. To strengthen the level of anonymity protection, we have used pseudonyms for all thirteen organizations, i.e. GovA-GovB, ConA-ConF, ProdA-ProdD and BankA-BankB. See Appendix for a summary of the participants and their demographics.

We digitally recorded the interviews and these were later transcribed, verbatim. Data collection started during the early stages of the study and terminated when reaching data saturation, i.e. the situation whereby no new concepts are emerging (Corbin and Strauss, 2015).

Analysis – coding

During the first coding activity, referred to as open coding, qualitative codes were constructed by defining what was identified in the data (Charmaz, 2006) using the qualitative research tool NVivo [1], in order to get an overview of the collected data. Each transcript was reviewed sentence by sentence, and lower-level concepts were identified. In addition to the NVivo software, Microsoft Excel spreadsheets were also used during later phases of the coding work, in order to get a better overview of the compiled material from NVivo. By using a constant comparison technique, the newly-identified concept was compared with the previous concepts within both the same and previous transcripts, as well as concepts from our memos (Glaser and Strauss, 1967). Higher-level concepts i.e. categories or themes are presented in Figure 1. Categories communicate what a group of lower-level concepts points to (Corbin and Strauss, 2008).

The next step in the coding process is known as axial coding and entails integrating and identifying the relationships between categories. This coding is the core of theory building (Corbin and Strauss, 2015). In theory generation, a substantive theory is applicable to a specific area, whereas a formal theory concerns a more general process or phenomenon covering a broader area (Hallberg, 2006). When generating a substantive theory, it is necessary to conduct selective coding to gain a more complex and abstract level of analysis and to integrate the categories and construct a substantive theory (Corbin and Strauss, 2015). The coding process was ended when the transcripts were only delivering more evidence and examples, but no new concepts or categories, which indicates theoretical saturation (e.g. Glaser and Strauss, 1967).

The emergence of the core category

As analysis continues, the basis for making comparisons tends to become more high-level and more abstract (Corbin and Strauss, 2008). Concepts achieving the status of a category are thus known as abstractions (Corbin and Strauss, 2008). They represent the experience of many participants, reduced into and depicted by several highly-conceptual terms. The core category is a conceptual idea into which all the other categories can be included (Corbin and Strauss, 2008). In this study, the abstract core category evolved from the list of underlying categories and lower-level concepts or codes presented in Figure 2.

The Agile transition process, in most of these cases, is pushed by top managers using a convincing hierarchy strategy dedicated to informing the people within the organizations about the expected benefits of Agile for them (Annosi and Brunetta, 2017). However, one must be aware that the transition from plan-driven software development to the Agile way of working is a major change, and that the inherent, latent tensions can be made salient through processes of change (Fairhurst et al., 2016; Smith and Lewis, 2011). The first author wrote an extended memo on the tensions that were found. This memo was discussed with professors and senior lecturers with grounded theory experience, resulting in the core category: “Balancing between stability and change”. Corbin and Strauss (2008) developed their own strategies for probing data. One of the strategies, or analytical tools, is “playing with data” by means of applying metaphors. “Balancing” in our study is a deliberate metaphor. The imaginary metaphor here, “The balance beam scale”, shows that the main concern of the participants in this study is balancing between a feeling of stability and a feeling of change.

Results: a substantive theory of continuously balancing between stability and change in Agile teams

This paper answers the following open questions: What are the concrete tensions that Agile team members experience? In what ways are these tensions experienced? Between which stakeholders do these tensions exist? In this study, the findings are captured in the core category “Balancing between stability and change”. Five other categories are related to the core category: “Understanding the Agile way of working”, “Changing roles and responsibilities”, “Caring for the team”, “Sharing knowledge” and “Building trust”. The core category, along with the five other categories, constitutes a substantive theory of continuously balancing between stability and change, during the Agile way of working, from an employee perspective.

Next, the core category is described in more detail. After that, the five categories are presented. We have used Corbin and Strauss's (2015, p. 77) model (see Figure 1) as a template for building our framework (Figure 3), with the emergence of the core category “Balancing between stability and change” being based on the underlying categories identified. We use the metaphor “The balance beam scale” to show that the main concern of the participants is balancing between a feeling of stability and a feeling of change. The underlying categories are positioned together in order to balance stability and change.

Explaining the core category: balancing between stability and change

Although the decision to abandon a plan-driven approach and start working Agile can be made quickly, it is a process that requires both time and resources. What we are not used to can be difficult to get used to. The plan-driven way of working can be seen as a structure that provides security, something that is safe and stable. In the event of a transition, this approach should be abandoned in order to instead focus on changeability and flexibility. Thus, the core category, which is described by the participants, is an ongoing tension in terms of handling both stability and change. To exemplify this ongoing tension, one participant said:

I think that, in order to be flexible, there must be something else that's more stable. Something you can fall back on when the turbulence is at its greatest. It may be that we always have our three-week sprints, we know it, it's predictable. [P12 Product owner from ProdA]

In everyday language, it is common to use metaphors. To explain the difference between a plan-driven and an Agile way of working, several participants described this as a pendulum where the two ways of working were represented by the two different endpoints. First, the pendulum is at the plan-driven endpoint and then it swings over to the Agile endpoint. The interpretation of this metaphor is that the plan-driven way of working generates a feeling of stability. However, when the Agile way of working was introduced, it caused a sense of “chaos” for the participants. After a period of working Agile, two participants [P6 Scrum Master from ConB and P14 product owner from ConE] said “the pendulum strikes back”, once again against the previous plan-driven way of working. The following quote illustrates this:

On my team, they want to work Agile, but they also like to gather every 10–12 weeks or so and make a joint overall plan. You could say that the pendulum strikes back for more structure. [P6 Scrum Master from ConB]

Therefore, an understanding of the core category, the ongoing tension as regards handling both stability and change, is critical. Furthermore, the paradox perspective shifts away from an “either/or” toward a “both/and” logic. In understanding “The Agile way of working”, in order to improve software development, a more structured way of working can be introduced in order to balance Agile practices. The following quote clearly illustrates this:

Now we have better routines than before, when things were just too flexible, but there was no structure. [P3 Project manager from ConB]

To have a feeling of stability, there must be a structure, with this structure being made up of, for example, roles and responsibilities. After the transition from plan-driven software development to the Agile way of working, it is necessary to clarify both “the new changing roles and the new changing responsibilities” in order to have a feeling of stability. Moreover, in the Agile way of working, “the team” is given a key role, and it is essential that the individuals in the team also have a feeling of “trust”. People who work closely together in small teams cannot hide behind others. In addition, in small self-organizational teams, the members must handle all the tasks. Therefore, it is necessary both to assist and to “share knowledge”. One prerequisite for being creative and flexible is the team being stable. For instance, one participant said:

The team is also stable. We thus have some things that are stable as regards handling this flexibility. [P12 Product owner from ProdA]

In this study, it was discovered that the transition and working processes also include other inherent processes. These processes exist within the team, but also within the organization and between different stakeholders. The core category (process), along with the five other categories (processes), constitutes a substantive theory of continuously balancing between stability and change, in Agile teams and from an employee perspective. Next, the five categories (processes) that are simultaneously ongoing in order to balance the need to have both stability and change are presented: “Understanding the Agile way of working”, “Changing roles and responsibilities”, “Caring for the team”, “Sharing knowledge” and “Building trust”.

Explaining the category: Understanding the Agile way of working

In a self-organizing Agile team that has authority and responsibility and makes decisions, the customer has an important role. The customer (in the role of product owner) prioritizes “what” should be done and the others in the team prioritize “how” the work should be done. The Agile approach is much more than just methods and practices; it is a mindset. Therefore, insufficient knowledge of the Agile way of working, as well as its principles and values, can be a significant obstacle to a successful and smooth transition. Introducing an Agile way of working and using it entails a decisive change in the organization's culture and strategy. If the people within the organization do not understand what this change means, conflicts can arise. One respondent visualizes such a conflict thus:

At times, project managers and line managers just came and snatched people from my team and wanted to send them to do training somewhere else. Then I went crazy and said that you have not understood what Agile is. [P8 Test leader from GovB]

During the current study, it turned out that the need to be able to see the big picture had not changed despite the transition to the Agile way of working. The following quote clearly illustrates this need:

It's important to get a holistic perspective using overall roadmaps. If I cannot see the product's lifecycle, or the whole, my motivation will decrease. [P19 Scrum Master from ConE]

Having no overview and a lack of time can also lead to other consequences. For instance, one participant said:

Without an overall structure, nothing holds things together and this means everyone working with their own tasks. As a developer, you do not have much time, so in the short–term, it might feel unimportant to know what the others are doing, but I think in the long–run, it's important to have a holistic understanding so that you can be helped out if someone gets sick. [P20 Scrum Master from ConF]

It is, furthermore, important for the new way of working to be accepted and supported by the entire organization and all the stakeholders, at both the management and operational levels. The participants in this study have experience of customers lacking knowledge of how to think and work Agile. One participant explains it thus:

There are sometimes customers who are frustrated because you're too strict about new features not entering the sprint, or you're too flexible because you cannot say when features will be ready. [P3 Project manager from ConB]

During the study, it was also discovered that some customers wanted an overview of the whole project, the control, the flexibility and the changeability all at the same time. One participant describes this in terms of customers “wanting to have their cake and eat it”. [P5 Project manager from ConB]. In a team, there may also be insufficient knowledge of how to work in an Agile way. For example, one participant said:

In the beginning, many felt that everything connected with the Agile way of working was difficult. There were too many meetings, and we had to discuss everything as a team because the team is responsible, and some people just wanted to write code. [P8 Test leader from GovB]

In an Agile team, where everyone has to make joint decisions, it is difficult to “hide” to avoid taking responsibility for your work. One participant explains it thus:

I think the Agile way of working can sometimes be a bit tricky when there's so much focus on the team and less on the individual. [P1Scrum Master from GovA]

To summarize, entire organizations are affected, with everyone needing to understand the new way of working. After transitioning from plan-driven software development to the Agile way of working, reorientation is required, not only on the part of the developers but also on the part of management. The “roles and responsibilities are changed” on all levels, and how to collaborate has to be agreed upon.

Explaining the category: changing roles and responsibilities

Compared to plan-driven software development, the boundaries between developer roles are less well-defined in the Agile way of working; it is important for developers to be competent in a wide range of skills as opposed to being an expert in just one area. Conboy et al. (2011) call this issue “master of all and master of none”. This issue was confirmed in our study:

I do not think you learn as much as you did before. You lose your knowledge; it's challenging to find someone who can do something and who really knows that he or she can do it. Because there are so many different people involved and you work with so many different products so there's no one who can cover it all. These expert roles we had before, they're not around anymore. I think this is a major shortcoming and I miss it very much. [P4 Team member from ProdA]

Several participants expressed being uncertain of their new roles, also mentioning that they had been in conflicts about these. Time and resources were spent on resolving these role conflicts. The following quote indicates this kind of experience:

My roles … it is not easy to understand the balance … what's my responsibility and what is the customer's responsibility, and how much responsibility should you let them assume, and how much should I try to get them to assume it? That's a constantly ongoing interaction. [P5 Project manager from ConB]

As we mentioned earlier, decision-making has changed in the Agile way of working, compared to the plan-driven approach. For example, the project manager's role has changed; from previously leading and controlling to instead participating and coordinating. In our study, it became clear that it is difficult to go from the role of project manager into the new Agile role of Scrum Master. The following quote clearly illustrates this problem:

Behaviors the project manager should display are: being organized, having some kind of drive and being good at driving people, and also pointing out who should do what. These behaviors are directly wrong when used in the role of Scrum Master. Then you really should not suggest things forcefully, just take a step back and let the team make decisions together. [P14 Product owner from ConE]

This participant goes on to explain:

It's almost impossible to take a step back and delegate responsibility to the team if you work with the same people you worked with before in the role of project leader. For now, in the Agile way of working, you have to work differently and “hold back” instead of leading. So, it's better to switch colleagues and or teams. [P14 Product owner from ConE]

These new roles and leaderships mean team members being equally worthy and having joint responsibility to take “care of their teams”, as described in the following category.

Explaining the category: caring for the team

Self-organized teams are the most central feature of the Agile way of working. In order to handle these new areas of responsibility in the best way, it is important for the individuals in the team to feel motivated and satisfied with their work. They need to feel in control of their own work and to be able to schedule and solve their own tasks. The concept of self-organized teams means freedom, on the one hand, and responsibility, on the other. In the study, this tension between freedom and responsibility was noticed and described by one of the participants as follows:

I see myself as a ‘team player’ who makes sure to solve tasks. But in practice, some people do some things on the basis of experience and because they think they're fun. We solve things within the group, so it's quite free, but it's freedom coupled with responsibility, so it's a matter of things you cannot get from the start, so you have to learn it well. [P10 Team member from ConD]

Compared to the plan-driven software development team, the Agile team is jointly responsible for project results. When people work together, with good communication and interaction, they can work at significantly higher levels of efficiency than when they use their individual capacities. A synergy effect arises if team members understand their part in the all-important whole and put the team in the foreground. One participant testifies to the team's special importance thus:

It's the team that'll solve the tasks, and if it is not done properly, then it'll be the team that has not succeeded, not the individual. [P2 Scrum Master from ConA]

The Agile mindset is a recurring theme among the participants. Agile team members are jointly responsible for the end product and must develop common mental models by assigning common understandings of both teamwork and the task. One participant explains it thus:

In order to get a smoothly-functioning group, you need to have a similar mindset, or at least some understanding, in order to take advantage of everyone's differences. [P1 Scrum Master from GovA]

As mentioned before, in these small teams, the team members will be able to handle all the tasks. Thus, they need to help each other out and “share their knowledge”. In other words, “sharing is caring”, something which continues to be described in the following section.

Explaining the category: sharing knowledge

The view of knowledge and the emphasis on silent or clear knowledge differ with whether the work is plan-driven or Agile. To these differences can also be added the transfer of both explicit and tacit knowledge between the project's stakeholders. Several of the respondents testify to the importance of being competent in a wide range of skills in the Agile teams. It is different from working plan-driven, where the respondents expected to have expert competence in a few areas. One participant describes the difference thus:

You have to cope with everything within the same team. We work cross-functionally so then we have to be able to do everything from design to testing and delivery, the whole bit, and preferably in several fields of expertise in order that we also function as a whole and assume all the responsibility. [P4 Team member from ProdA]

Another participant also confirms this:

We have to be able to do everything, and that's what Agile is all about. That's why knowledge sharing is so important for the organization, so that it does not become dependent on one single member of the team. [P11 Team member from ConD]

The concept of “team player” reappears; here, the focus is on having a lot of responsibility, as a team player, to share your knowledge. One participant explains it thus:

It's the team that jointly owns the problems and solutions. There are great opportunities to learn different things, even though you might not have the right skills profile. There will always be new challenges, and you might learn from each other in the team. Within the team, you have the support of the other members, through reviews and in pair-programming, so there are many positives with the Agile way of working, but not everyone likes it. It depends on whether you're a team player or not. [P5 Project manager from ConB]

In addition to this, team members must also feel trust and confidence in being the “team player” of choice, in demand. Consequently, in the next category, the focus is on “building trust”.

Explaining the category: building trust

Building trust forms part of creating a climate of mutual respect and caring. This climate is a criterion for being able to work Agile, where the importance of self-organizing teams is emphasized and where there is trust in the team's ability to make its own decisions, solve problems and deliver results. In this study, one participant emphasizes the importance of trust being the most important thing to keep in mind when working Agile. He visualizes it by describing it thus:

Trust is the world's most beautiful palindrome [2]. [P7 Agile Coach from ConC]

As mentioned before, the new roles might result in role conflicts and tensions. One participant recognizes this and describes it thus:

As a project manager, I have to relinquish control to the team and the Scrum Master. I have to greatly trust in them doing what they're supposed to do’ and that they'll flag up anything on the reconciliations that remains to be done. I'm much less involved in day-to-day routines in my role as an Agile project manager. [P3 Project manager from ConB]

Having trust within the team is key, but this is also true between the different stakeholders. One participant explains it thus:

We want to work as an autonomous team, but when we do not get a sufficient degree of freedom, tension arises. [P1 Scrum Master from GovA]

Finally, together with the customer, it is necessary for the team to create trust. One participant confirms this:

Since it does not matter what kind of a slant you put on things, what makes people disappointed is when you do not deliver what you've promised to deliver at the end of the sprint. [P2 Scrum Master from ConA]

To sum up: The five categories presented in the study are captured in the core category: Balancing between stability and change. Together, they constitute a substantive theory of continuously balancing between stability and change, in Agile teams, from an employee perspective, something which we will now discuss. In addition, the next section proposes three guidelines for helping organizations that are changing their way of working to Agile.

Discussion and guidelines

This study aims to create a better understanding of how practitioners implement and work with Agile methods while balancing the tensions arising between stability and change. To fulfill this aim, a grounded theory approach was used. Grounded theory is increasingly being used to study the human and social aspects of Agile teams. It is well-suited to investigating how practitioners collaborate and produce software during their everyday working lives (Hoda, 2011). Even though many organizations have implemented Agile in preference to plan-driven software development, more studies are needed in order to fully uncover the emergent tensions accompanying this transition (Jovanović et al., 2017).

Comparison with related works

Following grounded theory, this study discusses the implications of the substantive theory of balancing between stability and change in Agile teams against the backdrop of the existing literature. As previously noted, several grounded theory studies have been conducted in the field; for instance, Hoda et al. (2012) describe the balancing acts performed by self-organizing Agile teams, between (1) the freedom provided by senior managers and the responsibility expected from them in return; (2) specialization and cross-functionality across different functional roles and areas of technical expertise; and (3) continuous learning and iteration pressure, in an effort to maintain their self-organizing nature. In addition, Gandomani and Nafchi (2016) argue that it is important for the organization to understand the Agile way of working, as well as the changes in roles and responsibilities that come with it. In addition, they also found that knowledge sharing and team management are key to building trust (and from there, an acceptance of changes being made to their way of working). However, although the studies mentioned address the challenges and balancing acts of Agile teams, they do not specifically address the tensions that are experienced at the team level while both implementing and working Agile. Hence, the contributions made in this paper do expand our knowledge in this regard.

This study broadens our knowledge of balancing between stability and change, to include both transition and working Agile from team members’ experience. From the author's point of view, it is clear that challenges or tensions exist within organizations and thus the first step toward being able to handle or balance these tensions is identifying and investigating them. If these paradoxes are ignored, it can be harmful for the organization, and tunnel vision can be generated (Aubert et al., 2015).

Since the transition from plan-driven software development to the Agile way of working is a major change, inherently latent tensions can be made salient through processes of change (Fairhurst et al., 2016; Smith and Lewis, 2011). It is only when tensions are made visible that individuals become able to put them into words, and the opportunity to deal with them presents itself. One of the participants called these tensions “monsters”; however, these monsters were also difficult to put words to. We think this is what is usually said: “Trolls caught in sunlight turn to stone”. Farjoun (2016), Jarzabkowski et al. (2013) are in the same vein when stating that, as individuals make sense of tensions, they can be more active. They can respond to the tensions with acceptance, confrontation and transcendence. These responses can, in turn, explore tensions and, in doing so, use the creative potential of the paradox perspective to enable change in both belief and practice (Jarzabkowski et al., 2013) and assist both theory building and discovering creative solutions (Aubert et al., 2015).

However, even in the strongly emerging research field of Agile software development, there is a lack of knowledge of what these tensions consist of and what strategies exist to deal with them (Lindskog and Magnusson, 2021; Wang et al., 2008). In this study five categories were identified, i.e. inherent processes that are simultaneously ongoing in order to balance the need to have both stability and change: “Understanding the Agile way of working”, “Changing roles and responsibilities”, “Caring for the team”, “Sharing knowledge” and “Building trust”. The core category, along with the five other categories, constitutes a substantive theory of continuously balancing between stability and change in Agile teams, from an employee perspective. Although organizations have switched to Agile work, it is important to be aware that these ongoing processes still need to be maintained.

This study contributes with the fact that our discovered categories show that several inherent processes are ongoing at the same time in order to balance the need to have both stability and change. Based on these findings, the following section highlights three different guidelines on how to implement and work Agile (both from a managerial and a project member perspective). Hence, while most software development organizations have already implemented the Agile way of working, or are in the process of doing so, more than half of these organizations' teams are still struggling with transitioning away from using plan-driven methods (Noll et al., 2017). Thus, our proposed guidelines can help organizations that are about to change their way of working to Agile. They can also assist organizations to move from “doing Agile” to “being Agile”, thus becoming more successful (Denning, 2016a).

Take a holistic view and let it take time

The transition from plan-driven to the Agile way of working can be seen as a paradigm shift (e.g. Abrahamsson et al., 2002); it can be difficult to learn old, traditional methods and to move toward new ones (Thangasamy, 2012). Thus, as mentioned before, it is important for the new Agile way of working to be understood, accepted and supported by all stakeholders. Unfortunately, it is rather the case that most software organizations are still hierarchical, with management units having little or no interest in, or knowledge of, process-oriented Agile practices (Gren and Lenberg, 2020). On that basis, Van Waardenburg and Van Vliet (2013) identify one successful mitigation strategy as “changing the mindset of business stakeholders”. The Agile way of working should not be treated as something that can be formalized in a functional manual (Denning, 2015). Instead, Agile should be seen as another way of understanding and acting in the world (Denning, 2015). Therefore, insufficient knowledge of the Agile way of working, as well as its principles and values, can be a significant obstacle to a successful and smooth transition (Gandomani and Nafchi, 2016). The argument here is if business stakeholders become more aware of, and better understand, how the Agile process works, it will be easier to manage requirements. This is especially important in an organization where Agile and plan-driven software development coexist (Gandomani and Nafchi, 2016).

The Agile way of working is so much more than a way of working. It's a whole new way of thinking, i.e. a new mindset, which people absorb to varying degrees; as already mentioned, the difference between “being Agile” and “doing Agile” (Denning, 2016a). Given time and maturity, there is a possibility that “doing Agile” can be a step toward “being Agile”, since the transition process can take several years and requires major resources. It is important to be aware that change can encounter resistance, which might explain why organizations are partly adhering to their old ways of working. A good point of departure is to make sure that top-down commitment is visible, together with the knowledge that transition will take time to fully implement within the organization. Also, even if the “core” process is the transition, everyone involved will have to understand that there are several inherent sub-processes within the major one. In addition, none of these processes will end just because “the transition project” itself has ended. Thus, it is important to take a holistic view of Agile implementation and give it the time to mature.

Accepting change

When implementing the Agile way of working as a replacement for plan-driven software development, roles and responsibilities will change, something that affects everyone. The study by Conboy et al. (2011) found that, compared to plan-driven software development, the boundaries between the developer roles were less defined in the Agile way of working. In our study, several respondents expressed being unsure of their new roles, also mentioning that they had been involved in conflicts about these. Time and resources were spent resolving these role conflicts. Consequences of this change can thus cause problems and frustration (Conboy et al., 2011). An example of a change is the clear project leadership role in the plan-driven approach not being as clear in Agile, in terms of leadership. Instead, the team should jointly own the problem and make decisions. If we are used to leading others or being led by others, and this “leadership” instead “spreads down” to the team and the hierarchy and becomes flat, conflicts can arise. Stewart et al. (2019) examine the paradoxical concept of “self-leadership”, emphasizing that almost all efforts to change individual and team behaviors will face obstacles and problems. However, a survey found that 67% of Agile organizations were still using the project leadership role (Shastri et al., 2017). This continued use of the project manager role may be due, among other things, to the fact that human cultures and mindsets cannot be easily changed (Gandomani et al., 2014b).

A set of misconceptions has existed regarding the Agile way of working –– e.g. that documenting or planning are not allowed. Janes and Succi (2012) call these misconceptions “The dark side of Agile”. There has also been some discussion about Agile values (see Table 1), and how to prioritize between these. Beck et al. (2001, p. 2) state: “While there is value in the items on the right, we value the items on the left more.” On the contrary, Rakitin (2001) indicates that, in his experience, the items on the right (i.e. processes, documentation, contracts and plans), are crucial, while those on the left (i.e. interactions, collaborations and responding to change) reflect a “hacker” culture. Vidgen and Wang (2009, p. 356) explain that: “Rakitin's ‘hacker interpretations’ of the Agile Manifesto put Agile methods at the opposite pole of planning and discipline and regard Agile values as chaos generators.” One reason for the existing misconceptions about the Agile way of working might be because it is easier to interpret overall values in different ways. Another reason might be the major human resistance to change. Bovey and Hede (2001) looked at organizations that were implementing major organizational change. They found that individuals with a higher number of irrational ideas are more likely to resist organizational change. Therefore, an intervention strategy is needed to guide management in developing a method for tackling resistance and gaining acceptance when implementing major change. With that, we come back once again to the human focus. This could prove that a mixed approach using Agile and plan-driven software development might be the most suitable strategy for enabling organizations to manage the tension between business-driven needs for predictability (i.e. long-term planning) and the flexibility of Agile methods (Abrahamsson et al., 2010; Port and Bui, 2009). Taken together, we argue to “get the pieces” together, accepting change among all stakeholders is crucial when implementing Agile.

Recognize the need for trust

Building trust is part of creating a climate of mutual respect and caring (Edmondson, 1999). This climate is a criterion for being able to follow the Agile Manifesto (Beck et al., 2001), where the importance of self-organizing teams is emphasized and where there is trust in the team's ability to make its own decisions, solve problems and deliver results. However, if team members are used to working on their own, and then suddenly forced to work closely together with other developers, conflicts can arise (McHugh et al., 2011). The traditional view of trust entails interpersonal trust, which usually needs time to develop. However, it may be the case that sufficient time is not available; thus, trust must be created in a short space of time (Buvik, 2019). It is furthermore important to understand that, in the Agile way of working, team members are of equal worth and jointly responsible for “taking care of their team”. As the team members jointly own the problems and responsibilities, they also need to share the knowledge that each team member possesses. Trust becomes a prerequisite of a change of mindset, taking on new roles and daring to take on tasks that might not be mastered to a hundred percent.

In order to create trust, it is critical to develop an environment wherein all the stakeholders trust and respect each other. Therefore, Agile advocates practices, e.g. pair programming, daily stand-ups and retrospectives, as an aid to fostering trust (McHugh et al., 2011). We believe that building trust is the key factor in successfully balancing stability and change in a successful way. A lot of trust is needed when working in a new way, assuming new roles, changing responsibilities and daring to share knowledge. We argue that teams need to have a team leader, or Scrum Master, who acts as a “gate-keeper”. He or she allows the team members to work in an undisturbed and self-organized way. The gate-keeper role could be connected to the concepts of “swift trust”, meaning that individuals rely on defined roles rather than specific people (Buvik, 2019).

All of these proposals could contribute to individual and team safety. Given this sense of safety, it is so much easier to step outside of your “comfort zone” and to be creative, both individually and as a team. Hence, building trust is an important factor of success when implementing and working Agile.

In sum, we argue that the three guidelines mentioned, i.e. having a holistic view and letting it take time, accepting change and recognizing the need for trust, are all important to organizations faced with implementation and working Agile. Organizations need to realize that several different sub-processes need to be identified and maintained, during the implementation of major change work, but also afterward. This concludes that balancing between stability and change is an Agile paradox. Since implementing and working Agile demands management of the tension between planning future work, from a business need for stability and predictability and simultaneously being flexible and changeable.

Limitations of the study

The inherent limitation of a grounded theory study is that a substantial theory can only explain the specific contexts explored in that study. All the emergent codes, lower-level concepts and categories in this study came directly from data. Therefore, the findings are sufficiently grounded in substantive contexts. Thus, this study's contribution is a substantial theory that needs to be further developed and improved. We do not claim that our findings are generic since access to the appropriate resources was limited to participants voluntarily accepting participation. In other words, the findings are context-dependent; this is reflected in the categories, and thus it is not proposed that the findings are generalizable beyond the defined Agile context of the study. Generalizability in grounded theory is achieved through the ability of the generated theory to be modified to fit with, work within and be relevant to new and different contexts (Hoda et al., 2012). For example, our substantive theory, balancing between stability and change in Agile teams, can be modified to make predictions in other substantive areas, for instance sales and marketing teams.

This study emphasizes the importance of the human factor in the Agile way of working. It responds to the need found by Mishra et al. in their study of what Agile practitioners want researchers to investigate. In that study, it turned out that the theme of Collaborative culture and Team was a topic that came up at each annual Agile conference supported by the Agile Alliance (www.agilealliance.org) and being run mainly by Agile practitioners.

Future works

In the future, it would be useful to perform similar research in other contexts in order to refine the findings presented in this study. Future studies should focus on the categories emerging from this study. For instance, a study could shed light on how competence sharing might be enhanced during transitioning, but also afterward, while another could focus on how changes in roles, responsibilities and decision-making affect individuals, teams and organizations. Additionally, a study of how to build and strengthen trust within and between teams, as well as between teams and stakeholders, could also be of interest.

Conclusion

This study's contribution is a substantive theory of “Balancing between stability and change”, which sheds light on Agile practitioners' experience of implementing and working with Agile methods. This theory results from a grounded theory study involving twenty Agile practitioners working in different organizations, ranging from consultancies, government agencies and product development companies to banks and in different roles. The primary finding is a core category, i.e. “Balancing between stability and change”. Five other categories are related to the core category: i.e. “Understanding the Agile way of working”, “Caring for the team”, “Changing roles and responsibilities”, “Sharing knowledge” and “Building trust”.

The new perspective that this study contributes to is that “being Agile” is about handling the inherent processes ongoing at the same time in order to balance the need to have both stability and change. Further, this study has also illustrated the application of a grounded theory method in order to develop a substantive theory of continuously balancing between stability and change in Agile teams. Implementing a grounded theory in the Agile context has shown that different aspects of the Agile way of working need to be reflected upon in order to have a fruitful change management process.

The findings have an employee perspective i.e. those who actually do what is to be done. Based on these perspectives, we present three guidelines regarding what matters to employees experiencing the transition to/implementation of the Agile way of working as a replacement for plan-driven software development. Because this is about employee perspectives, it is important for managers not to put themselves front and center while working methods are being changed. All stakeholders need to understand the importance of having a holistic view and letting the transition process take time. They also need to accept changes in roles and responsibilities. Finally, all of this requires trust. We believe that these guidelines can help organizations to create a better understanding of what is important both during and after their transition to the Agile way of working.

Figures

Figure 1

Constructing grounded theories in the form of a pyramid

Figure 2

Examples of the emergence of the core category from the underlying categories, lower-level concepts or codes

Figure 3

A framework for the emergence of the core category: Balancing between stability and change from underlying categories

Table 1

Values from the Agile Manifesto (Beck et al., 2001, p. 2)

(1) Individuals and interactions over processes and tools

(2) Working software over comprehensive documentation

(3) Customer collaboration over contract negotiation

(4) Responding to change over following a plan

Table 2

Related grounded theory studies in the field of Agile software development

Author	Transition	Practice	Role	Key focus/Insight
Hussain et al. (2009)		x	x	Investigates how the integration and user-centered design is carried out in practice using grounded theory
Hoda (2011)	x	x	x	Highlights the importance of adequate customer involvement on Agile projects and the impact of different levels of customer
Dorairaj et al. (2012)			x	Investigates the emergent key concerns, particularly the impact of trust, in distributed Agile teams
Hoda et al. (2012)		x	x	Identifies the balancing acts performed by self-organizing Agile teams between (1) freedom and responsibility, (2) specialization and cross-functionality and (3) continuous learning and iteration pressure in an effort to maintain their self-organizing nature
Gandomani et al. (2013)	x	x	x	Highlight's problems, hindrances and challenges during the Agile transformation process. The challenges are mainly in organizational culture, management, people and process areas
Van Waardenburg and Van Vliet (2013)		x	x	Discusses challenges and possible solutions when Agile methods and plan-driven development co-existence within an organization
Gandomani et al. (2014a)	x	x	x	Identify eight major facilitators that should be used by Agile teams to support Agile transition and adoption
Gandomani et al. (2014a)	x	x	x	This study shows that people's behaviors can be a barrier when transitioning to Agile
Waterman et al. (2015)		x	x	Suggest five strategies that teams use to determine how much architecture to design up-front
Gandomani and Nafchi (2015)	x			Provides an Agile transition model in the form of PDCA (plan, do, check, adjust)
Gandomani et al. (2015)	x	x	x	Discovers that inadequate and dysfunctional training was one of the critical issues that affected the Agile transformation process
Gandomani and Nafchi (2016)	x	x	x	Describes the origins and reasons of human-related challenges throughout the Agile transition process. The results show that the root of the emerged issues is the people's perceptions about Agile transition
Stray et al. (2016)		x	x	Studies how daily stand-up meetings are conducted and what the positive and negative attitudes toward them are
Hoda and Noble (2017)	x	x	x	Presents the theory of becoming Agile considers an Agile transition to take place within a multidimensional network of ongoing changes in different areas of practice
Jovanović et al. (2017)	x		x	Identifies how traditional organizational roles are transformed toward Agile roles and how they are influenced by various circumstances
Masood et al. (2020a)		x	x	Presents a comprehensive grounded theory of making self-assignment work, which explains the context and conditions that give rise to the need for self-assignment
Masood et al. (2020b)		x		Shows how Scrum works in practice as compared to how it is presented in its formative books. The authors identified significant variations when comparing the formative descriptions and the “real world setting”
Shastri et al. (2021a)		x	x	Highlights the continued presence of the role of the project manager in Agile software projects as a part of the transition from traditional to Agile ways of working
Shastri et al. (2021b)		x	x	Presents and describes the Scrum master's role in Agile projects and find a positive association between the presence of the Scrum master and the frequency with which Agile practices are carried out by the team

Notes

1. https://www.qsrinternational.com

2. The Swedish word for trust is tillit, which is a palindrome even though trust is not.

Appendix

Table A1

Participants

Participant	Type of organization	Alias	Gender	Age	Role	Years of Agile experience
P1	Government agency (Sweden)	GovA	Man	30–39	Scrum master	>10
P2	Consultancy (Sweden)	ConA	Man	30–39	Scrum master	>10
P3	Consultancy (Sweden)	ConB	Woman	30–39	Project manager	>5
P4	Product development company (Sweden)	ProdA	Woman	50–59	Team member	>5
P5	Consultancy (Sweden)	ConB	Woman	40–49	Project manager	>10
P6	Consultancy (Sweden)	ConB	Man	50–59	Scrum master	>10
P7	Consultancy (Sweden)	ConC	Man	50–59	Agile coach	>10
P8	Government agency (Sweden)	GovB	Woman	50–59	Test leader	>10
P9	Consultancy (Sweden)	ConD	Woman	40–49	Team member	>5
P10	Consultancy (Sweden)	ConD	Man	30–39	Team member	>5
P11	Consultancy (Sweden)	ConD	Woman	40–49	Team member	>10
P12	Product development company (Sweden)	ProdA	Man	40–49	Product owner	>10
P13	Bank (Sweden)	BankA	Man	40–49	Agile coach	>10
P14	Consultancy/Product development company (Sweden)	ConE	Man	40–49	Product owner	>10
P15	Product development company (Sweden)	ProdB	Man	20–29	Product owner	<5
P16	Product development company (Austria)	ProdC	Woman	40–49	Product owner	<5
P17	Product development company (Sweden)	ProdD	Man	30–39	Product owner	<5
P18	Bank (Sweden)	BankB	Woman	40–49	Scrum master	>10
P19	Consultancy/Product development company (Sweden)	ConE	Man	60–65	Scrum master	>20
P20	Consultancy (Sweden)	ConF	Woman	20–29	Scrum master	<5