A Culture of Uncertainty: Interaction and Organizational Memory in Software Engineering Teams under a Productivity Scheme

Memory and interaction in organizations

Over the past couple of decades, inquiry into the role of culture in organizations and organizational change has blossomed (see, e.g., Fayard &Van Maanen, 2015; Schein, 1985; Pfeffer, 1981; Sheridan, 1992; Weeks, 2003). People in organizations create and share distinctive sets of durable schemes, stories, rituals, and routines that guide their actions (Fine, 1984; Fine & Hallet, 2014; Morrill, 2008; Schein, 1985). While culture has sometimes been hailed as an important determinant of productivity (Ouchi, 1981; Pfeffer, 1981), its durability also makes it the culprit of resistance to change, whether such change is due to environmental shifts (Hannan & Freeman, 1984) or managerial decisions (Beer, Eisenstat, & Spector, 1990; Kanter, 1989; Kanter et al., 1992; Kirkman & Shapiro, 1997; Schaffer & Thompson, 1992). Because organizational culture shapes how workers interpret and respond to new situations, workers under conditions of change may voice objections, not follow new rules, or covertly undermine changes that are not compatible with their taken-for-granted assumptions about the organization (Labianca et al., 2000; Zucker, 1977).

This renewed interest in organizational culture (see Morrill, 2008) needs careful treatment. If we attribute failure to change to cultural resistance, we run the risk of portraying workers as ‘the’ cause of failure: change fails because workers are unable to adapt to it despite organizational needs. Worker resistance then appears fundamentally ‘irrational and dysfunctional’, even though the resistance makes perfect sense to the workers (Ford et al., 2008). Instead, resistance to change is a product of organizational members’ actions and interactions in the organization, and ‘situated discursive and nondiscursive practices that are simultaneously enabling and constraining, coherent and contradictory, complex and simple, efficacious and ineffectual’ (Mumby, 2005, p. 20). To accurately understand how culture relates to worker resistance, then, we must stop treating culture as a fairly stable scheme that was created in the past and is therefore independent of current interactions. Instead, we need to look at the co-constitutive relationship between the ‘past’ that organizational members share and their current practices. To understand how culture influences workers’ actions, then, we need to theorize the link between organizational memory – the historical construct that members draw on – and workers’ actions.

Organizational memory is not a static and objective portrait of the organization’s history; it is a selective set of reconstructions of the past (Walsh & Ungson, 1991; Rowlinson et al., 2009). Organizational memory is the shared recognition of collective experience, and it is reenacted every time workers interpret their current situation. Workers use this reenacted organizational memory as a guidepost in making sensible and appropriate choices about the present and future (Walsh & Ungson, 1991; Olick, 2003; Olick & Robbins, 1998). As Halbwachs notes (1980), the past is always relevant to the degree that it relates to people’s present concerns and thus is always subject to reinterpretation. These reinterpretations are constrained by previous renderings (Olick, 2007), but organizational memory is flexible enough to serve as a resource that organization members can draw upon when facing practical problems (Swidler, 1986).

Several scholars over the past two decades have discussed the importance of memory in organizational studies (Walsh & Ungson, 1991; Moorman & Miner, 1998; Fiedler & Welpe, 2010; Wadhwani & Bucheli, 2014). However, there is a dearth of studies that explore the relationships between organizational memory, culture creation, and reactions to change in situ. This article responds to the need for an empirically grounded model that explains how organization members take up organizational memory, build and sustain meaning systems, use these cultural schemas to interpret situations, and then draw on these interpretations to respond to organizational change. The article goes beyond simply equating organizational memory with cognitive frameworks; instead, it looks at organizational actors in interaction to see how organizational memory becomes a salient prism through which workers understand their current situation in the organization.

My choice of ethnography as a methodological approach was also driven by this theoretical question. Cultural schemas shape organization members’ actions, which then recursively (re)create the schema. If we want to study such processes of structuration and understand how members use organizational memory to constitute cultural schema, it is essential to conduct continuous observation of workplace interactions (Barley & Tolbert, 1997). As scholars of memory work note, remembering the past is a constitutive part of understanding the present (Olick, 2007, Olick & Robbins, 1998) and using projective capacity to decide on courses of action (Mische & Emirbayer, 1998). It is in these moments of interaction that people ‘organize’ organizations (Barley & Tolbert, 1997; Bechky, 2011; Hallet, 2010; Hallet & Ventresca, 2006). By zeroing in on such moments, this article advances our understanding of workers’ agency and responses to change without blackboxing such responses as ‘resistance’. Interactionist theory guides researchers to look at the situations through which organizational members interpret and then respond to a productivity scheme change and the effects of these responses on the organization’s culture.

A new software engineering productivity scheme: Scrum

In the case I studied, a software engineering organization introduced a new productivity scheme called ‘Scrum’. Scrum is one of the ‘agile’ methods that gained popularity in the mid-1990s. ‘Agile’ methods emerged as alternatives to what creators termed the ‘traditional’ Waterfall model of software engineering. In the Waterfall model, the whole software engineering project is divided into large phases of design, development, and testing, and each phase must be completed before the project can proceed to the next phase. This model, though still commonly used in the industry, has been criticized as rigid and risky because it cannot incorporate changes that occur mid-project (Royce, 1970). Agile methods arose to overcome the Waterfall model’s perceived problems.

Scrum is a management technique consisting of a set of rules designed to empower engineering teams and a set of rules about software engineering. Like other agile methods, Scrum features shorter development cycles with smaller releases of added new features or new versions, as well as increased communication and collaboration over managers’ direction and documentation (Larman, 2004). Scrum has gained popularity in the industry, and many large organizations (such as IBM) have adopted it with the help of consultants.

From an organizational perspective, the biggest changes required for successful Scrum implementation are shifts in organizational structure and decision-making practices. Scrum requires a flatter organization, devoid of the middle-range managers who typically direct software-production teams. Instead, Scrum dictates that software-production teams be self-managed. Indeed, this is seen as the essential but most difficult part of Scrum to fully implement. One of the founders of Scrum, Schwaber (2004), describes cases in which Scrum implementation failed and then states: ‘Those examples show how easy it is for people to misunderstand Scrum … They don’t understand that Scrum involves a paradigm shift from control to empowerment, from contracts to collaboration, and from documentation to code’ (p. 26).

According to Scrum literature, the scheme is meant to organize software production as a collaboration between stakeholders and to minimize the need for management control for production. ‘Scrum Masters’ are chosen from among engineers and serve as the equivalent of project managers (Schwaber, 2004, p. 16), but they are meant to be facilitators, not managers, who serve only to help the team make decisions and mediate between upper management and the Scrum Team (Larman, 2004, p. 115.) The people who are engaged in actual production – including Product Owners (who represent customers and request what they need for the software), the Scrum Master, and the Team – have strong control over the output and schedule of work. All others, including managers, have to work through the team and have ‘no direct control over the project’s execution or progress’ (Schwaber, 2004, p. 15). In short, Scrum dictates that ‘although it might seem counterintuitive that Teams are managers, one of the central tenets of Scrum is that Teams handle their own management’ (p. 15).

Literature on the implementation of Scrum is largely found in Management Information Systems (MIS) research. This literature points to a large and stable trend in software production that recommends increasing software engineers’ self-management and minimizing management overhead. Thus, the challenge is seen as that of reorienting software engineers from individual work to self-managed teamwork. MIS researchers seem to agree that social factors are key to successful implementation. Moe et al. (2010), for example, note that ‘trust and shared mental models’ were important for a successful implementation of Scrum. Studies (e.g. Abrahamsson et al., 2003; Boehm & Turner, 2005; Nerur et al., 2005) indicate that most firms that decide to implement Scrum (or similar agile methods) have been operating under traditional, more hierarchical models of software production and that the transition is often blocked by the very ways that these previous work practices have affected the structure and culture of the organization. For instance, managers may continue to try to control the way software engineers plan their work, despite Scrum’s vision of empowerment, or they may fail to allocate the resources and time necessary for the team to self-manage its production (Cohn, 2010; Moe et al., 2010; Boehm & Turner, 2005).

Although MIS researchers seem to agree on the obstacles to implementing Scrum (Nerur et al., 2005), they are less clear on the actions to take to cultivate what Moe et al. termed ‘trust and shared mental models’. Abrahamsson et al. (2003) thus call for more empirical research that takes a deeper look at what goes on in the process of transition from traditional work models to Scrum. This article responds to that call by analyzing a case in which software engineers were unable to transition to the new interpretative scheme.

Settings

CIS is a well-known US-based international manufacturer of office-automation equipment (all company and individual names are pseudonyms used to ensure confidentiality). Its software-engineering division is made up of several business units, each of which includes many smaller teams. The teams are responsible for developing and maintaining software products that control the office-automation equipment that the company sells. The software engineering division consists of approximately 16 business units distributed across the country and abroad, but its two main offices are located in an East Coast city and in the large, post-industrial, West Coast city where I conducted my study.

The company enjoyed an almost complete monopoly on the market between the 1950s and the 1970s, but it now faces fierce competition from other companies in the United States and Northeast Asia. Office-automation equipment is now easily mass-produced, and its price has gone down sharply. Consequently, the software-engineering division has been under cost pressures that began in the 1980s but have intensified in recent years and have led to frequent layoffs of software engineers. Over the last 25 years, following the cancellation of large software projects and the emergence of offshore development, the organization laid off approximately two-thirds of its West Coast employees because these offices now have no managerial functions and only deal with production. The layoffs coincided with previous change efforts, as the firm tried to restructure and improve the software-engineering division at the same time. Remaining engineers were reassigned to form new teams in a new and completely restructured organization.

The quality of the software and the timeliness of new releases have also been sources of contention within the company. Because of the restructuring, layoffs, and reorganization, some software-development teams found it hard to maintain production quality and meet demands for cost and timely delivery. In one business unit, the executive decided to implement Scrum in hopes of increasing productivity and cutting costs without further layoffs. During the period of my field observation between 2007 and 2008, all the teams on the East Coast and three of the five teams on the West Coast were practicing Scrum. The two teams that did not adopt Scrum were excused because they did maintenance work rather than software development and their members’ seniority and expertise were stable.

I conducted field observations with two teams practicing Scrum within one business unit in the software engineering division. That business unit was responsible for manufacturing and maintaining all the software for a series of products. The business unit had ten teams: five on the East Coast and five on the West Coast. The five teams on the East Coast were responsible for most managerial functions and software development, while the five teams on the West Coast mainly developed particular functions of the software and maintained the software for older products. Each team consisted of approximately eight to 15 engineers, and in total, the organization employed about 70 software engineers in its West Coast offices.

The two teams I observed consisted of approximately 25 engineers, all of whom worked under one line manager. Their tenure in CIS varied, but the majority of them had been there for more than ten years; each team had a few engineers who had been hired recently and had worked for CIS for less than five years. In this article I distinguish four levels of hierarchy. I call the top manager of the software division the ‘executive’. I call the next level of managers, who were in charge of a particular subsystem and were responsible for about 60 engineers each ‘second-level managers’. ‘Line managers’ were directly responsible for one or two teams of engineers. ‘Software engineers’, more commonly called ‘engineers’, filled the largest part of the hierarchy. Since the corporation was large and had many product lines, it also included three to four layers of management above the ‘executive’ and up to the CEO, but since they are not directly relevant to my analysis here, they are not described.

My fieldwork started several months after the introduction of Scrum. The organization gradually started to introduce the new process beginning early in the summer of 2007, first experimenting by applying it to one small team. I made preliminary visits to the field site beginning in August 2007. I conducted fieldwork from January through December 2008, usually visiting the workplace two or three times a week for a full workday (eight to ten hours). Additionally, I conducted 28 in-depth interviews and numerous short, one-on-one casual conversations with engineers and managers. These interviews enabled me to discern what kinds of experiences and expectations software engineers and managers had before Scrum implementation and to track their changing opinions about Scrum.

While in the field, I observed how engineers and managers worked. I observed software engineering work, design meetings, managerial meetings, corridor communications, and conversations in informal settings. I had permission to study these processes with the management’s consent, and in return I was expected to share observations and insights into the changes that Scrum produced in the organization. The majority of the organization’s members were cooperative: they allowed me to observe their work, answered the many questions I asked, and sat for numerous informal interviews. I conducted one- to two-hour interviews with some of these managers and engineers to gain more insight into the organization and their experiences of Scrum’s ‘empowerment’ paradigm. Although I did participant observations and some in-depth interviews with managers, the vast majority of data I collected concerned engineers and their interactions. Thus, my analysis primarily focuses on engineers and their culture creation. I used the interviews with managers to understand the official accounts of organizational change and general perceptions regarding past productivity schemes.

I introduced myself to software engineers as a social scientist who was interested in organizational culture and was trying to understand the social aspect of software engineering. I was also a graduate student at the time, and the software engineers quickly began to refer to me as such – a graduate student trying to get a degree by conducting a thesis project. I thus gained the position of a harmless observer with whom workers could share their opinions and feelings about their work lives. Workers confided in me about their worries about Scrum and often told me about their career contingency plans (as well as worrying about my plans for after graduate school).

I was allowed to carry a notebook wherever I went, and I usually jotted down as many details as possible about conversations and interactions that I observed. I wrote field notes based on these jottings as soon as I left the field for the day. I was also allowed to audio-record formal meetings; thus, I audio-recorded and then transcribed the managerial and team meetings I attended, as well as all one-on-one interviews. I ended up with more than a thousand pages of interview transcripts and field notes, and I also drew on archival materials, including meeting minutes, email messages, company handbooks, and organizational charts.

I analyzed my field notes and documents using a grounded theory approach, closely following Emerson’s approach to inductive theorizing (see Emerson et al., 1995; Glaser & Strauss, 1967). Thus, I repeatedly coded field notes and interviews. In the first few rounds, I was engaged in open coding – themes included ‘choosing which task to work on’, ‘working in a common room’, ‘manager-engineer interaction’, ‘complaints about the team’, ‘who to ask for help’, and so on. As my coding progressed, I was able to reduce these initial themes to three analytic themes: ‘issues of hierarchy’, ‘memories of past productivity schemes’, and ‘talking about Scrum’. Subsequently, I chose the analytic theme of engineers’ group culture, because I realized that organizational memory had to be instantiated by engineers, since it was in interviews and conversations with engineers that this theme arose. Similarly, ‘issues of hierarchy’ were a problem precisely because engineers and managers found it so. Interaction among engineers was the key to understanding how the three themes connected and how Scrum was reshaping the organization. Once I decided on the project’s analytic theme, I reread all my field notes and interview transcripts to conduct more focused coding and then wrote numerous analytic memos to further develop the themes of interactional creation of engineers’ group culture and that culture’s relationship with organizational memory. I also continuously read theories of interactionism, ethnographies of work, and research on group culture before, during, and after the fieldwork period. This article is a product of an iterative process between data gathering, data analysis, and theorization (see Katz, 2001; Tavory & Timmermans, 2014).

The initial change: Background and summary

With the implementation of Scrum, old software development teams were disbanded and reformed as two ‘Scrum teams’. Engineers divided themselves into two teams so that their skills would be equally distributed without managers’ involvement. Engineers on each team were told to work as a team and to be self-managed and self-organized. They were provided a common area (called the Scrum room) as well as private offices, and they were strongly encouraged to work in the common area so that it would be easier to collaborate. A ‘burn-down chart’ on the wall of the common area depicted each team’s progress by displaying the number of hours the team expected to spend on each task. Each engineer was supposed to indicate their status on their task so all members would know what the others were working on.

Teams also had the authority to decide which and how much work to schedule within each two-week development period. They were to make these decisions based on a long list of prioritized tasks provided by ‘Proxies of Product Owner’ – technical experts who represented the company’s customers. After the team had decided what their tasks would be, they discussed and decided together both how much work each task would involve and who in the team would work on which tasks. Each team assigned one engineer to become a ‘Scrum Master’ who facilitated the team’s decision-making and worked to remove any obstacles (called ‘remove barriers’ in Scrum terminology) to meeting the delivery schedule (such as negotiating when to use testing machines, for example).

As teams were given more autonomy and decision-making authority, line managers’ roles diminished, as recommended by Scrum. Line managers were not allowed to direct engineers regarding the execution of software development and were only allowed to help them ‘remove barriers’ when explicitly asked to do so by engineers. They had two remaining roles: coaching interpersonal skills and evaluating the accomplishments of individuals.

Six months after Scrum was implemented, there was a reorganization. A new line manager, Josh, was brought in from another division of the company to manage the two teams. Additionally, a new second-level manager, Luke, moved up from managing two smaller teams that were not practicing Scrum to overseeing all West Coast teams, including the Scrum teams. Both managers and engineers knew Luke to have a ‘great track record’, but engineers did not know his attitude toward Scrum; all teams he had managed previously were not doing Scrum.

I begin my analysis in the next section by showing that the managers and engineers alike shared a memory of the organization as one that was always trying a new scheme to increase productivity, only to abandon it after a few years. This organizational memory, however, existed in the intertwining of remembering the past, understanding the present, and devising new actions. Therefore, in the subsequent section, I show how workers employed and constituted this organizational memory in interaction: together, engineers interpreted management decisions through the lens of the organizational memory and, by doing so, sustained collective uncertainty toward Scrum. I trace the situations of talk at work in which engineers collectively scrutinized management actions as potential signals of Scrum abandonment, cast doubt on the legitimacy of Scrum, and presented a lack of commitment to the productivity scheme.

Organizational memory among workers

One of the challenges of workplace change is rewriting the organization’s past (Anteby & Molnar, 2016). The introduction of new procedures inevitably requires new ways of making meaning, and new meanings must somehow be amenable to the organization’s narrative about itself. In CIS’s case, two elements of the past seemed to strongly influence how engineers interpreted the introduction of Scrum. First, the past authority-and-control system, in which each line manager directed ‘his’ team, provided a familiar prototype for interaction despite Scrum’s empowerment paradigm (see also Labianca et al., 2000). Second, engineers and managers alike remembered that CIS had implemented quite a few productivity schemes in the past decade, only to abandon them after a few years. Since the 1990s, CIS had tried at least three management techniques: CMM (Capability Maturity Model; see Paulk et al., 1995), Critical Chain (Leach, 2000), and Feature-Driven Development (see Palmer & Felsing, 2002). In the office, engineers and managers commonly referred to this organizational history of trying out different management ‘processes’ only to move onto the next one. Although Scrum was substantively different from the other processes that the organization had tried, what organizational members remembered was not the content of the schemes themselves, but rather that those previous ‘processes’ had come and gone.

Engineers and managers often mentioned CMM to me while we were discussing Scrum. CMM is a productivity scheme that involves documenting every process so that the best practices can be replicated and CIS had implemented this scheme in the late 1990s. At the time, CMM had been mandated throughout the organization. A task force had been created to apply CMM and ensure that the organization was properly certified. Yet, it had lasted for only three years – a short time relative to many engineers’ tenure – after which it had been replaced by a completely different productivity scheme. It had also resulted in some human resources turbulence. A veteran engineer and a second-level manager both described their bitter experience with CMM in separate interviews. A veteran engineer, who had worked for CIS for more than 30 years, shared in an interview how he felt about Scrum and the organization:

In this excerpt, the engineer describes the generalized ‘process’ as having been forced, having been of no help to engineers, and having died out within a few years. He then moves onto explaining the next ‘process’ he experienced in the organization: Feature-Driven Development. Although the two productivity schemes have little content in common, in the memory of the engineer, they formed a series of management fashions that did not work. In fact, Roger defended Scrum by saying, ‘I thought it made more sense than some of the other ones we did’. But his comparison also presumed that Scrum was one of many productivity schemes that he had experienced and would continue to experience at CIS.

The next excerpt – from Luke, a second-level manager – shows how he thinks about ‘the processes’ and, additionally, that he remembers the introduction of a new scheme as part of the company’s restructuring efforts. After discussing the layoffs and big restructuring of engineering units and projects, the line manager described when CIS started looking into ‘modern project management or modern development management or so on’:

Both Roger and Luke employ organizational memory to make sense of their current situation (Walsh & Ungson, 1991). Productivity schemes, by their account, do not help engineers actually do their work; Roger describes the decision to implement CMM as the result of a manager’s whim and connections. As this excerpt exemplifies, engineers and even managers commonly thought that CMM and other management techniques had ‘failed’ and did not hesitate to speak of them in such terms. Indeed, in a brief interview, Jack, the executive who had decided to try Scrum, told me that the reason he wanted to try Scrum was that the other processes he had tried had never worked.

Organizational memory of ‘processes that fail and go’ was quite commonly shared, and skepticism toward them was both common and openly held. The resulting resignation that engineers and managers alike felt toward ‘processes’ was complicated by the fact that these management techniques affected the careers and evaluation of engineers – in the worst case, in the form of layoffs. When the executive who had propelled CMM left, CMM was discarded without much official notice or contestation; as Roger said, ‘it faded away’. But in the resulting restructuring, the people who had left software production to implement CMM had been let go. An engineer mused to me during an interview, ‘Every Thanksgiving someone has to go, so it became like a tradition!’ And, as layoffs occurred, those who were engaged in the last productivity scheme – those who had stopped being engineers to become ‘process people’ – were targeted for removal because they were deemed less valuable in a critical moment of reorganization. Because the period when CIS was implementing and abandoning CMM coincided with the period when the firm was fiercely restructuring, no one could accurately estimate how many workers had been laid off because of their involvement with CMM. The result, however, was that workers’ stories of productivity schemes were tied to their stories of layoffs.

When Scrum was implemented, engineers wanted to know both who had decided to implement it and the degree of consistency that they could expect from the management – especially the second-level manager and line manager who directly supervised them – regarding the change. Thus, when there was a reorganization and a new second-level manager was assigned to overview the two Scrum teams I was observing, talk regarding the ramifications of the reorganization on Scrum was rampant throughout the organization. I asked an engineer what he thought of the reorganization. Interestingly, his reply revolved around the question of whether this new manager, Luke, seemed to ‘like’ or ‘not like’ Scrum. As the new scheme was considered to be potentially a passing fad, the engineer would not be certain about Scrum’s legitimacy unless he knew about Luke’s attitude toward it. This excerpt from my field notes begins with my description of Mel knocking on my office door:

After the announcement meeting, I went back to the office to write up a memo. Around 5:30, somebody knocked on the office’s door. The door was open, but Mel did it so that I would realize that I had a visitor. We chat a little bit, and then I ask him to explain the reorganization.

‘But you were in the meeting!’

‘Yes, but I understood only half of it’, I said.

‘Okay. So the biggest change for us is that now we have Josh instead of Tom. Tom is going to manage the team Josh was managing.’ We talked about a few other re-assignments of managers, and then the conversation moves to how he thought about Scrum. He said when Scrum started, it was very much Bill’s initiative. ‘Bill was very much into it, and he also wanted a flatter organization, as in the book of Scrum’, he said. ‘But I had mixed feelings about it. Some of it I liked. Other things I didn’t.’ He continues to explain his take on Scrum, and shifts again to the evaluation of changes.

‘The biggest change is Eric’, he continued. ‘For Tom, he just got another team. Josh as well, in his case, two teams each with 10–15 people. But Eric is going back to be an engineer’, he said. I wasn’t sure what to say. Eric was a Scrum Master of another team, but now he was assigned to be one of the engineers in another team. ‘I heard very nice things about Luke.’ He praised his new second-level manager. ‘Luke doesn’t seem to like Scrum so much.’

As the excerpt shows, the engineer took organizational decisions such as promotion and reassignment as indicators of the management’s evaluations and judgments about Scrum’s legitimacy. Because the teams were reassigned to Luke, who had not managed Scrum teams before, Mel decided that his new second-level manager took a certain distance from Scrum. Although all reassignments were given official explanations that had nothing to do with Scrum’s legitimacy, Mel saw them as having immediate ramifications that he needed to interpret. Specifically, two reassignments stood out to the engineers. First, Bill, who had championed Scrum, moved to a supervisory position over the Scrum process but lost the teams he managed to Luke. Second, Eric, who had been the line manager of a team, was reassigned to work as an engineer on another team. Mel treated both changes as demotions that should be interpreted as warning signs regarding Scrum’s slipping legitimacy. Engineers engaged in discussions about the reorganization, and the consensus seemed to be that Scrum’s legitimacy was being contested.

Later the same day, when I returned to my car, I found an engineer called Zian chatting with an engineer from another team:

I put everything in my bag and went to the parking lot. Zian and another engineer were standing just next to my car, chatting. ‘We were talking about the reorg’, Zian said. ‘Oh yeah! It was a big change, wasn’t it?’, I said. They seemed to reach to the conclusion that Scrum will not be practiced so much anymore. ‘Luke doesn’t like Scrum’, Zian said. ‘In a year we’ll not have any Scrum teams’, he pronounced. They continue talking about the human resources changes. They were talking about Eric going back to be an engineer. But in the end Zian shrugged his shoulders and said ‘the salary doesn’t change anyway, so why care about a demotion?’

In this excerpt, two engineers take for granted that some reassignments should be interpreted as ‘demotions’, despite the fact that the reorganization was not officially presented in such terms. The engineers seemed to fill in the gaps they saw in the official explanations of reorganization with their interpretation: that the ‘demotions’ of certain people who were practicing Scrum heralded the fall of the Scrum regime.

As these excerpts suggest, the engineers tied the company’s reorganization to its commitment to Scrum and subjected both to multiple discussions and reinterpretations. For the members of the organization, it went without saying that the reorganizations signaled certain demotions and promotions of people and a possible demotion of the productivity scheme at hand. The organizational memory of past productivity schemes and layoffs shaped engineers’ group perspective (Becker et al., 1977): they understood management techniques to be short term, personnel dependent, unlikely to help them accomplish tasks, and risks to their job security. Thus, rather than accepting Scrum and empowerment unproblematically, engineers saw it as one more ‘process’ that would soon be abandoned and acted to ensure that the fall of Scrum would not affect their well-being in the organization.

This perspective was not a static cognitive bias resulting from past personal experiences. Rather, it was created in situ as engineers recalled the organizational memory to make sense of the current implementation of Scrum. The perspective further helped create and maintain engineers’ culture by continuously assessing whether the management would continue to support Scrum. As I show below, meaning-making in interaction sustained engineers’ uncertainty and guided their dispositions toward Scrum. Engineers opted to show that they were engaged with the new productivity scheme only to the extent the management seemed to commit to it. Meanwhile, they kept watch, debating every single management act as a portentous sign of the future of Scrum.

A culture of uncertainty: Interactional creation of non-commitment

While the engineers’ perspective arose out of the organizational memory they embodied and their vulnerable organizational position as workers, it was through continuous interaction among the engineers that they produced a collective understanding of the fad-like nature of productivity schemes. The collective understanding then led them to avoid committing to Scrum. Talk at work thus not only enabled coworkers to work together by sharing important work information, but also shaped workers’ group identity: through talk, workers created collective meanings, including collective understandings of how to solve problems (Fine, 1984; Fine & Hallett, 2014; Orr, 1996).

The engineers at CIS constantly talked with one another – during meetings, in small talk while working, at the coffee room while heating their lunch, carpooling, and at other work and social occasions. In these conversations, engineers hashed over the smallest of cues to try to guess what management intended to do in the future; together, they interpreted the meanings of management’s actions. Thus, even when managers’ remarks did not explicitly concern Scrum and empowerment but instead addressed other technical or managerial issues, engineers read them as veiled signals that actually referred to the continuation or discontinuation of Scrum.

At one point, the managers on the East Coast decided to create a team to check the quality of the components of certain software features the company was developing. According to Scrum guidelines, however, it was supposed to be the job of each team’s ‘Proxies of Product Owner’ to define the design requirements and receive the delivered software. The change did not seem to accord with what Scrum books and consultants recommended. My field notes describe how engineers scrutinized this decision:

The change was significant for engineers because it had been made by the East Coast office – the management headquarters. Although the decision had come from the need to control a software program, the engineers interpreted it as a sign of Jack’s detachment from Scrum because Jack was deviating from what the Scrum manuals said. Since Jack would ultimately be responsible for the final verdict on Scrum for the whole organization, the engineers decided that the scenario ‘Jack kills Scrum’ had just become more likely. They quickly converged on the conclusion that ‘the management may not commit to Scrum’. Sam voiced their shared question when he said, ‘No, I’m asking … where is the link?’ It was the link between management’s action and their degree of commitment that the engineers were looking for and interpreting together. Engineers paid careful attention to signs from management, interpreted them together, and adjusted their commitment to Scrum accordingly. Their assumption that the management would abandon Scrum was renewed and vindicated every time they interpreted a management action as a potential signal of Scrum abandonment.

Because the engineers understood Scrum as something that the company was currently practicing and could abandon at any time, rather than a set of routines that they could follow uncontested, the question became how much they should follow Scrum practices. When the Scrum Master for the networking team was absent for training, the team members discussed dropping some Scrum practices and ‘read into’ a manager’s everyday remarks as part of making their decision. Mel, a mid-career engineer in his 40s, was serving as substitute Scrum Master for the week:

In the daily Scrum progress meeting, Zian and other engineers were gathering at the Scrum room. Mel stands up, and says ‘let’s Scrum.’ It started from Martin, making clockwise circle. In Zian’s report, he asked if they have retrospective [retrospective meeting, where teams share knowledge and solutions; essential in Scrum practices] today or not. They had not decided when due to some schedule conflicts. Mel said he will talk about it in his turn. After reporting what he did, he brought up that topic.

This excerpt shows how, in interaction with one another, engineers made sense of the current status of Scrum and engaged or disengaged with it accordingly. As the last section showed, engineers already had a particular frame of interpretation for productivity schemes, but it was in these kinds of recurrent interactions that they solidified their shared view of Scrum and made decisions about how to act in relation to it. When Zian proposed skipping a meeting that Scrum required, he supported his proposal by giving an example of a team that had already decided to skip the same meeting. Another engineer underscored Zian’s argument by observing that the second-level manager, Luke, did not seem to appreciate Scrum – a recurrent theme that would not have been salient if engineers believed Scrum would not be abandoned. In this case, the network team decided not to skip the meeting, but this interaction was one in a series of conversations in which engineers discussed whether and how to practice Scrum and its required strategies of empowerment.

Engineers, of course, had different opinions about Scrum. When I asked them about it individually, some of them replied favorably, stating that they like the teamwork and the opportunity to learn by taking on a new task or working with someone else. Others, on the other hand, said that Scrum did not work because it invited shirking and failed to account for individual engineers’ extra ability or effort. No matter what each engineer’s personal opinion of Scrum was, however, the engineers as a group used their collective understanding of Scrum’s position in the organization to guide their actions and reactions in given situations. In these collective interpretations and reinterpretations of management actions, Scrum seemed to have fluctuating and unstable legitimacy.

The next excerpt is a negative case: it shows how an engineer who tried to act in accordance with Scrum had to backtrack when faced with a situation in which doing so would have negatively affected how managers perceived him. David, who had been appointed as a Scrum Master, had difficulty interacting with managers when they did not share the same opinions about Scrum:

When I visited one of the Scrum teams, I found that one engineer was taken off the Scrum Master role, which was subsequently given to David by the line manager. Talking to David, he complained that the decision to make him Scrum Master was a top-down decision. That was not in accordance of Scrum principles, he thought. Subsequently, this topic was discussed with Luke, the second level manager, when they had a communication meeting. The meeting goes on and the topic of Scrum Master rotation is discussed. Luke asked what was wrong with the line manager’s decision.

David’s action is strangely contradictory at first sight. He raised the issue of Scrum violation with his superiors: he told them that their decision to make him Scrum Master did not accord with Scrum’s principle of empowerment while at the same time explicitly stating that he cared about Scrum only to the extent that the managers wanted it. Luke, the second-level manager, responded that, according to Scrum principles, the team should be able to have comfortable discussions without second-guessing the manager’s intentions and holding back their own ideas. After the meeting, however, David did just the opposite of what Scrum principles would dictate: he reported his actions to another manager who he thought could validate what he had said as Scrum Master. In his interpretation, voicing his objections to a manager at this meeting made him ‘the trouble guy’.

David’s actions make sense when we look at them from the engineers’ perspective: they thought that they should engage with Scrum – because they had been instructed to – but they also thought that they should not be more committed to it than the managers were, since the managers might decide to abandon it in the future. Like the other engineers, David understood Scrum as potentially temporary and so tried to make sure that he was legitimately and properly empowered for both eventualities: Scrum’s continuation and its discontinuation. Mel, a mid-career engineer, succinctly summarized this perspective in an interview when I asked for his assessment of engineers’ commitment to Scrum:

I think people just wanted a clear direction. If it’s one way, let me know; I’ll work with it. If it’s the other, let me know; I’ll work with it. They want a direction, as opposed to someone saying some things and others saying other things. Of course, some people are more vocal than others, but I think in general people are fine as long as we know the directions. That’s the impression I got.

The engineers had created and maintained a shared understanding that all productivity schemes end sooner or later, and they scrutinized all management decisions as cues about Scrum’s legitimacy. As a result, their sense of Scrum’s legitimacy fluctuated, and they found it impossible to discern a single management ‘direction’. To put it differently, because the engineers could jointly interpret any and all management actions as early signs of potential Scrum abandonment, they were in a double bind of uncertainty. Precisely because they needed management’s constant reassurance of Scrum’s legitimacy, they could never actually get it. The engineers’ everyday interactions shaped and reshaped their understanding of Scrum in ways that guided their interpretation of work events. As a result, their conviction that Scrum would soon be undermined became a self-fulfilling prophecy: the engineers themselves undermined its legitimacy and refrained from committing to it, despite managers’ intentions to continue Scrum. The organization continued Scrum throughout my yearlong research period and for at least a year afterward, but Scrum never became institutionalized: the engineers continued to assume that the scheme would eventually, and inevitably, end, and oriented their behavior accordingly.