Role clarity deficiencies can wreck agile teams

Background One of the twelve agile principles is to build projects around motivated individuals and trust them to get the job done. Such agile teams must self-organize, but this involves conflict, making self-organization difficult. One area of difficulty is agreeing on everybody’s role. Background What dynamics arise in a self-organizing team from the negotiation of everybody’s role? Method We conceptualize observations from five agile teams (work observations, interviews) by Charmazian Grounded Theory Methodology. Results We define role as something transient and implicit, not fixed and named. The roles are characterized by the responsibilities and expectations of each team member. Every team member must understand and accept their own roles (Local role clarity) and everbody else’s roles (Team-wide role clarity). Role clarity allows a team to work smoothly and effectively and to develop its members’ skills fast. Lack of role clarity creates friction that not only hampers the day-to-day work, but also appears to lead to high employee turnover. Agile coaches are critical to create and maintain role clarity. Conclusions Agile teams should pay close attention to the levels of Local role clarity of each member and Team-wide role clarity overall, because role clarity deficits are highly detrimental.


INTRODUCTION
The Agile Manifesto (Beck et al., 2001) suggests to "Build projects around motivated individuals. Give 25 them the environment and support they need, and trust them to get the job done." So agile teams need to 26 self-organize: Where a conventional team would have a manager who assigns tasks to people, defines team 27 work processes, and mediates conflicts that might arise among team members, an agile team needs to do all 28 those things themselves, perhaps supported by a coach who is supposed to catalyze the self-organization 29 processes. 30 The most widely used agile method, Scrum (Sutherland and Schwaber, 2016), which is our sole focus 31 here, is quite explicit about this. It has only three roles: Product Owner, who defines requirements; Scrum 32 Master, the coach; and everybody else, called the "development team". The overall team ("Scrum team") 33 is supposed to self-organize. Self-organization is at the very heart of the method; all formalized Scrum 34 method elements are merely tools for making self-organization easier. 35 There is plenty of evidence that self-organization is difficult (Barker, 1993;Hoda, 2011;Moe et al., 36 2008; Gren et al., 2017;Karhatsu et al., 2010;Hackman, 1986). Requiring agile teams to self-organize is 37 one of the most pronounced differences to previous forms of software development. Hackman (1986) 38 examined self-organized teams over decades long before agile software development. In those results, 39 being self-organized is not necessarily an advantage; there are low-performing as well as high-performing  Manuscript to be reviewed Computer Science Hoda et al., 2017), few works have considered self-organization as such and as a whole. Karhatsu et al. 47 (2010) states that autonomy, communication, and collaboration are the major components for building 48 self-organizing teams. Moe et al. (2008) find the division of labor that results from the specialized skills 49 of the team members to create a major self-organization hurdle. Hoda (2011) explains many different 50 phenomena observed in agile teams all in terms of self-organization. She describes balancing acts such 51 as specialization versus cross-functionality or continuous learning versus iteration pressure (Hoda et al.,52 2010). She also describes roles such as Mentor, Translator, or Coordinator which are also not based on 53 job description (Hoda et al., 2013). 54 In conclusion there is research about self-organized teams in general which shows that roles are 55 one input factor on performance of self-organized teams. There is research about the problems of self-56 organized teams in software development and there is research about roles in software development. What 57 is missing is how roles are helping or hurting in making self-organized software development teams work. 58 Since a few years, we have worked with agile teams and analyze how self-organization works or fails 59 to work. In our previous work (Barke and Prechelt, 2018) we focused on cross-functional collaboration. 60 Cross-functional teams do have a wide variety of roles (dependent or independent of job description). 61 In this first article, self orientation and team orientation were auxiliary concepts for some facet of the 62 cross-functionality problem. Focusing on these two concepts led to the present work which show how 63 clarifying roles in self-organized software development teams is critical for team surviving.

64
Contributions: We explicate the process by which Roles 1 are defined and what leads to Role clarity, 65 thus making that process visible, negotiable, and controllable for individuals and teams. We expect 66 our work helps practitioners reach Role clarity, allowing smoother day-to-day-work, reduced employee 67 turnover, and accelerated team maturation. The examples shown will hopefully motivate teams to pick the 68 process up.

69
As for the structure of the article, we start by describing our research method (Section 2). The core 70 part of the article presents the definition of role and the two core concepts in detail along with the evidence 71 that led to them (Section 3), followed by discussion of the findings, the related work and the application 72 for practice (Section 4). After a short discussion of limitations (Section 5), we formulate the take-home 73 message (Section 6).    87 We used Theoretical Sampling (Charmaz, 2014, p. 195 were made during feedback meetings and discussions and were used to further differentiate some concepts.

105
In addition, more than 100 pages of hand-written notes reflect observations from team meetings where 106 participants did not like to be audio-recorded. These hand-written notes contain as much near-verbatim 107 language as possible to gain unbiased raw data even without audio recording it.

108
The longest research collaboration with one team (t2) lasted 11 months. All teams stated they work 109 with Scrum, which was the only property they all had in common. Other than that, they represent a wide 110 spectrum as shown in  Comparison, and Theoretical Sampling. We now explain their interplay by means of Figure 1, which 141 shows the practices (as rectangles) and the resulting concepts obtained with them (in red). Theoretical Sensitivity and were subsequently tested in the analysis (iterative cycle).

160
In this paper we restrict ourselves to a small selection of concepts that help to tell and understand   towards written language during translation. We guaranteed anonymity to the interviewees and teams 167 such that quotes can not be traced back to them, so we cannot give public access to all of our data.

168
Our discussion is structured around grounded and generalized phenomena, not around specific people 169 or teams as a case study would do it.   Our results characterize steps needed to achieve Local role clarity and Team-wide role clarity and also 198 how teams can fail to achieve them. The narrative results points out that Role clarity is difficult, because 199 it requires two steps, each having multiple substeps, and any missing substep tends to make clarity 200 unachievable. 201 We refer to the following process when we discuss the team episodes we use for grounding and 202 illustration (see also figure 2):  • knows how to support M in it (team-support). to learn about new tricks."" (t5sm1) ) and so the team saw a better overall perspective for him.

282
This shows how R2-Expertise and R3-Acting can be a problem as well -not because of a lack of 283 technical competence (R2-Expertise), but as a hurdle for Team-wide role clarity: Successful negotiation 284 of Roles enables a team to do its job with whatever level of technical competence is available at the time, 285 but forming joint expectations about R3-Acting may involve conflict, which is created for instance from 286 perception differences or preference differences.

287
The first two substeps of Team-Reflection towards Team-wide role clarity mirror the substeps of

296
Having Role clarity has several positive effects for the team and each team member.  Team-Reflection are aligned and Role clarity is gained. This led to tailor-made help for t3dev3 to grow 310 R2-Expertise as follows. In a team meeting, the team considers many possibilities and their constraints:

311
(1) t3dev3 has stated that he wants to contribute to the team's output, so he wants to work on complete 312 tasks.

313
(2) The next sprint will start new things in green-field fashion so other team members will be learners as 314 well.

315
(3) The team could plan fewer tickets to allow for pair programming, so t3dev3 could learn a lot and the 316 language barrier could be lowered.

317
(4) However, t3dev3 likes to work out an overview and understanding by himself, so this idea is 318 postponed.

319
(5) t3dev3 has sometimes stopped asking questions when they were not answered on first try.

320
(6) The team encourages t3dev3 to perhaps submit questions in writing and 321 (7) also ask more questions, because more things are unclear for more team members in the future anyway. Manuscript to be reviewed

Computer Science
We do not know how the situation played out eventually, but it is obvious from these observations that 323 without the team's concerted attempt at understanding how to support t3dev3 in his Role, it would have 324 been more difficult to make him productive; this corroborates that self-organization becomes difficult 325 when Team-wide role clarity is low.

327
The following episode illustrates an interesting aspect of Team-wide role clarity: Increasing Team-wide 328 role clarity can make a team more robust and resilient against dysfunctional or even destructive behavior 329 of a team member.

330
An example: In an act of Self-reflection, one day t4dev3 decides it is time for him to move on in his 331 career: He wants the role of a team lead and assign tasks to others. He speaks with management, who 332 denies him such a role, as it would be alien to the agile work style. As a consequence, t4dev3 starts 333 disrupting meetings or staying away from them.

334
His team colleagues are confused, because they do not know the reasons for his dysfunctional behavior.

335
The coach t4sm2 makes this behavior a topic of the next retrospective. t4dev3 explains that it is a 336 conscious tactic to make management take him out of the agile context and give him a team lead role.

337
The coach reports: The fate of t2test3 was the same as the one of the disrupting team member t4dev3 or the one who 372 believes he is a high-performer (t6dev2): They all were asked to leave the company even though they 373 were technically skilled. These were not the only cases of people from our teams leaving their company. 374 We saw five cases overall 5 . With only one exception, roles issues were involved and played a major part 375 5 including in teams t2 and t3 that generally had long member tenures.

Manuscript to be reviewed
Computer Science in the event: Either a team member lacked Self-Reflection, or a member performed Self-Reflection, but did 376 not communicate their expectations to the team, or the team was unable to create consensus about a role 377 (Team-Reflection). 378 We conclude that a lack of Team-wide role clarity frequently leads to loss of team members, which may 379 sometimes be helpful for the team, but more often will be a major concern for the teams and companies 380 involved, because capable software development people are scarce. (E3) the negative emotional subtext in the extremely-unclear-role case of t2 is difficult to overlook. 386 We even encountered one episode that had the emotional aspect at its very center:

387
(E4) t5dev1 is very unhappy with some aspects of how t5dev2 acts in his role. After some time, he took 388 the courage to unannouncedly visit t5dev2 at home in the evening to invite him to a beer and No. 14:

389
"confess" (t5dev1) his feelings. When t5dev1 confronted t5dev2 with his troubling work behavior, he 390 was not surprised of the behavior itself at all; he was aware that he acted in this manner. But he was quite 391 surprised by t5dev1's negative feelings about it. So t5dev2 had Self-Reflection, but for t5dev1 it was 392 an emotional hurdle to trigger Team-Reflection and "confess" his feelings.

393
In the longer term, the dynamics of this role conflict were explosive: t5dev1 does not follow up the 394 resolution of the conflict and falls silent again until eventually he has an emotional outburst and leaves the 395 team and even the company. But t5dev1 (just like t5dev2) was a key technical person in that team; over 396 the course of a few months, the whole team dissolves and all members except one also leave the company. Here, we summarize our findings, discuss how they relate to earlier research, and give some ideas how 403 they might be used to improve software practice.    planning. This makes planning a crucial moment in the roles-finding process (and many of our episodes 480 illustrate this), so paying attention to this aspect of planning will likely pay off highly.

481
Some team members fail at (or do not even attempt) Self-Reflection and then coaches need to work 482 with them individually. More often, however the reflection difficulty occurs at the team level and coaches 483 can then use natural situations for their interventions, such as planning, story refinement steps, and of 484 course retrospectives. In any case, Team reflection about roles appears to be a near-continuous need.

485
When we discussed our results with agile coaches and non-coaches from outside our teams, they 486 agreed that making the process explicit ought to be helpful for practitioners, because they can then replace 487 intuitive action with rational action and explicit discussion. work illustrates dynamics that are sure to exist (due to grounding), the explanation of those dynamics may 502 be incomplete; it is not a full theory.

503
Generalizability: All our teams were Scrum teams, making generalization to other styles of agile 504 development less reliable (although we are optimistic in that respect). All our teams were German teams.

505
Further studies need to check where the results do or do not apply to different work cultures.

506
Validity: In contrast to the team member interview data, the statements of the consultants could not 507 be validated by direct observations or other triangulation.

508
Representativeness: Most of our concepts are grounded in only a small number of instances. There-509 fore, they are likely to miss a few elements that are in fact common.

510
Quantification: As with any GTM study, the grounding can only provide existence evidence, but 511 cannot measure the relative commonality or importance of different phenomena. A GTM-based study is 512 inherently unsuitable for quantifying phenomena, because no representativity must be assumed. However, 513 it is striking that we found relevant role-clarification dynamics in all of our teams and did so without 514 ever looking for them actively -we found these concepts only by deeper analysis of data we had already 515 collected previously. So they appear to be common phenomena in agile teams.

517
As we have seen, issues with roles in self-organizing teams are diverse and having such issues appears to 518 be common. They can occur at a personal level (finding one's own role) or team level (agreeing on roles).

519
When they are present, they severely damage the team's self-organization capability and obstruct the  (and presumably crucial) in making these issues visible and helping the team resolve them. Resolving 522 roles issues has large practical as well as emotional benefits for the team. 523 We conclude that our concepts of Local role clarity (an individual is aware of a particular role for 524 themselves and accepts it) and Team-wide role clarity (each team member is also aware of their team 525 mates' roles, accepts them, and knows how to support them in fulfilling these roles) are worthy of a lot of 526 attention from agile teams. They provide lenses through which teams can address a sizable fraction of 527 their self-organization issues and are a helpful stepping stone for becoming a high-performance team.

528
Further work should validate the expectation that actively developing a notion of role clarity in a team 529 will lead to improved cooperation.