Keywords

1 Introduction

There is an industry trend towards adopting agile methodologies in-the-large, and although research into agile software development (ASD) has matured in the past years, agile in large-scale settings are not much explored [1]. Although some studies are reported from large-scale transformations, such as the presented studies in Dikert, Paasivaara, and Lassenius [2], there are few studies investigating implementations of large-scale agile frameworks. This study can help to bridge that gap.

A suggested future research agenda for large-scale ASD was a call for further research in how coordination change over time [3]. Coordination can either be planned, such as dividing work in advance and identifying dependencies or designed to deal with emerging dependency issues, such as daily or weekly meetings to solve problems [4]. Different ways to coordinate are sometimes called practices [5], mechanisms [5, 7], or routines [4]. Feldman and Pentland define organizational routines (hereafter, simply routines) as “repetitive, recognizable patterns of interdependent actions, carried out by multiple actors” [7, p. 94] which well describes different ways of coordination and therefore the term routine will be used henceforth.

For example, Dietrich et al. [5] studied the different types of coordination routines on individual versus group mode used in large-scale ASD, and Dingsøyr et al. [6] studied different types of coordination routines used in a large-scale ASD program and how they evolved. Both studies present a list of routines for coordination in large-scale agile settings but do not investigate in detail how the routines were changed or tailored in detail from a performative aspect. This paper focuses on the details of one specific planned coordination routine performed in large-scale ASD with the research question: How is the PI planning routine tailored in SAFe implementations?

To answer the research questions, 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 observations at these case organizations started when they implemented the Scaled Agile Framework (SAFe), and observations went on for one and a half year.

2 The PI Planning Coordination Routines in SAFe

SAFe consists of a number of roles, artifacts, and routines, and this is a brief description of one investigated routine for planned inter-team coordination. PI planning, as described in SAFe [7], is a routine for dividing work and identifying dependencies between teams for a set period of time into the future. SAFe explains that “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” [7]. According to SAFe, the typical iteration is hence two weeks long.

The importance of PI planning is explained on the website: “PI planning is essential to SAFe: If you are not doing it, you are not doing SAFe” [7]. The routine follows a strict two-day agenda (see Fig. 1) where the first half day comprises different presentations followed by “Team Breakouts” where each team plans their work.

Fig. 1.
figure 1

(source: Scaled Agile Framework [8]).

PI planning standard agenda.

Full size image

The first day ends with a presentation and review of a draft plan and the first half of the second day is used for adjustments and further planning and ends with a presentation and review of the final plan. The second, and last, part of the second day comprises risk management, a confidence vote (in which teams vote on their confidence in meeting their planned PI objectives) and a joint retrospective for all teams and stakeholders participating in the PI planning workshop. Depending on the result of the final plan review and confidence vote, an undefined amount of time [8] is set aside for rework of the plan to be finalized before the end of the second day. Out of the two full days, only five hours (30%) is dedicated for team breakout time.

Something that is not visualized in the standard agenda is to conduct a number of inter-team meetings called Scrum of Scrums (SoS) during the team breakout sessions where all Scrum Masters attend to follow up if teams are following the intended planning schedule. A number of questions are raised in these meetings such as “Has capacity (velocity) been identified for each iteration?”, “Have any program risks been identified?”, and “Have dependencies with other teams been identified and/or resolved?” [9]. These meetings are also called SoS Sync to differ them from the ordinary SoS meetings which are conducted during the program increment, often two or three times a week, to sort out emerging team dependency issues [8].

As can be seen, the way to conduct PI planning is expressed in a prescribed manner regarding the steps to be performed. Conboy and Carroll [10] put forth, in a study of 13 agile transformations, that the risk of implementing a common framework is that it imposes too many restrictions and rigidity on the employees. On the other hand, the lack of guidelines from a common framework may lead to a lack of common direction in the agile implementation as Paasivaara et al. [11] pointed out from studying the company Ericsson.

3 Method

Observations, using field notes and photographs, together with memoranda from meetings, were used as data for the study. On-site visits and observations in the various cases are presented in Table 1. Results are presented in a tabular format as well as a short narrative describing the identified results. The analysis is comprised of investigating and comparing differences between the detailed prescribed way of conducting PI planning according to SAFe and how the PI planning routine was performed in the three cases. The studied organizations (Auto, Gov, and Bank), had a history of agile ways of working between four to six years before starting to implement SAFe. The cases were chosen because they all had experience and maturity in agile ways of working, since the study focuses on the implementation of a large-scale framework, not implementing ASD per se. Also, it was essential to select cases which were at the beginning of implementing the SAFe framework, to be able to follow tailoring from the very starting point. The teams at Bank and Gov were each organized as one unit, also called an Agile Release Train (ART) [8]. At Auto, they were divided into three ARTs, hence the many hours spent on observation in this organization compared to the other two cases.

Table 1. The number of on-site visits and hours of observation.
Full size table

The on-site observations were conducted during a number of PI planning workshops, from April 2017 until November 2018, a period of one and a half years, as depicted in Fig. 2.

Fig. 2.
figure 2

On-site observations at the case organizations.

Full size image

Data was collected from the starting point of the implementation of SAFe at Bank and Gov while Auto had started their transformation three months prior to the first observation and had already conducted two PI planning workshops.

4 Results

The results presented in Table 2 are from the first and the last observed PI planning workshop.

Table 2. Data from PI planning at Auto, Gov, and Bank from the first and last observation.
Full size table

Auto was conducting their third PI planning during the first observation, and all three ARTs had decided on a set 10-week cadence, all three within the same week. The cadence remained the same all through the observation period but the agenda changed over time, mainly by removing common presentations and adding time for team breakout sessions. Amount of time for team breakout changed from 45,8% of time used for PI planning up till 65,2% in the last observed session.

PI 0 at Gov was not a real PI planning but a one-day information workshop to incur buy-in of SAFe to the five teams and let them meet physically since two teams had their home office in another city. A follow-up from the first real PI planning, PI 1, showed lots of negative feedback where draft plan reviews and risk resolving meetings were mainly seen as waste and “unhelpful status meetings”. Gov did not use time as a basis for cadence but instead the amount of resources, in this case, available man-hours. For the summer months, PI:s were longer since many employees go on vacation.

Negative comments were also put forth regarding the SoS sync meetings at Gov. Gov started out with two SoS sync meetings during their first PI planning, where scrum masters answered seven questions twice during the two-day workshop. In their second PI planning, they only held one SoS sync meeting, and in the third PI planning, they abandoned the SoS sync entirely. Auto started out with three SoS syncs but later reduced this to two SoS syncs per PI planning, still keeping the same format with eight follow-up questions. Bank, on the other hand, started with two longer SoS syncs, answering as much as thirteen follow-up questions but changed the format to become shorter (only five questions to answer) and more often (five times per PI planning).

At Bank, the first PI was only aimed at planning two sprints and not, as prescribed by SAFe, intended to become a set cadence. Instead, Bank proposed shorter PIs during the first PI planning sessions in order to train team members and to get shorter feedback loops on tailoring the PI planning routine. During the last observation, PI 5, four sprints had been used as PI length for two times, and Bank did not see any benefits in reaching for more extended planning periods. Instead, four sprints became the fixed cadence for future PI planning workshops.

5 Discussion

The planned coordination routine called PI planning is described in SAFe as a two-day workshop with a prescribed standardized two-day agenda where teams in an ART plan according to a fixed cadence “typically 8–12 weeks long” where the “most common pattern for a PI is four development Iterations, followed by one Innovation and Planning (IP) Iteration” [8]. But is this a proper PI format and is the proposed standard schedule a suitable format for PI planning? Since the second most reported obstacle reported in Laanti and Kettunen [12] was that SAFe was not fitted correctly to the organization, tailoring is probably needed. But how could the planning routine be tailored? Three organizations with disparate business logics were investigated to answer the research question: How is the PI planning routine tailored in SAFe implementations?

Investigating details of this specific planned coordination routine in the three case organizations gives a much more dynamic view, compared to the static description presented in SAFe [8]. The planning periods observed ranged from 6 to 15 weeks and at Bank, deciding on a set cadence from the start was not the intention. Instead, the logic at Bank was during the beginning of implementation to have shorter feedback loops to be able to tailor PI planning according to the needs of the ART. At Gov, the cadence was based on amount of resources available, meaning that PI:s during spring or fall were shorter than in the summertime since more employees go on vacation in the summertime. Deciding on a cadence for a PI can, as can be seen in the three cases, be based on different logics. In the Bank case, the length of the planning period was decided based on having short early feedback loops to learn how to conduct PI planning quickly. At Gov, the same amount of available resources was the basis for the length of the PI while Auto used what SAFe prescribes: the same number of weeks per PI. Also, although SAFe claim two weeks to be the typical length of iterations, this was not true in any of the cases as they all preferred longer iteration times: 2,5 versus 3 weeks in length.

In all three organizations, feedback from the teams was that too much time was spent in joint meetings which were mainly seen as waste. Time was instead added for teams to plan, the so-called Team Breakout sessions. At Gov, the first PI planning workshop was conducted according to SAFe prescription with 30% of the time spent in Team Breakout, the least amount of Team Breakout time compared to Auto and Bank. At the last observed PI planning workshop at Gov, teams spent 66,7% of their time in Team Breakouts. The increased amount of time spent in Team Breakout was also seen at Auto and Bank. This suggests that organizations implementing SAFe values Team Breakout more than other suggested items in the PI planning schedule.

Although the time-span of the PI during the last PI planning was within suggestions from SAFe (8–12 weeks) at two of the organizations and one even longer (15 weeks at Gov), none of the organizations felt the need for more than one and a half day to plan. This suggests that the suggested amount of time to plan is perceived as unnecessary long.

Planned PIs consisted of three to five sprints, and Auto was the only case which had an actual IP iteration at the end of the PI (which lasted for one week). Both Gov and Bank only allowed one day for innovation and the rest of the time (1,5 days) for planning the next PI. This is somewhat surprising since a basic idea of SAFe is to have time set aside for improvement and innovation [8]. An area for future research is to investigate why such little time is allowed for improvement and innovation in some organizations and the implications of these different approaches. Are organizations who allow more time for innovation more innovative or does not the allowed time for improvement have the intended effects?