The paper outlines a four-year journey of a software engineering team based in Bangalore, India, which transitioned from having the responsibility of different modules to complete engineering responsibility of the range of software products. The paper also talks about the proactive steps taken to transition to Scaled Agile Framework (SAFe)  successfully and discusses the challenges related to people and team culture. The paper also summarizes lessons learned from the journey.
Artificial intelligence (AI) is transforming care delivery and expanding precision medicine. This paper presents experiences of a 110-person, spread across three countries, involves multiple business units and external suppliers that successfully achieved multiple milestones. The product is an organization visionary software system, a mission-critical software system that conforms to stringent healthcare regulatory standards.
We are practicing three styles of coordination practices that brings a solution to communication challenges. We are also describing our experiences of SAFe practices, Spotify like team culture, and 'Psychological Safety' that that helps in time-critical situations.
The authors bring our experiences as a Program Manager, Project Manager, Quality Manager, and chief Architect who has been an integral part of the journey and establishing these practices over since the incubation stage of the referred product. These practices have helped to an extent where we have achieved regulatory acceptance and milestones successfully within aggressive time and taking steady steps towards where other business units are adopting our practices for managing multiple healthcare software systems.
We report on a longitudinal case study conducted at the Italian site of a large software company to further our understanding of how development and communication tools can be improved to better support agile practices and collaboration. After observing inconsistencies in the way communication tools (i.e., email, Skype, and Slack) were used, we first reinforced the use of Slack as the central hub for internal communication, while setting clear rules regarding tools usage. As a second main change, we refactored the Jira Scrum board into two separate boards, a detailed one for developers and a high-level one for managers, while also introducing automation rules and the integration with Slack. The first change revealed that the teams of developers used and appreciated Slack differently with the QA team being the most favorable and that the use of channels is hindered by automatic notifications from development tools (e.g., Jenkins). The findings from the second change show that 85% of the interviewees reported perceived improvements in their workflow. Despite the limitations due to the single nature of the reported case, we highlight the importance for companies to reflect on how to properly set up their agile work environment to improve communication and facilitate collaboration.
Despite the prevalence of global software Engineering (GSE), many companies continuously struggle to collaborate across geographical distance, nationalities, and languages. Prior research documents how the use of national cultural differences as an argument for failed collaboration is common amongst people working in GSE, which has made IT companies blind to the fundamental challenges of GSE work emerging upon the conditions for the actual conduct of work and practices undertaken by human actors. Based on an interventionist ethnographic study conducted within a Danish IT company, we present the results of attending to implicit bias as an approach to combat pervasive practices that deploy static cultural narratives and negative stereotypes in GSE. We find that implicit bias is a useful grip for moving discussions beyond negative cultural rhetoric and to reconsider the actual and locally situated collaboration-related problems that exist within organizations involved in GSE.
Software Ecosystem (SECO) comprises third-party developers cooperating and competing when contributing to a platform provided by a central organization (keystone). A keystone has invested in a Developer Relations (DevRel) internal team as a global business strategy to attract and engage a critical mass of third-party developers in producing and evolving contributions. For this reason, the DevRel team should promote social relationships among SECO actors and synergy among keystone' goals and developers' expectations. It can help to establish and sustain a competitive value creation network (VCN) within a SECO that must survive to inherit changes. However, it is still a challenge the way DevRel team can act on a SECO to better engage the developers' communities aiming to establish a robust VCN. In this paper, we advance on investigating the perceptions of 31 DevRel practitioners from large, medium and small-size companies based on seven countries about value creation in DevRel. We found 55 elements of value creation distributed in retention, efficiency, innovation, and complementarity. Based on our analysis, we contribute with a set of seven insights (feedback loop, loyalty program, roadmap enhancement, technical training, processes restructuring, innovative products, cost reducing) and a DevRel VCN that involves elements, suppliers and consumers. It fosters a common perspective for DevRel practitioners, keystones and researchers for designing strategies and a research roadmap.
Community smells are symptoms of organizational and social issues within the software development community that often increase the project costs and impact software quality. Recent studies have identified a variety of community smells and defined them as suboptimal patterns connected to organizational-social structures in the software development community such as the lack of communication, coordination and collaboration. Recognizing the advantages of the early detection of potential community smells in a software project, we introduce a novel approach that learns from various community organizational and social practices to provide an automated support for detecting community smells. In particular, our approach learns from a set of interleaving organizational-social symptoms that characterize the existence of community smell instances in a software project. We build a multi-label learning model to detect 8 common types of community smells. We use the ensemble classifier chain (ECC) model that transforms multi-label problems into several single-label problems which are solved using genetic programming (GP) to find the optimal detection rules for each smell type. To evaluate the performance of our approach, we conducted an empirical study on a benchmark of 103 open source projects and 407 community smell instances. The statistical tests of our results show that our approach can detect the eight considered smell types with an average F-measure of 89% achieving a better performance compared to different state-of-the-art techniques. Furthermore, we found that the most influential factors that best characterize community smells include the social network density and closeness centrality as well as the standard deviation of the number of developers per time zone and per community.
In globally distributed software development, many software developers have to collaborate and deal with issues of collaboration. Although collaboration is challenging, collaborative development produces better software than any developer could produce alone. Unlike previous work which focuses on the proposal and evaluation of models and tools to support collaborative work, this paper presents an interview study aiming to understand (i) the motivations, (ii) how collaboration happens, and (iii) the challenges and barriers of collaborative software development. After interviewing twelve experienced software developers from GitHub, we found different types of collaborative contributions, such as in the management of requests for changes. Our analysis also indicates that the main barriers for collaboration are related to non-technical, rather than technical issues.
We share the experience of a globally distributed software development organization in addressing the performance issues resulting from the increased complexity caused by rapidly changing market demands. We discuss the challenges caused by the complexity within the teams, which were characterized by the emergence of thinking in silos, reduced morale, and accountability for overall project results, and a reduction in trust. We outline our successful approach to restore performance, which centered on fixing the trust deficit. Over time, the team progressed and went on to surpass its previous high-performance levels. Eventually, the software release process became a non-event for the team.
Global Software Development has brought many benefits to the industry. On the other hand, it carries with it new challenges mostly regarding knowledge transfer. When new hires join a company, they should learn about the working process, organization structure and company corporate culture. Therefore, companies should be adopting strategies to manage and transfer knowledge to better support newcomers as well as to hire new members to increase the developer team due to massive demand. As we work in GSD scope, we use Wiki as an alternative for sharing knowledge and for helping newcomers learn about our software development process. However, newer members reported great difficulty during Wiki usage, due to a large amount of information, lack of information process and non-structural knowledge sharing. For this reason, we surveyed to understand which difficulties newer PLs members faced during wiki usage at Sidia R&D Institute. The results show important contributions to understand how their learning work process, difficulties to access wiki information caused by usability issues and knowledge management adequate. Despite it, one important finding is that Wiki did informal aid learning, but there is still plenty of room for improvement.
A large international engineering office in Germany needed to double in size in 12 months. We designed an onboarding programme within 3 months to help it do so efficaciously. We wanted to optimize for: fast iterations in the programme rollout, to keep the 'flywheel spinning' by reducing drag on current staff, rapid acceleration where new hires contributed quickly, and smooth integration where new hires adapted to the engineering, company, and country cultures.
To reduce drag we onboarded in cohorts and involved existing practitioners in the design and discussion. To encourage contributions quickly we built contributions into the sessions, we also streamlined IT Support. To help new hires adopt the culture we encouraged help and mentoring within and across cohorts.
For fast iterations, we incorporated existing islands of onboarding, involved local technical staff in design and delivery of hands-on training, and applied analytics to help improve the practice. And we launched early to bootstrap our learning and evaluation.
Our approach worked; new hires were able to make meaningful contributions within a week and they scored the onboarding programme positively (8.5 NPS).
Sourcing the right IT engineers is critical for project success. In recent years, two sourcing strategies have been grabbing attention: crowdsourcing and inner-sourcing. Each has their own good points and bad points. Crowdsourcing allows organizations to recruit IT engineers from outside on demand. However, organizations working on closed-source code with confidential information might be worried about security concerns (e.g., information leak). The other strategy, inner-sourcing, can make any IT engineer in an organization become a member of all projects by adopting open source software development practices. This improves the mobility of IT engineers between projects inside the organization. However, there is a limit to the types of IT engineers that one organization can have. In this report, we propose a hybrid sourcing approach. It integrates the two sourcing strategies to develop software - crowdsourcing and inner-sourcing. This approach distributes the development tasks to either software crowdsourcing or inner-sourcing according to task type. As a case study, we adopt hybrid sourcing approach for an industrial project. The project developed a web application system for a bus company. We evaluate the effectiveness and future issues of hybrid sourcing.
Lately, crowdsourcing has emerged as a viable option of getting work done by leveraging the collective intelligence of the crowd. With many tasks posted every day, the size of crowdsourcing platforms is growing exponentially. Hence, workers face an important challenge of selecting the right task. Despite the task filtering criteria available on the platform to select the right task, crowd workers find it difficult to choose the most relevant task and must glean through the filtered tasks to find the relevant tasks. In this paper, we propose a framework for recommending tasks to workers. The proposed framework evaluates the worker's fitment over the tasks based on worker's preference, past tasks (s)he has performed, and tasks done by similar workers. We evaluated our approach on the datasets collected from popular crowdsourcing platform. Our experimental results based on 5,000 tasks and 3,000 workers show that the recommendation made by our framework is significantly better as compared to the baseline approach.
SIDIA is an R&D Institute located in Manaus (AM) focused on research and software development. SIDIA works in partnership with the Global Device Manufacturer developing the Android operating system embedded in mobile devices (smartphones and tablets) for Latin America. This complex scenario involves the development of products in collaboration with partners in different locations to accomplish manufacturing schedules. This poses a challenge in managing software development projects. This experience report describes a tool-based approach aiming to improve the availability of resources (software and hardware under development) as well as the requirements management process. We also report the lessons learned and difficulties of adopting the tool-based approach in the software development process.
Developing Android mobile devices with geographically distributed teams can be arduous. SIDIA is an R&D institute that is responsible for research and development for the Brazilian and global market. SIDIA has clients around the world, and one of them is a mobile device manufacturer which embeds the Android operating system into such devices. To sell smartphones in all desired countries, some regulations must be adhered to. In Brazil and Colombia, one of the mandatory regulations by law is that every product must contain a User Instruction Manual (UIM), which helps users to figure out distinctive aspects and features of the product. Currently, the Android OS Version for mobile devices commercialized in America (Latin mobile devices) and UIM are developed and designed in cities from different states (Manaus, Amazonas - Campinas, São Paulo) from Brazil. Moreover, to design the UIM is necessary to have access to the physical device, so it must be shipped across distant cities. Due to logistical problems and bureaucracy in administrative processes, the device may take a long time to be delivered and, consequently, may delay smartphone manufacturing, causing financial damage. This experience report describes the lessons learned on developing and integrating a tool-based approach that allows users to remotely access a device thereby solving the physical device dependency problem and addressing specific requirements of the UIM development.
Context: Designing software is an activity in which software developers think and make design decisions that ultimately shape the structure and behavior of software products. Currently, designing software is one of the least understood activities in which software developers engage. In a collaborative design setting, distances such as geographic, cultural, or social distance can lead to socio-technical challenges that potentially affect the way software is designed.
Objective: To contribute to an increased understanding of software design, we investigate how geographic distance affects collaborative software design.
Method: To this end, we conducted a multiple-case study exploring in depth the design thinking of co-located and distributed software developers in a collaborative design setting.
Results: We find that, compared to co-located developers, distributed developers practice less problem space exploration and focus instead more on the solution space. This could be related to different socio-technical challenges caused by distributed collaboration, such as lack of awareness and common understanding.
Conclusion: Our findings contribute to an increased understanding as to how software design is affected by geographic distance. Developers engaging in collaborative design need to be aware that problem space exploration is reduced in a distributed setting, which would adversely affect the development achievement and therefore customer satisfaction.
Global Software Development (GSD) has been a trend as the software industry is experiencing increasing commercial globalization. On the other hand, working with distributed teams also face new difficulties and challenges, resulting from geographic separation such as time zone, culture, and activities synchronism. Sidia is a R&D Institute, located in Manaus-Brazil, that develops innovative software solutions on Android Platform in all Latin America. The institute works collaborating with Samsung Mobile Division, located in South Korea, and external stakeholders provided by Mobile Network Operators (MNO) from Latin America countries (e.g., Brazil, Mexico, Chile, Peru). For this reason, to meet the demands of MNOs, Sidia works in GSD environment. In this context, the project management process becomes difficult due to the coordination of many different stakeholders in a distributed environment, such as tracking requirements, wrong releases, tracking issues. To minimize these difficulties, we developed a tool to support our project management process, called Release Manager (RM). This paper describes the introduction of the RM Tool to improve management in distributed projects for the Android Platform Update.
In this experience report, we discuss the development of a solution that enables conflict-affected youth to discover and access relevant learning content. A team of individuals from a not-for-profit, a large multi-national technology company, and an academic institution, collaborated to develop that solution as a conversational agent named Hakeem. We provide a brief motivation and product description before outlining our design and development process including forming a distributed virtual team, engaging in user-centred design with conflict-affected youth in Lebanon, and using a minimum viable product approach while adapting Scrum for distributed development. We end this report with a reflection on the lessons learned thus far.
The emergence of Global Software Development (GSD) has led to certain difficulties in the life cycle of global projects, in addition to the traditional challenges of collocated development, particularly as regards Project Management (PM). These difficulties are caused by the geographical, linguistic and cultural distance among the members of the team, signifying that the project manager requires special skills with which to mitigate these issues. Bearing this in mind, this paper describes a serious game (SG), denominated as GLOBAL-MANAGER, whose objective is to provide training in the management of GSD projects. The game attempts to develop several skills in its players whilst simultaneously providing them with an immersive, pleasant and attractive experience. The skills developed are related to coordination, communication and control, which are three of the principal challenges in GSD.