Subscribe to the gold package and get unlimited access to Shamra Academy
Register a new userA Grounded Theory of Cognitive Load Drivers in Novice Agile Software Development Teams
106
0
0.0
(
0
)
Added by
Daniel Helgesson
Publication date
2021
fields
Informatics Engineering
and research's language is
English
Ask ChatGPT about the research
No Arabic abstract
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 teams, 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.
rate research
Read More
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
Developing sustainable scientific software for the needs of the scientific community requires expertise in both software engineering and domain science. This can be challenging due to the unique needs of scientific software, the insufficient resources for modern software engineering practices in the scientific community, and the complexity of evolving scientific contexts for developers. These difficulties can be reduced if scientists and developers collaborate. We present a case study wherein scientists from the SuperNova Early Warning System collaborated with software developers from the Scalable Cyberinfrastructure for Multi-Messenger Astrophysics project. The collaboration addressed the difficulties of scientific software development, but presented additional risks to each team. For the scientists, there was a concern of relying on external systems and lacking control in the development process. For the developers, there was a risk in supporting the needs of an user-group while maintaining core development. We mitigated these issues by utilizing an Agile Scrum framework to orchestrate the collaboration. This promoted communication and cooperation, ensuring that the scientists had an active role in development while allowing the developers to quickly evaluate and implement the scientists software requirements. While each system was still in an early stage, the collaboration provided benefits for each group: the scientists kick-started their development by using an existing platform, and the developers utilized the scientists use-case to improve their systems. This case study suggests that scientists and software developers can avoid some difficulties of scientific computing by collaborating and can address emergent concerns using Agile Scrum methods.
Agile processes are now widely practiced by software engineering (SE) teams, and the agile manifesto claims that agile methods support responding to changes well. However, no study appears to have researched whether this is accurate in reality. Requirements changes (RCs) are inevitable in any software development environment, and we wanted to acquire a holistic picture of how RCs occur and are handled in agile SE teams in practice. We also wanted to know whether responding to changes is the only or a main reason for software teams to use agile in their projects. To do this we conducted a mixed-methods research study which comprised of interviews of 10 agile practitioners from New Zealand and Australia, a literature review, and an in-depth survey with the participation of 40 agile practitioners world-wide. Through this study we identified different types of RCs, their origination including reasons for origination, forms, sources, carriers, and events at which they originate, challenging nature, and finally whether agile helps to respond to changes or not. We also found that agile teams seem to be reluctant to accept RCs, and therefore, they use several mitigation strategies. Additionally, as they accept the RCs, they use a variety of techniques to handle them. Furthermore, we found that agile allowing better response to RCs is only a minor reason for practicing agile. Several more important reasons included being able to deliver the product in a shorter period and increasing team productivity. Practitioners stated this improves the agile team environment and thus are the real motivators for teams to practice agile. Finally, we provide a set of practical recommendations that can be used to better handle RCs effectively in agile software development environments.
Industry in all sectors is experiencing a profound digital transformation that puts software at the core of their businesses. In order to react to continuously changing user requirements and dynamic markets, companies need to build robust workflows that allow them to increase their agility in order to remain competitive. This increasingly rapid transformation, especially in domains like IoT or Cloud computing, poses significant challenges to guarantee high quality software, since dynamism and agile short-term planning reduce the ability to detect and manage risks. In this paper, we describe the main challenges related to managing risk in agile software development, building on the experience of more than 20 agile coaches operating continuously for 15 years with hundreds of teams in industries in all sectors. We also propose a framework to manage risks that considers those challenges and supports collaboration, agility, and continuous development. An implementation of that framework is then described in a tool that handles risks and mitigation actions associated with the development of multi-cloud applications. The methodology and the tool have been validated by a team of evaluators that were asked to consider its use in developing an urban smart mobility service and an airline flight scheduling system.
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 results. 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.
Log in to be able to interact and post comments
comments
Fetching comments
Sign in to be able to follow your search criteria
