__________________________________________________________________________________________This research presents a systematic literature review of motivation in Software Engineering. The objective is to report on what motivates and de-motivates developers, and how existing models address motivation. The majority of studies find Software Engineers form a distinguishable occupational group. Results indicate that Software Engineers are likely to be motivated according to: their 'characteristics' (e.g., their need for variety); internal 'controls' (e.g., their personality) and external 'moderators' (e.g., their career stage). Models of motivation in Software Engineering are disparate and do not reflect the complex needs of Software Engineers in their different career stages, cultural and environmental settings.

No abstract

Original article can be found at : http://www.sciencedirect.com/ Copyright Elsevier [Full text of this article is not available in the UHRA]Motivation in software engineering is recognized as a key success factor for software projects, but although there are many papers written about motivation in software engineering, the field lacks a comprehensive overview of the area. In particular, several models of motivation have been proposed, but they either rely heavily on one particular model (the job characteristics model), or are quite disparate and difficult to combine. Using the results from our previous systematic literature review (SLR), we constructed a new model of motivation in software engineering. We then compared this new model with existing models and refined it based on this comparison. This paper summarises the SLR results, presents the important existing models found in the literature and explains the development of our new model of motivation in software engineering

The Open University's repository of research publications and other research outputs Collaboration and coordination in mature eXtreme programming teams

No abstract

a b s t r a c tAgile software development promotes feedback, discipline and close collaboration between all members of the development team, and de-emphasises documentation, 'big design up front' and hierarchical processes. Agile teams tend to be co-located and multi-disciplinary, and rely heavily on face-to-face communication and seemingly simple physical artefacts to support interaction. In this paper we focus on the functionality of two key physical artefacts -the story card and the Wall -which, individually and in combination, underpin the team's activity. These artefacts have two main roles -one which enables a shared understanding of requirements and one which facilitates the development process itself. We consider these roles from two perspectives: a notational perspective and a social perspective. This discussion shows how the two perspectives -the notational and the social -intertwine and are mutually supportive. Any attempt to replace these physical artefacts with alternative support for an agile team needs to take account of both perspectives, and the complex relationships between them.

Previous discussions of how User Experience (UX) designers and Agile developers can work together have focused on bringing the disciplines together by merging their processes or adopting specific techniques. This paper reports in detail on one observational study of a mature Scrum team in a large organization, and their interactions with the UX designers working on the same project. The evidence from our study shows that Agile development and UX design practice is not explained by rationalized accounts dealing with processes or techniques. Instead, understanding practice requires examining the wider organizational setting in which the Agile developers and UX designers are embedded. Our account focuses on the situatedness of the work by making reference to values and assumptions in the organizational setting, and the consequences that those values and assumptions had for practice. In this organizational setting, cooperation between the Agile developers and UX designers was achieved through ongoing articulation work by the developers, who were compelled to engage a culturally distinct UX design division. Based on this study, insights into culture, self‐organization and purposeful work highlight significant implications for practice. Copyright © 2011 John Wiley & Sons, Ltd.

Much of the knowledge used within an