1 Introduction

Adopting agile ways of working and empowering autonomous, self-organizing teams in large-scale settings is becoming increasingly popular, and many organizations implement large-scale agile frameworks for software development [1]. When self-organizing teams need to work together, they must sacrifice some level of autonomy [2]. Design and programming need to be coordinated with other teams, and development efforts are often part of a portfolio or a program. According to Bass and Haxby [2], this means, for example, that self-organizing teams must sacrifice some creativity and autonomy to reach consensus on common standards. Reduced autonomy and creativity could lead to lower team performance, but the performance of an autonomous team does not only depend on the competence of the agile team itself; it also depends on the organizational context provided by management [3].

Also, most studies report positive impacts due to the empowerment of teams but some highlight potential challenges as difficulties in implementing autonomous teams in certain settings or without sufficient leadership and support [4]. In the context of large-scale agile software development settings, there is a need for further research on the process of designing, supporting, and coaching autonomous agile teams to increase their performance. As highlighted in the proposed research agenda for autonomous teams at XP2018 [5], we need to get a better understanding of and deepen the knowledge about practices and strategies in forming autonomous teams. This will yield practical importance on how companies should organize for the right level of team autonomy and utilize autonomous agile teams in order to attain better performance, productivity, innovation, and value creation to strengthen competitiveness [5].

Some organizations, such as Ericsson [6], invent and tailor practices to scale up the agile ways of working while others implement full frameworks. The most commonly adopted framework today for large-scale agile ways of working is the Scaled Agile Framework (SAFe), according to the industrial survey The State of Agile [1]. Authors of SAFe, Leffingwell et al. [7], make a number of claims regarding expected benefits by implementing SAFe based on case studies written by end users. The highlighted benefits include, for example, increased team performance and more motivated employees. But these claimed benefits of SAFe do not stand unchallenged. For example, Schwaber [8], one of the originators of Scrum, criticize SAFe in several ways as being too top-down and inflexible, with the risk of suffocating teams under detailed routines and practices. This risk is verified by Conboy and Carroll [9] who investigated thirteen agile transformations and put forth that a major challenge was not to impose too many restrictions and rigidity when implementing a large-scale agile framework.

The purpose of this study is to increase our knowledge about team members perceptions from working according to SAFe; to understand how autonomy has changed since the implementation of the framework. The research question for this study is: How is team autonomy affected by implementing the SAFe framework when agile software development is scaled up in the organization? Instead of hearing opinions from method makers, let us hear the voices from the teams.

Three case organizations were investigated: Auto, a product development department within the Automotive industry. Gov, a project at a Government Agency in Sweden, and Bank, a development department in one of the four largest business banks in Sweden. The study of these case organizations began at the starting point of the implementation of SAFe, and interviews and observations went on for one and a half year. A survey was conducted about a year after the implementation began at the three organizations.

2 SAFe

SAFe consists of several roles, artifacts, practices, and routines described on different levels, starting from team level to the portfolio level, program level, and organizational level [10]. A very central practice is the joint planning two-day workshop with several teams for one Program Increment (PI) at a time, called PI planning. The practice, as described in SAFe [10], is aimed at dividing work and identifying dependencies between teams for a set period of time into the future; “PIs are typically 8–12 weeks long. The most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration” [10].

Besides PI-planning, there are other practices and routines such as Scrum of Scrums (SoS) where Scrum Masters from all teams frequently gather in short meetings to solve emerging dependency issues and System demo where several teams present results at the end of a sprint in a joint presentation event. As can be seen, practices and routines on the team level in SAFe propose several joint events between all teams working together. The artifacts, such as the Program board, are supporting tools to visualize the dependencies and the sequence of work.

3 Method

This is a multiple-case study where qualitative data is used to reveal how autonomy in teams is affected by implementing a large-scale agile framework. A survey was performed, and interviews were conducted. For further triangulation of data, several on-site visits were performed (see Table 1).

Table 1. Data sources.
Full size table

The three studied organizations had implemented agile ways of working for three to five years with self-organized autonomous teams working side by side before they started investigating large-scale frameworks. All three organizations decided to adopt practices to be able to scale up and cooperate more efficiently between teams and started implementing SAFe during the beginning of 2017. Auto was first, starting in January while Gov began in March and Bank in April. The development organizations are divided into a number of teams with one Scrum Master (SM) per team and almost one Product Owner (PO) per team (some act as POs for two teams).

Auto is a product development department in an organization within the automotive industry which mainly develops software but to some extent hardware (20% of all development) as well. The observed department, when the survey was conducted, was organized in 24 cross-functional teams, divided into three different value streams or Agile Release Trains (ART) to use SAFe terminology [4]. The total amount of people working in the department was 141. The average age in the department was 36,9 years old, with an average of 9,5 years working at Auto.

The Gov-project is a SAFe implementation that started as a pilot project in a large Swedish Government Agency where large-scale agile processes were implemented with the aim of finding best practices to be used for the whole organization. Gov consists of seven teams working in one ART. The total amount of employees in this software development organization was 70 people. The average age at Gov was 44,9 years, with an average of 10,5 years working at Gov.

Bank is a department in one of the major business banks in Sweden consisting of seven teams that work together in one ART. They decided to implement large-scale agile practices because a new software platform was being developed, which would increase the number of dependencies between all teams in the department. The department consists of 7 teams with 42 team members. Bank is also organized as one ART in the same manner as Auto and Gov. The average age in the department was 38,9 years with an average of 9,6 years working at Bank.

Regarding the survey, paper-based questionnaires were used at all organizations. They were handed out and collected during planning workshops when all teams participated. The survey was conducted in February 2018 for Auto, in March 2018 for Gov and in April 2018 for Bank. The questionnaire consisted of multiple sections: (1) background (e.g., the number of years worked in the organization), (2) agile roles, team, and department, (3) opinions of working in a large-scale agile context and effects on teamwork. This study focus on Sects. 3 and 2 was used to identify which respondents who were team members. Section 3 consisted of a number of multi-choice questions targeting the different practices in SAFe (that will not be used in this study) and the following two open questions:

  1. (1)

    “What do you consider as the main benefit of working according to SAFe in your organization?”

  2. (2)

    “What do you consider as the main drawback of working according to SAFe in your organization?”

201 survey responses could be used: 109 from Auto, 56 from Gov and 36 from Bank, which represents a 79,4% (201/253) response rate. 150 of these responses came from team members (80 from Auto, 39 from Gov and 31 from Bank).

The open-ended answers were first inductively coded, and themes were created based on expressed benefits and drawbacks. Then, all responses were analyzed deductively, searching for opinions related to team autonomy specifically. These opinions related to team autonomy are used in this study.

To get a richer description, semi-structured interviews were conducted with 14 team members and 4 scrum masters. The interviews contained a number of questions regarding large-scale agile work, and one of them was the following specific question: In what way has autonomy changed in the teams since the implementation of SAFe?

Besides analyzing the answers from this question, the rest of the transcribed interviews were also read through in search of answers relating to team autonomy.

Also, a total of 17 on-site observations were conducted (379 h of observation) during PI planning workshops, from April 2017 until November 2018, a period of one and a half years. Besides the performed interviews and use of the questionnaire, these on-site visits gave an opportunity to informal discussions and listening in on presentations and meetings which all benefitted to a better understanding.

Thematic analysis, which is a qualitative inductive research approach [11], was conducted to analyze the transcribed interviews as well as the open-ended answers. The six-step analysis process [11] resulted in four major themes.

4 Results

From the answers to the open-ended question in the survey questionnaire regarding benefits of working according to SAFe, 23 were related to autonomy in teams. Two of these answers spoke of autonomy but were not part of any of the themes. Instead, they addressed the benefits of being autonomous: “team autonomy gives motivation”, and “more fun and creative”. The remaining 21 answers were grouped into the four major themes.

In 12 out of the 18 interviews conducted with 14 team members and 4 scrum masters the first, immediate, answer to the question: “In what way has autonomy changed in the teams since the implementation of SAFe?” was that it had not changed at all. But by going through the rest of the transcribed interviews, several answers regarding team autonomy could be identified. In the rest of this section, the four major themes based on both interview answers and open-ended questions, are presented.

4.1 Veto Power

An area where autonomy for the teams has improved, according to two of the respondents, is that it was easier to say no to more work now. Since the more detailed planning shows both available resources as well as “load” (the amount of estimated work each team has planned for), it was easy to see when there was too much of planned work. Both these respondents argued that, although this could have been done before the implementation of SAFe, it was easier now when everybody planned at the same time, in a joint workshop where differences between team loads became apparent.

From the open-ended questions, the answer “it feels easier to reject/accept tasks” also speaks of a sense of improved veto power for the team.

4.2 Give Help, Get Help

Another area highlighted by a respondent was that it had become easier to help other teams. The team member expressed that previously, when teams had a dependency with another team and the other team was delayed, they often just sat and waited. Now, because of the joint planning, the team knew more about the intended feature, and it was therefore easy (and fun) to walk over to the other team and help them.

The answer from the open-ended questions: “problems and success is shared and highlighted” shows that the single autonomous team are perceiving a heightened decision-making power in both giving, and getting, more help.

Likewise, five other answers to the open-ended questions put forth better possibilities for giving, and getting, help: “better coordination between and within team”, “resource allocation is planned and reviewed/confirmed independently”, “includes everyone in the planning”, “visualization within the team”, and “we can see what the other people in the teams are doing”.

Three answers related to improved competence, which makes it easier to help out, both within the team as well as other teams: “Adds to a broadening of our competencies”, “Broader competence” and “broadening our expertise”. Regarding competence to, four answers displayed the need for help because of the challenges in putting teams together: “we are a team on paper but we can’t have common goals since we have different distinct competencies”, “to get the right people in the right places”, “you are in a team where you don’t have common tasks to solve”, and “should have more mixed competencies in the teams”.

4.3 Less Choice of Work

Some respondents expressed the lack of freedom regarding choosing features to build for the team. Their explanation for this was the increased amount of planning, pre-planning, and refinement before each PI planning event. One of them, a scrum master, talked about the idea in SAFe that teams should be able to pick the features they want from the product backlog but that this was not possible in their organization. She reflected that it was not due to the specializations of the teams, but that pre-planning ahead of the PI planning event meant that product owners and stakeholders needed to discuss details with teams in advance and therefore, features naturally were dedicated to teams before PI planning. Another respondent viewed this development as something natural since, in his ART at Auto, they were now better at assigning larger features for each team, which resulted in better knowledge within a specific area. Hence, further development of features within this area was naturally assigned to this team. The respondent claimed that this probably was different in different teams since some had not as dedicated areas as his team had.

A related area, also expressed by several respondents was that requirements now, since the implementation of SAFe, were much more detailed in advance before the teams could see them.

“It is hard to really feel something for the features when they are already very well detailed when we receive them.” - Team member at Auto.

Two of the respondents saw this mainly as something negative, that the teams were not part of the detailing process. One respondent expressed a sense of “suffocation” because of less mandate in choosing what to work with. The third respondent was positive and meant that it helped the teams in understanding the requirements better.

Four answers from the open-ended questions also display increased managerial control and loss of mandate for decision making for the team: “we still don’t get to select features to develop”, “too many managers/leaders compared to developers”, “the teams are too much top-managed. They are better at sorting out problems on their own”, and finally “it makes us work more like machines and less as humans”.

4.4 Speak up

One respondent expressed that there could be a downside to all joint activities implemented in SAFe with many people attending.

“If you are shy, SAFe is not any fun for you.” - Team member at Gov.

She mentioned the system demo, where she claimed to know people that didn’t show all the details of a sprint result in fear of getting bad critique and be humiliated. She expressed this one step further by claiming that shy people will not like this way of working and that some colleagues once refused to present the teams PI plan in front of other teams. Instead, they sent presentation slides in advance but did not show up and later claimed they had missed the meeting since they did not know at what time presentations should start at.

Three answers from the open-ended questions expressed a loss of clarity due to problems with team members and stakeholders not speaking up: “harder to get clear responsibilities, things end up between chairs”, “unclear about who is in charge of problems that arise”, and “lost sense of personal responsibility and urgency”.

5 Discussion

When self-organizing teams need to work together, they must sacrifice some level of autonomy. As exemplified by Bass and Haxby, this will have impacts on creativity and autonomy to reach consensus on common standards [2], but few details on changes to autonomy have been put forth in research on large-scale agile ways of working. Even less have been studied when scale-up is performed by implementing a framework, such as the increasingly popular SAFe [1].

Therefore, the following research question was formulated: “How is team autonomy affected by implementing the SAFe framework when agile software development is scaled up in the organization?”. The multiple-case study conducted at the three case organizations Auto, Gov, and Bank, shows how the joint activities with several teams form important arenas that affect autonomy in the single team. The PI planning event, for example, creates a better overview which seems to allow better possibilities to help, and receive help, from other teams. According to the respondents, this also appears to broaden competencies in the team, allowing even more cross-functionality to the team. The increased planning transparency seems to empower teams, even giving them more veto power to stop poor resource planning with overloaded teams.

These arenas, however, do not seem to empower teams on their own. According to the interview respondents, they require people who dare to speak up, that are not shy or afraid to demonstrate plans proposed by the team in public. Respondents also reported a lost sense of personal responsibility and clarity regarding responsibility for solving emerging dependency issues. This further pinpoint the need for speaking up, to raise concerns, and clarify responsibilities.

Several agile practitioners, Schwaber [8] for example, have criticized SAFe for being too strict and formal, thereby risking to suffocate teams under detailed routines and practices. Conboy and Carroll [9] confirm the risk of imposing too many restrictions and rigidity when implementing large-scale frameworks from a study of thirteen agile transformations. This problem is somewhat supported in this study, especially regarding long-term planning routines. The “suffocation” expressed from team members relate to less mandate in choosing what to work with. Because of the added planning, pre-planning and refining routines, it seems as teams have lost much of their possibility to choose what to work with and to “feel” for the upcoming work, since much detailing has been conducted outside the team.

A conclusion from the large-scale agile transformation at Ericsson [6], who invented and tailored their own practices, was that they probably would have benefitted from implementing a common framework instead. They thought such a framework would have provided a common ground for team practices which could instead have been tailored later on [6]. Findings from this study, however, suggest that it is not that simple as having a shared framework. Implementing a framework such as SAFe could lead to other problems such as a “sense of suffocation” and less ability to choose between different features for the teams.