When software products and services are developed and maintained over longer time, software engineering practices tend to drift away from both structured and agile methods. Nonetheless, in many cases the evolving practices are far from ad hoc or chaotic. How are the teams involved able to coordinate their joint development?This article reports on an ethnographic study of a small team at a successful provider of software as a service. What struck us was the very explicit way in which the team adopted and adapted their practices to fit the needs of the evolving development. The discussion relates the findings to the concepts of social practices and methods in software engineering, and explores the differences between degraded behavior and the coordinated evolution of development practices. The analysis helps to better understand how software engineering practices evolve, and thus provides a starting point for rethinking software engineering methods and their relation to software engineering practice.

Even though agile methods have been flourishing in the last decades, their implementation in (globally) distributed arrangements still present hard challenges. Due to this tension, practices are either modified or added to compensate with the additional control required by the setup. In this paper, we present a case study about a company that managed to incrementally design a process that does not compromise the foundations of the agile philosophy by embracing the characteristics of distributed development. We show how a virtual work environment has been crafted by continuously improving practices and carefully selecting technologies to allow each team member to fully participate regardless of the actual physical location. Aware of the single nature limitation of the reported case, we present extensive information to frame the context allowing meaningful comparisons by researchers and providing concrete examples for practitioners.

Background: Agile and distributed software development are two trends that continue to increase rapidly in today's software industry. Even though the benefits achievable by combining them are potentially many, the intrinsic challenges of such marriage often lead to severe complications that can jeopardize the successful completion of software projects. Method: To investigate empirically how these two trends can coexist without compromising on the agile core values and principles, we conducted an exploratory holistic case study. Focusing on the development team of a Danish SME having both distributed offices as well as teleworking arrangements, we showcase (the evolution of) their practices. Results: The case is an example of the effective application of the agile reflective culture that allowed the company to evolve to a level in which the collocation restrictions of agile software development are overcome by a continuously evolving software process geared towards reducing waste to achieve speed and simplicity. Conclusions: Even though results need to be considered carefully due to the single nature of the reported case, we highlight five elements that have been fundamental in such journey: agile servant-leader, agile team, trust, virtual work environment, inspect & adapt, and reduce waste. Extensive information is provided to frame the context and to allow meaningful future comparisons.

Distributed software engineering and agility are strongly pushing on today's software industry. Due to inherent incompatibilities, for years, studying Scrum and its application in distributed setups has been subject to theoretical and applied research, and an increasing body of knowledge reports insights into this combination. Through a systematic literature review, this paper contributes a collection of experiences on the application of Scrum to global software engineering (GSE). In total, we identified 40 challenges in 19 categories practitioners face when using Scrum in GSE. Among the challenges, scaling Scrum to GSE and adopting practices accordingly are the most frequently named. Our findings also show that most solution proposals aim at modifying elements of the Scrum core processes. We thus conclude that, even though Scrum allows for extensive modification, Scrum itself represents a barrier for global software engineering, and development teams have to customize Scrum properly to benefit from agile software development in GSE.