اشترك بالحزمة الذهبية واحصل على وصول غير محدود شمرا أكاديميا
تسجيل مستخدم جديدSelf-organising Roles in Agile Globally Distributed Teams
97
0
0.0
(
0
)
اسأل ChatGPT حول البحث
ﻻ يوجد ملخص باللغة العربية
The ability to self-organise is posited to be a fundamental requirement for successful agile teams. In particular, self-organising teams are said to be crucial in agile globally distributed software development (AGSD) settings, where distance exacerbates team issues. We used contextual analysis to study the specific interaction behaviours and enacted roles of practitioners working in multiple AGSD teams. Our results show that the teams studied were extremely task focussed, and those who occupied team lead or programmer roles were central to their teams self-organisation. These findings have implications for AGSD teams, and particularly for instances when programmers - or those occupying similar non-leadership positions - may not be willing to accept such responsibilities. We discuss the implications of our findings for information system development (ISD) practice.
قيم البحث
اقرأ أيضاً
Agile software developers are required to self-organize, occupying various informal roles as needed in order to successfully deliver software features. However, previous research has reported conflicting evidence about the way teams actually undertak
e this activity. The ability to self-organize is particularly necessary for software development in globally distributed environments, where distance has been shown to exacerbate human-centric issues. Understanding the way successful teams self-organise should inform distributed team composition strategies and software project governance. We have used psycholinguistics to study the way IBM Rational Jazz practitioners enacted various roles, expressed attitudes and shared competencies to successfully self-organize in their global projects. Among our findings, we uncovered that practitioners enacted various roles depending on their teams cohort of features; and that team leaders were most critical to IBM Jazz teams self-organisation. We discuss these findings and highlight their implications for software project governance.
Motivation: How immature teams can become agile is a question that puzzles practitioners and researchers alike. Scrum is one method that supports agile working. Empirical research on the Scrum Master role remains scarce and reveals contradicting resu
lts. While the Scrum Master role is often centred on one person in rather immature teams, the role is expected to be shared among multiple members in mature teams. Objective: Therefore, we aim to understand how the Scrum Master role changes while the team matures. Method: We applied Grounded Theory and conducted qualitative interviews with 53 practitioners of 29 software and non-software project teams from Robert Bosch GmbH. Results: We discovered that Scrum Masters initially plays nine leadership roles which they transfer to the team while it matures. Roles can be transferred by providing a leadership gap, which allows team members to take on a leadership role, and by providing an internal team environment with communication on equal terms, psychological safety, transparency, shared understanding, shared purpose and self-efficacy. Conclusion: The Scrum Master role changes while the team matures. Trust and freedom to take over a leadership role in teams are essential enablers. Our results support practitioners in implementing agile teams in established companies.
Agile software teams are expected to follow a number of specific Team Practices (TPs) during each iteration, such as estimating the effort (points) required to complete user stories and coordinating the management of the codebase with the delivery of
features. For software engineering instructors trying to teach such TPs to student teams, manually auditing teams if teams are following the TPs and improving over time is tedious, time-consuming and error-prone. It is even more difficult when those TPs involve two or more tools. For example, starting work on a feature in a project-management tool such as Pivotal Tracker should usually be followed relatively quickly by the creation of a feature branch on GitHub. Merging a feature branch on GitHub should usually be followed relatively quickly by deploying the new feature to a staging server for customer feedback. Few systems are designed specifically to audit such TPs, and existing ones, as far as we know, are limited to a single specific tool. We present Bluejay, an open-source extensible platform that uses the APIs of multiple tools to collect raw data, synthesize it into TP measurements, and present dashboards to audit the TPs. A key insight in Bluejays design is that TPs can be expressed in terminology similar to that used for modeling and auditing Service Level Agreement (SLA) compliance. Bluejay therefore builds on mature tools used in that ecosystem and adapts them for describing, auditing, and reporting on TPs. Bluejay currently consumes data from five different widely-used development tools, and can be customized by connecting it to any service with a REST API. Video showcase available at governify.io/showcase/bluejay
Objective: The purpose of this paper is to identify the largest cognitive challenges faced by novices developing software in teams. Method: Using grounded theory, we conducted an ethnographic study for two months following four ten person novice te
ams, consisting of computer science students, developing software systems. Result: This paper identifies version control and merge operations as the largest challenge faced by the novices. The literature studies reveal that little research appears to have been carried out in the area of version control from a user perspective. Limitations: A qualitative study on students is not applicable in all contexts, but the result is credible and grounded in data and substantiated by extant literature. Conclusion: We conclude that our findings motivate further research on cognitive perspectives to guide improvement of software engineering and its tools.
In globally distributed projects, virtual teams are often partially dispersed. One common setup occurs when several members from one company work with a large outsourcing vendor based in another country. Further, the introduction of the popular BizDe
vOps concept has increased the necessity to cooperate across departments and reduce the age-old disconnection between the business strategy and technical development. Establishing a good collaboration in partially distributed BizDevOps teams requires extensive collaboration and communication techniques. Nowadays, a common approach is to rely on collaboration through pull requests and frequent communication on Slack. To investigate barriers for pull requests in distributed teams, we examined an organization located in Scandinavia where cross-functional BizDevOps teams collaborated with off-site team members in India. Data were collected by conducting 14 interviews, observing 23 entire days with the team, and observing 37 meetings. We found that the pull-request approach worked very well locally but not across sites. We found barriers such as domain complexity, different agile processes (timeboxed vs. flow-based development), and employee turnover. Using an intellectual capital lens on our findings, we discuss barriers and positive and negative effects on the success of the pull-request approach.
سجل دخول لتتمكن من نشر تعليقات
التعليقات
جاري جلب التعليقات
سجل دخول لتتمكن من متابعة معايير البحث التي قمت باختيارها
