Is Extreme Programming Just Old Wine in New Bottles

Merisalo-Rantanen, Hilkka; Tuunanen, Tuure; Rossi, Matti

doi:10.4018/jdm.2005100103

Cited by 53 publications

(21 citation statements)

References 62 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…For example, whilst Hilkka et al [15] found that tools facilitated fast delivery and easy modification of prototypes, amongst the core values of the 'agile manifesto' was a focus on "individuals and interactions over processes and tools" and a number of studies [16] emphasized the importance of organizational rather than technical factors.…”

Section: Context and Related Workmentioning

confidence: 99%

Industrial Adoption of Model-Driven Engineering: Are the Tools Really the Problem?

Whittle

Hutchinson

Rouncefield

et al. 2013

Lecture Notes in Computer Science

102

View full text Add to dashboard Cite

show abstract

Section: Context and Related Workmentioning

confidence: 99%

Industrial Adoption of Model-Driven Engineering: Are the Tools Really the Problem?

Whittle

Hutchinson

Rouncefield

et al. 2013

Lecture Notes in Computer Science

102

View full text Add to dashboard Cite

show abstract

“…Common to all agile methods is an emphasis on communication and the human side of software development (Merisalo-Rantanen et al, 2005). Conducting a daily stand-up meeting (DSM) is an important practice in the agile methods Scrum and Extreme Programming to improve communication in software projects.…”

Section: Introductionmentioning

confidence: 99%

The daily stand-up meeting: A grounded theory study

Stray

Sjøberg

Dybå

2016

Journal of Systems and Software

100

View full text Add to dashboard Cite

Context: The daily stand-up meeting is one of the most used agile practices but has rarely been the subject of empirical research. Aim: The present study aims to identify how daily stand-up meetings are conducted and what the attitudes towards them are. Method: A grounded theory study of the daily stand-up meeting was conducted with twelve software teams in three companies in Malaysia, Norway, Poland and the United Kingdom. We interviewed 60 people, observed 79 daily stand-up meetings and collected supplementary data. Results: The factors that contributed the most to a positive attitude towards the daily stand-up meeting were information sharing with the team and the opportunity to discuss and solve problems. The factors that contributed the most to a negative attitude were status reporting to the manager and spending too much time; both the frequency and duration of the meeting were perceived to be too much. Based on our results, we developed a grounded theory of daily stand-up meetings and proposed evidencebased guidelines on how to organize them. Conclusion: Organizations should be aware of the factors that may affect attitude towards daily stand-up meetings and should consider our proposed guidelines to improve the way the meetings are conducted.

show abstract

“…[96]. Indeed, according to 'Google Trends' [104], the terms 'user requirement' (or 'stakeholder requirement') receive six times less search interest than Agile's equivalent 'user story' term in 2015, whereas they [108]. Indeed, an Agile user story using Cohn's template of "As a <user type>, I want to <goal> so that <reason>" [94] could be interpreted such that the <reason> field maps to the concerns of URs, while the <goal> field maps to user-task-oriented SysRs.…”

Section: Discussionmentioning

confidence: 99%

Repetition between stakeholder (user) and system requirements

et al. 2015

View full text Add to dashboard Cite

Stakeholder requirements (also known as user requirements) are defined at an early stage of a software project to describe the problem(s) to be solved. At a later stage, abstract solutions to those problems are prescribed in system requirements. The quality of these requirements has long been linked to the quality of the software system and its development or procurement process. However little is known about the quality defect of redundancy between these two sets of requirements. Previous literature is anecdotal rather than exploratory, and so this paper empirically investigates its occurrence and consequences with a case study from a UK defence contractor. We report on a survey of sixteen consultants to understand their perception of the problem, and on an analysis of real world software requirements documents using natural language processing techniques. We found that three quarters of the consultants had seen repetition in at least half of their projects. Additionally, we found that on average, a third of the requirement pairs' (comprised of a system and its related stakeholder requirement) description fields were repeated such that one requirement in the pair added only trivial information. That is, solutions were described twice while their respective problems were not described, which ultimately lead to suboptimal decisions later in the development process and reduced motivation to read the requirements set. Furthermore, the requirement attributes considered to be secondary to the primary 'description' attribute, such as the 'rationale' or 'fit criterion' fields had considerably more repetition between UR-SysR pairs. Given that the UR-SysR repetition phenomena received most of its discussion in the literature over a decade ago, it is interesting that the survey participants did not consider its occurrence to have declined since then. We provide recommendations on preventing the defect, and describe the freelyavailable tool developed to automatically detect its occurrence and alleviate its consequences.

show abstract

Is Extreme Programming Just Old Wine in New Bottles

Cited by 53 publications

References 62 publications

Industrial Adoption of Model-Driven Engineering: Are the Tools Really the Problem?

Industrial Adoption of Model-Driven Engineering: Are the Tools Really the Problem?

The daily stand-up meeting: A grounded theory study

Repetition between stakeholder (user) and system requirements

Contact Info

Product

Resources

About