No abstract

Objective: Most current development methods argue that teams should self-manage. Our objective is thus to provide a better understanding of the nature of self-managing agile teams, and the teamwork challenges that arise when introducing such teams. Method:We conducted extensive fieldwork for nine months in a software development company that introduced Scrum. We focused on the human sensemaking, on how mechanisms of teamwork were understood by the people involved. Results:We describe a project through Dickinson and McIntyre's teamwork model, focusing on the interrelations between essential teamwork components. Problems with team orientation, team leadership and coordination in addition to highly specialized skills and corresponding division of work were important barriers for achieving team effectiveness. Conclusion:Transitioning from individual work to self-managing teams requires a reorientation not only by developers but also by management. This transition takes time and resources, but should not be neglected. In addition to Dickinson and McIntyre's teamwork components, we found trust and shared mental models to be of fundamental importance.

Agile development methods were believed to best suit small, co-located teams, but the success in small teams has inspired use in large and very large-scale software development. However, fundamental assumptions of agile development are challenged when applying the methods at a very large scale. An interpretative revelatory case study on one of the largest software development programmes in Norway shows how agile methods were adapted and complemented with practices from traditional methods to handle the scale. The programme ran over four years with 12 colocated development teams and a total of 175 people involved. The case study was conducted retrospectively using group interviews with 24 participants and documents. Findings on key challenging areas are reported: customer involvement, software architecture, and inter-team coordination. The revelatory study also suggests refinements of a research agenda for very large-scale agile development. Empir Software Eng (2018) 23:490-520

No abstract

No abstract

Many organizations have turned towards globally distributed software development (GSD) in their quest for cheap, higher‐quality software that has a short development cycle. However, this kind of development has often been reported as being problematic and complex to manage. There are indications that trust is a fundamental factor in determining the success or failure of GSD projects. This article studies the key factors that cause a lack of trust and the effect of lacking trust and present data from four projects in which problems with trust were experienced. We found the key factors to be poor socialization and socio‐cultural fit, increased monitoring, inconsistency and disparities in work practices, reduction of and unpredictability in communication; and a lack of face‐to‐face meetings, language skills, conflict handling, and cognitive‐based trust. The effect of lacking trust was a decrease in productivity, quality, information exchange and feedback, morale among the employees, and an increase in relationship conflicts. In addition, the employees tended to self‐protect, to prioritize individual goals over group goals, and to doubt negative feedback from the manager. Further, the managers increased monitoring, which reduced the level of trust even more. These findings have implications for software development managers and practitioners involved in GSD. Copyright © 2008 John Wiley & Sons, Ltd.

No abstract

Abstract. Large projects are increasingly adopting agile development practices, and this raises new challenges for research. The workshop on principles of large-scale agile development focused on central topics in large-scale: the role of architecture, inter-team coordination, portfolio management and scaling agile practices. We propose eight principles for large-scale agile development, and present a revised research agenda.