Balancing between stability and change in Agile teams

PurposeThis 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/approachA 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.FindingsAs 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/implicationsThe 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 implicationsThe 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/valueThe 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.


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  Stability and change in Agile teams 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 teaman 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(Turner et al., , 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, IJMPB 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 Agerfalk, 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 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 (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 1. Values from the Agile Manifesto (Beck et al., 2001, p. 2) Stability and change in Agile teams 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. 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 c 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 IJMPB Author Transition Practice Role Key focus/Insight Hussain et al. (2009) x x Investigates how the integration and usercentered 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 selforganizing Agile teams between (1) freedom and responsibility, (2) specialization and crossfunctionality 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)  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 humanrelated 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 c 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 (continued )

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 c 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 Author Transition Practice Role Key focus/Insight 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 Table 2. IJMPB 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 twophase 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.

Stability and change in Agile teams
Data collectioninterviewing 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).
Analysiscoding. 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 IJMPB 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:

Lower-level Concepts
(some examples from this study) Figure 3.
A framework for the emergence of the core category: Balancing between stability and change from underlying categories

IJMPB
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: 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: 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: 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 allimportant 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 Stability and change in Agile teams 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.
[ 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: 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 plandriven software development, more studies are needed in order to fully uncover the emergent tensions accompanying this transition (Jovanovi c 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 Stability and change in Agile teams 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 plandriven 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 IJMPB 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  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 . 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.

Stability and change in Agile teams
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 IJMPB 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.
Notes 1. https://www.qsrinternational.com 2. The Swedish word for trust is tillit, which is a palindrome even though trust is not.