Autonomous agile teams

Today, many companies allow their employees to work from anywhere, which has changed how employees coordinate their work and align toward the same goals. Objectives and Key Results (OKRs) is a goal-setting framework applied in such distributed settings. This research aimed to investigate how OKRs are used in large-scale agile contexts. We interviewed team members and analyzed documents, including a survey. Our study's results provide both enabling and limiting situations that make team members' utilization of the framework either easier or more difficult. We found that OKRs aided knowledge sharing and improved transparency between teams. We present four strategies used for overcoming challenges and maximizing the benefits of using a goal-setting framework. An important takeaway is that companies that employ OKRs must support their employees, especially in defining key outcomes that align and encourage teams toward a common goal. CCS CONCEPTS • Software and its engineering → Software creation and management .

Background The COVID-19 pandemic triggered a natural experiment of an unprecedented scale as companies closed their offices and sent employees to work from home. Many managers were concerned that their engineers would not be able to work effectively from home, or lack the motivation to do so, and that they would lose control and not even notice when things go wrong. As many companies announced their post-COVID permanent remote-work or hybrid home/office policies, the question of what can be expected from software engineers who work from home becomes more and more relevant. Aims To understand the nature of home telework we analyze the evidence of perceived changes in productivity comparing office work before the pandemic with the work from home during the pandemic from thirteen empirical surveys of practitioners. Method We analyzed data from six corporate surveys conducted in four Scandinavian companies combined with the results of seven published surveys studying the perceived changes in productivity in industrial settings. In addition, we sought explanations for the variation in perceived productivity among the engineers from the studied companies through the qualitative analysis of open-ended questions and interviews. Results : Combined results of 7686 data points suggest that though on average perceived productivity has not changed significantly, there are developers who report being more productive, and developers being less productive when working from home. Positively affected individuals in some surveys form large groups of respondents (up to 50%) and mention benefiting from a better organization of work, increased flexibility and focus. Yet, there are equally large groups of negatively affected respondents (up to 51%) who complain about the challenges related to remote teamwork and collaboration, as well as emotional issues, distractions and poor home office environment and equipment. Finally, positive trends are found in longitudinal surveys, i.e., developers’ productivity in the later months of the pandemic show better results than those in the earlier months. Conclusions We conclude that behind the average “no change” lays a large variation of experiences, which means that the work from home might not be for everyone. Yet, a longitudinal analysis of the surveys is encouraging, as it shows that the more pessimistic results might be influenced by the initial experiences of an unprecedented crisis. At the end, we put forward the lessons learned during the pandemic that can inspire the new post-pandemic work policies.

Psychological safety has been postulated as a key factor for the success of agile software development teams, yet there is a lack of empirical studies investigating the role of psychological safety in this context. The present study examines how work design characteristics of software development teams (autonomy, task interdependence, and role clarity) influence psychological safety and, further, how psychological safety impacts team performance, either directly or indirectly through team reflexivity. We test our model using survey data from 236 team members in 43 software development teams in Norway. Our results show that autonomy boosts psychological safety in software teams, and that psychological safety again has a positive effect on team reflexivity and a direct effect on team performance.

There has been a recent increase in the use of agile coaches in organizations. Although the use of the job title is popular, empirical knowledge about the tasks, responsibilities and skills of an agile coach is lacking. In this paper, we present a systematic literature review on agile coaching and the role of the agile coach. The initial search resulted in a total of 209 studies identified on the topic. Based on our inclusion and exclusion criteria, a total of 67 studies were selected as primary studies. Our findings suggest that agile coaching facilitates the adoption and sustainability of agile methods and deals with agile adoption challenges. Agile coaches help in training and developing software development teams and all the stakeholders involved in the agile adoption process. The primary skills of an agile coach identified herein are leadership qualities, project management skills, technical skills, and expertise in agile methods. Based on the findings, it can be argued that agile coaches play a significant role in addressing challenges in an agile transformation such as resistance to change. Coaches focus on removing barriers to team autonomy in agile teams and making agile meetings more valuable.

Given the relevance of coordination in the field of global software engineering, this work was carried out to further understand coordination mechanisms. Specifically, we investigated meetings and the collaboration tool Slack. We conducted a longitudinal case study using a mixed-methods approach with surveys, observations, interviews, and chat logs. Our quantitative results show that employees in global projects spend 7 h 45 min per week on average in scheduled meetings and 8 h 54 min in unscheduled meetings. Furthermore, distributed teams were significantly larger than co-located teams, and people working in distributed teams spent somewhat more time in meetings per day. We found that low availability of key people, absence of organizational support for unscheduled meetings and unbalanced activity from team members in meetings and on Slack were barriers for effective coordination across sites. The positive aspects of using collaboration tools in distributed teams were increased team awareness and informal communication and reduced the need for e-mail. Our study emphasizes the importance of reflecting on how global software engineering teams use meetings and collaboration tools to coordinate. We provide practical advice for conducting better meetings and give suggestions for more efficient use of collaboration tools in global projects.

Context: There is an indisputable industrial need for highly skilled individuals in the role of software testers. However, little is known about the educational background of these professionals, their first contact with the role, their preferences in acquiring skills, the impediments they face, and their perception of the software testing role. Objective: In the current paper, we report on the background, skills, learning preferences, and role profiles as described by professionals in software testing, spanning over a significant number of industries, countries, and software development models. Method: We conducted 19 in-depth, semi-structured interviews with software testing practitioners, across eight industries. We performed a content and thematic analysis of the collected data. Results: The practitioners in software testing had diverse educational backgrounds, and their first contact with the testing role was accidental. Exploratory testing was the preferred testing technique, while curiosity was identified as the most important feature in their skill set. Our respondents collaborated extensively with the developers, whom they perceived as a learning source and symbiotic work partner. Conclusion: The professionals in software testing described their skills as a rather undefined heap of knowledge, increasing with each work task. They used mainly informal and hands-on learning approaches. They found it necessary for education providers to present information on software testing. Generally, companies assisted them well in their skill development but need to allocate sufficient time for the learning. We identified five specialties of the role: product owner in testing, UX tester, DevOps tester, test-script automator, and test-process coordinator.

When the value increases engagement, engagement increases the value.

Many companies have turned towards globally distributed software development in their quest for access to more development capacity. This paper investigates how a company onboarded distributed teams in a global project, and report experience on how to study such distributed projects. Onboarding is the process of helping new team members adapt to the existing team and ways of working. The goal of the studied onboarding program was to integrate Por-tuguese developers into two existing Norwegian teams. Further, due to the growing trend in utilizing globally distributed projects, and the challenge of conducting studies in distributed organizations, it is crucial to find good practices for researching such projects. We collected qualitative data from interviews, observations, Slack conversations and documents, and quantitative data on Slack activity. We report experiences on different onboarding practices and techniques, and we suggest guidelines to help other researchers conduct qualitative studies in globally distributed projects. CCS CONCEPTS • General and reference → Empirical studies; • Software and its engineering → Software creation and management.

The new generation of software companies has revolutionized the way companies are designed. While bottom-up governance and team autonomy improve motivation, performance, and innovation, managing agile development at scale is a challenge. We describe how Spotify cultivates guilds to help the company share knowledge, align, and make collective decisions.

Organizational management traditionally has taken care of all the important strategy, structure, and work-design decisions, as well as most of the ongoing decisions about work procedures. In large-scale corporations with many geographically distributed sites and high divisional detachment, such strategies are yet doomed to result in implementing irrelevant work methods and procedures that conflict with the local interests. As Tayloristic habits are disappearing, organizations willingly or unwillingly change their decision-making approaches to enable more participation and influence from the performers. These trends are associated with the rise of participation-based parallel structures, such as quality circles, task forces or communities of practice. In this paper, we present our findings from studying corporate-level communities by the means of a multi-case study at Ericsson. We found that the main hindrances are related to the limited decision-making authority of parallel structure, member selection and achieving representation across the organizational units. Our results suggest that parallel structures highly depend on the authority of the members within their local communities, and their ability to not only channel the dialog between the units they represent and the community, but also enable the active engagement of the unit in the community studies. As such, we believe that special attention shall be put on the ambassador role of the community members.

Coordination of teams is critical when managing large programmes that involve multiple teams. In large-scale software development, work is carried out simultaneously by many developers and development teams. Results are delivered frequently and iteratively, which requires coordination on different levels, e.g., the programme, project, and team levels. Prior studies of knowledge work indicate that such work relies heavily on coordination through "personal" modes such as mutual adjustment between individuals or through scheduled or unscheduled meetings. In agile software development processes, principles and work structures emerge during the project and are not predetermined. We studied how coordination through scheduled and unscheduled meetings changes over time in two large software development programmes relying on agile methods. Our findings include transitions from scheduled to unscheduled meetings and from unscheduled to scheduled meetings. The transitions have been initiated both bottom-up and top-down in the programme organizations. The main implication is that programme management needs to be sensitive to the vital importance of coordination and the coordination needs as they change over time. Further, when starting a program, we recommend to early identify the important scheduled meetings, as having enough scheduled meetings is important to develop a common understanding of domain knowledge.

Members of high performing software teams collaborate, exchange information and coordinate their work on a frequent, regular basis. Most teams have the daily stand-up meeting as a central venue for these activities. Although this kind of meeting is one of the most popular agile practices, it has received little attention from researchers. We observed 102 daily stand-ups and interviewed 60 members of 15 teams in five countries. We found that the practice is usually challenging to conduct in a way that benefits the whole team. Many team members have a negative experience from conducting the meeting, which reduces job satisfaction, co-worker trust and well-being. However, the practice can be adjusted and improved to empower teams. In this article, we describe key factors that affect the meeting and propose four recommendations for improving the practice.

Software testing is an integral part of software development that provides better-quality products and user experiences and helps build the reputation of software companies. Though software testers perform a role that requires specific tasks and skills, in-depth studies of software testers lag behind research studies of other roles within software development teams. In this paper, we aim to create a profile of testers by presenting an empirical analysis of the skills the industry currently needs. We analysed data from 400 job adverts in 33 countries. We mapped the skills on a taxonomy comprising test-related, technical, and domain-specific skills. In addition, we looked at the demand for educational attainment, relevant certifications, and previous experience requirements. Our findings show that employers are mostly interested in skills related to test planning and design, test automation, functional testing, performance testing, and progress reporting. One third of the job advertisers were interested in people with the skills to operate test execution tools. Selenium was the testing tool most in demand. The testers must have strong technical abilities, including programming skills in Java, C#, and SQL. Also, they must handle project management tasks such as estimation, risk management, and quality assurance. Employers do not emphasise domain-specific knowledge, which indicates that they consider testing skills portable across industries. One in seven job adverts asks for a software testing certification. Our study helps clarify the complexity of the testing job and outlines the capabilities one needs to fulfil a software tester’s responsibilities.

Virtual teams rely on enterprise social networking tools such as Slack to collaborate efficiently. While such tools contribute to making the communication more synchronous and support distributed agile development, there are several challenges such as how to interact with each other and how to balance the communication with other types of communication mechanisms such as meetings, e-mail, and phone. In this paper, we describe and discuss how a distributed global project used Slack. Some of the challenges we identified were related to language problems, using too much direct messaging when communicating, and unbalanced activity (33% of the users accounted for 86% of the messages). The positive aspects of using the tool were increased transparency, team awareness, and informal communication. Further, Slack facilitates problem-focused communication which is essential for agile teams. Our study stresses the importance of reflecting on how virtual teams use communication tools, and we suggest that teams decide on guidelines on how to use the tools to improve their coordination.

Members of high performing software teams collaborate, exchange information and coordinate their work on a frequent, regular basis. Most teams have the daily stand-up meeting as a central venue for these activities. Although this kind of meeting is one of the most popular agile practices, it has received little attention from researchers. We observed 102 daily stand-ups and interviewed 60 members of 15 teams in five countries. We found that the practice is usually challenging to conduct in a way that benefits the whole team. Many team members have a negative experience from conducting the meeting, which reduces job satisfaction, co-worker trust and well-being. However, the practice can be adjusted and improved to empower teams. In this article, we describe key factors that affect the meeting and propose four recommendations for improving the practice.

According to the principles articulated in the agile manifesto, motivated and empowered software developers relying on technical excellence and simple designs, create business value by delivering working software to users at regular short intervals. These principles have spawned many practices. At the core of these practices is the idea of autonomous, self-managing, or self-organizing teams whose members work at a pace that sustains their creativity and productivity. This article summarizes the main challenges faced when implementing autonomous teams and the topics and research questions that future research should address.