Erin Friess
Abstract
Purpose: This exploratory study investigates the project management (PM) language used by Agile Scrum team members at a software development firm within their Scrum meetings.
Method: The meetings from three sprints were audio-recorded and all spoken exchanges were transcribed. A codebook was developed to assess for meeting function PM language. A correspondence analysis assessed the association of Scrum meeting type and PM language.
Results: The results of this exploratory study suggest that the Scrum team members use PM language in somewhat ritualized ways, particularly when some of the PM language is deployed. The correspondence analysis also suggests five associations between certain meeting types and certain PM language.
Conclusion: This exploratory study provides a baseline of in situ Scrum-based project management upon which other studies may build, which may become useful as future studies may expand to include Kanban and Scrumban. It also suggests that while this Scrum-based group uses some PM language in expected ways (i.e., team maintenance is associated with kickoff meetings), other uses are unexpected (i.e., planning language is not associated with planning meetings). These differentiations from the ideal Scrum PM process suggest that future research is warranted.
Keywords: Agile, discourse analysis, project management, Scrum, exploratory study
Practitioner’s Takeaway:
- Looking directly at the PM language used in Scrum meetings can be difficult, but it may be helpful to determine if Scrum teams are functioning in ways that run counter to Scrum practice.
- In these Scrum sprint meetings, the technical writer is primarily absent or silent. We need to consider whether technical writers should be part of the multi-disciplinary Scrum team or whether technical writers should work adjacent to but separate from the Scrum process.
In their 2015 analysis of technical communication job postings, Eva Brumberger and Claire Lauer found that project management was one of the most commonly requested competencies across all the studied categories, only behind written communication as the most requested competency in job postings (e.g., Brumberger & Lauer, 2015). Yet, despite the need for a project management skillset, little research has taken place in technical communication to ascertain just what these skills are (Dicks, 2013). Perhaps this is due in part to the fact that project management (PM) is not an inherently technical communication endeavor but an endeavor pursued and researched by a host of other fields, including organizational management, organizational psychology, and software engineering.
Regardless of the field, PM research has tended to focus on prescriptive theories and strategies of how PM should occur, often based on anecdotal experiences or hypothetical situations (e.g., Allen, 2015; Hackos, 2007; Kister, 2016; Ryle, 2014; Snyder, 2014) or on research collected through self-reported means, such as interviews, focus groups, or surveys (e.g., Drury, Conboy, & Power, 2012; Drury-Grogan, 2014; Moe, Aurum, & Dybå, 2012; Rasnacis & Berzisa, 2017; Špundak, 2014). These anecdotal and self-reported data only enable us to learn what participants think as they look back on prior activities; they do not provide insight into what happens as the process of project management unfolds. This study addresses that methodological gap by investigating the actual spoken words exchanged by team members of an Agile Scrum group in their standard Scrum meetings. I chose to investigate a group that has actively worked in a firm-wide Agile Scrum environment for the past decade, because Agile Scrum is a common PM structure for both software and non-software firms (The State of Scrum Report, 2017; Stringer, 2016). Furthermore, Scrum is an established framework as well as an increasingly important process for technical communicators (Fox, 2013; S. Johnson, 2014; T. Johnson, 2017a, 2017b). By looking directly at the PM and Scrum language used by the team members in three sprints, we can better assess how technical communication should be viewing and analyzing PM as a whole and Scrum in particular.
Specifically, this exploratory study of the PM language of team members at a software engineering firm aims to answer the following research questions:
RQ1: What kinds of interactionary project management language are used in Scrum meetings?
RQ2: When is PM language used in Agile Scrum meetings?
This project, by looking at what Scrum team members actually say and do, rather than what Scrum team members self-report to say or do, provides particular insight that isn’t possible through other research mechanisms. As an exploratory study, its purpose is not to identify definitive practices for Scrum or project management but to identify “patterns in data that one might not predict or assume” (Lam, 2016, p. 301). Such patterns may inform future research so that further self-reported or experimental studies might pursue areas of identified merit (Lam, 2016). Additionally, as an exploratory study, this project presents a baseline so that others who repeat the study may identify commonalties and differentiations across organizations. Further, this study may encourage practitioners to evaluate their own language usage in project management conversations.
In what follows, I will first conduct a literature review of PM and Agile Scrum, followed by a description of my discourse-driven methodology. I will then explore the findings and discuss the implications of the findings.
Review of Literature
In this literature review, I will first present an overview to Agile and Scrum before discussing Agile and Scrum from a project management perspective.
Agile and Scrum: An Overview
Agile and Scrum are frameworks for software development that, over time, have also been adapted to work in nearly any organizational environment (Conforto, Salum, Amaral, da Silva, & de Almeida, 2014; Larson & Chang, 2016; Waldock, 2015). Agile was created in the 1990s as a lightweight software development alternative to the heavyweight “Waterfall” approach of the 1980s (Cobb, 2011). Waterfall consisted of a “series of sequential phases that have to happen in sequence, and each phase cascades into the next” (Cobb, 2011, p. 5). In other words, Requirements would pass on the product to Design, who, upon completion, would pass along the product to Development, who would then pass along the product to QA, at which point the product would hopefully be ready to ship. Waterfall required much “upfront planning and control” with limited changes once the process began to ensure that the costs and schedule remained intact (Cobb, 2011, p. 5).
Agile removed much of that upfront planning and the sequential phases of work. Instead, Agile was presented as a “discipline that copes adaptively with rapid change through feedback learning loops that interactively create and incrementally deliver value” (Moran, 2015, p. 3). At the core of the Agile framework is that it “eschews specialists working to specifications, preferring instead to employ multi-disciplinary and highly communicative teams that share their experiences and tacit knowledge in order to gain consensus regarding the solution” (Moran, 2015, p. 4).
Scrum is a particular Agile framework that gives structure to the general Agile principles and beliefs set forth in the Agile Manifesto (“Manifesto for Agile Software Development,” 2001). In a Scrum environment, work “is performed in short, timeboxed iterations, which usually range from a week to a calendar month in length” (Rubin, 2012, p. 2). Then in each iteration, called a sprint, “a cross-functional team does all of the work—such as designing, building, and testing—required to produce a completed working feature” (Rubin, 2012, p. 2).
Within each sprint, there are typically three defined roles (product owner, ScrumMaster, and team members) who typically iterate within the structure of 4–5 types of meetings (Rubin, 2012; Schwaber & Sutherland, 2017; Sims & Johnson, 2012; “User Stories,”). First, in the planning meeting, which sometimes is combined with the kickoff meeting, the product owner, who is responsible for collecting user stories and ensuring the most return on investment out of the sprint team, decides which user stories will be presented in a sprint. User stories are “short, simple descriptions of a feature told from the perspective of the person who desires the capability, usually a user or customer of the system” (“User Stories,” para. 6). Then, “the team members doing the actual work are the ones who decide how much work they can take on” (Sims & Johnson, 2012, p. 38). In other words, the product owner tells the team members what needs to be accomplished, but then the team members have autonomy in completing the user stories. In the kickoff meetings, the user stories are refined, the story points (i.e., an estimation of the complexity of a particular user story) are assigned, capacity (i.e., the effort in terms of work hours) will be determined, and the ScrumMaster will be selected. The ScrumMaster is often a team member whose function, in addition to whatever their purpose is as a team member, is to help “everyone understand and embrace the Scrum values, principles, and practices” (Rubin, 2012, p. 185) and to remove impediments that may prevent team members from completing their user stories (Schwaber & Sutherland, 2017).
The daily stand-ups (sometimes called daily scrums) are 15-minute meetings scheduled and led by the ScrumMaster. In the daily stand-up, team members identify what they have done since the last stand up, what they will accomplish before the next stand-up, and any impediments in their way (Sims & Johnson, 2012). In the demo (or the sprint review), all stakeholders, including clients, view the outcome of the user stories (Sims & Johnson, 2012). And finally, in the sprint retrospective, the team dedicates time to “focus on what was learned during the sprint…and how that learning can be applied to make some improvement” regarding the internal Scrum process (Sims & Johnson, 2012, p. 43).
Ultimately, Scrum is a framework that attempts to better organize approaches to solving problems. Scrum is now the most common framework for Agile, with upwards of 89% of Agile firms employing Scrum (The State of Scrum Report, 2017).
Agile and Scrum from a PM Perspective
While Agile and Scrum were born in software development, their frameworks are now used across many fields and have been investigated empirically. Recent studies of PM that employ Agile and/or Scrum frameworks come from fields such as library science, information, IT, management, and engineering (Drury, Conboy, and Power, 2012; Dulock & Long, 2015; Kautz, Johanson, & Uldahl, 2014; Machado, Pinheiro, & Tamanini, 2015; Rasnacis & Berzisa, 2017; Stettina & Hörz, 2015). Many of these studies possess particular interest to this study. For example, Drury, Conboy, and Power explored how PM obstacles within Agile environments can sabotage an entire firm’s commitment to Agile (Drury et al., 2012). Serrador and Pinto found that the degree to which a team adhered to Agile principles during PM phases ultimately affected the perceived success of the project by all stakeholders (Serrador & Pinto, 2015). Stettina and Hörz found that the implementation and success of Agile PM at a lower level of a firm can enable successful implementation of Agile at a more global level (Stettina & Hörz, 2015).
However, these studies of Agile and Scrum, along with all other studies I found, save one, rely on self-reporting mechanisms, surveys, or interviews for data collection. Although these are appropriate mechanisms for assessing Agile or Scrum for PM, they may or may not accurately reflect actual Agile and Scrum practice and instead rely on the respondants to filter their perceptions of the process as they respond, usually after the fact. This methodological gap poses a problem for those who wish to understand how Scrum is actually used, rather than what respondents report on their Scrum usage. Only one study actually looks at a team conducting an Agile or Scrum sprint. In that study, the researchers observed every meeting during a six-week sprint, with field notes, not the spoken exchanges, being the object of analysis. In their observations, they found that geographic and cultural differences can affect the degree to which Agile can or will be followed (Embretsen & Hyder, 2017).
I found no study that investigated the actual spoken exchanges between team members within an Agile or Scrum environment. Discourse analysis “sheds light on how speakers indicate their semantic intentions and how hearers interpret what they hear” (Johnstone, 2008). Therefore, to address the methodological gap in the research, I aimed to evaluate the team’s use of project management from a discourse, rather than self-reflective, perspective to begin to understand how project management is carried out in a Scrum environment. Specifically, I aimed to identify both the kinds of PM language in Scrum meetings and when PM language is used in Scrum meetings in order to provide a methodological perspective other than self-reflection of how PM is used by team members in meetings.
Methodology
Broadly speaking, in order to answer my questions about what kind of PM language is used in Agile Scrum meetings and when that language is used, I audio-recorded and transcribed the meetings of Agile Scrum teams, I coded the language they used in these meetings for specific uses of PM, and I used discourse analysis and correspondence analysis to identify the relationship between the Scrum meetings and the PM language. Again, the purpose of this exploratory study was not to identify the best practice of PM or Scrum but to identify a real (not idealized) practice of PM that could then be used to prioritize and improve future research and to provide a baseline for future comparative studies. In what follows, I will detail the methods for data collection, the participants, and the coding procedures.
Data Collection
I audio-recorded three sprints of a mid-sized U.S.-based software engineering firm. I received permission from the firm to audio-record the sprint meetings as long as I did not use any meetings in which clients participated. Thus, due to the NDA agreed upon with the firm, I was not able to record the demos or several daily standups, as both types of meetings often included clients. Therefore, I did not include any standups in my dataset. Although the firm does have teams dedicated to new product development, the teams I recorded were working on feature development for existing software products. Each team member signed an IRB-approved informed consent form and completed a brief demographic survey prior to the recording of the meetings. The IRB identified that I would be audio-recording the data, transcribing and anonymizing the data, and then coding the data based on the anonymous transcriptions.
The three sprints were recorded during a 10-week period. All three sprints took 5 weeks, with Sprint 1 occurring first followed by two concurrent sprints (Sprints 2a and 2b). Sprint 1 consisted of six meetings, Sprint 2a consisted of three meetings, and Sprint 2b consisted of four meetings that I was allowed to record. The total number of hours team members spent in the recorded meetings for these three sprints (minus the daily stand-ups and the demo) was about 15 hours. The average meeting length was 69 minutes. The longest meeting was 133 minutes, and the shortest meeting was 23 minutes.
This group worked within a relatively common Agile Scrum sprint structure. Although some firms that implement Scrum combine planning and kickoff meetings into one meeting, this firm had separate planning and kickoff meetings (Schwaber & Sutherland, 2017). The planning and kickoff meetings for this firm were organized and led by the designer assigned by the product owner to the sprint. The planning meetings broadly consisted of an initial discussion of user stories, story points, and task assignments. The kickoff meetings typically followed the day after the planning meetings and refined the user stories, assigned story points, finalized task assignments, designated a ScrumMaster, and returned some user stories to the product backlog. Each day between the kickoff and the sprint demo, the ScrumMaster organized a daily standup. Daily standups were not to exceed 15 minutes. If there was any issue that appeared to exceed the parameters of the daily standup, the team members who were involved in the issue moved it from the stand-up meeting to what this team called a “maintenance” meeting (which is relatively uncommon in Scrum) (Schwaber & Sutherland, 2017). At the end of the sprint, the sprint conducted a demo for interested stakeholders. Planning meetings averaged 71 minutes, kickoff meetings averaged 77.5 minutes, maintenance meetings averaged 68 minutes, and retrospective meetings averaged 28 minutes.
Participants
The first sprint (Sprint 1) had 16 team members. The next sprint cycle consisted of two concurrent sprints (Sprint 2a and Sprint 2b). Members from Sprint 1 populated both Sprint 2a and Sprint 2b. Sprint 2a had a total of 13 team members with seven team members having been part of Sprint 1. Sprint 2b had a total of 14 team members with seven team members having been part of Sprint 1. Two high level members participated in all three sprints. A total of 27 unique team members populated the three sprints.
Job titles
The 27 team members held 9 different job titles: QA (10 team members), Developer (6), Architect (3), Designer (3), IT Engineer (1), Product Owner (1), Project Manager (1), Security Engineer (1), and Technical Writer (1). The breakdown of the job titles in each sprint can be seen in Table 1.
Table 1. Number of team members with each job title on each sprint
| Sprint 1 | Sprint 2a | Sprint 2b | |
|---|---|---|---|
| QA | 3 | 6 | 3 |
| Developers | 4 | 2 | 3 |
| Architect | 2 | 1 | 3 |
| Designers | 2 | 1 | 2 |
| IT Engineer | 1 | 1 | 0 |
| Product Owner | 1 | 1 | 1 |
| Project Manager | 1 | 1 | 1 |
| Security Engineer | 1 | 0 | 1 |
| Technical Writer | 1 | 0 | 0 |
Group distribution
All meetings were held in a conference room at the firm’s U.S.-based headquarters. However, that statement is complicated by the fact that the team was geographically distributed. One developer worked remotely entirely from India. He would call in to the meetings from his workspace in India. All remaining team members worked from the US. However, the firm also had a remote work policy available to most team members. This policy enabled team members to work from home three days a week; this policy was taken advantage of by most of the team members. Therefore, in many meetings, fewer than half the team members actually met face-to-face in the meeting room. While colocation of teams is perhaps desirable, it is common for Scrum teams to be geographically distributed (Schwaber & Sutherland, 2017; Woodward, Surdek, & Ganis, 2010). Team members were able to elect what days they would go into work, and thus there was no pattern of who met face-to-face and who did not. Further, on occasion, team members would be at the headquarters but would phone into the meeting from their desks so they could continue to work. During the period of my study, the percentage of team members meeting face-to-face in any given meeting ranged from 31% to 57%.
Coding Data
In order to assess the language used by the team during their sprints, I transcribed each meeting and then assessed the transcriptions for language related to PM language functionality. This codebook was based in large part on the hallmarks of language in the workplace explored by Holmes and Stubbe (Holmes & Stubbe, 2015). I used a modified grounded theory approach that I based on Holmes and Stubbe’s hallmarks while adding additional relevant codes as they emerged from the dataset (see Table 2 for a complete list of codes). Although this list contains items beyond the traditional nuts and bolts of project management, it does include items that prior research has suggested to be relevant for overall project success and, therefore, necessary for successful project management (Callahan & Brooks, 2004; Schulz, 2008). The unit of investigation was clauses, as spoken exchanges often do not take traditional sentence structures. This small unit of investigation also allowed for mutual exclusivity of the codes.
Table 2. Meeting functionality language
| Agenda |
| Appreciation |
| Decision-making |
| Humorous diversions |
| Indicator of agreement |
| Indicator of dissent |
| Keeping on track |
| Knowledge exchange |
| Non-decision-making negotiations |
| Planning |
| Progress summary |
| Questioning |
| Request |
| Small talk |
| Suggestion |
| Team maintenance |
| Technology maintenance |
After each meeting, I reviewed the codes and made modifications to redundant or muddled codes. After coding approximately half the dataset, I then conducted an inter-rater reliability assessment on the 17 codes defined by the codebook. An additional coder and myself independently coded a previously uncoded 10% of the dataset. The initial reliability of the PM functionality yielded a Krippendorf’s alpha of 0.75, which indicates good agreement. After modifications to the codebook, a subsequent coding of a different 10% yielded a Krippendorf’s alpha of 0.88, which indicates very good agreement. I then recoded all previously coded data as well as all uncoded data in accordance to the new codebook.
Results and Discussion
This exploratory study investigated the use of PM language in Scrum meetings by recording the actual exchanges between team members in those meetings. Here, I will take a closer look at the results stemming from that study.
RQ1: What kinds of project management language are used in Scrum meetings?
The most common functions of the language were in the form of knowledge exchanges (36.3% of the clauses coded for functionality), questions (18%), team maintenance (15%), and indicators of agreement (14.9%). Given their commonality, it isn’t surprising that every meeting had at least 12 occurrences of each of these functionalities. Furthermore, for the four types of Scrum meetings I observed, these four functions were the most common in every meeting. And in many ways, this result is not entirely surprising, as these mark specific ways in which the group was able to approach the user stories and make progress toward their state of doneness. It is perhaps surprising how proportionately little of the group’s overall language was dedicated to planning. This may be because, according to the coding scheme, language related to team immediate, in-the-moment needs were coded as “team maintenance,” while language related to future needs or action was “planning.” Nonetheless, it is surprising that the language related to what the team needs to do in the future only made up 5.1% of the team’s overall language use.
The least common usages were in the form of agenda items, introductions, non-decision-making negotiations, small talk, and progress summaries, with each consisting of no more than 1% of the coded clauses. Some of these functions are limited, because they are typically only put forth by the ScrumMaster, such as agenda items and introductions. Additionally, the ScrumMaster was typically the one who took the lead when it came to Technology Maintenance (“I don’t think y’all can hear me,” “I’m going to share my screen now”). Small talk may be limited due to the distributed nature of the team; indeed, nearly all off the small talk occurred between the team members who were co-located in the conference room. Only one small talk exchange took place between a distributed team member and a person in the conference room, and no small talk exchanges took place between two distributed team members.
RQ2: When is PM language used in Agile Scrum meetings?
In looking at the raw data of when the language is used, we find that planning meetings, both in total and on average, contained more language related to appreciation, planning, introductions, and technology maintenance than the other meetings. Kickoff meetings used more language related to agendas, requests, keeping on track, indicators of agreement, questions, and team maintenance than other meetings. These results are not entirely surprising, given that the point of planning and kickoff meetings is to identify what can be done during the sprint, how the work will be done, and what the goal of the sprint is (Schwaber & Sutherland, 2017). Thus, language related to questions, planning, and team maintenance makes sense. Further, technology maintenance was perhaps more of an issue in the kickoff and planning meetings simply because, typically, all members of the sprint joined the planning and kickoff meetings and the coordination of multiple technologies was complicated. Fewer members attended the maintenance meetings or the (supposedly required) retrospective meetings.
Maintenance meetings used more language related to humor, indicators of dissent, knowledge exchanges, progress summaries, and suggestions than the other meetings. Maintenance meetings were meetings that were established as issues arose in standups that would push the meetings to be longer than the expected 15 minutes. Therefore, language related to knowledge exchanges, dissent, and suggestion may be more apparent given the nature of the meeting. Retrospective meetings included more small talk than other types of meetings (although the overall usage of small talk was less than 0.2% of language used). For planning, kickoff, and maintenance meetings, knowledge exchanges were the most common type of PM language, while in retrospectives, indicators of agreement were the most common type of language.
To further analyze the data, I conducted a correspondence analysis (CA) on the data set to explore the relationship between the type of Scrum meeting and the PM language used by the group. CA is a “useful statistical method for analyzing and visualizing categorical data” (Lam, 2016, p. 299). Categories that contributed less that 2% of the data set were removed from the analysis (Lam, 2016). Based on the results of the CA, the variables (Scrum meeting type and PM language) were significantly associated (p<0.0001, X2 =1192.8). Additionally, the two variables (Scrum meeting type and PM language) explain 24.9% of the total inertia, which suggests that, while the coding scheme has reliability and explains about a quarter of the data variation, a more refined coding scheme (either with fewer or more distinct categories) may improve the inertia. Based on the decomposed inertia across dimension 1 (59.1%) and dimension 2 (27.4%), a 2-D interpretation is appropriate for the CA.
The results of the CA revealed that, in terms of meeting type, on dimension 1, maintenance meetings (62%) contributed more than average, while planning (61%) and kickoff meetings (34.3%) contributed more than average on dimension 2. It also revealed that, in terms of PM language, on dimension 1, indicators of dissent (12.1%), knowledge exchanges (16.9%), questioning (23.3%), suggestions (15.8%), and team maintenance (14.4%) contributed more than average, while on dimension 2, planning (23.9%), team maintenance (30.8%), and technology maintenance (26%) all contributed more than average.
The CA biplot (see Figure 1) suggests five associations. First, the biplot suggests three PM associations with maintenance meetings: knowledge exchanges (32.7% of knowledge exchanges were in maintenance meetings), suggestions (64.5%), and indicators of dissent (73.9%). Second, this biplot also suggests an association between the planning meeting and the technology maintenance language (60.2% of the technology maintenance language took place in the planning meetings). Finally, this biplot suggests an association between kickoff meetings and team maintenance language (68.7% of the team maintenance language occurred in kickoff meetings).
Interestingly, the biplot does not suggest an association between PM planning language and the planning meetings or the kickoff meetings. I mentioned previously that these teams used relatively little language regarding planning overall; nonetheless, we might expect whatever planning language that was used to be associated with kickoff and planning meetings, where “the work of the sprint is to be planned” (Sims & Johnson, 2012). However, the CA does not suggest an association. Further, we might expect that since the kickoff meeting has an association with team maintenance, the planning meeting would have a similar association with team maintenance. However, the data do not suggest this to be the case. Future researchers may wish to pursue further whether other teams have similar behaviors and why these two meetings, held at the beginning of a sprint in order to establish the sprint’s protocol, may have differing associations.
Therefore, the results of this exploratory study and correspondence analysis suggest that the PM used by the groups may, but not always, depend on the type of meeting was being held. These results suggest that some PM language is associated with particular meeting types, but several kinds of language are not associated with particular meeting types when we might expect them to be. We might expect more of an association between appreciation and suggestion language and the retrospective meeting (in which the Scrum Team “inspect[s] itself and create[s] a plan for improvements to be enacted during the next sprint”) than what the data suggest (Schwaber & Sutherland, 2017, p. 14). We may also expect more indicators of dissent in planning and kickoff meetings, in which members may disagree with early proposals, than what is represented here. As is the point for exploratory research, more research should be conducted to further identify how well the noted associations and absent associations appear in other groups. But this exploratory study has provided an initial empirical assessment of the deployment of PM language in situ and the baseline for future comparative evaluations as well as direction for self-reported measures.
A Closer Look: Team Maintenance
Given that the purpose of an exploratory study is to identify possible areas of future research, I will now take a closer look at team maintenance within this group’s Scrum meetings. Team maintenance referenced the meta-discussions related to the team. These are not discussions about, for example, how a particular client request would be handled in a particular environment. Instead, these are the discussions about the immediate “doing” of the sprint: Who is doing what task? What is each team member’s capacity? Are other team members needed in order to accomplish the user stories?
Team maintenance occurred in every meeting type. Kickoff and planning meetings had more references to team maintenance than maintenance and retrospective meetings. Kickoff meetings dedicated more discussion to team maintenance than planning meetings. On average, kickoff meetings spent 25% of the time dedicated to team maintenance, with some kickoff meetings dedicating as much as 59% of their time to team maintenance. Planning meetings spent about 10% of their time dedicated to team maintenance.
Language related to team maintenance occurred in relatively static locations depending on the meeting type. Team maintenance language was found throughout the kickoff meetings, though they clustered slightly more at the beginning and at the end of the kickoff meetings. Planning meetings also found team maintenance language clustered within the first 15 minutes and the last 15 minutes of the meetings. However, planning meetings had a unique 11–17-minute section that usually occurred 30–45 minutes into the meeting. In this timeframe, the project manager, who did not stay for the entirety of any meeting, would interject (“Hey y’all, hate to jump in”), gather information from the team regarding team function (i.e., capacity), and then depart the meeting. In maintenance meetings, language of team maintenance was only ever found in the last 10 minutes of the meetings. And in retrospective meetings language of team maintenance was only ever found in the first 5 minutes of the meetings.
These patterns suggest, then, that team maintenance is a routine function of the teams and the language associated with team maintenance is found in highly consistent places within each type of meeting. A follow-up survey may reveal how cognizant these team members are about their fairly ritualized usage of team maintenance language within these meetings.
A Closer Look: The Technical Writer
The purpose of this exploratory study was to find patterns of interest in the data, and, although this is outside the parameters of the research questions, one item stood out as particularly relevant for practitioners of technical communication: the absence of any meaningful data from the technical writer. The data from the technical writer are too brief to draw any substantial or generalizable claims about the role of the technical writer in a cross-functional Scrum team. The firm had a technical writing department, and technical writers were to take part in the Scrum process. In this particular firm, technical writers were part of their standard Scrum sprints. At least, they were supposed to be. Only Sprint 1 had a technical writer assigned to it. The technical writer spoke in only two of the six meetings, though he was present for five of the six recorded meetings. The two meetings in which the technical writer spoke were a planning and a kickoff meeting. The technical writer only spoke in 31 turns, which constitutes less than 0.5% of the turns in Sprint 1. Half of those turns were five words or fewer (e.g., “Oh, okay,” ‘Sounds good,” “I’ll have to check,” “I’ll get back to you”).
In the planning meeting of Sprint 2a, a developer asked if a technical writer had been assigned to the sprint. The following exchange then transpired.
Product owner: I asked [Technical Writing Lead] to give us someone with broadband [i.e., extra hours of capacity] and I never heard back.
Developer: Not like we usually have one anyway.
Indeed, a technical writer did not join Sprint 2a or Sprint 2b. However, in the Sprint 2a retrospective, the following conversation occurred.
Designer: You know that UI [user interface] change? You know maybe we should see what [technical writer] thinks in case they have their way they like to do this.
Developer: He does UI?
Designer: Oh! Maybe not.
It is apparent in these exchanges that the technical writer is not viewed as a necessary component to the Scrum process. His absence does not delay a meeting (something that would almost assuredly occur should any other team member fail to show up to a planning meeting). Further, the relative value of the technical writer to the team (does the technical writer do UI? Or documentation? Or something else?) is also in question. The developer and designer simply do not know enough about the functionality of the technical writer to know if a concern should even be forwarded to the absent technical writer at all.
The purpose of this study isn’t to locate technical writing’s place in Scrum. But from a PM perspective, the lack of technical writing involvement in this Scrum is noteworthy. Apparently, the technical writer is supposed to be a part of the cross-functional team, but it appears here that the technical writer is not part of the team the same way the developers, designers, and architects are. No aspect of any user story addresses documentation or help, no definition of done involves reviewing anything from a technical writing perspective, and the technical writer, while sitting in over five hours of meetings, barely has a voice. Indeed, Tom Johnson (2017), a prominent blogger of technical writing, suggests that attending these meetings puts technical writing in a “weak” and “passive” role:
When tech writers attend every meeting (even if 90% irrelevant) and contribute very little (because of the irrelevance), they’re essentially portraying themselves as a weak, passive role. What other role would attend every meeting just listening for some relevant piece of information while developers rattle on endlessly about issues irrelevant to docs? It demeans the status and importance of tech writers. (T. Johnson, 2017b, para. 69)
Using Johnson’s terms, this technical writer isn’t working in a Scrum team; he’s working with a Scrum team (albeit the team is uncertain about any aspect of the technical writer’s value). Indeed, as emphatically stated in the Agile Manifesto, working software is valued over comprehensive documentation (“Manifesto for Agile Software Development,” 2001). Nonetheless, although perhaps technical writing and documentation should be parallel endeavors to the Scrum sprint, in this sprint, it appears that technical writing is essentially ignored. As such, from a PM perspective, the language used (and not used) by the technical writer in those meetings reveals the technical writer as a misused resource. Yet, although the technical writer may have missed opportunities to establish value had he been invited to either of the second sprints, he may have been more valuable to the organization as a whole by completing the documentation needed for the sprint while not being embedded in an hour-long discussion in which he could (or chose to) contribute little, as represented in Sprint 1.
Conclusions, Limitations, and Future Research
This study is, to date, the largest study of the actual spoken language exchanges of Scrum teams in situ. In it, I investigated PM as conducted by team members in three Scrum sprints, and I found that three of the four meeting types (planning, kickoff, and maintenance meetings) were associated with particular PM language. Although the findings of this study are appropriate given the methods and the scope, the results are limited by factors that commonly affect exploratory workplace studies. First, I was limited in my NDA to meetings that did not include the client, a common limitation in workplace studies. Second, this exploratory study collected nuanced data for analysis, but the data was only collected at one site. However, the purpose of this exploratory study was not to identify generalizable best practices but to identify areas that should be prioritized for future research. In what follows, I identify several areas that this exploratory study suggests may be fruitful for future research.
First, and perhaps most obviously, additional research at additional sites that replicate this study would enable comparisons of Scrum PM language across organizations. This data collection is not easy. This study required 10 weeks of dedicated data collection while embedded at a firm, only after all parties (including the participants, management, and legal) agreed to the observations and recordings. But additional nuanced, recorded study would allow for PM language variations within Scrum meetings across organizations to be identified, which, in turn, may begin to allow for best practices to be formed.
Second, additional research at the same site may allow for longitudinal assessment of how PM language alters over time. Along those same lines, it may be useful to see if the associations between meeting type and PM language vary over time or vary based on ScrumMaster. Additionally, it may be useful to identify how Scrum language (i.e., story pointing, user stories, capacity) affects PM language. This study also suggests that a more nuanced look at how team maintenance language is deployed is warranted. In this instance, a survey or interviews may help to explain why team maintenance language was associated with kickoff meetings but not planning meetings and why planning meetings were not associated with either planning or kickoff meetings.
Furthermore, this study provides a baseline of not only how the study could be duplicated with other Scrum organizations but with organizations who do other Agile or Scrum-like PM, such as Kanban or Scrumban. Comparisons to this dataset may reveal that groups that profess to doing Scrum may, for example, actually be doing something more like Scrumban.
Finally, this study also suggests that more research of the function of the technical writer in the Scrum environment is warranted. Additional in situ research may reveal that the technical writer’s engagement in the PM language is idiosyncratic. Or maybe it’s not. Surveys and interviews may also triangulate the data to figure out more about how technical writers feel about their placement in Scrum teams and how others (such as designers, developers, and architects) feel about the technical writers as either being included or excluded from their Scrum teams. It may be the TPC community is uniquely positioned to develop a PM strategy that eliminates the passive, weak role for any position that technical writers currently occupy in Scrum.
This exploratory study has demonstrated the kinds of PM language Scrum team members at an organization use in their Scrum meetings and when they use that language. As an exploratory study, it has also identified several areas that warrant future investigation. As PM continues to be an integral part of technical communication, additional in situ research, like that explored in this study, will be needed so we can gain clearer understanding of the actual language processes that occur in the PM process and not rely solely upon participant-reported data for our best practices models.
Acknowledgements
I thank the University of North Texas’s Faculty Development Leave program for affording me the opportunity to conduct this research. I also thank my colleagues Ryan K. Boettger and Chris Lam as well as Ben Lauren and Joanna Schreiber, the guest editors for this special issue, for their feedback.
References
Allen, D. (2015). Getting things done: The art of stress-free productivity. New York, NY: Penguin.
Brumberger, E., & Lauer, C. (2015). The evolution of technical communication: An analysis of industry job postings. Technical Communication, 62, 224–243.
Callahan, K. R., & Brooks, L. M. (2004). Essentials of strategic project management. Hoboken, NJ: John Wiley & Sons.
Cobb, C. G. (2011). Making sense of agile project management: balancing control and agility. Hoboken, NJ: John Wiley & Sons.
Conforto, E. C., Salum, F., Amaral, D. C., da Silva, S. L., & de Almeida, L. F. M. (2014). Can Agile project management be adopted by industries other than software development? Project Management Journal, 45(3), 21–34.
Dicks, R. S. (2013). How can technical communicators manage projects? In J. Johnson-Eilola & S. A. Selber (Eds.), Solving Problems in Technical Communication (pp. 310-332). Chicago: University of Chicago Press.
Drury, M., Conboy, K., & Power, K. (2012). Obstacles to decision making in Agile software development teams. Journal of Systems and Software, 85, 1239–1254.
Drury-Grogan, M. L. (2014). Performance on Agile teams: Relating iteration objectives and critical decisions to project management success factors. Information and Software Technology, 56, 506-515.
Dulock, M. J., & Long, H. (2015). Digital collections are a sprint, not a marathon: adapting scrum project management techniques to library digital initiatives. Information Technology and Libraries (Online), 34(4), 5.
Embretsen, D., & Hyder, L. (2017). Scrum in global software development: An ethnographic case study of Scrum’s mitigation effects on global software development challenges. (Unpublished doctoral dissertation).
Fox, A. (2013). Agile and tech comm: Viewing Scrum from a writer’s eyes. Retrieved from https://techwhirl.com/agile-tech-comm-viewing-scrum-writers-eyes/
Hackos, J. T. (2007). Information development: Managing your documentation projects, portfolio, and people. Hoboken, NJ: John Wiley & Sons.
Holmes, J., & Stubbe, M. (2015). Power and politeness in the workplace: A sociolinguistic analysis of talk at work. London, UK: Routledge.
Johnson, S. (2014). Writing in an Agile world. Retrieved from https://www.agileconnection.com/article/writing-agile-world
Johnson, T. (2017a). Tech docs and Agile: Alternatives to integrating into engineering Scrums (Part 2). Retrieved from http://idratherbewriting.com/2017/08/04/part2_alternatives-to-agile-scrum-for-tech-writers/
Johnson, T. (2017b). Tech docs and Agile: Problems with integrating tech writers into engineering Scrums (Part 1). Retrieved from http://idratherbewriting.com/2017/08/04/part1_when-agile-doesnt-work-technical-writers/
Johnstone, B. (2008). Discourse analysis. Malden, MA: Blackwell.
Kautz, K., Johanson, T. H., & Uldahl, A. (2014). The perceived impact of the agile development and project management method scrum on information systems and software development productivity. Australasian Journal of Information Systems, 18, 303–315.
Kister, T. M. (2016). Improving the Information Development Process: A Refined Iterative Development Model. Technical Communication, 63, 186–211.
Lam, C. (2016). Correspondence analysis: A statistical technique ripe for technical and professional communication researchers. IEEE Transactions on Professional Communication, 59, 299–310.
Larson, D., & Chang, V. (2016). A review and future direction of agile, business intelligence, analytics and data science. International Journal of Information Management, 36, 700–710.
Machado, T. C. S., Pinheiro, P. R., & Tamanini, I. (2015). Project management aided by verbal decision analysis approaches: a case study for the selection of the best SCRUM practices. International Transactions in Operational Research, 22, 287–312.
Manifesto for Agile Software Development. (2001). Retrieved from http://agilemanifesto.org/
Moe, N. B., Aurum, A., & Dybå, T. (2012). Challenges of shared decision-making: A multiple case study of agile software development. Information and Software Technology, 54, 853–865.
Moran, A. (2015). Managing Agile: Strategy, implementation, organization and people. Cham: Springer.
Rasnacis, A., & Berzisa, S. (2017). Method for adaptation and implementation of Agile project management methodology. Procedia Computer Science, 104, 43–50.
Rubin, K. S. (2012). Essential Scrum: A practical guide to the most popular Agile process. Upper Saddle River, NJ: Pearson.
Ryle, F. (2014). Keeping score: A 9 step approach to managing any project. New York, NY: IIL Publishing.
Schulz, B. (2008). The importance of soft skills: Education beyond academic knowledge. Journal of Language and Communiation, 2(1), 146–154.
Schwaber, K., & Sutherland, J. (2017). The Scrum guide: The definitive guide to Scrum: The rules of the game. Retrieved from https://www.scrum.org/resources/scrum-guide
Serrador, P., & Pinto, J. K. (2015). Does Agile work?—A quantitative analysis of Agile project success. International Journal of Project Management, 33, 1040–1051.
Sims, C., & Johnson, H. L. (2012). Scrum: A breathtakingly brief and Agile introduction. Dymaxicon.
Snyder, C. S. (2014). A guide to the project management body of knowledge: PMBOK (®) guide. Newtown Square, PA: Project Management Institute, Inc.
Špundak, M. (٢٠١٤). Mixed agile/traditional project management methodology–reality or illusion? Procedia-Social and Behavioral Sciences, 119, 939–948.
The State of Scrum Report. (2017). Retrieved from www.scrumalliance.org/why-scrum/state-of-scrum-report/2017-state-of-scrum
Stettina, C. J., & Hörz, J. (2015). Agile portfolio management: An empirical perspective on the practice in use. International Journal of Project Management, 33(1), 140–152.
Stringer, M. (2016). Four reasons why Scrum is so popular. Retrieved from https://blog.soprasteria.co.uk/2016/01/22/four-reasons-why-scrum-is-so-popular/
User Stories. Retrieved from https://www.mountaingoatsoftware.com/agile/user-stories
Waldock, B. (2015). Being Agile in business: Discover faster, smarter, leaner ways to succeed at work. Boston, MA: Pearson.
Woodward, E., Surdek, S., & Ganis, M. (2010). A practical guide to distributed Scrum (Adobe Reader). Boston, MA: Pearson.
About the Author
Erin Friess is an Associate Professor of technical communication at the University of North Texas. Her research explores the discipline of technical communication, workplace communication, and usability/user experience. In 2016, her research was awarded the Rudolph J. Joenk, Jr. Award. Her research has appeared in IEEE Transactions on Professional Communication, Technical Communication Quarterly, and Journal of Business and Technical Communication. She serves on the IEEE Professional Communication Society’s Advisory Committee. She can be reached at erin.friess@unt.edu.
Manuscript received 30 December 2017; revised 5 February 2018; accepted February 6, 2018.